<iframe src="//www.googletagmanager.com/ns.html?id=GTM-TT8R4P" height="0" width="0" style="display:none;visibility:hidden">
Stay updated on the latest news from
the makers of Nexus
When Licenses Meet Reality, the Result is Often Confusing
by Jamie Whitehouse on May 17, 2012

One of my responsibilities at Sonatype is creating the pages that communicate licensing and security information in Nexus Professional and Insight for CI. We have a large team that is responsible for these pages and making sure that we’re providing accurate information. You would be surprised at the number of interesting edge cases that we identify in the process of scanning 400,000+ artifacts in Central. From invalid licenses to exotic, one-off licenses that include odd requirements, everyone who works on this team has had to become an expert in OSS licensing.

The following post about Meteor, a new, node.js-based approach to building web applications backed by MongoDB got my attention because it highlights some of the tricky integration issues we’ve had to think about when coming up with hypothetical use-cases for Insight. Here's a quote that captures the complex relationships between Meteor, originally a GPL-licensed Javascript library, and an Apache-licensed library to access MongoDB:

From Olov Lassus’s popular blog post “Meteor meets NoGPL”

“The copyleft (viral, contaminating, whatever you want to call it) aspect of GPL is tricky. Take MongoDB as an example. Meteor uses it by importing the node-mongodb-native package (require('mongodb')). That one is Apache 2.0 licensed, which is a permissive license that happens not to be compatible with Meteor’s GPL (v2) license, at least not according to the FSF. Tricky. Dependency chains, bindings between JS ↔ C and RPC makes it trickier even. I wouldn’t be surprised to see Meteor change to a GPL + a-bunch-of-OSS-exceptions license similar to what Qt and MySQL used to have, to avoid issues like this.”

Don't get me wrong, I'm not questioning the Meteor team's right to choose whatever license they want, but I noticed this post because these are the kinds of relationships that we've been trying to sort out between different libraries in Central. We’ve encounter libraries that advertise themselves as BSD-style licenses which end up requiring dependencies on GPL components. This highlights the problem of licensing intent versus licensing reality. Just because a particular components is licensed under a particular license doesn’t mean you can actually use it under the terms of that license.

Lots of activity on Olov Lassus’ twitter feed and many opinions on the hacker news threads. This one was good about the ambiguity of the GPL w.r.t. derivative works.

Note: Meteor has since changed the license to MIT, which makes this very interesting project that much more compelling to a wider audience.

Posts by Topic

see all

Get Blog Updates