Hi John, all, Finally getting back to this important issue after 3 weeks of traveling. As we have made some progress with preparations for the next release otherwise, I’m keen to try and sort out the final issues here, so we can include the resulting changes in this release as well. As it’s been some time, here is a link to my original summary to which others responded: https://lists.spdx.org/pipermail/spdx-legal/2017-October/002258.html <https://lists.spdx.org/pipermail/spdx-legal/2017-October/002258.html>
As to deprecating the plain identifier - functionally, the only way to do this - that I can see - is to have the “only” and “any later version” options hard-coded into the license list for the GNU licenses, as they used to be, that is: - the current GPL-2.0 (which means “only) would be changed to GPL-2.0-only - GPL-2.0+ which is currently created by using the + operator, would be added back to the license list as a separate line item. I think we had discussed this prior, but the issue of losing the + operator to be used with other licenses could cause other problems. What did not occur to me, nor did we discuss, was the idea of doing the above for the GNU family of licenses, but also keeping the + operator to be used with other licenses. This would effectively treat the GNU family licenses differently, and also makes it so the identifiers always indicate “only” or “any later version”. As John notes below, the issue that seems to be preventing us from reaching a solution is the example of finding a copy of the license text and how to identify that accurately. At the file level, by way of example: - COPYING.txt (text of GPL, version 2) - source1.c (no license info) - source2.c (no license info) - source3.c (no license info) In this case, I think everyone agrees that a scanning or human when identifying the “license info in file” (just the facts, no conclusions/interpretations) would use NOASSERTION for source1.c, source2.c, source3.c The question we’ve been debating is how to identify the “license info in file” for the COPYING.txt file - to this end, I had asked the FSF whether the license alone has a default value of GPL-2.0-only or GPL-2.0+ (using the starting point of GPL-2.0 because the actual license text of GPL, version 2 is present and identifiable. One of the concepts I seem to hear from John’s post below and others is that the lack of any license notice in the files means those files are not licensed at all. This is not what a court would find. Consider how software in its common forms besides open source software specifically - I download a binary software blob that has a license accompanying it in some way (e.g., a click through or a license placed with the software, etc.) Just because the license information or a license notice is not in the actual “file” does not mean there is no license. Likewise, in the example of above - if I found those files in one repository and the repository owner tried to later sue me for infringement based on the theory that the lack of license notice in each file meant I had no license to use the files even though a license was provided in the obvious place that licenses are provided - that argument would not hold legal water for a number reasons. If the FSF, as the license authors and stewards, stated that a “bare” license defaults to “only” or “any later” version of the license provided - which I think the FSF is entitled to do - then we could reflect that with the appropriate identifiers along the lines of my idea above - could we not? But, if the FSF would rather not do so and then we need a way to specifically indicate “the license text was found in this file” - then I don’t understand why the plain identifier as per the proposal is problematic. Sorry John! I’m not trying to be difficult, but the plain identifier is needed to be able to add operators to it (“only”, “+” or anything else we might come up with) so I don’t see how we can completely deprecate it unless we “hard code” the “only” and “later version” options (as I suggested above). Also, the plain identifier use in this case would be consistent with how every other license identifier is used: if I find a copy of MIT - be it in a LICENSE.txt file or sourceN.c file - it is identified as MIT, as the text of that license. I think the thing that makes the GNU family of licenses different from other licenses or potentially ambiguous in the case above is NOT what was found (the license text of a specific license was found), nor even what version of the license text was found, but the absence of specific additional statement explicitly. not sure if this helps, but at least getting the conversation going again! I think Trevor has a response with further info, which I’ll respond to in turn as well. Thanks, Jilayne SPDX Legal Team co-lead opensou...@jilayne.com > On Oct 12, 2017, at 8:44 AM, John Sullivan <jo...@fsf.org> wrote: > > Hi Jilayne, > > Thanks for writing this up. > > A key part is missing in the description of the original FSF proposal > here though -- which is deprecating the existing GPL-2.0 and similar > "plain" identifiers for GNU licenses so that the identifiers used always > indicate whether the version is "only" or "any later". > > As I understand it, people had concerns with deprecating the plain > identifiers because of situations where they (for example) find a copy > of GPLv2, but no clear statement about whether the program is actually > licensed under its terms. > > To address this, we suggested still deprecating the plain identifier but > adding an ambiguous/unclear identifier that still indicates a copy of > the GPL was found but does not mislead observers into thinking that > there are sufficiently clear licensing statements along with it. > > I understand SPDX doesn't want to make legal judgments. Which is why it > should indicate when there is uncertainty. Situations like "found a copy > of the license but not clear licensing statement" should be flagged as > things to be fixed, if SPDX wants to achieve its goal of successfully > communicating reliable license information. Sure, determining when there > is uncertainty could be described as a legal judgment. So is acting as > though there is certainty. Some level of that is both unavoidable and > necessary. > > We haven't changed our mind about what we do and don't support here; and > I think we'd be open to other ways to indicate ambiguity/uncertainty, > including possibly using NOASSERTION. > > Can we get a list of all of the options on the table for dealing with > the case of "found a copy of the GPLv2, but no licensing statement > anywhere"? > > -john > > -- > John Sullivan | Executive Director, Free Software Foundation > GPG Key: A462 6CBA FF37 6039 D2D7 5544 97BA 9CE7 61A0 963B > https://status.fsf.org/johns | https://fsf.org/blogs/RSS > > Do you use free software? Donate to join the FSF and support freedom at > <https://my.fsf.org/join>. > _______________________________________________ > Spdx-legal mailing list > Spdx-legal@lists.spdx.org > https://lists.spdx.org/mailman/listinfo/spdx-legal
_______________________________________________ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
