>> 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
