Re: GPLv2 - Github example
Dne torek, 12. september 2017 ob 20:14:11 CEST je Zavras, Alexios napisal(a): > For even more extreme fun, I can point to cases like ffmpeg, where, > according to the options get passed to configure build script, different > files (under different licenses) get compiled and linked. Great example. For a short (probably incomplete) overview of which options can trigger which license(s), taking a look at ffmpeg’s package in Gentoo is very instructive: https://packages.gentoo.org/packages/media-video/ffmpeg https://gitweb.gentoo.org/repo/gentoo.git/tree/media-video/ffmpeg/ ffmpeg-3.3.3.ebuild?id=4a75a4f185c8c636eb2dc74f78a2817ac6d57dfa#n37 cheers, Matija -- gsm:+386 41 849 552 www:http://matija.suklje.name xmpp: matija.suk...@gabbler.org sip:matija_suk...@ippi.fr ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
RE: GPLv2 - Github example
Zavras, Alexios: > I think I understand Mark's reservations about package-level licenses and I > agree with them... > In all these cases, it seems that the “package-level license”, should simply > be the collection of all different licenses found in all the files of the > package. I think that Mark was wondering whether this is particularly useful… It's useful, though the ability to be more precise would be nice. A user or developer needs to know "what am I allowed to do?", in a *SIMPLE* way, when confronted with a package. Most software packages (however defined) have a relatively simple license expression that suffices to describe what you're allowed to do. Historically people only used a few software packages, but today people routinely use much larger sets of software packages. Clearly there are packages which have more complex licensing requirements. In most cases today, all I really need is a *hint* that there's a potential issue, so I can focus on the packages where there MIGHT be an issue. I suspect it'd be more productive to find ways to expand the license expression syntax to cover them, if that turns out to be important. --- David A. Wheeler ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
RE: GPLv2 - Github example
I think I understand Mark's reservations about package-level licenses and I agree with them. On previous instances of this same discussion (there have been a few ☺), it seemed that there was a disconnect, which was mostly explained by what people were considering when thinking about “packages”. People coming from Java (Maven) environment had one idea, people with experience in Javascript (npm) a somewhat different one, etc. Myself, I come from a good ol’ Unix/C environment. In my mind, a “package” is, for example, a .tar.gz release of a specific software. So, what would be the package-level license of, say, zlib-1.2.10.tar.gz? We all know that zlib uses the Zlib license. However, keep in mind that this “package” (archive), contains: * The source of zlib, obviously, licensed under Zlib; but also * other files like “README” or “Changelog” without any specific license; and even * some source (in contrib/ada) under GPL-2.0+ (!) Therefore, if you are using this package/archive to generate a library with Ada bindings, the resulting artifact would probably be licensed under GPL-2.0+. If you ignore this contrib directory and generate the zlib library for C, Zlib is probably the correct license. For even more extreme fun, I can point to cases like ffmpeg, where, according to the options get passed to configure build script, different files (under different licenses) get compiled and linked. In all these cases, it seems that the “package-level license”, should simply be the collection of all different licenses found in all the files of the package. I think that Mark was wondering whether this is particularly useful… -- zvr – From: spdx-legal-boun...@lists.spdx.org [mailto:spdx-legal-boun...@lists.spdx.org] On Behalf Of Marc Jones Sent: Tuesday, 12 September, 2017 19:48 To: W. Trevor King ; Wheeler, David A Cc: SPDX-legal Subject: Re: GPLv2 - Github example Mark, You said 'A package is a “box of stuff” where some stuff may be related by linking while other stuff is not.' While I agree that is true, I am not sure I agree that dealing with it at a file level avoids many problems. For two reasons: 1) wheather lawyers and licensing nerds like it or not there is a huge amount of FOSS that has never had and will never have a licensing statement include in each file. And 2) The file doesn't play any special boundary in copyright law, at least not any more than one could argue any other method of organizing information on a computer does. You can have the same multi-license complications in a single file that are present in a multi-file package, Take for example a program composed of two files, one under the BSD license and one under a Apache license. What is the license of the combination? It is not clear, actually I don't think it is dictated in that case. Go ahead and cut and past the contents of one of those files into the other. Has your licensing gotten any more or less complicated? I think you are still left asking the question of what license the combined work is licensed under? -Marc On Tue, Sep 12, 2017 at 12:47 PM W. Trevor King mailto:wk...@tremily.us>> wrote: On Tue, Sep 12, 2017 at 02:52:26PM +, Wheeler, David A wrote: > Mark Gisi: > > the SPDX identifier model will need to accommodate a LicenseRef > > like mechanism... > > I'm not arguing to *remove* licenserefs, I agree they can be useful. > > My point is different. Since many users *only* use SPDX license > expressions, it's important that SPDX license expressions have > enough expressiveness (hah!) for common use cases WITHOUT using > licencerefs. Agreed. I don't think anyone is arguing for removing LicenseRef. A new ‘only’ operator allows you to express ‘CDDL-1.0 only’ as a vanilla license expression where you currently need to use a LicenseRef, but there are obviously lots of other LicenseRef use cases that an ‘only’ operator will not replace. > > This is a far bigger problem than the "only" operator. In fact, it > > is the ill- conceived package license concept that is creating > > significant frustration and confusion over the GPL only issue. The > > problem is not at the file level. The license expression syntax is > > well suited for that. It is not well suited for the package > > level. Until that is addressed we will continue to struggle. > > It's not ill-conceived. Package-level results are the WHOLE POINT. I don't know if I'd go as far as that; being able to drill down to find the license for a particular file or snippet is useful too. But I certainly don't see a reason why license expressions would not work fine for projects given that they work fine for files; projects are just collections of files. Similarly, files are collections of snippets. SPDX license expressions can (and do?) allow to you state the licen
Re: GPLv2 - Github example
Mark, You said 'A package is a “box of stuff” where some stuff may be related by linking while other stuff is not.' While I agree that is true, I am not sure I agree that dealing with it at a file level avoids many problems. For two reasons: 1) wheather lawyers and licensing nerds like it or not there is a huge amount of FOSS that has never had and will never have a licensing statement include in each file. And 2) The file doesn't play any special boundary in copyright law, at least not any more than one could argue any other method of organizing information on a computer does. You can have the same multi-license complications in a single file that are present in a multi-file package, Take for example a program composed of two files, one under the BSD license and one under a Apache license. What is the license of the combination? It is not clear, actually I don't think it is dictated in that case. Go ahead and cut and past the contents of one of those files into the other. Has your licensing gotten any more or less complicated? I think you are still left asking the question of what license the combined work is licensed under? -Marc On Tue, Sep 12, 2017 at 12:47 PM W. Trevor King wrote: > On Tue, Sep 12, 2017 at 02:52:26PM +, Wheeler, David A wrote: > > Mark Gisi: > > > the SPDX identifier model will need to accommodate a LicenseRef > > > like mechanism... > > > > I'm not arguing to *remove* licenserefs, I agree they can be useful. > > > > My point is different. Since many users *only* use SPDX license > > expressions, it's important that SPDX license expressions have > > enough expressiveness (hah!) for common use cases WITHOUT using > > licencerefs. > > Agreed. I don't think anyone is arguing for removing LicenseRef. A > new ‘only’ operator allows you to express ‘CDDL-1.0 only’ as a vanilla > license expression where you currently need to use a LicenseRef, but > there are obviously lots of other LicenseRef use cases that an ‘only’ > operator will not replace. > > > > This is a far bigger problem than the "only" operator. In fact, it > > > is the ill- conceived package license concept that is creating > > > significant frustration and confusion over the GPL only issue. The > > > problem is not at the file level. The license expression syntax is > > > well suited for that. It is not well suited for the package > > > level. Until that is addressed we will continue to struggle. > > > > It's not ill-conceived. Package-level results are the WHOLE POINT. > > I don't know if I'd go as far as that; being able to drill down to > find the license for a particular file or snippet is useful too. But > I certainly don't see a reason why license expressions would not work > fine for projects given that they work fine for files; projects are > just collections of files. Similarly, files are collections of > snippets. SPDX license expressions can (and do?) allow to you state > the license terms of any work, regardless of whether that work is a > snippet, file, project, distro, …. What the ‘only’ operator is about > is making vanilla license expressions (which do not reference custom > LicenseRefs and such) more expressive. That will help folks who are > restricted to vanilla license expressions, regardless of what they > happen to be licensing. > > Cheers, > Trevor > > -- > 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 > ___ > 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
Re: GPLv2 - Github example
On Tue, Sep 12, 2017 at 02:52:26PM +, Wheeler, David A wrote: > Mark Gisi: > > the SPDX identifier model will need to accommodate a LicenseRef > > like mechanism... > > I'm not arguing to *remove* licenserefs, I agree they can be useful. > > My point is different. Since many users *only* use SPDX license > expressions, it's important that SPDX license expressions have > enough expressiveness (hah!) for common use cases WITHOUT using > licencerefs. Agreed. I don't think anyone is arguing for removing LicenseRef. A new ‘only’ operator allows you to express ‘CDDL-1.0 only’ as a vanilla license expression where you currently need to use a LicenseRef, but there are obviously lots of other LicenseRef use cases that an ‘only’ operator will not replace. > > This is a far bigger problem than the "only" operator. In fact, it > > is the ill- conceived package license concept that is creating > > significant frustration and confusion over the GPL only issue. The > > problem is not at the file level. The license expression syntax is > > well suited for that. It is not well suited for the package > > level. Until that is addressed we will continue to struggle. > > It's not ill-conceived. Package-level results are the WHOLE POINT. I don't know if I'd go as far as that; being able to drill down to find the license for a particular file or snippet is useful too. But I certainly don't see a reason why license expressions would not work fine for projects given that they work fine for files; projects are just collections of files. Similarly, files are collections of snippets. SPDX license expressions can (and do?) allow to you state the license terms of any work, regardless of whether that work is a snippet, file, project, distro, …. What the ‘only’ operator is about is making vanilla license expressions (which do not reference custom LicenseRefs and such) more expressive. That will help folks who are restricted to vanilla license expressions, regardless of what they happen to be licensing. Cheers, Trevor -- 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 signature.asc Description: OpenPGP digital signature ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
RE: GPLv2 - Github example
Mark Gisi: > LicenseRefs are critical for creating SPDX files. I disagree, for at least two reasons: 1. A vast amount of software does *NOT* require weird special-case licenserefs. 2. Many people who use SPDX will never see nor use a SPDX file. Instead, many people use SPDX *exclusively* for the SPDX license expression format. I suspect the *majority* of SPDX users only use SPDX license expressions. > the SPDX identifier model will need to accommodate a LicenseRef like > mechanism... I'm not arguing to *remove* licenserefs, I agree they can be useful. My point is different. Since many users *only* use SPDX license expressions, it's important that SPDX license expressions have enough expressiveness (hah!) for common use cases WITHOUT using licencerefs. > Case 1: Because they are writing their own code, they could stick with > standard licenses and avoid the rare CDDL "only" notices along with all the > other weird third party stuff. We don't want to encourage them to use > non-standard stuff anyway. Therefore there is no need to add the "only" > operator since the current license expression syntax is sufficient to address > any standard case (including GPL 2.0 only and GPL 2.0 or a later version). Ah, I see. I think you missed the earlier discussion, where the *INSUFFICIENCY* of the current license expression syntax was discussed. I encourage you to go back to the archives to review the discussion about this. Here's a quick summary: The problem is that tools often can only determine "there's a GPL-2.0 license here", and *NOT* whether or not "or later" applies. Because of scale, people *depend* on tools to provide license information. So there's a mismatch between what SPDX license expressions allow you to express, compared to what tools can actually provide. In particular, the current license expression syntax is *NOT* sufficient to address the case "I saw GPL-2.0, but I don't know if 'or later' applies". The license expression syntax instead insists that you report information that is *NOT* available. The result is that in *practice* "GPL-2.0" often does *NOT* mean "exactly GPL 2.0", but "GPL 2.0 at least and I don't know if other versions apply". So "GPL-2.0" has one meaning in the spec, but two meanings in practice. Thus, we need a way to express those 2 different situations, instead of being ambiguous. > In a nutshell - The white elephant in the room is the package license. This is not the elephant in the room. It's the whole point of SPDX. It's the primary goal. When I look at a software package (as a user or developer) and ask, "do I want to use this software?", I need to know what I'm legally allowed to do. From my point of view, that's the point of SPDX, specifically the SPDX license expression. > An ill-defined concept that has plagued SPDX since its inception. Again, it's not an ill-defined concept - it's the primary purpose. > Everyone wants > to be given a top level license designation for every open source package > they receive. Is it the license of the project? Yes. At least, that's what it is *supposed* to be. > Is it the license in the top level license file? > What happens if there is more than one top level license file? Is it > the license most frequently found in the source files? Is it the AND of all > the > licenses found in the package? Or is it simply someone's guesstimate? > Different Linux distros will sometimes designate different top level licenses > for the same package. Which is why you need SPDX. SPDX files allow exchange of legal analysis information, so information can be exchanged and analyzed. The SPDX license expression that describes the entire package is the boiled-down summary of the analysis results, suitable for use by other tools & humans. When you're downloading several thousand packages into your final system, you *need* a simple SPDX license expression for each package to help you comply with all the license requirements. In the end, what matters as a *user* (customer) of software is, "what am I allowed to do?". And that is normally at a *package* level. It's not at the package level in all cases, true. For example, I could extract an individual files. But that is a rarer situation, because copying like that creates non-legal problems as well (e.g., I now get to "enjoy" larger maintenance costs). SPDX can handle file-level as well (as you note). Most of the time, though, users care about the *package* level license, which expresses "what am I allowed to do?" > This is a far bigger problem than the "only" operator. In fact, it is the ill- > conceived package license concept that is creating significant frustration and > confusion over the GPL only issue. The problem is not at the file level. The > license expression syntax is well suited for that. It is not well suited for > the > package level. Until that is addressed we will continue to struggle. It's not ill-conceived. Pack
RE: GPLv2 - Github example
Sorry for sending out a half composed email. It is late and I was rushing to complete my emails. In a nutshell - The white elephant in the room is the package license. An ill-defined concept that has plagued SPDX since its inception. Everyone wants to be given a top level license designation for every open source package they receive. Is it the license of the project? Is it the license in the top level license file? What happens if there is more than one top level license file? Is it the license most frequently found in the source files? Is it the AND of all the licenses found in the package? Or is it simply someone's guesstimate? Different Linux distros will sometimes designate different top level licenses for the same package. This is a far bigger problem than the "only" operator. In fact, it is the ill-conceived package license concept that is creating significant frustration and confusion over the GPL only issue. The problem is not at the file level. The license expression syntax is well suited for that. It is not well suited for the package level. Until that is addressed we will continue to struggle. - Mark -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 +, 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 ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
RE: GPLv2 - Github example
>> 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 +, 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
Re: GPLv2 - Github example
Unsubscribe. Sorry to send this to all but my last attempt didn't work. On Tue, Sep 12, 2017 at 8:18 AM Gisi, Mark wrote: > >> I disagree. LicenseRef is not a cornerstone, and for many use cases > it's irrelevant. > > We will have to respectfully disagree. LicenseRefs are critical for > creating SPDX files. Packages such as the Linux Kernel, Busybox and all the > OpenStack modules require LicenseRefs to create a proper SPDX file. > Therefore the LicenseRef construct is absolutely the SPDX cornerstone > method for dealing with customer license notices. > > >> If people think they "need" a LicenseRef, it's often one of two cases: > >> 1. The SPDX license list has an important omission (time to report the > license to SPDX, > >> not to use a LicenseRef!) 2. There's a weird license in use by a third > party. > > Where cases 1 and 2 above occur frequently. > > >> As a developer or potential user, I'm probably going to just avoid > using that software, > >> in which case problem solved... > > I agree - you will not encounter the weird stuff like CDDL-1.0 only > notice. This is a convenient choice you get to make but that is not a > realistic option for anyone creating SPDX files for code for any > significant open source project or Linux distro. > > >> Yes, if you have a full SDPX file, more information can be useful. But > *lots* of people use SPDX license expressions separately. > > Consider just the people who only use SPDX license expressions (and not > the full SPDX spec). > > Case 1: Because they are writing their own code, they could stick with > standard licenses and avoid the rare CDDL "only" notices along with all the > other weird third party stuff. We don't want to encourage them to use > non-standard stuff anyway. Therefore there is no need to add the "only" > operator since the current license expression syntax is sufficient to > address any standard case (including GPL 2.0 only and GPL 2.0 or a later > version). > > Case 2: If they decide to use other third party code then they will > encounter, from time to time, custom license notices. They will need a way > to deal with them - hence the need for a LicenseRefs like construct. > Therefore there is no need to add the "only" operator because you will have > a LicenseRef like mechanism. > > Regardless, the SPDX identifier model will need to accommodate a > LicenseRef like mechanism if it wants to accommodate customer license > notices that are frequently encountered in the wild. > > - Mark > > > > -Original Message- > From: Wheeler, David A [mailto:dwhee...@ida.org] > Sent: Monday, September 11, 2017 1:58 PM > To: Gisi, Mark; W. Trevor King > Cc: SPDX-legal > Subject: RE: GPLv2 - Github example > > W. Trevor King: > > >> But you can't define a LicenseRef in sitations (like npm [1]) where > > >> the only thing you can set is a license expression and you don't > > >> have access to the broader SPDX spec. > > >> [1]: https://docs.npmjs.com/files/package.json#license > > > > > Gisi, Mark: > > This is not a problem with the license expression language. It is a > > problem with the SPDX identifier mechanism. LicenseRefs are SPDX's > > cornerstone way of handling the many many non-standard license notices > > found every day in source code. In the above example you don't need an > > "only" operator you need a way to include LicenseRefs when using SPDX > > identifiers. LicenseRefs are so important that they need to be > > addressed in the SPDX identifier mechanism independent of your situation. > > I disagree. LicenseRef is not a cornerstone, and for many use cases it's > irrelevant. > > Many tools and formats *only* support SPDX license expressions, so it's > very useful to make it easy to express simple constructs like "*ONLY* > version 2 of the GPL is acceptable". > > If people think they "need" a LicenseRef, it's often one of two cases: > 1. The SPDX license list has an important omission (time to report the > license to SPDX, not to use a LicenseRef!) 2. There's a weird license in > use by a third party. As a developer or potential user, I'm probably going > to just avoid using that software, in which case problem solved... I really > don't need a "LicenseRef" to tell me more. If not, I'm going to ask a > lawyer to look at the REAL legal text, not the LicenseRef. In that case, > "OTHER" works just as LicenseRef to note that there's something different. > For people conside
RE: GPLv2 - Github example
>> I disagree. LicenseRef is not a cornerstone, and for many use cases it's >> irrelevant. We will have to respectfully disagree. LicenseRefs are critical for creating SPDX files. Packages such as the Linux Kernel, Busybox and all the OpenStack modules require LicenseRefs to create a proper SPDX file. Therefore the LicenseRef construct is absolutely the SPDX cornerstone method for dealing with customer license notices. >> If people think they "need" a LicenseRef, it's often one of two cases: >> 1. The SPDX license list has an important omission (time to report the >> license to SPDX, >> not to use a LicenseRef!) 2. There's a weird license in use by a third >> party. Where cases 1 and 2 above occur frequently. >> As a developer or potential user, I'm probably going to just avoid using >> that software, >> in which case problem solved... I agree - you will not encounter the weird stuff like CDDL-1.0 only notice. This is a convenient choice you get to make but that is not a realistic option for anyone creating SPDX files for code for any significant open source project or Linux distro. >> Yes, if you have a full SDPX file, more information can be useful. But >> *lots* of people use SPDX license expressions separately. Consider just the people who only use SPDX license expressions (and not the full SPDX spec). Case 1: Because they are writing their own code, they could stick with standard licenses and avoid the rare CDDL "only" notices along with all the other weird third party stuff. We don't want to encourage them to use non-standard stuff anyway. Therefore there is no need to add the "only" operator since the current license expression syntax is sufficient to address any standard case (including GPL 2.0 only and GPL 2.0 or a later version). Case 2: If they decide to use other third party code then they will encounter, from time to time, custom license notices. They will need a way to deal with them - hence the need for a LicenseRefs like construct. Therefore there is no need to add the "only" operator because you will have a LicenseRef like mechanism. Regardless, the SPDX identifier model will need to accommodate a LicenseRef like mechanism if it wants to accommodate customer license notices that are frequently encountered in the wild. - Mark -Original Message- From: Wheeler, David A [mailto:dwhee...@ida.org] Sent: Monday, September 11, 2017 1:58 PM To: Gisi, Mark; W. Trevor King Cc: SPDX-legal Subject: RE: GPLv2 - Github example W. Trevor King: > >> But you can't define a LicenseRef in sitations (like npm [1]) where > >> the only thing you can set is a license expression and you don't > >> have access to the broader SPDX spec. > >> [1]: https://docs.npmjs.com/files/package.json#license > Gisi, Mark: > This is not a problem with the license expression language. It is a > problem with the SPDX identifier mechanism. LicenseRefs are SPDX's > cornerstone way of handling the many many non-standard license notices > found every day in source code. In the above example you don't need an > "only" operator you need a way to include LicenseRefs when using SPDX > identifiers. LicenseRefs are so important that they need to be > addressed in the SPDX identifier mechanism independent of your situation. I disagree. LicenseRef is not a cornerstone, and for many use cases it's irrelevant. Many tools and formats *only* support SPDX license expressions, so it's very useful to make it easy to express simple constructs like "*ONLY* version 2 of the GPL is acceptable". If people think they "need" a LicenseRef, it's often one of two cases: 1. The SPDX license list has an important omission (time to report the license to SPDX, not to use a LicenseRef!) 2. There's a weird license in use by a third party. As a developer or potential user, I'm probably going to just avoid using that software, in which case problem solved... I really don't need a "LicenseRef" to tell me more. If not, I'm going to ask a lawyer to look at the REAL legal text, not the LicenseRef. In that case, "OTHER" works just as LicenseRef to note that there's something different. For people considering whether or not they should use some software, they just need to know if they might be in dangerous waters. Yes, if you have a full SDPX file, more information can be useful. But *lots* of people use SPDX license expressions separately. --- David A. Wheeler ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: GPLv2 - Github example
On Mon, Sep 11, 2017 at 08:59:17PM +, 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 signature.asc Description: OpenPGP digital signature ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
RE: GPLv2 - Github example
>> It's not the only justification. Having an ‘only’ operator also lets you >> give a very clear >> license expression (e.g. ‘GPL-2.0 only’) for grants like: >> >> This program is free software; you can redistribute it and/or modify >> it under the terms of the GNU General Public License version 2 as >> published by the Free Software Foundation. GNU General Public License version 2 = GPL-2.0. The "only" operator is not need here. The example is similar to following addresses by: Apache-2.0. * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at: * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software distributed * under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES * OR CONDITIONS OF ANY KIND, either express or implied. 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 above as it stands does not represent a problem. I am not saying there is no problem. 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. - Mark -Original Message- From: W. Trevor King [mailto:wk...@tremily.us] Sent: Monday, September 11, 2017 12:18 PM To: Gisi, Mark Cc: J Lovejoy; Marc Jones; SPDX-legal Subject: Re: GPLv2 - Github example On Mon, Sep 11, 2017 at 07:04:57PM +, Gisi, Mark wrote: > >> With the ‘only’ operator proposal [1], this situation can be > >> represented by ‘CDDL-1.0 only’. > > … Finally this case can be elegantly handled with a LicenseRef… But you can't define a LicenseRef in sitations (like npm [1]) where the only thing you can set is a license expression and you don't have access to the broader SPDX spec. > That is, the example represents a rare edge case that does not present > a situation that can't be express with today's current constructs. > Therefore it does not represent a good example > (justification) for adding the "only" operator. It's not the only justification. Having an ‘only’ operator also lets you give a very clear license expression (e.g. ‘GPL-2.0 only’) for grants like: This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License version 2 as published by the Free Software Foundation. which is one of the goals listed in [2]. That's a distinct license expression from ‘GPL-2.0’ for cases like “I found this license text in a separate file, but no clear grant applying it to this project” which is the “GitHub example” that spawned this thread. Although as discussed in this thread, some SPDX authors and tools may feel uncomfortable making a concluded-license call in that case. However, I expect tools like licensee, which only look for stand-alone license files and ignore grant comments [3], will be concluding ‘GPL-2.0’ and similar, and having an explicit ‘only’ operator allows consumers to distinguish those ambiguous conclusions from an explicit ‘GPL-2.0+’ or ‘GPL-2.0 only’. Cheers, Trevor [1]: https://docs.npmjs.com/files/package.json#license [2]: https://wiki.spdx.org/view/Legal_Team/only-operator-proposal#Goals [3]: https://github.com/benbalter/licensee/blob/v9.2.0/docs/what-we-look-at.md#what-about-checking-every-single-file-for-a-copyright-header -- 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 ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
RE: GPLv2 - Github example
W. Trevor King: > >> But you can't define a LicenseRef in sitations (like npm [1]) where > >> the only thing you can set is a license expression and you don't have > >> access to the broader SPDX spec. > >> [1]: https://docs.npmjs.com/files/package.json#license > Gisi, Mark: > This is not a problem with the license expression language. It is a problem > with the SPDX identifier mechanism. LicenseRefs are SPDX's cornerstone way > of handling the many many non-standard license notices found every day in > source code. In the above example you don't need an "only" operator you > need a way to include LicenseRefs when using SPDX identifiers. LicenseRefs > are so important that they need to be addressed in the SPDX identifier > mechanism independent of your situation. I disagree. LicenseRef is not a cornerstone, and for many use cases it's irrelevant. Many tools and formats *only* support SPDX license expressions, so it's very useful to make it easy to express simple constructs like "*ONLY* version 2 of the GPL is acceptable". If people think they "need" a LicenseRef, it's often one of two cases: 1. The SPDX license list has an important omission (time to report the license to SPDX, not to use a LicenseRef!) 2. There's a weird license in use by a third party. As a developer or potential user, I'm probably going to just avoid using that software, in which case problem solved... I really don't need a "LicenseRef" to tell me more. If not, I'm going to ask a lawyer to look at the REAL legal text, not the LicenseRef. In that case, "OTHER" works just as LicenseRef to note that there's something different. For people considering whether or not they should use some software, they just need to know if they might be in dangerous waters. Yes, if you have a full SDPX file, more information can be useful. But *lots* of people use SPDX license expressions separately. --- David A. Wheeler ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: GPLv2 - Github example
On Mon, Sep 11, 2017 at 08:26:56PM +, Gisi, Mark wrote: > >> But you can't define a LicenseRef in sitations (like npm [1]) where the > >> only > >> thing you can set is a license expression and you don't have access to the > >> broader > >> SPDX spec. > >> [1]: https://docs.npmjs.com/files/package.json#license > > This is not a problem with the license expression language. It is a > problem with the SPDX identifier mechanism. LicenseRefs are SPDX's > cornerstone way of handling the many many non-standard license > notices found every day in source code. Perhaps, but having an explicit ‘only’ is a cheap way to avoid a LicenseRef in cases like ‘CDDL-1.0 only’. Inlining LicenseRefs in license expressions (or talking external projects like npm into using the full SPDX spec) are both much larger changes. And… > In the above example you don't need an "only" operator… You *do* need this if you want separate license expressions for “I just found the GPL-2.0 text in a separate file, but am not clear on the intended grant” (GPL-2.0) and “this file is GPL-2.0 only” (GPL-2.0 only). There's no way to address that with LicenseRef. You might be able to cover that distinction with PackageLicenseComments [1], but that's not structured. So I see two use cases that a structured ‘only’ operator allows: a. ‘GPL-2.0 only’ is a fairly common license, so having a structured way to declare it seems useful to me (and it's nice to have that structured way be obvious from the license expression). b. Tools that do not look at grants (e.g. licensee, as I linked earlier) are also deployed in high-visibility areas (e.g. GitHub's auto-detected license API [2]), so having a structured way for them to *not* claim “only” vs. “or later” seems useful to me too. Do you believe that one or the other of those cases are not worth supporting? Or do you want to support both, but you prefer a different approach than an ‘only’ operator? Cheers, Trevor [1]: https://spdx.org/spdx-specification-21-web-version#h.41mghml [2]: https://developer.github.com/v3/licenses/ -- 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 signature.asc Description: OpenPGP digital signature ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
RE: GPLv2 - Github example
>> But you can't define a LicenseRef in sitations (like npm [1]) where the only >> thing you can set is a license expression and you don't have access to the >> broader >> SPDX spec. >> [1]: https://docs.npmjs.com/files/package.json#license This is not a problem with the license expression language. It is a problem with the SPDX identifier mechanism. LicenseRefs are SPDX's cornerstone way of handling the many many non-standard license notices found every day in source code. In the above example you don't need an "only" operator you need a way to include LicenseRefs when using SPDX identifiers. LicenseRefs are so important that they need to be addressed in the SPDX identifier mechanism independent of your situation. - Mark -Original Message- From: W. Trevor King [mailto:wk...@tremily.us] Sent: Monday, September 11, 2017 12:18 PM To: Gisi, Mark Cc: J Lovejoy; Marc Jones; SPDX-legal Subject: Re: GPLv2 - Github example On Mon, Sep 11, 2017 at 07:04:57PM +, Gisi, Mark wrote: > >> With the ‘only’ operator proposal [1], this situation can be > >> represented by ‘CDDL-1.0 only’. > > … Finally this case can be elegantly handled with a LicenseRef… But you can't define a LicenseRef in sitations (like npm [1]) where the only thing you can set is a license expression and you don't have access to the broader SPDX spec. > That is, the example represents a rare edge case that does not present > a situation that can't be express with today's current constructs. > Therefore it does not represent a good example > (justification) for adding the "only" operator. It's not the only justification. Having an ‘only’ operator also lets you give a very clear license expression (e.g. ‘GPL-2.0 only’) for grants like: This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License version 2 as published by the Free Software Foundation. which is one of the goals listed in [2]. That's a distinct license expression from ‘GPL-2.0’ for cases like “I found this license text in a separate file, but no clear grant applying it to this project” which is the “GitHub example” that spawned this thread. Although as discussed in this thread, some SPDX authors and tools may feel uncomfortable making a concluded-license call in that case. However, I expect tools like licensee, which only look for stand-alone license files and ignore grant comments [3], will be concluding ‘GPL-2.0’ and similar, and having an explicit ‘only’ operator allows consumers to distinguish those ambiguous conclusions from an explicit ‘GPL-2.0+’ or ‘GPL-2.0 only’. Cheers, Trevor [1]: https://docs.npmjs.com/files/package.json#license [2]: https://wiki.spdx.org/view/Legal_Team/only-operator-proposal#Goals [3]: https://github.com/benbalter/licensee/blob/v9.2.0/docs/what-we-look-at.md#what-about-checking-every-single-file-for-a-copyright-header -- 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 ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: GPLv2 - Github example
On Mon, Sep 11, 2017 at 07:04:57PM +, Gisi, Mark wrote: > >> With the ‘only’ operator proposal [1], this situation can be > >> represented by ‘CDDL-1.0 only’. > > … Finally this case can be elegantly handled with a LicenseRef… But you can't define a LicenseRef in sitations (like npm [1]) where the only thing you can set is a license expression and you don't have access to the broader SPDX spec. > That is, the example represents a rare edge case that does not > present a situation that can't be express with today's current > constructs. Therefore it does not represent a good example > (justification) for adding the "only" operator. It's not the only justification. Having an ‘only’ operator also lets you give a very clear license expression (e.g. ‘GPL-2.0 only’) for grants like: This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License version 2 as published by the Free Software Foundation. which is one of the goals listed in [2]. That's a distinct license expression from ‘GPL-2.0’ for cases like “I found this license text in a separate file, but no clear grant applying it to this project” which is the “GitHub example” that spawned this thread. Although as discussed in this thread, some SPDX authors and tools may feel uncomfortable making a concluded-license call in that case. However, I expect tools like licensee, which only look for stand-alone license files and ignore grant comments [3], will be concluding ‘GPL-2.0’ and similar, and having an explicit ‘only’ operator allows consumers to distinguish those ambiguous conclusions from an explicit ‘GPL-2.0+’ or ‘GPL-2.0 only’. Cheers, Trevor [1]: https://docs.npmjs.com/files/package.json#license [2]: https://wiki.spdx.org/view/Legal_Team/only-operator-proposal#Goals [3]: https://github.com/benbalter/licensee/blob/v9.2.0/docs/what-we-look-at.md#what-about-checking-every-single-file-for-a-copyright-header -- 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 signature.asc Description: OpenPGP digital signature ___ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
RE: GPLv2 - Github example
>> With the ‘only’ operator proposal [1], this situation can be represented by
>> ‘CDDL-1.0 only’.
The above license notice is rare. Furthermore CDDL-1.0, as a license of choice,
has diminished significantly. Finally this case can be elegantly handled with a
LicenseRef. It is for these reasons the CDDL license notice:
* 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.
That is, the example represents a rare edge case that does not present a
situation that can't be express with today's current constructs. Therefore it
does not represent a good example (justification) for adding the "only"
operator.
As a general guiding principle - once a new operator or construct is added, it
is very difficult to undo if necessary. Therefore there should be a high bar
to surmount before a modification is made to any language (let alone the SPDX
license expression language). We should find a collection of compelling source
code examples that provide a practical justification for adding an "only"
operator. Other Suggestions?
- Mark
-Original Message-
From: W. Trevor King [mailto:wk...@tremily.us]
Sent: Monday, September 11, 2017 10:30 AM
To: Gisi, Mark
Cc: J Lovejoy; Marc Jones; SPDX-legal
Subject: Re: GPLv2 - Github example
On Mon, Sep 11, 2017 at 03:40:05PM +, Gisi, Mark wrote:
> 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.
With the ‘only’ operator proposal [1], this situation can be represented by
‘CDDL-1.0 only’. There will no longer be a need for LicenseRef for that case,
which is nice for folks looking to represent that license grant using only a
vanilla licence expression.
Cheers,
Trevor
[1]: https://wiki.spdx.org/view/Legal_Team/only-operator-proposal
--
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
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal
Re: GPLv2 - Github example
On Mon, Sep 11, 2017 at 03:40:05PM +, Gisi, Mark wrote:
> 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.
With the ‘only’ operator proposal [1], this situation can be
represented by ‘CDDL-1.0 only’. There will no longer be a need for
LicenseRef for that case, which is nice for folks looking to represent
that license grant using only a vanilla licence expression.
Cheers,
Trevor
[1]: https://wiki.spdx.org/view/Legal_Team/only-operator-proposal
--
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
signature.asc
Description: OpenPGP digital signature
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal
RE: GPLv2 - Github example (was: Re: New license proposal: Verbatim)
>> 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
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
