Making Copyleft Do What We Thought It Did

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.