Making the GPL more scary

By Jonathan Corbet

October 18, 2018

For some years now, one has not had to look far to find articles proclaiming the demise of the GNU General Public License. That license, we are told, is too frightening for many businesses, which prefer to use software under the far weaker permissive class of license. But there is a business model that is based on the allegedly scary nature of the GPL, and there are those who would like to make it more lucrative; the only problem is that the GPL isn't quite scary enough yet.

The business of selling exceptions to the GPL, where one pays the copyright holder for a proprietary license to the code, has been around for a long time; MySQL AB was built on this model, for example. Companies that buy such a license normally do so because they fear that their own code may fall under the requirements of the GPL; vendors tend to take an expansive view of what constitutes a derivative work to feed those fears and encourage sales. It is a model that has been shown to work, and it has generally passed muster even with organizations that are committed to the spread of free software.

MongoDB Inc. is a business built on this model. Its core database product is licensed under the Affero GPL , which tries to close the perceived "software-as-a-service loophole" in the GPL with this language:

Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software.

LikeRedis Labs before it, MongoDB has concluded that this license allows a bit too much. In particular, cloud providers are offering access to MongoDB instances without cutting the company in on the resulting revenue stream, and that doesn't feel right. In response, MongoDB has just announced an immediate shift to its brand-new Server Side Public License (SSPL) . This license is based on the AGPL, but adds some extra text to section 13 with, it is claimed, this effect:

The SSPL builds on the spirit of the AGPL, but clarifies the condition for providing open source software as a service. The license retains all of the same freedoms that the open source community had with MongoDB under the AGPL: freedom to use, review, modify and redistribute the software. The only substantive change is an explicit condition that any organization attempting to exploit MongoDB as a service must open source the software that it uses to offer such service.

The license itself is more explicit about what software must be released in this manner:

"Service Source Code" means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.

The affected code must not only be released, it must be made available under the SSPL. This language, thus, extends the reach of the license beyond any modifications that may have been made to MongoDB itself or to anything that could conceivably be considered a derivative work; it now encompasses all of the software that runs around a commercial MongoDB installation. For a cloud provider, this language would appear to compel the release of most of that provider's internal software used to provide its services as a whole. That is an extension of the scope of the license that could indeed prove scary to businesses using this code.

As Matthew Garrett pointed out , expanding a license's requirements beyond derived works is not entirely new; the GPL's requirement that build scripts be released is one example. But this takes that requirement to a rather different level, to the point of, Garrett suggested, even requiring a relicensing of the Linux kernel if a MongoDB service runs on Linux.

MongoDB argues that this license will inspire more companies to participate in the development community, but it seems unlikely that this is the real goal. That goal, instead, is simply to drive the sale of more proprietary licenses. The company claims that it is an open-source license, and has submitted it to the Open Source Initiative for approval. Whether that approval will be forthcoming is far from clear at this point.

One could see this change as being just another company trying to go proprietary without actually looking proprietary. But there are a couple of points to take away here. The first of these is that this kind of license change is just one of the types of obnoxiousness that can come with software that is owned by a single company, whether that software is open-source or not. Anybody depending on such software should always be aware that abrupt and unwelcome policy changes are possible.

There is a lesson here for contributors as well. The request for license approval notes that: " As of this writing, the MongoDB GITHUB repository shows over 43,000 commits, 680 releases, and over 350 contributors ." To become one of those contributors, a developer must first sign MongoDB's contributor agreement , which assigns copyright ownership to MongoDB. Those contributors all gave MongoDB the right to relicense their code in this manner — a permission that some of them may be reconsidering now. Some of the affected contributions may well have come from the very companies that the new license is meant to target. Developers should always be aware of the possibility of this kind of change before handing ownership of their code to another organization.

MongoDB submitted this license for approval with the optimistic statement that " we expect our license will quickly gain a wide following ". That remains to be seen. This license does, however, appear to be part of a trend in some parts of the market aimed at extracting more revenue from users of free software — or of projects that used to be free software. Making money with free software can be challenging, beyond any doubt, just like most other ways of running a business. But if that challenge is solved by making the software non-free, the business may have gained something, but the community around that software can only lose.

to post comments)