Making the GPL more scary

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.

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.

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

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.

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.

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.

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.

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.

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

Alternately, a GPL-only fork seems likely.

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?

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

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.

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

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.

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.