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