TL;DR:
- Context: Redis add-ons Commons Clause announcement (HN), Drew Devault’s response (HN), Antirez (Redis creator)’s response (HN).
- Yes, the Commons Clause is proprietary. It’s intended to be better than existing proprietary licenses: source code is still publicly available; the community can still modify, use, and contribute; and the community still gets contributions in return.
- I expect that Commons Clause will primarily be adopted for enterprise additions to open source projects. Enterprise add-ons are a well-known method to help fund development on core open-source products (this is known as “open core”). Traditionally, the alternative is for these enterprise additions to be closed source, which I think is strictly worse.
Disclosures: I work at FOSSA along with Kevin. I was not involved in the creation of Commons Clause. The views expressed here do not represent the views of my employer. I am not a lawyer, and nothing I write should be construed as legal advice.
What happened?
On Tuesday, Redis Labs announced that its enterprise add-ons would be licensed under the Commons Clause. This announcement was commonly misconstrued as Redis itself being relicensed as Commons Clause, which is not the case. This resulted in a flood of angry responses and criticisms about the Commons Clause.
Why do people dislike Commons Clause?
Going through the HN comments, here are some common complaints:
This isn’t open source.
Correct (see FAQ).
This will actively reduce the number of open source projects.
This seems like a bit of a reach. I don’t expect open source projects to adopt this en masse, and we are not pushing any projects to do so. I think the common use case will be for enterprise add-ons (that would otherwise be closed source) to instead be as permissive as possible while still providing developers with a revenue stream.
There are better ways for open source projects to fund themselves.
There are definitely different ways for open source projects to fund themselves. Open core and consulting for enterprise add-ons are common approaches, and I think providing legal tools to enable them is not a bad thing. The Commons Clause tries to preserve the spirit of open source as much as possible while balancing the need for a sustainable revenue stream to fund development. The alternative is enterprise add-ons that are often entirely closed source.
You should use AGPL, GPL, MPL, or non-commercial/commercial licenses instead.
Licensing options have to be considered in the context of the software and its developers. I think the common use case for the Commons Clause will be for enterprise add-ons that would otherwise be closed source. For this kind of use case (“I want to make money by writing enterprise add-ons to an open source core product”), these other choices all have shortcomings:
- AGPL, GPL, and MPL allow others to sell your product, which potentially hurts your ability to fund core development.
- Existing commercial and non-commercial licenses are non-standard and often more restrictive than what you want. Many developers in this context would prefer to be as permissive as possible.
Commons Clause isn’t perfect, but it isn’t destroying open source
One reason I work at FOSSA and with Kevin is because I really believe in open source and improving the open source community. Everyone on the team does, and the work we do comes from a genuine desire to improve the community as much as we can.
The Commons Clause is an experiment at investigating a new point in the license design space:
- We want to be as permissive as possible: the Commons Clause tries to apply as few restrictions as possible to its underlying license.
- We want to be easy to understand: the Commons Clause is short and piggybacks off of well-known existing licenses.
- We want to enable sustainable open source: the Commons Clause prevents larger players from reselling the enterprise features that sustain open source development, while maintaining source availability and community contributions.
I think that experimenting with new types of licenses and new forms of sustainable open source development is a good thing. Supporting and funding open source development is a hard and open question. Help us answer it.
