Motivations and pitfalls for new "open-source" licenses

One of the bigger developments of the last year has been the introduction of licenses that purport to address perceived shortcomings in existing free and open-source software licenses. Much has been said and written about them, some of it here, and they are clearly much on the community's mind. At FOSDEM 2019, Michael Cheng gave his view on the motivations for the introduction of these licenses, whether they've been effective in addressing those motivations, what unintended consequences they may also have had, and the need for the community to develop some ground rules about them going forward.

In the past year we have seen several unusual new licenses, the Server Side Public License (SSPL), the Commons Clause license addendum, the CockroachDB Community License, and the Confluent Community License among them. All either perturb the historical copyleft norm of "you must distribute derivative works under the same license" by extending the scope past what's covered under the definition of a derivative work, or they exclude some historically permitted form of activity such as building similar works or making money. These developments have been of concern to many; talks at FOSDEM and the immediately-following Copyleft Conference with titles like "Redis Labs and the tragedy of the Commons Clause", "Who wants you to think nobody uses the AGPL and why", and "What is the maximum permissible scope for copyleft?" leave little room to doubt how many people are mulling over them.

Cheng is a lawyer at Facebook who helps manage the company's open-source program, though, as is traditional, we were warned that the talk contained only his own opinions. But those opinions drive day-to-day licensing decisions inside Facebook, so they are of interest. He started off by reminding us that there is a class of technology that lives deep in the cloud stack, as part of the modern equivalent of the once-ubiquitous LAMP stack. It is increasingly developed by companies that offer a basic version of their product as free software and reserve a non-free, more featureful version for paying customers, which is a business model known as "open core". Other companies have taken the free versions of such software and founded profitable cloud-hosting businesses based on it.

To Cheng's mind, the driver for the new licenses has been a perception that the cloud providers aren't playing fair, a point of view he supported with quotes such as the CEO of MongoDB saying: "Once an open source project becomes interesting or popular, it becomes too easy for the cloud vendors to capture all the value and give nothing back to the community". This perception, he says, then gets used by open-core companies as justification to react; some of them have reacted by producing new licenses. The questions that arose in his mind are whether the cloud providers are violating the AGPL (and other free licenses) and whether the users have any moral obligation to contribute back to the project over and above what the license requires.

His problem with the first question is that if companies are currently violating the free licenses on the open-core technologies they're using, then the one thing that won't help at all is a new license, since it presumably will be adhered to no better than its predecessors. As for the second, he believes that the contribution norms are clearly stated in the licenses themselves; the circumstances under which you must share any contributions you make, and the terms under which you must share them, are spelled out in those licenses. He is unpersuaded by claims that there are traditional community norms that require contribution over and above what's stated in the license.

He also thinks that people feeling aggrieved by how open core has worked out for them are overlooking some of their own business decisions. Each of them decided to go with open core, each decided which software would be given away and which kept proprietary, and each decided which license to pick. Having made those business decisions, things didn't turn out as expected, and it seems to him that now some of them are trying to move the goalposts.

Some have raised the issue of basic fairness. It is true, Cheng conceded, that open-core companies have often invested a lot in their products. But if those products have become popular, it is substantially because people thought the core was "free". Fairness is not an issue, because fairness is built into the license itself; the license is our expression of what's fair. The real issue is the economic realities of the industry, in support of which assertion Cheng quoted an "(ex-)founder" of RethinkDB, who said:

He also reminded us that other industries that have been disrupted, specifically the music recording, film, and newspaper industries, have also at times complained about fairness. When they did so, what they were trying to do was make a play on our values.

Cheng then drilled into the specifics of the licenses listed earlier, and looked at the shortcomings of each. Particular attention was reserved for the Confluent Community License and the SSPL. The former he found to have a lot of the "look and feel" of open-source licenses, even though its own FAQ states that it's not an open-source license; he ascribes the discrepancy to simple, blatant marketing. As for the SSPLv1, he examined the license's land grab of what it defines as "Service Source Code", which must be distributed under the SSPL, noting that it includes vast amounts of code that in copyright terms is in no way derived from the licensed work. It generously exempts the operating system itself, but to Cheng's mind that is because it would otherwise be practically impossible to honor, so nobody would ever use software covered by it. The SSPLv2 is better, but only slightly so, and the changes were motivated by the unfulfilled hope that the Open Source Initiative would approve the license.

Following these debates infuriates him, he said, because they are not changing anyone's behavior. In the course of his work, he gets many inquiries from Facebook people asking him if they can use a particular piece of technology. His normal workflow is such, he said, that if it takes him more than five seconds to work out if he can he use a given piece of technology, he probably won't bother. The only result of this whole exercise in new licenses has been to decrease adoption of technology covered by it. Specifically, projects governed by the SSPL, the CockroachDB or Confluent licenses, or any license with a Commons Clause addendum are prohibited from any kind of use anywhere at Facebook.

Having earlier warned us to retain spare soft food items for use as projectiles, Cheng grasped the nettle and talked about Facebook's own foray into the world of interesting new licenses. He noted that the company didn't agree with the community's interpretation of the BSD+patents license, but ultimately it didn't matter. Facebook doesn't make any money from React; Facebook does React to show off its talent and to impress the community. The community's thoughts are important, so when the company had to choose between retaining the community's respect and having a long debate about the new license, relicensing was an easy choice.

That is not the case with the open-core companies; their lifeblood is the sale of their enterprise licenses and they are consequently a lot less responsive to community disapproval. Cheng's particular fear is that the relicensing strategy becomes attractive and that the domino effect takes us from a few additional weird licenses to hundreds of them, most of which are understood by nearly nobody. Open core is here to stay, so he feels it needs rules, and the purpose of his talk (like many of the others on the subject) is to help forge community consensus about those rules. Ultimately, he hopes to work toward an ecosystem where new licenses are not needed, or are clearly not beneficial and so they aren't created.

His suggestion for guidelines to make it all work are:

• You can't have your cake and eat it, too: If you choose to make open-core products you must clearly distinguish between the open and closed bits of your offering.
• Don't confuse people by using licenses as marketing tools: They should be clear statements of what you can do, what you can't do, and what you must do.
• Be transparent.
• Seek consultation.
• Seek technical and business solutions to problems: The legal and, specifically, license-based solutions aren't so great.

There were several interesting questions. One attendee asked whether a provision for maintenance costs could be built into a license to ensure the future for a piece of vital core software. Cheng thought it might be possible, but he couldn't immediately see how and didn't think it was the right way to go. He also particularly disliked the use of trademarks to enforce behavior, because there are traditional ways to use trademarks and free-software users are not using a trademark in any of them.

In summary, license proliferation for bad reasons is something that's upon us. It's good that we appear to be worrying about it and hopefully out of all this heat some light will come to illuminate the community's preferred path for companies undertaking open-core development. It's also worth noting that companies can only switch licenses like this because all the external contributors to their projects are required to either transfer the copyright in their contributions to the project or to license their contributions under terms that permit license changes. Next time someone tells you you have to sign a Contributor License Agreement, it may be worth pausing to wonder what that might mean down the road.

The video of the talk should eventually be up here; according to Cheng the FOSDEM person responsible is in the middle of moving to South America, which is quite reasonably having knock-on effects on the availability of the video.

[We would like to thank LWN's travel sponsor, the Linux Foundation, for travel assistance to Brussels for FOSDEM.]