How does Insight handle conflicting OSS licenses?

May 16, 2012 By Mike Hansen

As we’ve been busy building out the Insight product line we’ve spent significant time considering the issues associated with “conflicting” and “invalid” licenses — licenses which upon consumption preclude further redistribution without being in violation of the licensing terms.  Conflicting (or incompatible) licenses are problematic for development organizations using open source software as there is no effective way to consume and then redistribute the software (or derivative work).  You simply cannot combine GPL and EPL 1.0, for example, because it is not possible to maintain compliance with all licensing obligations specified by both under any licensing construct upon further distribution.  EPL cannot be consumed within GPL and vice versa.  See for additional information.

If you consume both EPL and GPL in a Maven POM or another build, and then you subsequently ship that software, you would not be able to satisfy your obligations as a distributor and would therefore be in violation of one or both of the licenses.   As developers, we have enough to worry about already.  This a job best done by the tools we use — in this case Insight for CI and Nexus Professional.  Depending on your circumstances, having your CI system alert upon detecting incompatible licensing constructs at build time reduces risk and costs by catching problems early in the development lifecycle.

Invalid license constructs are similar to conflicting licenses in that they also create a situation where a distributor is not able to meet all of the required license obligations specified by all open source components included.  The difference is that the licenses are in fact compatible, just that they are not valid in the particular direction specified.  For example, you cannot move from nonpermissive to permissive, such as GPL to BSD.  But, using BSD licensed code within a broader GPL work is perfectly acceptable.

An example scenario:

Someone integrates a GPL licensed artifact into their code but (incorrectly) chooses a BSD license for the combined work.  This is an invalid license structure since the GPL is a non-permissive license and BSD is.  The GPL does not allow for a reduction in the rights expressly granted to the consumer, which is what is implied by a BSD license — e.g. as a consumer of BSD, you are not entitled to receive a copy of the source code from the distributor but with GPL you are.  There is no way, under the BSD license, for a distributor to fully satisfy the obligations of the GPL, hence this arrangement is invalid.

As part of developing this product, we’ve consulted with legal professionals who have given us guidance on handling invalid and conflicting licensing.  The short version:

  • Sonatype’s licensing products only report factual information.   Our products don’t give specific legal advice.  (In other words, Insight for CI and Nexus Professional are not a substitute for a qualified legal professional.)
  • Obligations shown for an artifact must be the set of all obligations of everything in a particular JAR regardless of hierarchy.   This is why you might be surprised every once in awhile by an artifact that advertises itself under an Apache 2.0 license that is listed as a potential LGPL or GPL artifact.    Licensing isn’t about intent, it is about what the end product’s resulting obligations are given a combination of artifacts covered by various licenses.
  • Sonatype products effectively identify “invalid” and “conflicting” licenses and highlight these occurrences.   If there is an artifact in your repository that is covered by two licenses that cannot be combined that’s something we will flag so that you understand the potential distribution risks implied.

Such a situation has an element of risk for a customer.  We identify such risks, and call attention to the potentially problematic combinations.   Again, our products are not in the business of rendering legal opinion, we’re just here to report the facts.  It is an exercise for the user to determine the implications this might have given their unique circumstances.

Most developers don’t spend much time thinking about these types of licensing issues.  Who needs more work to do?  Yet, every day, developers consume open source components often without giving these considerations much thought.  This means that when an organization ultimately decides to take a look at licensing they can uncover issues they never knew existed, occasionally nestled deep within their application’s dependency graph.  Often times, there is also no path to remediation since the work in question has already been distributed.   In short, you could be compelled to meet the obligations of hidden viral licensing — perhaps through open sourcing your intellectual property.