I understand and agree with David's concerns - also coming from a tooling perspective.
However, I believe this is a different problem than the FSF issue and a problem we have today with the current license expression syntax and the current license list. It seems we are talking about 2 different usage scenarios for SPDX license expressions: 1) Someone is using a license expression to document what they "know" or assert is the license for a file or package. For example, the copyright owner is adding an SPDX license ID in their file headers. 2) Someone or something is documenting findings on license information for files or packages. For example, a license scanning tool. For #1, we don't want to allow someone to be ambiguous about whether a GPL license is "only" or "or later" when describing a license using SPDX license expressions. I believe this is the issue the FSF is concerned about. For #2, we will find situations where it is not clear if a GPL license is to be used "only" with that version or with that version or later (BTW - it's not just tools that have this problem). We would like to be able to express this situation using SPDX since it is very useful information. On the last legal call, it seemed clear to me that our attempts to solve #2 created a great deal of concern for those trying to solve #1. In order to make progress, I still feel we should divide and conquer solving the FSF issue first then addressing the ambiguous license version issue in a future release of the spec. Perhaps we can come up with a more generalized solution for ambiguous license findings for #2 if we had more time to design and discuss the solution. One additional thought: We could use a LicenseRef to document the exact text of the ambiguous license version and add a license comment to indicate it is GPL, just not clear which version. The LicenseRef approach would only work for SPDX documents and would provide more information than a NOASSERTION. Gary > -----Original Message----- > From: spdx-legal-boun...@lists.spdx.org [mailto:spdx-legal- > boun...@lists.spdx.org] On Behalf Of Wheeler, David A > Sent: Friday, November 17, 2017 3:20 PM > To: brad.edmond...@gmail.com > Cc: SPDX-legal > Subject: RE: update on only/or later etc. > > Brad Edmondson [mailto:brad.edmond...@gmail.com] > > I think your points are good ones, but it seems to me they go to the > > separate issues of "file:detected license" and "package:concluded license." > The clarity of the spec argument is aimed at making the "file:detected > license" case more explicit, and if it leaves tools with NOASSERTION for > "package:concluded license," then I think that's OK, no? > > No, it fails to work for multiple reasons: > 1. "NOASSERTION" is basically useless, because it provides no information. In > many cases, all I need to know is "there's a version of the GPL here", and I > can make a decision. Being able to provide *some* information is often all > that's needed , while providing *no* information creates a lot of unnecessary > work for tool users. > 2. Tools, lacking sentience, often cannot determine whether or not "or later > versions" applies. So they're unable to be "more explicit" in > package:concluded. The current structure requires that conclude either "only > 2.0" or "2.0 or later"... even though tools typically CANNOT make that > determination. SPDX should make it possible report the information *actually* > available. > 3. The majority of SPDX users do not use SPDX files. Instead, they *only* use > SPDX license expressions (as available in package managers, file content > declarations, etc.). So there's no "file:detected" vs. "package:concluded" > entries to compare anyway. > > --- David A. Wheeler > > _______________________________________________ > 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
