> From: Vladimir Sitnikov <sitnikov.vladi...@gmail.com> > It looks like you are inclined that "SDPX should have some definition of > or-later". That is good to know.
I think standards should be as clear and precise as possible, so sure. David>Maybe we should claim that a version number is the first match > How about Spencer-86, Spencer-94, Spencer-99? > How about Unicode-DFS-2015, Unicode-DFS-2016? > W3C-19980720, W3C-20150513, W3C? None of those match the proposed pattern, so by my proposal none of them have a version number. I'm fine with that. The Spencer-86 can be reworked that as Spencer-86.0. If someone wants something different propose that instead. > David>Maybe we should claim that a version number is the first match after a > "-" to some pattern like this regex: > How that classifies 1.3a vs 1.3c? Is "c" a part of the license name? Yes, as defined by the proposed regex, and I did that on purpose. This is all just a discussion right now, of course. Perhaps people think a different pattern would be better. But "1.3c" is a plausible version number. David> regardless of what the license text says > I'm sure one should not specify "Bundle-License: CC-BY-SA-2.0" and overrule > it for "just 2.0" at the same time. That is *EXACTLY* what the Linux kernel and Busybox do - they take the GPL 2.0 license and say, "exactly and only this license". Overruling a license text to fix the version number is not at all unusual. Some lawyers require it, because they can't see all possible future versions, and thus will only approve releases under licenses they can review. > Either the author uses "the canonical SPDX variation of CC-BB-SA-2.0" or the > license is different (== its SPDX expression must be different from > CC-BB-SA-2.0). No, because it is *NOT* a different license. Let's look at the world as it *is*. All a tool can typically analyze with any confidence is that the license text in the LICENSE file matches some license text (e.g., the CC-BY-SA-2.0 license). But that is true in either the "or later" or "not or later" case. To do better, a tool would have to reliably read natural language prose & provide good justification for that decision. This is a tension that I've documented a number of times before: 1. Some people want to record using SPDX what the license of the software actually *is*, as that is important for determining rights. It's completely reasonable to want this. 2. In reality we must often use automated tools, which CANNOT do this in general. Tools can generally only report "a license text I've found" or "A SPDX license expression I've found", and that is not the same thing as the actual licensing. Yes, they can (and are) programmed to detect specific cases, but it's not reliable enough to guarantee anything. I think it's reasonable to depend on an expressly stated SPDX license expression, but not all software has one (yet :-) ). We need a better way for SPDX to report "I found this license, I don't know if 'or later' applies". Just because the *default* of the license is that "or later" applies doesn't mean that it actually applies in the case of a particular piece of software, and there's no way to indicate this. It's already hard enough to determine if a license actually matches at all. The most widely-used license analysis tool (in terms of users) is licensee, because that's how GitHub determines what license is used for its display. That uses a probabilistic analysis of the LICENSE file (or similar) and that is *all* it does - it does NOT attempt to examine the README and so on. SPDX maintains a more complex pattern system for matching licenses, but again it CANNOT tell if the README adds "only this version". > It might be SPDX standard should allow "-only" optional modifier for all > license ids (e.g. CC-BY-SA-2.0-only), however that is a bit different story. There are three cases for any given license: 1. This license, this version only 2. This license, this version or any later version 3. This license, and I *DO NOT KNOW* if "or later" applies. SPDX is incapable of reporting case 3, and that's a problem because that is the *ONLY* kind of information available from tools in many cases. So if you want to strongly define "or later", you also should tackle of reliably reporting "or later status unknown". --- David A. Wheeler -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#3734): https://lists.spdx.org/g/Spdx-tech/message/3734 Mute This Topic: https://lists.spdx.org/mt/32049933/21656 Group Owner: spdx-tech+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
