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.
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.
Note: Meteor has since changed the license to MIT, which makes this very interesting project that much more compelling to a wider audience.