License override does not work for third-party dependencies with multiple licenses

[AnatolyPopov]

When I'm trying to use license overriding for a library that have multiple licenses only first license from the list is overridden.
Example:
in generated THRID-PARTY.txt

(ALS 2.0) (GPL v2) (MPL 1.1) RabbitMQ Java Client (com.rabbitmq:amqp-client:5.1.2 - http://www.rabbitmq.com)

When I add

com.rabbitmq--amqp-client--5.1.2=Apache Software License - Version 2.0

to override-THIRD_PARTY.txt file the result is

(Apache Software License - Version 2.0) (GPL v2) (MPL 1.1) RabbitMQ Java Client (com.rabbitmq:amqp-client:5.1.2 - http://www.rabbitmq.com)

Should license overriding replace all the licenses specified for particular dependency?

[ppalaga]

Might some add-third-party expert (e.g. @digulla, @nfalco79, @elballa) please state whether the above behavior is expected?

[AnatolyPopov]

@ppalaga This is clearly a bug. As I can see in the code only the first license in alphabetical order is overridden. Another example:
a library have
(Apache Software License - Version 2.0) (Eclipse Public License - Version 1.0) Jetty :: Continuation (org.eclipse.jetty:jetty-continuation:9.4.11.v20180605 - http://www.eclipse.org/jetty)

and override-THIRD_PARTY.txt file contains

org.eclipse.jetty--jetty-continuation--9.4.11.v20180605=Eclipse Public License - v 1.0

and the result is

(Eclipse Public License - Version 1.0) (Eclipse Public License - v 1.0) Jetty :: Continuation (org.eclipse.jetty:jetty-continuation:9.4.11.v20180605 - http://www.eclipse.org/jetty)

[digulla]

My first instinct would be to reject the override since the project has a license and we shouldn't ignore them on a whim. Unfortunately, many projects have an wrong / useless license name ("apl" - is that Apache? 1.0, 1.1 or 2.0? Or something else entirely?).

I'd suggest to log at INFO level which licenses we override (if the project has some) and then replace the list with the override.

[wollefitz]

My first instinct would be to reject the override since the project has a license and we shouldn't ignore them on a whim. Unfortunately, many projects have an wrong / useless license name ("apl" - is that Apache? 1.0, 1.1 or 2.0? Or something else entirely?).

I'd suggest to log at INFO level which licenses we override (if the project has some) and then replace the list with the override.

Did you come to a decision on how to treat this case yet? We're generating our license book with add-third-party and would like to be able to override licenses for dependencies that let you choose between multiple licenses with the chosen one.

[lama0206]

Did you come to a decision on how to treat this case yet? We're generating our license book with add-third-party and would like to be able to override licenses for dependencies that let you choose between multiple licenses with the chosen one.

We have the same issue here - we're generating a license overview of the dependencies so that we can easily provide our customers with the sources of the libraries that require source distribution (their licenses, that is). To avoid delays (due to discussions) and to make the list more clear, we'd like to override the licenses where one can choose.

Overriding only the lexicographically first license (which is the current implementation) does not make sense anyways. I've changed the implementation so that an override-configuration overrides all license entries from a multi-license project. As suggested by @digulla, the implementation logs these actions to INFO.

[caroso-de]

I can confirm this problem, any updates on the pending pr?

[bmarwell]

Hi @caroso-de – I see no PR.
PRs and reviews are very welcome, we do not have a lot of committers at the moment.

[lama0206]

#374

depending on your judgement regarding the comments there...

[caroso-de]

Hi @caroso-de – I see no PR.
PRs and reviews are very welcome, we do not have a lot of committers at the moment.

Hi @bmarwell, I was referring to #374 from @lama0206. If this works as @digulla suggests, I'd very much like it to be accepted.

If the single merge conflict is all that needs to be done, maybe we can get this thing fixed after all.

[lama0206]

I think that the basic problem has been resolved in the master already (yet without logging etc) - unfortunately the master build is failing (and also the build of my PR).

[lama0206]

@bmarwell the build for the PR runs "on my machine" - I know that's hardly enough. Yet, I don't know what's the problem there:

[ERROR] Failed to execute goal on project test-ISSUE-324-child1: Could not resolve dependencies for project org.codehaus.mojo.license.test:test-ISSUE-324-child1:jar:2.0.1-SNAPSHOT: The following artifacts could not be resolved: org.pentaho:pentaho-aggdesigner-algorithm:jar:5.1.5-jhyde, org.codehaus.mojo.license.test:test-ISSUE-324-child2:jar:2.0.1-SNAPSHOT: Could not find artifact org.pentaho:pentaho-aggdesigner-algorithm:jar:5.1.5-jhyde in local.central (file:///C:\Users\appveyor\.m2\repository) -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal on project test-ISSUE-324-child1: Could not resolve dependencies for project org.codehaus.mojo.license.test:test-ISSUE-324-child1:jar:2.0.1-SNAPSHOT: The following artifacts could not be resolved: org.pentaho:pentaho-aggdesigner-algorithm:jar:5.1.5-jhyde, org.codehaus.mojo.license.test:test-ISSUE-324-child2:jar:2.0.1-SNAPSHOT: Could not find artifact org.pentaho:pentaho-aggdesigner-algorithm:jar:5.1.5-jhyde in local.central (file:///C:\Users\appveyor\.m2\repository)

That's not a problem of this PR (nor of the latest commit 4736bf6 in master...), is it?

[caroso-de]

@lama0206 The dependencies you're using in your it are not locally available during the build. I'd suggest you make your testcase into a tiny aggregator project so that you can build your own dependency with two or more licenses:

aggregator
-> my-dependency (has 2 or more licenses)
-> my-test-module (has a dependency to "my-dependency")

you'd then test against the results of the "my-test-module"

[lama0206]

@caroso-de Thanks for the suggestion. The IT is now running w/ a local dependency.

[caroso-de]

@lama0206 you're welcome. Btw, does your pr also fix aggregate-add-third-party?

[lama0206]

Currently, overriding has to be set in the aggregator's configuration (I didn't change that):

• a/pom.xml -> parent (packaging: pom)
• a/child1/pom.xml -> child 1 (packaging jar) w/ dependency A and licence LIC-A-1.0
• a/child2/pom.xml -> child 2 (packaging jar) w/ dependency B and licence LIC-B-1.0
• a/src/license/override-THIRD-PARTY.properties -> child 1=LIC-B-1.0

produces an aggregated licence list with A (LIC-B-1.0) and B (LIC-B-1.0).

Overriding the license of dependency A in a/child1/src/license/override-THIRD-PARTY.properties does not work.

@caroso-de To be honest: I'm not sure - what's the intended behavior?

[caroso-de]

@lama0206 I'm not sure either, for aggregate-add-third-party this sounds about right though.

[lama0206]

Pragmatically, this means that you'll end up with (possibly) different license reports depending on the report "level": Overriding in the child will not override the license in the parent's list.

I can live with that - if you want to override the licenses in the child and the parent, its a choice you have to make (and document). It's both, a bit counter-intuitive and obvious once you know it.

[caroso-de]

You mean - depending on whether you use aggregate-add-third-party or add-third-party? I'd personally be fine with that though it might not be what's intendet. Maybe one of the maintainers likes to weigh in?

[cowwoc]

Any workarounds for this bug?

[profTwinglings]

It would benefit me a lot because
fixing the bug on license selection for maven plugin is important because it ensures that developers who use the plugin are in compliance with the licensing requirements of third-party libraries that they depend on. Without a fix, developers could potentially use libraries with incompatible licenses, leading to legal issues and potential violations of intellectual property rights. By fixing the bug, the plugin ensures that developers choose licenses that are compatible with their project and the third-party libraries they use. This promotes adherence to licensing requirements and protects against legal risks, ultimately making the development process smoother and more legally compliant.

[lama0206]

THANKS @slawekjaranowski

[profTwinglings]

Thnx @slawekjaranowski!