One key difference between building software products in Java versus .NET is the preponderance of open source libraries in the Java space. In .NET, most companies are content to go with a fully Microsoft stack and, after Microsoft’s anti-open source campaign of the mid-2000s, are wary of letting open source creeping into their code base. However, with antiquity and incompleteness of the core Java libraries, only a crazy or paranoid company would shy away from taking advantage of the wealth of open source libraries available.

This profusion of open source creates two challenges: dependency management and license verification. For dependency management, we use Maven 2. I’m not a big fan of Maven’s build lifecycle, but it does a reasonable job of dealing with dependencies. This past week, Cailie set up the Maven report plugin to generate a report detailing the project’s dependencies and their associated open source licenses. Very useful stuff, and a great application of the metadata associated with each dependency in the Maven repository. We have the reports regenerated as part of our automated build process, so that we can always see the project’s current dependencies and their associated licenses.

Unfortunately, only about half of the open source libraries that we use have their licenses specified in the central Maven repo. For those that do, they all tend to name their licenses differently (“Apache Software License V2.0″ vs. “APL 2.0″ vs “Apache 2″) as the license field is free text, which impedes the readability of the report. And there are always projects that use licenses like “Bob’s Open Source License”, but you would really only know that it is a BSD-derivative (with or without the attribution clause?) by carefully reading the license.

For those dependencies without license metadata in the central repository, the recommended approach is to load those dependencies into an in-house repository with a custom pom specifying the appropriate license. This is a serious pain in the ass. Also, this only works for dependencies managed by Maven (what about javascript libraries, etc?). A nicer approach would be an extension to the maven report plugin that allows metadata to specified for each dependency. Maybe one of these days I’ll get the time to make this extension. In the meantime, we’ve got license information spread across the report and our wiki.