PR: Many updates to third party file lists in NOTICE.txt #17003
Conversation
between the last Spyder 2.x release and 3.0.0b1.
…ommit: 2021-02-11 d90ef71 Also, correct the name of another pyQode-using file.
2021-03-15 c219148 in NOTICE.txt. Many images removed, and many images renamed. The WinPython logo section is removed as it is now redundant.
following commit: 2021-03-25 756f62c
commit, being replaced by custom icons: 2021-03-30 4f1e8e4
the following commit: 2019-05-20 f7e7c01
|
BTW, there were two changes that I couldn't track down precisely, presumably due to |
ccordoba12
changed the title
|
Wow, thanks @juliangilbey ! That's a ton of work (and would know, having spent several days effort putting the file together originally many years ago). Ideally we'd automate this with SPDX tags or something, but for now this looks good; I'll review it shortly. Thanks again! |
CAM-Gerlach
changed the title
There was a problem hiding this comment.
This looks great, @juliangilbey . I reviewed all your changes here, though I trust your judgement on the specifics of the file additions, moves and deletions—manually rechecking all of that would require redoing all of your hard work, haha!
Since we took the effort to meticulously record all of this, it might be worth putting it in a standardized, programmatically readable and updatable SPDX manifest or SBOM type format, but this looks good for now. Thanks again!
|
Thanks, @CAM-Gerlach, it was indeed a bunch of work! It was significantly helped by the file having a very consistent format, so I could write a simple script to translate the NOTICE.txt file into the format used for Debian's debian/copyright file; this did about 90% of the copy-pasting type work. Then There are a few files that still have some question marks about them:
Would it be worth opening an issue about this? It's obviously quite low priority, though. Best wishes, |
|
Sorry for all the work; once we finally implement SPDX expression support in the packaging ecosystem (see my PEP 639 PR python/peps#2164 ) this will be one complicated SPDX expression, heh.
I'm glad all that work (and my subsequent pedantic nitpicks of other PRs updating it) wasn't for nothing ^_^
Yep, correct. The files mentioned contain content from the named source under the mentioned license, but may and often do contain Spyder-licensed additions, modifications or original content.
Correct, and any changes to the BSD-3-clause code would be MIT also.
Yep, same.
I'm generally the most persnickety Spyder core dev when it comes to licensing, but is the fact that three different permissive licenses cover portions of a particular file instead of two (and the SPDX license expression would be the same complexity either way, The code for the two different components from two different sources is already cleanly separated into two different classes, with their source explicitly attributed in their respective docstrings, and this is also explained in detail in the file's license header and its module-level docstring. I'm not sure doing major refactoring to separate them would add any further additional legal clarity, as users still need to reference each file to see what code originates from Spyder and which from the external source, and the Git history as the canonical source of precisely what modifications were made. Maybe there's something I'm missing...could you explain in more detail how this creates a practical issue? |
|
I just had a look at the PEP 639 PR - wow, you've done a lot of work! I'm pretty fine with everything you've written; it all seems eminently reasonable (though I am not a lawyer). I only have one point of disagreement. You wrote: "Correct, and any changes to the BSD-3-clause code would be MIT also." But I don't believe that is permissible: the BSD-3-clause license specifically says that modified versions have to be licensed under the same conditions. It seems reasonable the other code written to support or use BSD-3-clause licensed code could have its own license, but the modified BSD-3-clause code itself must surely have to remain under the BSD-3-clause license? |
|
As a disclaimer, IANAL also, though I briefly worked for one, I'm sure like yourself I've long had a close interest and worked on a lot of copyright-related issues over the years.
There is a distinction here: The BSD still applies to the original work and the portions substantially derived from it, but as it is a permissive license, not a copyleft license like the GNU family, contributors are allowed to license their changes (as well as the combined work as a whole) under a different license (even a proprietary one), provided the conditions in the BSD license are still followed (therefore, those portions of code would be licensed The original code still remains BSD-3, but only without any substantial modifications made to it that were released under MIT instead, in which case both licenses apply. Therefore, a company who modified BSD-3 (or MIT, etc) licensed code could release it under a proprietary license and prevent others from using it with any of their modifications. The GPL and other copyleft licenses prevent this by requiring any changes to be released under the same license as the original work, so the company would not be able to do this unless they owned the original copyright. That is the fundamental distinction between copyleft and permissive licenses. So, yes, the modified code would remain under BSD-3, but the changes (the deltas) would be under MIT, so the particular code would be under both licenses. If all of the modified code were eventually replaced with substantially different changes, then it would be purely MIT (though the distinction there gets difficult to prove one way or the other in court). |
|
Ah, I did not appreciate that subtlety - thank you for the clarification. You are clearly more of a lawyer than me! I am then perhaps slightly mystified why some of the BSD-3 licensed code in Spyder has the modification licensed under BSD-3 (for example Sphinxify). But I don't think it's a significant issue. Best wishes, Julian |
|
Heh, well I can't speak for some of the other examples, but as for Sphinxify, that's a whole long story |
Description of Changes
NOTICE.txtis suffering from bit-rot; it hasn't been updated as files were removed (or, in at least the one case I accidentally found, added) to Spyder.I have checked that every listed file is still valid, and gone through the git history to locate the fate of those files which are not in the current (5.x) version. Some of them have been removed, some have been renamed, and in two cases, there was just a typo in the filename in
NOTICE.txt.I have addressed each change or group of changes in a separate commit on this branch, mostly one commit per original commit, and noted the original commit date and hash in the new commit messages. Every file listed in the resulting version of
NOTICE.txtin this PR is present in the current 5.x branch.Affirmation
By submitting this Pull Request or typing my (user)name below,
I affirm the Developer Certificate of Origin, clauses (a) and (d),
with respect to all commits and content included in this PR,
and understand I am releasing the same under Spyder's MIT (Expat) license.
I certify the above statement is true and correct:
@juliangilbey