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. Package-level results are the WHOLE POINT. People normally don't use a single file from somewhere else; they use a large suite of packages written by others, and for each package we need to know what our rights & responsibilities are. The license expression syntax generally works well for packages. Are there some problems & struggles? Sure. But let's work on identifying exactly what those problems are, and fix them. --- David A. Wheeler _______________________________________________ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
