Besides the case of GPL version numbers, isn't the issue similar to when we have cases like where you have a package that simply says "This program is under the BSD license"
The author "declared" something, but the SPDX spec is not really useful, since the value of the field is a license (or a license expression) and not a free form text. None of the licenses in the SPDX license list can be used as "PackageLicenseDeclared". Do we put a list of the 15 or so BSD variants, or disregard the declaration by stating "NOASSERTION"? Taking it further, suppose that by looking at the actual wording of the license text in files, you might decide that the author is talking about BSD-3-Clause-No-Nuclear-License (in the nice case where all the files use the same text). But isn't this a "Concluded" rather than a "Declared" field? -- zvr - -----Original Message----- From: spdx-legal-boun...@lists.spdx.org [mailto:spdx-legal-boun...@lists.spdx.org] On Behalf Of Gisi, Mark Sent: Friday, 15 September, 2017 13:19 To: Bradley M. Kuhn <bk...@ebb.org>; SPDX-legal <spdx-legal@lists.spdx.org> Subject: RE: License identifiers sufficient to avoid loss of information in DeclaredLicense (was: GPLv2 - Github example) Quick clarification: >> I admit that I don't know how exactly to express such as Declarations. >> What is quite clear from this discussion, though, is that the >> Conclusions that people make about such Declarations vary. Mark Gisi >> Concludes most of these examples as NOASSERTION. >> I Conclude most of them are GPLv1-or-later. The examples addressed Conclude License (files and package) but not the Declared License. Furthermore, I only made a comment about Example 4. I agreed with the file Concluded License designations for Examples 1-3. Including Example 3 = GPL-1.0+. And yes, for Example 4 I concluded NOASSERTION for each of the four files that have zero licensing info in them. There are many scenarios where those files could be something other than GPL. For example, one or more source files could have been copied from an Apache project or a commercial code based. I have encountered two cases in as many years where commercial code was copied into a project with a GPL-2.0 file in the top directory. In one case the commercial license notice was retained in the file and in the other the notice was removed. Another situation I encountered ~5 years ago: someone admittedly removed the BSD license notices from several files he copied into his GPL project. He just assumed that they were now under the GPL-2.0 and the BSD notices were confusing and unnecessary! I had to explain he was violating the BSD license. As for Example 4, for me, hope is not a strategy. NOASSERTION. >> >> 3.15 Declared License >> The problem with this field does not lie with the LEL but with the values the "field" will accept. "This field lists the licenses that have been declared by the authors of The package. " It should probably accept a list of LELs. For example if the top level directory had the following license files: COPYING.GPL-2.0 COPYING.LGPL-2.0 Then the declared license field should accept the "list" of LELs: GPL-2.0, LGPL-2.1 This approach is simple and probably handles 95% + cases. - Mark -----Original Message----- From: spdx-legal-boun...@lists.spdx.org [mailto:spdx-legal-boun...@lists.spdx.org] On Behalf Of Bradley M. Kuhn Sent: Wednesday, September 13, 2017 11:47 AM To: SPDX-legal Subject: License identifiers sufficient to avoid loss of information in DeclaredLicense (was: GPLv2 - Github example) Since the Legal call where we first began discussing what Jilayne has called the "Github examples", I've been thinking about this question regularly. I do agree wholeheartedly with Richard Fontana's point that SPDX both has stakeholders who use the license identifiers outside of SPDX (and that SPDX as a project lauds such uses). SPDX should indeed think about those users. I'm primarily one of those users to the extent I use SPDX. However, for the purposes of this discussion, I suggest we return to first principles in the SPDX specification. So I asked myself, what job does SPDX expect license identifiers to do? I went to the SPDX spec and looked at this: 3.15 Declared License 3.15.1 Purpose: This field lists the licenses that have been declared by the authors of the package. Any license information that does not originate from the package authors, e.g. license information from a third party repository, should not be included in this field. (URL: https://spdx.org/spdx-specification-21-web-version#h.1hmsyys ) I began to think carefully about this question, what *is* the "Declared License" -- by the package authors -- in the examples at https://wiki.spdx.org/view/Legal_Team/only-operator-proposal#Examples_.2F_Challenges ? I admit that I don't know how exactly to express such as Declarations. What is quite clear from this discussion, though, is that the Conclusions that people make about such Declarations vary. Mark Gisi Concludes most of these examples as NOASSERTION. I Conclude most of them are GPLv1-or-later. In the last week, I've talked to people who Conclude them as GPLvN-only. I've also talked to people who Conclude them as GPLvN-or-later, where N is the version of the GPL that is put in the package directory. In other words, the Conclusions are all over the map for these rather simple Declarations. So, my meta-conclusion is clear: the proposed solution of https://wiki.spdx.org/view/Legal_Team/only-operator-proposal#Proposed_Solution:_add_only_operator probably will work fine [0], but only for the LicenseConcluded field. (In other words, I can't imagine any *Conclusions* that aren't covered by that group.) But, for *Declarations*, SPDX clearly needs some other identifier, which would usually only be used as Declared licenses. Such an identifier would allow SPDX files (a) to better include all the information that was available to best inform those who look at the Declared license, (b) properly inform those making Conclusions, and (c) avoid the current situation that causes Conclusions about GPL licensing to appear in as a Declared license. I don't know what such an identifier should be, but it is *not* GPLvN-or-later; it's not GPLvN-only; it's not GPLvN+. It's something else. [0] As I first said on this list back in October 2013, I still really think "-or-later" is a better operator than "+", but that's admittedly a minor quibble. -- Bradley M. Kuhn _______________________________________________ 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 Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Christian Lamprechter Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928 _______________________________________________ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
