>> 2. There's no way to express the “I just found this stand-alone >> license file but have not looked at license-grant comments” or the >> similar case when the license-grant comments are not given.
The problem with this whole topic (and one that comes up on a regular bases) is conflating file level licensing analysis with package level license analysis. Files and packages are fundamentally two different things. The license expression language was initially designed to capture the flexible licensing terms expressed in the license “notices” found in individual source files. NOT packages. The package license is an ill-conceived concept. Conversely, licensing of binary program and library files and the source files from which they are derived is well defined, and well served by the current SPDX license expression syntax. A package is a “box of stuff” where some stuff may be related by linking while other stuff is not. In addition to the more common stuff (source files, libraries), some other stuff found in a package might include documentation, build scripts, test cases, images, video, config files, and so forth. Unfortunately the concept of a package license is ill-defined and often not representative of all the different things in the package. The Busybox package components are represented by more than 15 different licenses and the Webkit package by more than 30. In the embedded software industry, packages are rummaged through, picked apart and often only a small subset of files (or components) are actually used. I must confess, as an SPDX user, I do not pay much attention to the package Concluded License field. I head straight for the source and library licenses from which the programs I distribute are built from. >> The real-world use cases are outlined in [1]. Case 4 in that list is the >> “GitHub example” from which this thread takes its subject. I started my initial response by replying to the request for comments on #4. See attached. Examples 1-4 are, in my opinion, straight forward. The problem is has everything to do with two things: 1) We are trying to define a method to determine a "package license" for a collection of files that are often poorly tagged with respect to licensing and could potentially include a mix I have yet to see any "source code file notice" examples that have a fundamental problem with regards to the "or later"/only problem. The problem appears to lie with package level licensing -----Original Message----- From: W. Trevor King [mailto:wk...@tremily.us] Sent: Monday, September 11, 2017 2:27 PM To: Gisi, Mark Cc: J Lovejoy; Marc Jones; SPDX-legal Subject: Re: GPLv2 - Github example On Mon, Sep 11, 2017 at 08:59:17PM +0000, Gisi, Mark wrote: > If the source file license is GPL-2.0 that currently means only one > thing. GNU General Public License version 2. There is no confusion. > > I understand that this has been discussed at length but I not sure the > problem is what people think it is. We need to find source code file > notice examples that can't be expressed using the current license > expression language in order to justify making changes. The problems with using ‘GPL-2.0’ to mean “GPL v2 only” are: 1. It's not immediately obvious that the author actually thought through only vs. or-later. 2. There's no way to express the “I just found this stand-alone license file but have not looked at license-grant comments” or the similar case when the license-grant comments are not given. Maybe you are very clear about what those cases mean, but I think the length of this thread and the larger discussion show that while there may be no confusion for you, different folks have different opinions on what is implied in case 2. > I am trying to move away from the theoretical problem descriptions and > find a collection of real world use cases that define the problem and > that would help lead to a solution. The real-world use cases are outlined in [1]. Case 4 in that list is the “GitHub example” from which this thread takes its subject. Cheers, Trevor [1]: https://wiki.spdx.org/view/Legal_Team/only-operator-proposal#Examples_.2F_Challenges -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
--- Begin Message --->> it’s the job of SPDX to provide a clear way to identify >> what is found and a language to express that in. I concur. Sometimes the best one can do is to document the lack of license information hence the existence of the NONE and NOASSERTION designations. Because a core SPDX principle is not to make legal determinations, focusing reporting the facts is the best one can do. In Example 4 I would expect to see the following values: Files # 1, 2, 3, 4: LicenseConcluded: NOASSERTION LicenseInfoInFile: NONE COPYING file: LicenseConcluded: GPL-2.0 /* by convention */ LicenseInfoInFile: GPL-2.0 Package level: PackageLicenseConcluded: NOASSERTION A less conservative choice for the package license would be GPL-2.0 but I don’t see how one comes up with GPL-2.0+ based on the information provided. In this example what I find valuable about SPDX is that it allows one to describe licensing information in the best terms possible by reporting the facts. This is a benefit over not having SPDX in that - it makes it easy to determine that this is a poorly licensed package. The SPDX file analogous to a dentist’s x-ray in that - instead of illuminating tooth decay, it illuminates licensing decay – a typical consequence in both cases of bad practice (hygiene). I do not see the “only” problem here. Files 1-4 are not even open source because there is no clear open source license grant. Beyond the fact that you can’t decisively determine whether the GPL-2.0 is applicable, how do you know one or more of the files where not copied from *another project* with just a LICENSE.txt (Apache-2.0 ) in the top directory. Or worst – copied from a project with zero licensing info in the top level or a commercial offering. Because someone copies a file into a GPL-2.0 project does not make it GPL-2.0. I know that the following CDDL was discussed with respect to the “only” problem: * This file and its contents are supplied under the terms of the * Common Development and Distribution License ("CDDL"), version 1.0. * You may only use this file in accordance with the terms of version * 1.0 of the CDDL. But this is handle by the LicenseRef construct (e.g., LicenseRef-CDDL-1.0-only). Because this is not a common use of the CDDL-1.0, I prefer to encourage the software recipient/customer take an additional look which is achieved by the use of a LicenseRef. - Mark From: spdx-legal-boun...@lists.spdx.org [mailto:spdx-legal-boun...@lists.spdx.org] On Behalf Of J Lovejoy Sent: Friday, September 08, 2017 7:07 AM To: Marc Jones Cc: SPDX-legal Subject: GPLv2 - Github example (was: Re: New license proposal: Verbatim) Hi Marc, Thanks so much for your thoughtful response to the examples set out to help with the only-operator proposal. You are the first one to respond to this, and I hope that others will also chime in here. Example 4 is indeed what we have been struggling with and is a common example in that the way Github repos are created, it’s easy to have only the license file with no other license info. I think your further examples of the kinds of responses you might get when asking for clarification are also very realistic in that you can’t count on getting a clear answer! Some education and guidance on this is clearly needed, but may still run into these scenarios and it’s the job of SPDX to provide a clear way to identify what is found and a language to express that in. I really hope you don’t go back to merely lurking! Cheers, Jilayne SPDX Legal Team co-lead opensou...@jilayne.com<mailto:opensou...@jilayne.com> Also to chime in on the question of if only a copy of the GPLv2 text is include in a code base: First I just want to offer my apologies for coming late to the party. I know from the meeting notes everyone involved has been working very hard and thoughtfully on this issue for months. My compliments to all of your hard word and appreciation for whoever is responsible for keeping such detailed meeting notes up to date. My comments are only meant to add to the conversation, not distract from it. I agree with the conclusions of examples 1, 2 and 3. (https://wiki.spdx.org/index.php?title=Legal_Team/only-operator-proposal). To address example 4. I think the solution is probably not intuitive (at least it was not to me,) but if you only include the text of the GPLv2 with no other licensing statements the plain meaning of the license text would require concluding that the code base is GPLv2 only. I can imagine buying into a theory where you get to any version of the GPL, and but at the moment I do not see how to get to "GPLv2 or any later version." The GPLv2 says "If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation." Not trying to be pedantic but the text of the GPLv2 clear refers to GPLv2. Being something seems to be the best way to specify that thing. If the only licensing information in a code base is the exact text of GPLv2 I have three questions: 1) does the mere presence of the GPLv2 text imply that the author intended the accompanying code to be licensed under the GPLv2? 2) Since the only licensing statement for the code base is implied by the full text of the GPLv2, is there anyway to argue that the version wasn't specified? And 3) is there anyway to argue that "or any later version" was specified? Q1: The answer to the first question is not obvious to me. To me the mere presence of the license text in a file does not an explicit license make. I think you need to rely on practice of the trade to get there, or at least an implied license. Dropping the text of a license into a file called LICENSE or even more specific to our industry COPYLEFT would not be obvious in all situations that that is the intended license. It could just be a random file with some other purpose that the copyright holder never noticed or intended to give that kind of effect to. I know that flies in the face of a lot of assumptions of the industry, but I think you would get a lot of mileage in front of a judge who was not FOSS developer with that argument. The best argument that it is a explicit license is that the name of the file 'LICENSE' is the explicit license, but that leaves those folks using COPYLEFT out to dry. At best including the text of a license is an implied license and is supported by the practice of the trade so it is reasonable to rely on it. Q2: To address the second question, I think you need to at the very least accept that the license include in the LICENSE file is the license of the code base. But then it seems contradictory to me to look at the full text of GPLv2 and conclude that means GPL but it doesn't specify which version of the GPL. At best I would think the implied license created by including the text of a license in a LICENSE file is "the license of this code base is as specified in the LICENSE file." And that license file clearly specifies the GPLv2, so by the terms of the GPLv2 it would not have left the version unspecified allowing you to choose any version of the GPL. If you do not buy the argument that the text of the license by its nature specifies the version of the license, then I will argue that Section 0 of GPLv2 states that "*This* License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License." So the text of the license says the "License" is "this license," which of course is GPLv2. And under GPLv3 it gets more specific where "This License" is defined as "version 3 of the GNU General Public License." It seems pretty clear that the version of the license is specified when you include the full text of the license. I would also think that people who dropped in a copy of GPLv3 and did not put in any other licensing notice would be surprised to learn that people are taking the license under GPLv2 because they failed to specify what version of the GPL they meant. I think they would be particularly surprised if Tivo said "great, you did not specify a version when you included the text of the GPLv3 in your code base, so we will just use it under GPLv2." Q3: I think the answer to the third question is similar to the reasoning of the answer to Q2. According to GPLv2 the only time you can choose any any later version of the license is when the copyright holder specifies "any later version." Since that phrase only occurs in the license text in the conditional statement granting this additional permission, I do not see how you ever conclude the copyright holder meant GPLv2.0+ by the mere inclusion of the license text in a code base. It seems like a separate explicit licensing statement somewhere outside of the text of the license is necessarily required to trigger that conditional clause. I present this hypothetical as an example: You copy a code base that includes a copy of the GPLv2 in a LICENSE file. There are no other licensing statements in the code base. You contact the copyright holder to clarify the license. 1) They send you a hostile email telling you the license is specified in the LICENSE file. Do you acknowledge their response and say you will be taking the the code under GPLv3? 2) They send you a hostile email telling you the license is GPLv2 as specified in the LICENSE file. Do you acknowledge their response and say you will be taking the the code under GPLv3? 3) Your email to them expecility asks if the license is "GPLv2 or any later version." They send you a polite email telling you the license is "GPLv2" as specified in the LICENSE file. Do you thank them for their response and say you will be taking the the code under GPLv3? I feel like notifying them that you will be taking the code under GPLv3 under all three scenarios seems risky. But even if you would not take the code under even one of those circumstances it seems like you should not assume the bare presence of the text of GPLv2 means GPLv2 or later. How this is implemented in the SPDX codes might be problematic, but seems like you folks are on the right track. I will attempt to return to my lurking now. My apologies for the uninvited opining. Warm regards, -Marc P.S. This was not legal advice, these view represent my own and not the views of my company. My opinion may change depending on the context in which similar questions arise, my mood, or what I ate for lunch that day, blah, blah, .... [1] http://www.apache.org/foundation/license-faq.html#mod-license _______________________________________________ Spdx-legal mailing list Spdx-legal@lists.spdx.org<mailto:Spdx-legal@lists.spdx.org> https://lists.spdx.org/mailman/listinfo/spdx-legal
--- End Message ---
_______________________________________________ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
