Back in December, Bryan Cantrill wrote a pretty good article titled Open source confronts its midlife crisis. He discusses a particular problem that's started cropping up over the past year or so: companies deciding that free software/open source licenses are unfair, and modifying them so that they're no longer free/open-source.
It's the same old problem we've been seeing since the start of the Free Software movement: how can you make a profit giving your software away for free? How can you stay in business if somebody else can just take your software and resell it without giving you a cut?
There's a growing trend toward answering that question with "Change the license so they can't do that."
One particular example is the inaccurately-named Commons Clause, which is a clause you can attach to some other license; here it is in its entirety:
"Commons Clause" License Condition v1.0
The Software is provided to you by the Licensor under the License, as defined below, subject to the following condition.
Without limiting other conditions in the License, the grant of rights under the License will not include, and the License does not grant to you, the right to Sell the Software.
For purposes of the foregoing, “Sell” means practicing any or all of the rights granted to you under the License to provide to third parties, for a fee or other consideration (including without limitation fees for hosting or consulting/ support services related to the Software), a product or service whose value derives, entirely or substantially, from the functionality of the Software. Any license notice or attribution required by the License must also include this Commons Clause License Condition notice.
We added the Commons Clause to our list of nonfree licenses. Not a stand-alone license in and of itself, it is meant to be added to an existing free license to prevent using the work commercially, rendering the work nonfree. It's particularly nasty given that the name, and the fact that it is attached to pre-existing free licenses, may make it seem as if the work is still free software.
We actually aren’t trying to "co-opt" the community or open source terminology. We tried really hard both in the license and in the blog post to be honest and upfront. Whether you like Confluent's license or not, you have to agree it is exceptionally permissive and the software has a pretty great community of users. How do you describe a license that lets you run, modify, fork, and redistribute the code and do virtually anything other than offer a competing SaaS offering of the product?
I describe it as "Not open source."
"Open source" is not a generic term. It doesn't just mean that you can look at a program's source code. It's a term of art, subject to the Open Source Definition. And the definition includes section 6:
6. No Discrimination Against Fields of Endeavor
The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.
I'm not a lawyer, but I'm pretty sure "a competing SaaS offering" counts as a field of endeavor.
Bruce Perens, who wrote the OSD, explains more in a blog post titled When Licenses Discriminate. It's a relatively short post, so I'm going to quote it in its entirety:
A long time ago, well-meaning people at the University of California, Berkeley created a license for their SPICE electronic simulation software that prohibited use by the Police of South Africa. This was, of course, during Apartheid.
Years later, Apartheid ended. The Police of South Africa now included Blacks and Whites with the same duties and powers. And they were still prohibited from using Berkeley SPICE. Getting the University of California to change the license, so that the software could be carried in Debian as "Free Software", was impossible at the time.
I took this example (among others) and wrote into the Open Source Definition (then the Debian Free Software Guidelines) that licenses could not discriminate against persons or groups, or against fields of endeavor.
This implements a major principle of Free Software. Freedom means Freedom for Everyone, not Freedom For People I Approve Of. Even when those folks abuse the freedom of others.
Someone recently created a license that discriminates against companies that have contracts with the U.S. Immigration and Customs Enforcement (ICE), a division of the Department of Homeland Security. Ironically, this is called "Moral Programming" or "Moral Licensing". I have to object to it on moral grounds.
I don't approve of the recent conduct of ICE under the direction of Donald Trump and his gang. Far, far from it. I am happy to say so, to participate in protests, and most importantly, I will not vote Republican in upcoming elections.
But if you insist on denying them the right to run your software in your license, please be careful not to call it Open Source or Free Software. Because your license will not comply with the Open Source Definition or the Four Freedoms of the Free Software Foundation. Which protect Freedom for everyone.
There's another license that's been getting some attention lately: MongoDB's Server Side Public License. It's based on the GNU Affero General Public License (which in turn is based on the GNU General Public License), but it makes a significant change. Here's Section 13 of the Affero GPL:
13. Remote Network Interaction; Use with the GNU General Public License.
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. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph.
Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the work with which it is combined will remain governed by version 3 of the GNU General Public License.
Here's the modified version in the SSPL:
13. Offering the Program as a Service.
If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License. Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Program or modified version.
"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.
That's some pretty dry legalese, but if you've made it this far, I suppose you're interested in reading about technical differences in free software licenses. So here goes:
If you take a program that's licensed under the Affero GPL, modify it, and make that modified version available to run over a network, you have to license your modified version under the Affero GPL.
Whereas under the SSPL, if you use MongoDB as part of a service package you offer to third parties, you have to release the entire package under the SSPL.
While MongoDB is couching this in the language of the GPL and copyleft, its goal seems more inline with the Commons Clause. It doesn't actually expect anyone to use MongoDB as part of a package and then release the entire software stack under the SSPL; it expects the terms of the SSPL to be so onerous that companies just pay MongoDB to license the software without the SSPL.
What's the point of all this?
It gets back to that earlier question: how do you make money on software you give away for free?
One of the traditional answers to that question has been that you charge for support. That was the idea behind MongoDB: they'd give the software away for free, but charge for support.
That may have been a viable business strategy a decade ago, but the market has changed. More and more companies are choosing not to run their own servers on-site, but instead to use Amazon Web Services. And that disrupts the traditional "pay for service" model -- because now companies are using MongoDB, and they're paying for service, but they're not paying MongoDB for service, they're paying Amazon for it.
Clearly the bean-counters at MongoDB saw this as a problem, and so they wrote a license that they hoped would force Amazon to pay them to continue using their software.
Meanwhile, neither the Free Software Foundation nor the Open Source Initiative has reached an official verdict yet on whether the SSPL is a free/open-source license, but it's under review, and Bruce Perens has his doubts.
First of all, he notes that it almost certainly violates the FSF's copyright on the AGPL; just because it's a license that allows redistribution of modified versions of software doesn't mean that it allows redistribution of modified versions of the text of the license.
The issue of the license text being infringing of FSF's copyright needs to be addressed. I doubt FSF is going to give permission for this use of their text. There is a possible 17 USC 102(b) argument, but most sources (Nimmer, Adams) disagree, and I don't know of any case law. This might require a full rewrite, and IMO OSI would face a risk of being a contributory infringer simply by hosting a copy of the current text on their site. The legal ambiguity of that might be sufficient reason for rejection.
And in the same post, he suggests it might violate sections 6 and 9 of the OSD. I've already quoted #6; here's the text of #9:
9. License Must Not Restrict Other Software
The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software.
And here's what Perens has to say about the SSPL:
I am most concerned with the second paragraph of section 13, and its conflict with OSD #9 and #6. The definition of how those pieces are coupled needs to be tighter. Management software, backup software, etc. may be used as part of the offering of a service, but they don't create a derivative work, nor are they combined into the same program. So, we get a restriction on works that are simply aggregated together (#9) or a restriction on use of the program if the data is backed up using a non-Open-Source backup program (#6).
In a later post, and with deep apologies, Perens backs off the Section 9 claims and states that the SSPL violates the spirit of Section 9, but not the letter.
The OSD terms were not written for software-as-a-service. OSD #9 very clearly states
The license must not place restrictions on other software that is *distributed* along with the licensed software. For example, the license must not insist that all other programs *distributed on the same medium* must be open-source software.
Since software-as-a-service software is not distributed, OSD #9 doesn't apply. Sorry. The document was written for another time and I could not predict today's conditions.
Regardless, even if it doesn't violate #9, it would nonetheless appear to violate #6. At any rate, Red Hat and its community version, Fedora, think so; they've rejected the SSPL and will be removing MongoDB from their software repositories. The Debian maintainers don't even think a strict analysis of the Debian Free Software Guidelines is necessary; it clearly violates the spirit of the DFSG, and that's good enough for exclusion from Debian.
Here's the thing: a change in license can kill a project. XFree86 was a much more essential package than MongoDB, and its owners made a much more minor change to its license. But that was enough to completely destroy the project. A previous version, with the old license, was forked as X.Org, and within a matter of months every Linux and BSD release had switched.
MongoDB is well along that path. The company has since introduced SSPL v2 in the hopes that it will prove more acceptable than v1, but MongoDB itself is still published under v1.
Maybe v2 will prove more acceptable. Maybe MongoDB won't end up like XFree86 and it'll end up like, say, KDE instead -- a project which initially used a nonfree license but then switched to a free license and continues to be widely used. Those are MongoDB's options: make your license acceptable to the free/open-source community, or fade into irrelevance as everybody switches to a fork. Time will tell which path MongoDB ultimately takes -- and what impact that has on the rest of this new crop of projects trying to pass off proprietary licenses as free ones.