I recently received a question from a client who had run an Application Health Check. They wished to understand why we highlight certain licenses in the health check report:
Regarding the ‘License-Copyleft’ – some libraries have e.g. a LGPL license and a CDDL/GPL license:
- Using the LGPL license shouldn’t be a problem in my opinion – or let me ask the other way around: Where do you see problems using LGPL based libraries?
- For the dual licensed CDDL/GPL licenses we chose the CDDL license and not the GPL license – thus everything should be fine, right?
The first thing to understand about the Health Check feature is that results are meant to be only indicative, and are in no way meant to say GPL/LGPL licences are necessarily bad. What the the health check illustrates is the different licenses based on a standard policy we’ve set to evaluate against. We do appreciate that every application and organisation has their individual use cases and sets of constraints. That’s why our Nexus Lifecycle app, the ‘commercial’ version of the application health check, will allow you to define these policies down to individual conditional values to suit your needs.
Regarding the ‘License-Copyleft’ – some libraries have e.g. a LGPL license and a CDDL/GPL license, you asked: * Using the LGPL license shouldn’t be a problem in my opinion – or let me ask the other way around: Where do you see problems using LGPL based libraries?
According to the Free Software Foundation (FSF), the custodians of the GPL licences, the LGPL in relation to Java has the following implication:
“When you distribute the library with your application (or on its own), you need to include source code for the library. But if your application instead requires users to obtain the library on their own, you don’t need to provide source code for the library.”.
This can be problematic in some cases, since if the component’s source code is modified, it necessitates releasing the modified source of that component.
It’s only the source of the component itself.
Your second question was the choice of licenses: * For the dual licensed CDDL/GPL licenses we chose the CDDL license and not the GPL license – thus everything should be fine, right?
The application health check highlights three things in the licenses. The observed license – which is what the source code of the JAR says in its’ headers, the Declared license, which is the licence the original author has declared the licence to be when publishing to maven central, and finally the effective license which is the assumed effective license of the application.
In case of dual licensing, we use the highest risk category for the license to draw your attention to these components so you can assess the risk. We would rather you look at the potential copyleft nature and decide that CDDL is fine, than assume it’s ok and have some higher risk overlooked.
Latest posts by Ilkka Turunen (see all)
- The Latest Victim of Deserialization-Gate - November 23, 2015
- Nexus and SSL - November 4, 2015
- 3 Things Developers Can Learn from the Scandal at VW - October 28, 2015
- Automating Nexus Deployment: Cookbooks, Modules and Playbooks - August 18, 2015
- Using the REST API in Nexus 2.x - August 13, 2015