How do you manage the licenses of the dependencies (libraries) of your project? [closed]

Answer 1

A customized solution for use with Artifactory + Ivy + ant is to scan each module for license information. If the license is found, populate that license file in Artifactory and update it's ivy.xml to have it available as a published artifact. Then call <ivy:retrieve/> to fetch the license along with its jar file.

The license can be specified within the module's ivy.xml as a URL. In this case, use ant's get task to download the license and write it to a text file.

[inside log4j's ivy.xml as an example]
<ivy-module xmlns:m="http://ant.apache.org/ivy/maven" version="2.0">
 <info organisation="log4j" module="log4j" revision="1.2.16" status="integration"
        publication="20120620150430">
  <license name="The Apache Software License, Version 2.0" 
  url="http://www.apache.org/licenses/LICENSE-2.0.txt"/>
   ...
 </info>
</ivy-module> 

Alternatively, the license can be included as a text file within the module's .jar file. In this case, use ant's unjar task to extract the license and write it to a text file.

[inside junit's .jar file as an example]
 junit-4.8.2.jar/LICENSE.txt

Once the license has been written out as a text file, use ant's xmltask task to add the license as an artifact.

[inside log4j's ivy.xml as an example]
<publications>
 <artifact conf="master" ext="jar" name="log4j" type="bundle"/>
 <artifact conf="sources" ext="jar" m:classifier="sources" name="log4j" type="source"/>
 <artifact conf="javadoc" ext="jar" m:classifier="javadoc" name="log4j" type="javadoc"/>
 <!-- next line added -->
 <artifact conf="master" ext="txt" name="log4j" type="license"/> 
</publications>

Publish the modified ivy.xml and the license back to Artifactory.

<ivy:resolve file="${ivy.xml}" />
<ivy:publish resolver="${resolver}" pubrevision="@{rev}" status="integration"
 overwrite="true" forcedeliver="true" haltonmissing="false"
 srcivypattern="${ivy.local}/[organisation]/[module]/ivy-[revision].xml" >
  <artifacts pattern="${ivy.local}/[organisation]/[module]/ivys/ivy-[revision].[ext]" />
  <artifacts pattern="${ivy.cache.dir}/[organisation]/[module]/licenses/[module]-[revision].[ext]" />
</ivy:publish>

Use <ivy:retrieve/> to fetch the license along with its jar file when bundling with your build.

<ivy:retrieve pattern="${ivy.local}/[artifact].[ext]" conf="compile, runtime" type="jar, license" />

Answer 2

The Artifactory functionality can be emulated using the Maven license validator plugin

http://code.google.com/p/maven-license-validator-plugin/

The practical problem with both these approaches that very few Maven Central modules have up-to-date license information in their POMs. So from what I can see this is a great idea which falls short of a real solution to the problem of assessing your build's license compliance...

My ideal solution is an external set of processes which scan the contents of the Nexus repository for available license information. This information is then used to seed the Nexus Professional's procurement suite to control the contents of an approved repository for use in release (non development builds).

Some binaries contain textual license files and alternatively the associated source code packages could be also be scanned for license and IP information. A number of 3rd party tools are available to perform this task. The ones I've been considering are:

• http://fossology.org/
• http://www.openlogic.com/discovery/
• http://www.blackducksoftware.com/

In conclusion, until Maven Central can provide reliable meta data on module licensing, I think solutions to this problem will remain highly customised and sub-optimal

Answer 3

The approach taken by Artifactory is a bit different, since raw artifact metadata is only used as starting point, but at the end of the day users can complete and amend missing/incorrect license information:

1. At first, POM (including all parent POMs) or Ivy descriptors are used to extract heuristic license information. This auto-discovery step is purely optional.
2. This license information is then attached to artifacts based on their checksum, and is fully editable by users. Admins can update the license details which will stick with the artifact for its lifetime.
3. Every license can be approved or unapproved according to a global policy.
4. At deployment time the license info of all dependencies is read - if unapproved or unknown licenses are found an email alert with the information is sent to preconfigured addresses.

This lets you deal with changes/additions of new dependencies (and their respective licenses) as soon as they are committed and picked-up by the build process.

Another key difference is the ability to handle artifacts with multiple-licenses, where only one of the licenses is approved and the others are not.

You can read more about it here -

http://wiki.jfrog.org/confluence/display/RTF/License+Control