Philippe Ombredanne <pombreda...@nexb.com> > 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. > 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. Vladimir: > Could you please provide an example for CC-BY-SA-2.0? (or later version of > that license) I can't, because CC-BY-SA is usually not used for software, and I've been focused on software licenses. Maybe someone who focuses more on media can do that. But no matter what, clearly requiring specific versions of licenses for *software* is a thing. The spec should include, as much as reasonable, a few operators that "just work in all cases". It's fair to include special cases for important circumstances or backwards compatibility, but simple generalization is generally best. --- David A. Wheeler -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#3738): https://lists.spdx.org/g/Spdx-tech/message/3738 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] -=-=-=-=-=-=-=-=-=-=-=-
