Hi David: On Mon, Jul 1, 2019 at 9:00 PM Wheeler, David A <[email protected]> wrote: > Philippe Ombredanne <[email protected]> wrote: >> What looks as a version number in an SPDX license identifier is NOT >> like a software version number. This is purely indicative and is not >> something that is specified to have any meaning. Actually nothing in >> an identifier has any specified meaning at all. > > I know, that's the defect we're trying to fix. There's an "or later" > operator in the SPDX license expressions that has no defined meaning. > It *implies* a use of the version number field in the SPDX license id, > but fails to actually state this, so it needs to be stated.
This "+" aka. "or later" operator is indeed in need for a fix. The fix we need is retirement, not expansion. It has served its purpose and is no longer needed IMHO. It has now been replaced mostly by concrete licenses with their own ids. If there is anything we could fix that would be to check if there are **any** license that would need such a variation. I do not known of any that is in any kind of usage, even rare usage. MPLs, CPLs and EPLs do not have such variation (they always allow any other version AFAIK). All the FSF licenses have been taken care of. So I do not think there is anything left. This + seems to be now only a source of bloat and rightful confusion. >> It just happens that as a convenience, folks like to put version >> numbers in licenses and these have been carried on in the license >> identifiers. You could have a license id of 234dssds-23.3475 and >> that would be OK. So please do not start to try to infer versions, >> relations and other things based on identifier strings, that's a >> dangerous slope. >> Instead, you may want and could track relations between licenses, as >> attributes of a license. For instance you could track that EPL-1.0 >> next version is EPL-2.0 and so on. But this becomes an explicitly >> stored relationship and not something vaguely inferred from opaque >> ids. > > Requiring humans to ignore the version numbers embedded in license ids > is the MUCH MORE dangerous slope. > > By that theory it would be okay to have LICENSE-1.0, followed by > LICENSE-3.0, followed by LICENSE-2.0. Then "LICENSE-3.0+" would > include "LICENSE-2.0". That would be horrifically awful for > usability, and basically guarantee mistakes. I am not saying you should ignore anything from an id string... I am just saying that no id part has any special meaning. Actually there are no parts in an id at all and there is no version part. The meaning is in the text referenced by the id and not in the id. Furthermore, the legal team assigns ids sensibly and they would never come with something that does not make sense. So your theoretical case would not happen in practice. Instead, the proper way to track relationships between versions (and more generally between licenses) would be to do that with attributes, not with ids. -- Cordially Philippe Ombredanne -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#3740): https://lists.spdx.org/g/Spdx-tech/message/3740 Mute This Topic: https://lists.spdx.org/mt/32049933/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
