Skip to content

Fix licensed libraries without URL classification - #188

Open
akilegaspi wants to merge 2 commits into
sbt:mainfrom
akilegaspi:main
Open

Fix licensed libraries without URL classification#188
akilegaspi wants to merge 2 commits into
sbt:mainfrom
akilegaspi:main

Conversation

@akilegaspi

Copy link
Copy Markdown
Contributor

Some Libraries indicate a license without a url which gets defaulted into NoneSpecified which breaks license categorization for these libraries

This change fixes that problem

Libraries which indicate their license but without url gets defaulted into NoneSpecified which breaks license categorization for these libraries
This change fixes that problem
@mdedetrich

Copy link
Copy Markdown
Contributor

Thanks for the PR, would it be possible to write a test for this? There are already a lot of example tests and since you have an example (webjars) it shouldn't be too hard.

@akilegaspi

Copy link
Copy Markdown
Contributor Author

Will do!

@mdedetrich

Copy link
Copy Markdown
Contributor

Thinking about this now, I am wondering whether its a better idea to do this more comprehensively, i.e. rather than casting a missing url entry to empty string instead we should explicitly handle this case by looking up the dependency chain.

@akilegaspi Do you want to see if this is easily possible? i.e. something like

licenses.map { case (name, optionalUrl) =>
  (name, optionalUrl.orElse(licenses.find{
     //do logic here to find parent artifact that may have the apache url
   })
}

You will probably need to modify pickLicense to pass in the originatingModule which will hopefully have the parent artifact containing the url.

@akilegaspi

akilegaspi commented Nov 27, 2025

Copy link
Copy Markdown
Contributor Author

Been thinking about this for quite sometime, I don't think we should attempt to resolve a license for a child artifact from a parent artifact in the case that these two libraries might be licensed differently, this would work if we could be sure that the artifacts do have provably equal licenses which could only be known by actually having that information.

We have this setting key

val licenseOverrides = settingKey[PartialFunction[DepModuleInfo, LicenseInfo]](
      "A list of license overrides for artifacts with bad information on maven."
)

But currently it isn't used as described and actually overrides for all artifacts instead of the described behavior and I think this should be used instead to actually allow overriding LicenseInfo for artifacts which have incomplete information, currently it's described for overriding artifacts which have "bad" information but what does "bad" mean in this case

Another way I could think of to not break behavior for downstream users is to introduce a new setting key which acts the same as licenseOverrides but only for artifacts which have missing url.

What do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants