2018's new open source licenses: Will they work? Should they work?

The past few months have seen an explosion of new open source licenses and license-like documents. A proposal from MongoDB has generated intense discussion, and Redis (followed by other companies) is beginning to use a new set of additional terms called the Commons Clause. These new options follow in the footsteps of last year’s License Zero Reciprocal License.

Why now?

After many years of relative stability on the licensing front, it is natural to ask: why is this happening now? To answer that, it helps to take a step back and look at the main ways to make money that companies and individual developers have built around open source.

There are a handful of tried-and-true open source business models including enterprise subscriptions, "open core" (i.e., with a proprietary plugin), dual licensing, and hosted models (as has become particularly popular for databases). For individuals, consulting or full-time employment with the largest users of their projects are also options.

The cloud has challenged these models. The large cloud platforms have a huge competitive advantage over individuals and small companies because of their size, and they've used this to deploy open source projects very successfully at massive scale.

This represents a threat to open source companies trying to sell enterprise support or hosting subscriptions, and limits the number of potential employers for developers trying to sell consulting services or get hired as developers. The hosted model also challenges those who use copyleft licenses to increase user freedom, since even the most aggressive licenses approved by the Free Software Foundation have limitations that hosting services can use to their advantage.

These new licensing strategies are an attempt to push back, and attempt to resurrect these open source business models that are under threat. The main approaches are either explicitly requiring payment for commercial usage (Commons Clause) or aggressively expanding source code requirements to the point where it would be very difficult and cumbersome for anyone to comply (MongoDB Server Side Public License).

Whether or not you think this new licensing direction a good idea, it is an understandable one: people sinking lots of time and money into these projects want to capture at least some of the benefit that is currently accruing in large part to the major platforms.

Will they work?

It's hard to say how well these new licenses will work. There's been some trenchant legal criticism, and lots of pushback. But they've also drawn some genuine praise. Here’s one example, from Michael DeHaan, an original founder of Ansible:

“I think the heart of the Commons Clause is in the right place, even if it is overly strict, needs revisions, and Redis shouldn’t have rolled it out for existing projects. ... We need to help avoid the “Tragedy of the Commons” that is all too possible.”

We've been hearing comments like this for some years now from many open source developers. The new wave of license proposals may mostly be coming from companies, but it mirrors many years of frustration from individual developers who have been providing enormous value without being directly compensated for their efforts.

Should they work?

There is an official definition of open source, but in practice I think two things are the real center of open source as it is practiced in 2018.

For companies, the core of open source is frictionless adoption: can they use software the way they want to, without limitations?

For developers, the core of open source is frictionless collaboration: can they write software the way they want to, with other people, but otherwise without limitations?

These new licenses tend to cut against both of these principles. The impact on frictionless adoption by companies is obvious: the new licenses are trying to decrease flexibility and turn it into licensing revenue instead. That’s not awful (developers deserve to get paid!), but it certainly isn’t a win-win for everyone.

The impact on frictionless collaboration is less obvious, but still important. By privileging one group over another, and (implicitly) requiring that all contributors give up certain legal rights to the original corporate author, these licenses and the related licensing assignments they require introduce barriers to participation, moving the projects further from collaboration and more towards a "source available" approach.

Are there better options?

These new licensing proposals are focused on blocking or reallocating value instead of creating new value. They’re not the only proposals, of course; developers have also suggested changing governance models, or simply asking for charity.

At Tidelift, we think the best answers make the pie bigger and share it more broadly. We can do this in a way that creates a win-win for corporate users and developers: better, more robust software created by happier, supported developers.

Or to put it another way: if it’s a business model problem, let’s change the business model, not the license; and let’s do it in a way that creates new value rather than building defenses around the value that is already there.

In our case, we think aggregating demand for basic open source assurances can help support many popular projects in a sustainable, long-term way, while preserving and even enhancing the low-friction approach that is so central to open source’s success.

You can learn more about the Tidelift approach and how we offer these assurances through the Tidelift Subscription.