Last week I learned about the License Maven Plugin's real
value. As developers, we usually just want to do our work and therefore
become upset about "unimportant" things that get in our way. One of
these things that we don't like to think about are licensing terms. When
we find a library, we want to use it - and not undergo a tedious
governance process which includes a deep analysis of the library's
license, the library's dependencies' licenses, the dependencies'
dependencies' licenses etc.
For me, it's "always" been normal just to grab the
dependencies that I need from "somewhat" trustworthy sources. However,
when you develop commercial software, there are some legal implications.
One of the main considerations is the license question. And since more
and more libraries depend on other libraries themselves, you must
examine the whole tree. Doing this manually can take up a lot of time.
Take for example the Smooks library I'm currently looking at. It's more than a library; Smooks defines itself
rather as a framework. It is used to process different data file
formats and perform transformations between them. The project has been
in development for several years now and as such "naturally" picked up a
lot of 3rd party dependencies over this time.
Now imagine yourself sitting there as a developer who wants
to use this library (or in this case framework). So you go ahead and
add it to your maven dependencies. You mention this to your
colleagues/team lead/... Suddenly, somebody with authority steps in and
asks: "Did you check the license terms? And what about all the
dependencies we're pulling in transitively now?"
This situation is far more common than most of us will like
to admit. Of course, you can now go ahead and check the specific
library's license, then look at its dependencies and do the same with
these - all manually. But if the dependencies have dependencies which
again have dependencies and so on... - well, you get the picture. This
will probably work out quite fine for a simple library with dependencies
that go no deeper than two levels. Beyond that, you can decide to either
keep an intern busy for a day or two - or look for a technical tool.
The technical tool I found is the above mentioned License
Maven Plugin. The usage page is a bit massive, but for my
relatively simple purposes, these steps were sufficient:
- Add the plugin to the build section within the main Maven POM:
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>license-maven-plugin</artifactId>
<version>1.8</version>
</plugin>
</plugins>
</build> -
Call mvn license:aggregate-add-third-party. In case of a single module project, you'd instead use the goal add-third-party.
-
This will produce a file called THIRD-PARTY.txt in the folder target/generated-sources/license of the project you made the call in.
-
This file lists all dependencies (including the transitive ones) in all child modules with their associated licenses (or Unknown license if that particular dependency contains no license information).
This file is what you can pass on to whoever asks you this kind of annoying question. Enjoy!
