Some licenses in the tree aren't named by their SPDX short identifier. Tools that do automated license checks depend on this to have some kind of standard. e.g. https://opensource.org/licenses/BSL-1.0 is in the tree as Boost-1.0
I'm pretty sure this was already requested in the past and rejected but I can't seem to find the bug.
I remember a discussion in the licensing team a long time ago, I think we kinda agreed that using SPDX names is a good thing and we'd do it for new licenses. But we didn't make it a strict rule and haven't made any effort to rename existing licenses. I personally think it'd be a good thing to always use SPDX identifiers when available.
Exactly, we consider using the SPDX identifier when adding a new license, but we don't change the ones that we already had before SPDX added them. If we had renamed our identifiers to the SPDX ones, then we would already have renamed them twice again, because the SPDX ones were changed. This even applies to popular licenses like the GPL. Plus, there will always be licenses without an SPDX identifier. Another problem is that their identifiers tend to be chatty (e.g., GPL-2.0-or-later instead of our GPL-2+), which may be acceptable for labelling a single file, but doesn't scale well to our LICENSE strings with several licenses. If we want to support automatic checks, how about a mapping file from our license identifiers to the SPDX ones instead? This would come with the additional advantage that licenses unknown to SPDX could be flagged, and it would be easy to update in case of future SPDX changes.
Please also note that we don't have 'license moves'. So if we rename a license, we either need to keep the old file for a very long time, or we instantly break all overlays.
license map could be useful indeed and can be consumed by qa and ebuild tools (like cargo-ebuild)
I think I'll look into adding a license map based on what we have in cargo-ebuild right now. Probably just a plain key=value file, and WITH handled as part of key.
(In reply to Michał Górny from comment #6) > I think I'll look into adding a license map based on what we have in > cargo-ebuild right now. Probably just a plain key=value file, and WITH > handled as part of key. IIRC the TeX team also has a mapping file for the licenses that occur in TeX Live.
One thing I'm wondering about is how to handle the "+" syntax of SPDX, e.g.: MPL-1.0+ Technically, we don't have an exact match for this. We could do something like: || ( MPL-1.0 MPL-1.1 MPL-2.0 ) However, as every approximation this has the disadvantage that if new licenses are added in the future, the earlier license entries no longer match. We could also avoid special treatment for now and revisit if we actually hit such packages.
I thought the + operator was (semi-)deprecated in the latest version of SPDX? For example, what used to be GPL-2.0+ is now GPL-2.0-or-later. (In reply to Michał Górny from comment #8) > || ( MPL-1.0 MPL-1.1 MPL-2.0 ) Yes, I'd go for that. It's a minor issue IMHO.
(In reply to Ulrich Müller from comment #9) > I thought the + operator was (semi-)deprecated in the latest version of > SPDX? For example, what used to be GPL-2.0+ is now GPL-2.0-or-later. Nope. Apparently for GPL they use the more verbose forms because of how GPL is but for other licenses `+` is still a thing.
(i.e. `+` is only discouraged if there is a more verbose alternative available)
