Making the GPL more scary [LWN.net]

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.

Like Redis 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.

Making the GPL more scary

Posted Oct 18, 2018 16:13 UTC (Thu) by oliwarner (subscriber, #81320) [Link]

"We expect our license will quickly gain a wide following"... because we expect rightsholders to accidentally implicitly relicense their own software under our license.

I can't tell if this is just an awful oversight while trying to block SAAS using Mongo without paying (bad enough), or a genius land-grab at a LOT of third party software. Either way, this license needs to burn.

Making the GPL more scary

Posted Oct 18, 2018 16:15 UTC (Thu) by zblaxell (subscriber, #26385) [Link] (1 responses)

> 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.

If all that stuff connects to a running instance of the program, and the instance doesn't need a connection from outside to work (which it hopefully doesn't; otherwise, there's an external point of failure), then this is a short list ("You need Linux, a kvm image running Debian, and this five-line shell script...have fun with your new service instance.").

If you've hacked it so that it pings your service watchdog, or it keeps calling a REST API on your billing server and refuses to work without a signed credentials blob in the reply, or you've built custom data exfiltration to some other product, then the list gets longer.

Arguably, if you built a mobile app that only talks to your service instance, that could count as "custom data exfiltration to some other product."

As always, the only thing that really matters is the stuff that the copyright holder cares about litigating.

Making the GPL more scary

Posted Oct 18, 2018 17:13 UTC (Thu) by rgmoore (✭ supporter ✭, #75) [Link]

If all that stuff connects to a running instance of the program, and the instance doesn't need a connection from outside to work (which it hopefully doesn't; otherwise, there's an external point of failure), then this is a short list ("You need Linux, a kvm image running Debian, and this five-line shell script...have fun with your new service instance.").

The problem is that the new license requires you not just to release all that stuff but to release it under this new license. Since some of that code will almost certainly belong to somebody else and be released under a different license- good luck releasing Linux under SSPL- it's effectively impossible to comply with the terms of the license. It's de facto making MongoDB available only under their proprietary terms.

Making the GPL more scary

Posted Oct 18, 2018 16:16 UTC (Thu) by kingjdm (subscriber, #126438) [Link]

I think I would hesitate now to even begin prototyping something with MongoDB unless I already had licenses on hand, or budgeted for a project

Making the GPL more scary

Posted Oct 18, 2018 16:18 UTC (Thu) by karkhaz (subscriber, #99844) [Link] (6 responses)

The text of the AGPL starts with the following statement:

> Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

doesn't this make the creation of licenses derived from the AGPL, like the SSPL, a violation of the FSF's copyright by MongoDB Inc? The FSF has not granted anybody a license to modify the AGPL, nor to distribute copies of texts derived from the AGPL...

Making the GPL more scary

Posted Oct 18, 2018 16:28 UTC (Thu) by dullfire (guest, #111432) [Link]

Hmmm if they literally copied the AGPL, then yes I think it does (but I'm not a lawyer, and especially not a copyright lawyer).
If I were the FSF (in the case where it is a direct copy), I would send them a CnD, and in it ask them to not verbatim copy the license.
However here in the real world, I doubt the FSF will do much about that, even if it is directly copied.

Making the GPL more scary

Posted Oct 18, 2018 16:40 UTC (Thu) by josh (subscriber, #17465) [Link] (4 responses)

Quoting https://www.gnu.org/licenses/gpl-faq.html#ModifyGPL

It is possible to make modified versions of the GPL, but it tends to have practical consequences.
You can legally use the GPL terms (possibly modified) in another license provided that you call your license by another name and do not include the GPL preamble, and provided you modify the instructions-for-use at the end enough to make it clearly different in wording and not mention GNU (though the actual procedure you describe may be similar).
If you want to use our preamble in a modified license, please write to <licensing@gnu.org> for permission. For this purpose we would want to check the actual license requirements to see if we approve of them.
Although we will not raise legal objections to your making a modified license in this way, we hope you will think twice and not do it. Such a modified license is almost certainly incompatible with the GNU GPL, and that incompatibility blocks useful combinations of modules. The mere proliferation of different free software licenses is a burden in and of itself.
Rather than modifying the GPL, please use the exception mechanism offered by GPL version 3.

Making the GPL more scary

Posted Oct 18, 2018 16:55 UTC (Thu) by karkhaz (subscriber, #99844) [Link] (3 responses)

Thank you, I hadn't seen that. (I don't really understand how this FAQ entry doesn't conflict with the assertion that changing the text is not allowed, but if they say that they're not going to take legal action, then I suppose it's fine)

Making the GPL more scary

Posted Oct 18, 2018 16:57 UTC (Thu) by karkhaz (subscriber, #99844) [Link] (2 responses)

Oh, actually, I do get it. Changing the wording but continuing to refer to the license as the GPL is what is prohibited, but copying and modifying some of the terms for your own differently-named license is fine.

Making the GPL more scary

Posted Oct 18, 2018 17:22 UTC (Thu) by juliank (guest, #45896) [Link] (1 responses)

The FSF should really just license the GPL under the GPL. A recursive license would be neat.

Making the GPL more scary

Posted Jan 28, 2021 11:34 UTC (Thu) by jengelh (subscriber, #33263) [Link]

The GPL is not source code but prose; for one, there is no notion of "object code" or "machine-readable". This consideration would warrant that a more appropriate license be chosen for prose, such as Creative Commons.

Making the GPL more scary

Posted Oct 18, 2018 16:19 UTC (Thu) by MarcB (subscriber, #101804) [Link]

This lincense is simply too scary, too broad and too vague. Any use of this software outside of development now seems dangerous, but I assume this is the intention.

Note the "without limitation" in the clause where it lists affected software. But even the listed things like automation, backup and monitoring are much too broad, as well as of little use to most users. And this must not only be made availaible to users, but to everyone.

As I see it, this, as well as the Redis move, are attemtps at monetization by companies that just used "open source" as a means to get users in the first place. Hardly anyone would have bothered to buy some new, semi-finished proprietary database. Making it "open source" made market entry much easier. Now that they perceive to have gained enough market share - or because investors are increasing pressure - they try to cash in.

Making Copyleft Do What We Thought It Did

Posted Oct 18, 2018 16:59 UTC (Thu) by kemitchell (subscriber, #124442) [Link] (1 responses)

Two thoughts: one on the "scariness" and copyleft, the other, narrower, about "scariness" and copyleft more generally.

re scariness:

"Making the GPL more scary" is a great title. I think it goes to the core issue, which the detailed report on the license doesn't quite reach.

I'd argue that every new copyleft license released by the FSF has been received by non-activist, patches-back developers, including dual licensing businesses, as "the license that makes the software free for free software only". That is how pragmatists, like Linus, have justified choosing GPLs to get patches back, despite not really jiving with anything in their preambles. And that's how companies putting together open source consumption policies have largely abstracted the strongest category of copyleft licenses of the day. Read enough essays on fsf.org, you can find places where RMS himself reinforces that stereotype.

It has only been a stereotype, a leaky abstraction, never the truth. By drafting choice and changes in programming reality, activist-drafted copyleft licenses have always implemented something less than the "free for free software" spec. For example, FSF licenses studiously preserve the right of companies to make and hoard "private changes", even within sprawling organizations, even though copyright licenses can require their release.

In its early days, when it was still courting small company producers of newly rebranded "open source", OSI actually approved a number of superior patches-back licenses, often called "reciprocal" licenses, drafted by companies without software freedom in their hearts. Plan 9. RPL. Open Watcom. FSF actually rejected these licenses as too strong.

Copyleft is "scary" in part because the fumes of the "viral" anti-copyleft bombing deforestation campaign have yet to entirely blow off, but also because the activist-drafted copyleft licenses introduced agonizing complexity, to implement the exceptions demanded by their philosophy. Exceptions like private changes. Firms choosing activist licenses for functional reasons brought those complicated terms into the business environment, on the consumer side. Customer firms have banned use of maximalist-copyleft projects as much out of fear for the cost of terms analysis as fear of the cost of compliance.

Except when it really matters. Mongo now reports that more sophisticated cloud providers, with staff attorneys dedicated to reading licenses as they are, rather than as they're abstracted, have operationalized the known holes in AGPLv3.

I'm all in favor of producing maximalist copyleft or reciprocal licenses that implement "free for free software" effectively. Mongo's new terms point in that direction. But I fear Mongo's laser-like focus on its own pain point, and its understanding of the political fight it is having to pick, encourage the same kind of complexity-inducing splitting of hairs that FSF's drafters have practiced. Instead of writing a new license that's "free for free software" only as applied to databases and similar in the hands of cloud providers, they should write a real, modern, general-purpose "free for free software" license, which the activist wing of the copyleft user community can also support.

The "free for free software" rule has always been scary, but less so over time, as word gets out that actual license terms lack the legal bite for all their bark. When they weaken enough, in situations that matter enough, we send maintenance lawyers in to spruce up the terms. I don't know why we keep doing that one tiny patch a time, increasing complexity, instead of addressing the real use case.

re centralizing IP rights:

The purpose of centralizing intellectual property rights, via copyright assignments or contributor license agreements, is precisely to create licensing flexibility. One capability flexibility affords is dual licensing, also know as selling exceptions. MongoDB does this. Another capability flexibility affords is license modernization. FSF does this, Eclipse has done this, Mozilla has done this, and arguably, that is what Mongo is doing now.

For some time, the activist wing of the copyleft party, as distinct from the more businessy patches-back wing, has offered automatic license upgrade as a solution. Projects without centralized IP can seamlessly upgrade to a new license, like GPLv3, by adopting a with-updates license, like "GPLv2 or later". That mechanism achieves the terms-upgrade functionality of centralized IP rights, without enabling the dual-licensing/selling-exceptions functionality, but at the cost of a significant agency problem. Especially when the license steward and the license user come to copyleft as a means to very different ends.

There's no better example of that problem than the kernel. Kernel developers also come to copyleft for very different reasons. I've seen public statements from Linus that he chose GPLv2 for patches back, and the rest is just details. Other kernel hackers share the FSF's philosophy, and might now prefer AGPL on principle.

Given the size of the GPLv2-v3 diff, there was very little practical chance of anything like the meaningful consensus needed to adopt v3. Had kernel somehow gone v3, folks would have been angry. We can imagine an alternative-alternative universe where FSF also stuck to its guns and actually merged AGPL and GPL in v3, and the kernel essentially went AGPLv3, where even more folks would be even more angry. Back in our reality, GPLv2 is kernel fact for the whole foreseeable future, without any licensing flexibility. Not because it suited Linus' task best. GPLv2 is a pretty deficient patches-back license, compared to others OSI, FSF, and Debian have approved. Because it served well enough, functionally, for the contributors that gave the kernel critical mass in its moment, and didn't adopt a license modernization mechanism early on. That stability is worth something in itself, but it has also meant that new problems, solvable with licenses, like patent infringement, have had to be solved(-ish) in other ways.

Making Copyleft Do What We Thought It Did

Posted Jan 28, 2021 17:30 UTC (Thu) by Wol (subscriber, #4433) [Link]

> It has only been a stereotype, a leaky abstraction, never the truth. By drafting choice and changes in programming reality, activist-drafted copyleft licenses have always implemented something less than the "free for free software" spec. For example, FSF licenses studiously preserve the right of companies to make and hoard "private changes", even within sprawling organizations, even though copyright licenses can require their release.

Because "Free Software" has always been about USER freedom. It's always been about the CONSUMER of software, and those big corps you talk about are CONSUMERS.

As soon as the consumer becomes a provider, Free Software licences bite, and that is the line the Free Software philosophy draws.

(And this is where the FSF has the problem with big corps selling devices, which are software updateable, but the USER is denied the ability/freedom to do the updating ...)

Contrast that with Open Source licences, which are all about DEVELOPER freedom.

In practice, code which satisfies one philosophy will satisfy the other, but the focus is completely different.

Cheers,
Wol

Making the GPL more scary

Posted Oct 18, 2018 17:09 UTC (Thu) by xorbe (guest, #3165) [Link] (2 responses)

Since the goal is that service providers won't offer their "derivative" works for download, basically this is now proprietary software with the source code upfront for evaluation. The point is that you can't use it without paying money, in any sort of fashion that might involve making money. It's only free to read the source code. I can't see distros including this without cash back-scratching. So when I see a distro pick this up, I'll have an assumption of what's going on behind the scenes.

Making the GPL more scary

Posted Oct 19, 2018 6:36 UTC (Fri) by k8to (guest, #15413) [Link] (1 responses)

I thought the intent was to get rid of people offering mongo as a service, instead of building services using mongo.

Most mongo users probably want to build something else, and presumably wouldn't mind this intent for practical reasons. However, the specific wording of the license and its impliciations are quite a bit messier than this intent.

Making the GPL more scary

Posted Oct 19, 2018 13:41 UTC (Fri) by WolfWings (subscriber, #56790) [Link]

Regardless of their intent this license change makes it impossible to use Mongo in any way in any environment which is for-pay without releasing the ENTIRE service up-and-downstream that so much as touches Mongo, without paying MongoDB for a commercial license at whatever terms they decide to dictate, which from what documentation I've been able to find starts at $12k per server per year. And this license could even apply to an ad-revenue-funded site or a webcomic site that happens to use MongoDB as a caching or back-end layer at some point if access is gated on, say, being a patron in their Patreon. Drupal, WordPress, and Joomla all support MongoDB in various ways, and various Magento plugins also interface with MongoDB, all of the above often for search functionality.

Making the GPL more scary

Posted Oct 18, 2018 17:47 UTC (Thu) by tdz (subscriber, #58733) [Link] (1 responses)

> Making the GPL more scary

I strongly dislike the title of this article.

First, I thought that there's talk about a possible 'GPL 4'. But the article isn't actually about the GPL.

Second point is that the title implies that the GPL is full of anti-features, scaring away users, and a problem in itself.

Making the GPL more scary

Posted Oct 18, 2018 19:38 UTC (Thu) by marduk (guest, #3831) [Link]

I think for the "more scary" part, that was the author referring to those who already think the GPL is scary. As for the "making the GPL", I understood it once I read the first few sentences of the article. It's no different than, for example, saying that "Saleen made a mean Mustang". If the article were about "GPL4" I'd think that would stand out in the title. So it could have been more verbosely written as "Making a variant of the GPL that's even more scary for people who already think that the GPL is scary" the original title is shorter and, I think, not deceptive.

Making the GPL more scary

Posted Oct 18, 2018 20:59 UTC (Thu) by ballombe (subscriber, #9523) [Link] (2 responses)

I am not surprised this happen...
I am sympathetic to the AGPL goal but not to the actual text.
Maybe the AGPL goal is simply not possible to implement in a free software license.

The AGPL is problematic from a legal stand point: a software is not a legal entity that can make binding offer, and the realization of such offer depend on the environment where the software run which cannot be controlled by the programmer.

But the SCCP do not close the biggest loophole in the AGPL, but makes it larger:

9. Acceptance Not Required for Having Copies.
You are not required to accept this License in order to receive or run a copy of the Program.

So all you have to do is to refuse to accept the license and run the software on your server.
You can even pay someone else to modify the program. As long as they do not run it they do not have to offer the source to anybody except you.

Making the GPL more scary

Posted Oct 18, 2018 21:23 UTC (Thu) by federico3 (guest, #101963) [Link] (1 responses)

That's not a loophole - it's perfectly OK to run an copy not modified by yourself and that's by design.

Making the GPL more scary

Posted Oct 19, 2018 2:41 UTC (Fri) by pabs (subscriber, #43278) [Link]

It is definitely a loophole from MongoDB's perspective, since it basically nullifies the whole reason the SSPL exists; to prevent the cloud vendors from running an unmodified version of the program on their own hardware and selling access to that.

Great article

Posted Oct 19, 2018 0:37 UTC (Fri) by bkuhn (subscriber, #58642) [Link]

So, Jon knows well that my tendency to hit the Post Reply button is when I want to complain about something in the article. I do like a lot of stuff I read on LWN, and I admit too often, I don't reply to say great job when LWN does a great job, but instead I stay silent and save my replies to complain.

So, hopefully that explains how particularly excellent I though this article was that I bothered to post this reply to say so, given that I usually just think “good coverage” and move on if there's nothing to complain about.

Specifically, Jon found an angle and key facts that people (including me in my own blog post on this) are failing to mention when they discuss the matter and showed how centrally relevant they are to what's happening. The point about how single-point-of-failure in licensing authority is a fundamental danger for all software, but particularly Free Software, is really well stated and an essential point here.

Thanks for a great article, Jon!

Making the GPL more scary

Posted Oct 19, 2018 1:41 UTC (Fri) by mirabilos (subscriber, #84359) [Link] (7 responses)

So, it’s all about the “revenue stream” — money.

They just word it as requiring more source code so it’s only obvious half a second after reading, instead of while reading.

Just another reason to stay clear off MongoDB. The PostgreSQL 11 release announcement is much happier news.

Making the GPL more scary

Posted Oct 19, 2018 17:30 UTC (Fri) by flussence (guest, #85566) [Link] (6 responses)

By many accounts PostgreSQL is also better at being a JSON document store than most of these single-function services, MongoDB included. The company just XFree86'ed itself.

Making the GPL more scary

Posted Oct 19, 2018 22:51 UTC (Fri) by mirabilos (subscriber, #84359) [Link] (5 responses)

A friend (also my employer’s professional DBA and Horracle admin, although I got him to like PostgreSQL while he was teaching me SQL) said he couldn’t have expressed that better ;)

I’m a bit concerned about trying to coin something negative with XFree86 here, though. I looked, at that time, and the “new” licence was not different from anything that was in the tree before. Rather, that was FUD allowing the “others” to split off to X.org while somewhat keeping face. I think they had disagreements before. I also met one of the two devs left, and had mail contact with the other, and both were quite nice; development went down though, I guess the development model of XFree86 and the volunteer time just were “over” and a new age had begun but elsewhere.

Making the GPL more scary

Posted Oct 22, 2018 20:25 UTC (Mon) by k8to (guest, #15413) [Link] (3 responses)

Huh? There was definitely a license change at the core of the XFree86 abandonment, it's just that when the issue bubbled up, it had been committed a number of months prior.

Making the GPL more scary

Posted Oct 22, 2018 20:41 UTC (Mon) by mirabilos (subscriber, #84359) [Link] (2 responses)

There was a change of the terms on a few files, yes, but not to a new licence. That licence was in use prior to that.

And the licence is basically equivalent to the 4-clause BSD licence.

Making the GPL more scary

Posted Nov 1, 2018 5:49 UTC (Thu) by donbarry (guest, #10485) [Link] (1 responses)

Yes, a clause which enormous effort had gone into almost everywhere else to *eliminate*.

At heart, it was a legal reflection of a complete breakdown of collegial relations between an old guard who had commit access (including several, like Wexelblat, who had gone over to Windows and hadn't worked on the project in many years) and the "punks" who wanted to bring X, insomuch as it was possible to do so while maintaining wire protocol compatibility, into the modern world.

Since the punks were doing the work and had backing from the distributions, the fork had a fairly preordained outcome, which can't usually be said about forks. And the rapid pace of development after the damage was routed around speaks for itself. In particular, the release of a modular X11 with a mainstream build system was achieved in relatively short order, an enormous step forward.

(When was the last time anyone ran "xmkmf"?)

Making the GPL more scary

Posted Nov 1, 2018 19:51 UTC (Thu) by mirabilos (subscriber, #84359) [Link]

Me, last thundersday, when I was debugging the build of magicpoint in Debian.

Unfortunately, imake in X.org is in a pretty bad state, and I had to override many variables during the make invocation to make it work.

Making the GPL more scary

Posted Nov 1, 2018 8:33 UTC (Thu) by Wol (subscriber, #4433) [Link]

> I also met one of the two devs left, and had mail contact with the other, and both were quite nice; development went down though,

As I understood it, Keith Packard was doing maybe 90% of the dev work. As he was also one of the most (negatively) affected people by the politics - of which the licence change was a minor part - it's not a surprise that XFree86 development pretty much stopped when he left.

Cheers,
Wol

Making the GPL more scary

Posted Oct 19, 2018 2:37 UTC (Fri) by pabs (subscriber, #43278) [Link] (2 responses)

I think it is most telling that MongoDB Atlas is proprietary, a competitor to the kinds of companies the SSPL is aimed at and since MongoDB Inc is sole copyright holder of MongoDB, they are not obliged to release MongoDB Atlas code publicly, let alone under the SSPL or one of the licenses compatible with the FSD/OSD/DFSG.

It seems very disingenuous of MongoDB Inc to release MongoDB under the SSPL without also releasing MongoDB Atlas.

Making the GPL more scary

Posted Oct 21, 2018 18:32 UTC (Sun) by IanKelling (subscriber, #89418) [Link] (1 responses)

Great point, this should be a bigger point in the discussion. Here is the contradiction in their own words:

https://www.mongodb.com/community/licensing:

"Our goal in selecting the Server Side Public License (SSPL) v1.0, an open source license introduced by MongoDB, as our open source license is to require that enhancements to MongoDB be released to the community."

https://www.mongodb.com/cloud-terms-and-conditions:

"You may not: (a) modify, alter, tamper with, repair, or otherwise create derivative works of any software included in the Service; (b) reverse engineer, disassemble, or decompile the Services or apply any other process or procedure to derive the source code of any software included in the Service"

Making the GPL more scary

Posted Oct 21, 2018 19:30 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]

I don't see a contradiction. One is the terms of the license. Other is the terms of the hosted service.

Making the GPL more scary

Posted Oct 19, 2018 7:04 UTC (Fri) by smurf (subscriber, #17840) [Link] (11 responses)

So, are there any "really-free" alternatives to MongoDB?

Alternately, a GPL-only fork seems likely.

Making the GPL more scary

Posted Oct 19, 2018 9:21 UTC (Fri) by sbakker (subscriber, #58443) [Link] (9 responses)

That was my first reaction as well. Take the last GPL-versioned commit and fork from there. If so, first order of business should be to change that awful name.

Making the GPL more scary

Posted Oct 20, 2018 21:56 UTC (Sat) by sorpigal (subscriber, #36106) [Link] (8 responses)

The fork should, obviously, be called "MingDB"

Making the GPL more scary

Posted Oct 21, 2018 5:31 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

"Ming" like in 明天？Otherwise it's not obvious at least to me.

Making the GPL more scary

Posted Oct 21, 2018 8:11 UTC (Sun) by mpr22 (subscriber, #60784) [Link]

Ming as in "Ming the Merciless", ruler of the planet Mongo.

Making the GPL more scary

Posted Oct 22, 2018 10:33 UTC (Mon) by rathann (subscriber, #50815) [Link] (5 responses)

Sounds appropriate, but there's already something else called "Ming": http://www.libming.org/ .

Making the GPL more scary

Posted Oct 23, 2018 18:47 UTC (Tue) by sorpigal (subscriber, #36106) [Link]

Too bad. I had already avoided suggesting FlashDB for a similar reason. Once again the continued existence of Flash is making life difficult.

Making the GPL more scary

Posted Oct 30, 2018 5:24 UTC (Tue) by flussence (guest, #85566) [Link] (3 responses)

That name in itself is going to confuse someone: http://www.libmng.com/

Making the GPL more scary

Posted Nov 2, 2018 13:13 UTC (Fri) by joib (subscriber, #8541) [Link] (2 responses)

Not to mention mingw

Making the GPL more scary

Posted Nov 3, 2018 1:03 UTC (Sat) by VITTUIX-MAN (guest, #82895) [Link] (1 responses)

And Xming too, when was the last time anyone ran that?

Making the GPL more scary

Posted Nov 3, 2018 20:29 UTC (Sat) by zlynx (guest, #2285) [Link]

Xming is running on my Windows desktop right now. I use it all the time.

Making the GPL more scary

Posted Oct 19, 2018 13:10 UTC (Fri) by aigarius (guest, #7329) [Link]

That and a *hard* smackdown by OSI and FSF are in order here.

Making the GPL more scary

Posted Oct 19, 2018 8:30 UTC (Fri) by edeloget (subscriber, #88392) [Link] (2 responses)

> Like Redis 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.

Oh, wait.

I was under the impression that allowing another user to use your software freely was the end goal of all open source licences.

Am I wrong?

Making the GPL more scary

Posted Oct 19, 2018 17:00 UTC (Fri) by rriggs (guest, #11598) [Link]

> I was under the impression that allowing another user to use your software freely was the end goal of all open source licences.

> Am I wrong?

I believe so. There are multiple goals for open source projects, which is why there are so many OSS license varieties. If that were the only goal, we would need only one license. However, licenses may also attempt to limit the author's liability, limit one's ability to redistribute modifications to the software, limit how one can use potentially trademarked names of software, etc. In the case of both the AGPL and now this one, the license attempts to impose requirements on the user of the software when they provide access to the functionality of modified versions of the software. One can say the same of GPL/LGPL in some respect.

I personally think the AGPL has overstepped a boundary a bit. But, at the same time, I can understand why it might be economically useful and a societal good. I do not yet see where Mongo's license provides a societal benefit.

Making the GPL more scary

Posted Oct 25, 2018 1:25 UTC (Thu) by brooksmoses (guest, #88422) [Link]

Hah!

I'm pretty sure "that doesn't feel right" was a tongue-in-cheek comment with an implied "to the MongoDB corporate decision-makers" after it. But then I'm also pretty sure your comment was responding in kind, so. :)

Pedantically, I might quibble that I think in most cases that's more a means to the end, rather than the end goal itself. For instance, in creating and applying the GPL, the GNU Project and the FSF also have the end goal of making it compelling for _other_ software developers to allow users to use their software freely too, so that all software becomes freely fixable by its users.

Even the BSD-like licenses, in many cases, are applied by people who have an the end goal of producing a regime where otherwise-competitor companies can collaborate on a project without excessive legal wrangling. The mechanism of doing that is to allow any user to use and modify the software freely, but the collaborative development community this fosters is the practical end goal. Or, when companies apply free-software licenses to libraries they throw "over the wall" to the world, this is often with an end goal of encouraging people to use their not-free-as-in-beer hardware or as-a-service products, and allowing people to freely write software that makes it easy to interact with those things is a means towards that end goal.

And it seems here that MongoDB is finding that this is not actually a means to the end they want. In some ways, that's not too surprising -- releasing your core product as freely-as-in-beer usable is a pretty challenging way to run a for-profit company, and very few companies that contribute to open source projects do that.

Making the GPL more scary

Posted Oct 19, 2018 10:24 UTC (Fri) by armijn (subscriber, #3653) [Link] (7 responses)

Looking at the licensing page ( https://www.mongodb.com/community/licensing ) it seems that the scope would not extend to for example the Linux kernel:

"We also make our drivers available under the Apache License v2.0.

If use of our drivers under the Apache License v2.0 or the database under the SSPL v1.0 does not satisfy your organization’s legal department, ..."

Most people would be using these drivers to communicate with the database and that would not create a derivative as the licensing page explicitly seems to allow that.

What bothers me more is the following from section 13 of the license:

"offering a service the value of which entirely or primarily derives from the value of the Program or modified version"

This is very vague.

Making the GPL more scary

Posted Oct 19, 2018 10:32 UTC (Fri) by mjg59 (subscriber, #23239) [Link] (6 responses)

I'm not sure why the creation of a derivative is relevant here - section 13 doesn't make any attempt to restrict itself to derivative works. It also doesn't prevent you from using the drivers under Apache 2, merely (arguably) that you commit to distributing those drivers under SSPL if you do so.

Making the GPL more scary

Posted Oct 19, 2018 11:05 UTC (Fri) by armijn (subscriber, #3653) [Link] (5 responses)

Section 0 states what a "covered work" is. Also, the interpretation by the copyright holder (in this case MongoDB) is relevant. Law is not math.

Making the GPL more scary

Posted Oct 19, 2018 11:14 UTC (Fri) by mjg59 (subscriber, #23239) [Link] (4 responses)

Section 13 requires you to distribute the "Service Source Code" under SSPL, and the definition of "Service Source Code" is significantly broader than the definition of "covered work". I agree that the copyright holder's opinion is the relevant thing here, but the text you quoted is still consistent with being required to distribute the drivers under SSPL if you use MongoDB in a way that triggers section 13.

Making the GPL more scary

Posted Oct 19, 2018 11:40 UTC (Fri) by armijn (subscriber, #3653) [Link] (3 responses)

I would argue that section 13 directly contradicts sections 2 and 5 (search for 'covered work' in those sections) and I am sure that in court this would raise some eyebrows: if I were to run an instance of MongoDB under this license, then I have to make software that I don't own the copyrights of (and cannot relicense) available under their license? That's just impossible, so I am not going to lose any sleep over it. Good luck to them trying to enforce it.

I think it is a bad license: they essentially turned MongoDB into scareware to get companies to buy a proprietary license as it simply means less hassle.

Making the GPL more scary

Posted Oct 21, 2018 18:01 UTC (Sun) by IanKelling (subscriber, #89418) [Link] (2 responses)

> make software that I don't own the copyrights of (and cannot relicense) available under their license? That's just impossible

I think you are mistaken. Making available under a different license is allowed by permissive licenses. That is part of their attraction: you can distribute the permissive licensed code under a proprietary license as part of some product. Sometimes this is referred to as "sublicensing".

Making the GPL more scary

Posted Oct 21, 2018 19:34 UTC (Sun) by armijn (subscriber, #3653) [Link] (1 responses)

No, I am not mistaken. If this license would extend to for example the Linux kernel for example I cannot relicense that, because I don't own the copyrights for that and the license for the Linux kernel doesn't allow relicensing, as it is not a permissive license.

Also, regarding permissive licenses: the original code will still be subject to the license conditions such as for example outlined in the BSD license (copyright notices).

Making the GPL more scary

Posted Nov 1, 2018 8:40 UTC (Thu) by Wol (subscriber, #4433) [Link]

Pretty much NO licences allow relicensing. They allow distributing under a different licence, which isn't the same thing.

If I take a BSD project, rewrite some of it, and redistribute, then it's perfectly okay to do so under the GPL. That doesn't change the licence of the code I borrowed - that *was* BSD, is *still* BSD, and will *remain* BSD. It's just that the project is now GPL and the safest option for recipients (unless they want a ton of work) is to abide by the GPL.

Cheers,
Wol

Making the GPL more scary

Posted Oct 19, 2018 20:34 UTC (Fri) by naptastic (guest, #60139) [Link] (3 responses)

But this license is web-scale.

Making the GPL more scary

Posted Oct 20, 2018 12:13 UTC (Sat) by laf0rge (subscriber, #6469) [Link] (2 responses)

I am a long-time reader of lwn.net and I think it has always been about quality journalism.

The title of this article is, for me, really stepping over some line.

First of all, there is nothing "scary" in the GPL. Like any license, you have to play by the rules. Nothing more, nothing less. So since the GPL is not generally considered "scary", you cannot make it "more scary".

Secondly, the MongoDB related discussions are about AGPL, not GPL. So if at all, it is about "making AGPL more scary".

Finally, it's neither the GPL nor the AGPL that is changed. Those licenses exist and their wording is unmodified until the FSF should ever release any future versions of those licenses.

So a more factual wording would have been along the lines of "some people want something more scary than AGPL". The result of "scarification" is not AGPL, but something originally based on AGPL which is not AGPL itself.

Making the GPL more scary

Posted Oct 20, 2018 20:23 UTC (Sat) by naptastic (guest, #60139) [Link] (1 responses)

(Did you mean for this to be a top-level comment, rather than a reply to another comment? Just making sure I didn't miss something / nobody missed that I was joking.)

Making the GPL more scary

Posted Oct 22, 2018 17:28 UTC (Mon) by laf0rge (subscriber, #6469) [Link]

sorry, indeed I mis-posted this at the wrong level of the hierarchy. My apologies.

Making the GPL more scary

Posted Oct 22, 2018 17:27 UTC (Mon) by laf0rge (subscriber, #6469) [Link]

I am a long-time reader of lwn.net and I think it has always been about quality journalism.

The title of this article is, for me, really stepping over some line.
First of all, there is nothing "scary" in the GPL. Like any license, you have to play by the rules. Nothing more, nothing less. So since the GPL is not generally considered "scary", you cannot make it "more scary".

Secondly, the MongoDB related discussions are about AGPL, not GPL. So if at all, it is about "making AGPL more scary".

Finally, it's neither the GPL nor the AGPL that is changed. Those licenses exist and their wording is unmodified until the FSF should ever release any future versions of those licenses.

Making the GPL more scary

Posted Oct 25, 2018 14:10 UTC (Thu) by nim-nim (subscriber, #34454) [Link]

What this all looks like to be is basically “oh, corporations are starting to understand *GPL, traditional *GPL FUD-ing is insufficient to make them flock to our closed licencing alternative, let's write a license that actually states what *GPL opponents have said it meant all this time, GPListas won't see the difference and no one listens to them anyway”.

Debian Free Software Guidelines?

Posted Nov 1, 2018 9:29 UTC (Thu) by davidgerard (guest, #100304) [Link] (2 responses)

Is this new license going to pass DFSG? Will the new Mongo make it into Debian, and hence Ubuntu, at all?

Or will we just have the last-DFSG version lingering in the repos indefinitely?

Debian Free Software Guidelines?

Posted Nov 2, 2018 8:54 UTC (Fri) by amacater (subscriber, #790) [Link]

Debian and Ubuntu could take different interpretations: Ubuntu isn't Debian and Canonical could put mongodb under any licence into their partners repository, for example. Canonical would then have to maintain it.

But if Fedora and Debian both have issues with, say Redis and mongodb - they don't get into either distro. Older versions will eventually have security or other bugs that can't be fixed and they get dropped ...

Debian Free Software Guidelines?

Posted Nov 3, 2018 1:28 UTC (Sat) by pabs (subscriber, #43278) [Link]

For some of the Redis modules that changed license, there is a fork by Debian folks of the last version before the license change and that is going into Debian. I expect something similar might happen to MongoDB.

https://goodformcode.com/

Making the GPL more scary

Posted Nov 1, 2018 9:42 UTC (Thu) by antow (guest, #108999) [Link]

> "Developers should always be aware of the possibility of this kind of change before handing ownership of their code to another organization."

Developers should be aware that signing ownership of their code to any organization can make that code be used for evil by that or another organization.

Signing the code over to a proprietary license is by that action depriving freedom-rights of the users of their code.

Making the GPL more scary

Posted Nov 1, 2018 12:53 UTC (Thu) by warmcat (guest, #26416) [Link]

While I agree with the thrust of the article, somehow I don't feel like being lectured about FOSS purity by an entity that demands paid 'subscriptions' to avoid being timeshifted into irrelevance.

Making the GPL more scary

Posted Nov 4, 2018 22:03 UTC (Sun) by gnufreex (guest, #70396) [Link]

Well, I don't think this kind of license can be included in any Linux distro. Especially paid ones. It is flat out illegal, no way to relicense Linux to this crappy license. So Red Hat needs to make a fork if it wants to have MongoDB in RHEL.

So I propose new fork be called ReDBlue. Re as in relational (add relational data model in future, it already has document and key-value) Red as Red Hat, Blue as IBM, DB as a database. Obviously, license will be AGPLv3. I bet shares of MDB will crash if they do this.