On Thu, 2020-04-23 at 08:15 -0700, Gary O'Neall wrote: Hi Vladimir, This may deserver a different thread, but you raise some good points on limitations on the license expressions below. Have you raised any of these issues with the SPDX group?
I can think of a few solutions: Note: unfortunately, SPDX license expressions are not well-defined. For instance, there are license terms that allow the use of "this or later version of the license". GPL-2.0+ license expression is likely to mean "GPL-2.0 or GPL-3.0 or ...", because "+" means "or later", however, SPDX provides no relationship between GPL-2.0 and GPL-3.0. There's no metadata that tells that GPL-3.0 is a later version of GPL-2.0. Well, there is the license version number itself which is incremented (2 -> 3). That can perhaps be considered metadata. [G.O.] We could introduce some license metadata in the license XML schema to describe which licenses are versions of the same license. This seems like a bad idea. You're going to likely use hashsums or UUID and not bury this in some XML file. There is a similar proposal for license families. The limitation in implementing the suggestion is volunteers to mark up the license data – if this is an important issue for you and you have bandwidth to help – this can probably be solved. On the other hand, there's GPL-2.0-or-later "license" which is effectively the same as GPL-2.0+ [G.O.] No comment on this one – there were a lot of factors that went into the discussion and decision – I agree it is confusing At the same time, "CC_BY_NC_1_0" means "CC_BY_NC_1_0 or CC_BY_NC_2_0 or CC_BY_NC_2_5 or .." because the license text for CC_BY_NC_1_0 contains explicit permission to use the package under later versions of the same CCBYNC license. [G.O.] This one we probably won’t tackle as it is interpreting the license. SPDX explicitly stays away from license interpretation and tries to stay with the facts. There are other efforts out there which do provide some machine readable interpretation such as the FINOS License Compliance Handbook<https://www.finos.org/blog/announcing-the-open-source-license-compliance-handbook> which is compatible with SPDX. I was ready to really hate that handbook, but it looks pretty darn good. SPDX contains **no** metadata on license equivalence (==SPDX says nothing on what "+" license modifier does), so the checkers would have to implement that on their own (which might result in different implementations by different checkers :( ). But is this flexibility a bad thing? You're going to have to create your own rule engine anyway as every organization has different policies. [G.O.] See SPDX Spec Appendix IV<https://spdx.org/spdx-specification-21-web-version#h.jxpfx0ykyb60> “An SPDX License List Short Form Identifier with a unary"+" operator suffix to represent the current version of the license or any later version. For example: GPL-2.0+”. If you feel this definition can be improved, you can submit a pull request for the next release in the SPDX Spec Github repo<https://github.com/spdx/spdx-spec>. Regards, Jeremiah ._,_ ________________________________ This e-mail and any attachment(s) are intended only for the recipient(s) named above and others who have been specifically authorized to receive them. They may contain confidential information. If you are not the intended recipient, please do not read this email or its attachment(s). Furthermore, you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and then delete this e-mail and any attachment(s) or copies thereof from your system. Thank you. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#3876): https://lists.spdx.org/g/Spdx-tech/message/3876 Mute This Topic: https://lists.spdx.org/mt/73090505/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
