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 http://www.gnu.org/licenses/license-list.html#EPL 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:
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.