Since the center of the Maven community lies within communities that value the Apache license, I feel compelled to add some explanation for people who want to know more about what went into this decision. In this post, I'm going to walk you through what went into this decision and talk about some of the general ground rules we're following when it comes to making license decisions.
Why we chose the GPL license for Nexus
Normally we would have used a BSD/MIT/Apache license for software that we develop. This is what we're used to, with most of our developers having been active in the Apache community for years, we're all very familiar with the philosophy behind this license. When we announced that Nexus was going to be released under a GPL license, some of our colleagues wanted to know how a group of Apache participants decided to use the GNU Public License?
When we started Nexus, the plan was to create a commercial product. We hadn't thought about creating Nexus as a commercial product built atop an open core. Once we got into the effort, we soon realized that creating a commercial-only product with a team full of open source developers wouldn't be very fun. When you develop a commercial product, you limit yourself to a small group of developers working in an isolated environment. It didn't take us long to remember that close-source development isn't as productive (or interesting) as developing a product out in the open, and as we like working with other developers, we very quickly decided to take the hybrid, open-core approach to Nexus.
Once this decision was made, we had to select the appropriate license for Nexus. As a company that is dedicated to the development of a sustainable product, we decided to use the GPL. This decision wasn't made in a vacuum, we can see other companies like Redhat having succeeded with the GPL license, and, quite frankly, we wanted to protect our investment in Nexus. As a company, we feel that the GPL provides us adequate protection and still allows people to view, hack, and contribute back if they want to.
We stated clearly from the introduction of Nexus that we intended to create a commercial version of Nexus. GPL was the most effective way to protect our investment. I don't believe this has adversely affected users and it doesn't appear to have hampered the adoption of Nexus at all.
While the core of Nexus is covered under the GPL license, many of the libraries that we develop as a part of the Nexus effort are covered under the Apache Software License. Spice, a collection of utilities and libraries that do much of the heavy-lifting in Nexus is covered under the ASL because we're sold on the value of releasing widely-used components under the least restrictive license possible.
Our License Selection Guidelines
I reserve the right to add to the following list of general licensing guidelines as we continue to learn from experience, but here are three things we think about when selecting licenses for our project and products.
Acknowledge Reasonable Limits to Copyleft
One recent trend for companies in our situation is to use a license like the Affero GPL. The Affero GPL was designed as the ASP-killer, unlike the GPL which requires you to "give back" any additions or changes you have made only if you distribute your software to others, the Affero GPL compels you to give back any modifications to a piece of software if you use it to deliver a service. We specifically did not choose the Affero GPL because we wanted to make sure that our users could extend Nexus without having to give back the changes and extensions they needed to make for internal use. If we had selected Affero, I can guarantee that we would have seen lower adoption of the tool and less community participation. There are limits to viral, copyleft licenses, and overstepping these boundaries has adverse effects on community involvement.
We have been fortunate that many plugins that have been developed by user organizations have been donated back to Nexus. We feel that using the GPL is appropriate for Nexus because it is not restricting users from extending Nexus to suit their needs and the Sonatype staff generally do the hard lifting to implement features requested by users and provide fixes as necessary.
Always Move Toward Less Restriction
One thing to be worried in any OSS product are licenses that move from less restrictive licenses to more restrictive licenses. Sonatype chose the GPL at first because we felt that was the way to honestly express our intent with the project to become a product. If we were ever to change our license it would be to a less restrictive license. I believe it is an unacceptable practice to start a project with a less restrictive license, like the ASL, and then switch to a more restrictive license. I call this the Open Source bait and switch.
Many organizations find less restrictive licenses more acceptable and we understand these motivations (again, we're very active in the Apache community). Less restrictive licenses provide more freedoms to users and organizations. For a project to remove those freedoms after having released code under a less restrictive license is a violation of the OSS social contract. You can't start a project using a less restrictive license to grow a community – because this tends to be easier with less restrictive licenses – and then switch. Such a practice is dishonest and you will never see Sonatype make a similar move.
Constantly Evaluate Restrictive License Decisions
From time to time, you are going to see us moving code from more restrictive to less restrictive licenses. As our offerings expand, and as portions of the code we develop become critical to the community that supports it, it only makes sense for certain components to become less restricted. Less restrictive licenses enable wider integration and make it easier to drum up community participation. Take the Nexus Indexer as just one example. The Nexus Indexer is released under the Eclipse Public License, a less restrictive license that is comparable to a BSD-style license. Because this component is released under the EPL, it can be integrated into all of the major repository managers, and it can be reused by anyone interested in creating a repository index. It should also be noted that we're in the process of donating the Nexus Indexer to the Apache Software Foundation to move it to an even less restrictive license: the Apache Software License.
Over time, you'll see some of our components make this transition. We understand the differences between the ASL and the GPL. We're committed to both when they are appropriate, and we're not dogmatic about either. When it makes sense for a component to be released under the EPL or the ASL, there will be no hesitation. If we need to rethink a restrictive license for a component and release the component under a less restrictive license, we'll do that.
What about documentation licenses?
Our documentation is a whole different situation. First, documentation isn't software. The distributable product isn't "code" in the same way that Nexus or Maven is, and, because of this, we didn't want to just use the standard Apache Software License or GNU Public License because both of these licenses have very specific clauses that relate to "software". We wanted to find a license that allowed our readers to distribute our documentation, but we also wanted to find a license that offered us some protection. Even though the books are "free", they were the product of a substantial investment of our time and money. Because Sonatype has an active training product, we didn't want to turn around and see competing companies using our books as a foundation for competing products.
Given these constraints, we elected to release our books under a Creative Commons license with three clauses: No Derivatives, Non-commercial, and Attribution. You can download and redistribute our books as much as you want, but you cannot modify or remix the work and sell the end-product for profit. You can print our books and distribute them at cost, but you can't base a training product on the material contained in the books. The CC 3.0 BY-ND-NC has been good for us, we've attracted external contributors to our books over the past few years, and each one of our books has at least two external developers with direct commit access.
So what?
This topic might be a little wonky for most. Most end-users are familiar with major licenses like the GPL and the Apache license, and they come to a basic understanding of the differences. The users the care the most about this issue are the users who, themselves, participate in the open source development community. At Sonatype, we pay attention to the nuances of these licenses, and we're committed to provide details behind the decisions that go into our products. I hope that this post has helped clarify these licenses for people who might have wondered why and how we chose them. If you have any opinions about these decisions, please feel free to let us know.
