declared-license-mapping: Remove conflicting BSD license mappings

[sschuberth]

It does not make sense to map "BSD License" and "The BSD License"
differently. In fact, the version cannot be told in either case. So simply
remove both mappings.

As an example why the version cannot be assumed, take [1] where "The BSD
License" is supposed to mean BSD-3-Clause instead of BSD-2-Clause.

[1] https://repo1.maven.org/maven2/org/antlr/antlr4-master/4.7.1/antlr4-master-4.7.1.pom

Signed-off-by: Sebastian Schuberth [email protected]

[tsteenbe]

If we can't assume the version of BSD license then the solution to go for in my view is to map it to something like LicenseRef-ort-bsd-family.

In this way we still produce a valid SPDX id but it will allow ORT admins to create a rule violation with a how to fix text explaining that "LicenseRef-ort-bsd-family" is a catch-all/generic SPDX license id for cases (similar to LicenseRef-scancode-other-permissive) where version of the BSD license could not be determined and that the user has to add manually determine the version and then add a declared license curation to curations.yml.

[sschuberth]

If we can't assume the version of BSD license then the solution to go for in my view is to map it to something like LicenseRef-ort-bsd-family.

Interesting idea, let's give it a try.

[fviernau]

bsd-family.

If we can't assume the version of BSD license then the solution to go for in my view is to map it to something like LicenseRef-ort-bsd-family.

In this way we still produce a valid SPDX id but it will allow ORT admins to create a rule violation with a how to fix text explaining that "LicenseRef-ort-bsd-family" is a catch-all/generic SPDX license id for cases (similar to LicenseRef-scancode-other-permissive) where version of the BSD license could not be determined and that the user has to add manually determine the version and then add a declared license curation to curations.yml.

This introduces a "generic" license identifier.
In my experience generic license identifiers are a bit trickier to deal with compared to not mapping the license at all.

Further, the user needs to understand the semantics of this license identifier before he can make a mapping.
To understand the semantics the user needs to go through the ORT mapping file and maybe even do a git blame to figure out the library this entry was introduced for.

Finally, if the user is interested in NOTICE files, the user needs to map that "family" license anyway, so no effort is saved.
Even if the user is not interested in notices, but only in copyright by license the user needs to re-map it.

Given the above I'd not prefer to introduce such "family" license identifiers at all in such cases.
@tsteenbe @sschuberth what do you think?

edit: I've added the missing "not" @sschuberth you mentioned below

[sschuberth]

Given the above I'd prefer to introduce such "family" license identifiers at all in such cases.

Is this lacking a "not" somewhere?

[sschuberth]

Independently of @fviernau's (reasonable) comments, I also ran into practical issues to apply a "family"-style mapping: It would consequently also require to map the "BSD" license in simple-license-mapping.yml to LicenseRef-ort-bsd-family, but the values in that mapping may only be SpdxLicense enums, not LicenseRefs. That's basically the same issue that blocks me in #3347, and solving this requires quite a bit more work.

TL;DR, for now I'd agree with @fviernau that simply removing these conflicting mapping is the better approach.

[fviernau]

If we do want to create a mapping in ORT, I believe we should introduce a way of mapping analog to the way we have in curations.
E.g. make a mapping specific to the 'Identifier' or to the 'Identifier' excluding the version.

[sschuberth]

If we do want to create a mapping in ORT, I believe we should introduce a way of mapping analog to the way we have in curations.
E.g. make a mapping specific to the 'Identifier' or to the 'Identifier' excluding the version.

Why do we need something analog to curations, if curations already support exactly that use-case? I'd rather go forward and finally start publishing (some of) our existing curations, which is something that we were planning to do anyway.

[fviernau]

Why do we need something analog to curations, if curations already support exactly that use-case?

My main point was (1) "doing it in ORT" and (2) in a way specific to the ID. How exactly doesn't matter for my proposal above.

I'd rather go forward and finally start publishing (some of) our existing curations, which is something that we were planning to do anyway.

Makes sense.

[sschuberth]

So, I went back and restored the original change which just removes the conflicting mappings.

The consensus was to not introduce something like "LicenseRef-ort-bsd-family".