Since the Maven community is 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 the general ground rules we're following when it comes to making license decisions.
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 active in the Apache community for years, we're all familiar with the philosophy behind this license. When we announced 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 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. As we like working with other developers, we 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 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, frankly, we wanted to protect our investment in Nexus. As a company, we believe the GPL provides adequate protection and still allows people to view, hack, and contribute back if they want.
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 appears to have hampered the adoption of Nexus at all.
While the core of Nexus is covered under the GPL license, many libraries that we develop as part of the Nexus effort are covered under the Apache Software License. Spice, a collection of utilities and libraries that do much 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.
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.
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 requires 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 ensure that our users could extend Nexus without having to give back the changes and extensions they needed 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 developed by user organizations have been donated back to Nexus. We feel that using the GPL is appropriate for Nexus, because it does not restrict users from extending Nexus to suit their needs. The Sonatype staff generally do the hard lifting to implement features requested by users and provide fixes as necessary.
One thing to worry about 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 ever changed our license, it would be to a less restrictive license. I believe it is unacceptable 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 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.
From time to time, you will 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 comparable to a BSD-style license. Because this component is released under the EPL, it can be integrated into all major repository managers, and 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.
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 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 result of a substantial investment in 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 of our books has at least two external developers with direct commit access.
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 learn about the differences. The users who care the most about this issue are the users who participate in the open source development community. At Sonatype, we pay attention to the nuances of these licenses, and we're committed to providing details behind the decisions that go into our products. I hope 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 let us know.