Always look for matches in fallbacks.edn and add those licenses to the dep's license list; effectively this wouldn't only be a fallback mechanism anymore, but also a manual "extension" mechanism. This is a trivial change, but means that deps such as org.slf4j/log4j-over-slf4j would be incorrectly listed with two licenses (in this case Apache-1.0 and Apache-2.0).
Add an overrides.edn file to the data, and treat it as a true override i.e. match deps in there first, and if there's a hit use whatever that file says and completely skip any automatic license detection within the dep's artifacts.
For pom.xml files, make license URL matching take precedence over license name matching, and also figure out why it isn't working for this specific dep.
Turns out there was a bug in the code that attempted to match license urls in pom.xml files with licenses. With that fixed, the specific issue with org.slf4j/log4j-over-slf4j went away.
org.slf4j/log4j-over-slf4j
is detected asApache-1.0
, due to the ambiguous license text included in the project'spom.xml
file. It is, in fact,Apache-2.0
as can be seen from the pom's license URL.Some possible solutions:
fallbacks.edn
and add those licenses to the dep's license list; effectively this wouldn't only be a fallback mechanism anymore, but also a manual "extension" mechanism. This is a trivial change, but means that deps such asorg.slf4j/log4j-over-slf4j
would be incorrectly listed with two licenses (in this caseApache-1.0
andApache-2.0
).overrides.edn
file to the data, and treat it as a true override i.e. match deps in there first, and if there's a hit use whatever that file says and completely skip any automatic license detection within the dep's artifacts.pom.xml
files, make license URL matching take precedence over license name matching, and also figure out why it isn't working for this specific dep.