Two Types of Open Source Communities

tl;dr The communities that form around community open source are very different from those that form around commercial open source; confuse them at your own risk.


The recent announcement by Elastic to relicense their software away from open source licenses to commercial and source-available licenses only has triggered the debate about rights and expectations of open source communities again (local copy 1, 2, 3).

Legally speaking, I assume that this is fully within Elastic’s rights. I assume they either outright own all copyright to the relicensed code or collected copyrights by way of contributor license agreements from anyone whose code they accepted into their code base.

Morally speaking, some people are questioning Elastic’s right to do so. They assert that the relicensing broke a contract with the community. I can understand this disappointment, but I can’t see how people can complain about Elastic acting in its own interest. Nobody was fooled here, Elastic was a commercial company from the beginning.

The confusion seems to stem from not properly distinguishing community open source from commercial open source.

  • Community open source is software that has no single proprietor and whose copyright is broadly distributed. This includes foundations like the ASF, who formally may be the proprietor of their projects (they collect the copyright), but by way of processes and bylaws clearly acts as a representative of a community and not for commercial interests.
  • Commercial open source is software that usually has a single or dominant proprietor who will manage the software according to their commercial interests.

The community around a community open source project determines where it is headed, including licensing changes (usually: never). The community around a commercial open source software does not.

The development efforts of a community open source project are carried 100% by the community (including vendors). The development efforts of a commercial open source project are mostly carried by its proprietor (percentages of outside contributions will vary by how and where you draw the boundary around the commercial open source and any supporting community open source).


With this, it is no surprise if a commercial open source vendor acts in their own interests, even if this (perceived or real) goes against the interests of the commercial open source community. In general, it is within their rights, and I don’t see how anyone can complain.

The only moral hazard I see is if the commercial open source vendor made promises and then broke them. Those who complain about Elastic argue that there were such implicit promises, but I have not seen them. Elastic obviously thinks there weren’t any.

A possible solution is to adopt what I called the commercial open source pledge. In it, a vendor clarifies its future intentions. This idea hasn’t got much traction though, because (I guess) vendors prefer to not make forward looking statements. So, users need to remain vigilant, as always, and think before they act.

4 Replies to “Two Types of Open Source Communities”

  1. “Those who complain about Elastic argue that there were such implicit promises, but I have not seen them. Elastic obviously thinks there weren’t any”

    https://www.elastic.co/what-is/open-x-pack says:

    “We did not change the license of any of the Apache 2.0 code of Elasticsearch, Kibana, Beats, and Logstash — and we never will.”

    1. Thanks, good find! This makes it look less well for Elastic. However, in my book this is gradual: Was this a deliberate lie at the time or an honest belief? I don’t want to defend Elastic, I’m just analyzing things here. I qualify anything a vendor says and view it from the driving motives, usually shareholder profits.

      Deliberate wishful thinking on the one side is equally improper as is deliberate lying on the other side. The closing down of a once open product (or parts thereof) is what seems to happen to a maturing product, cf. SugarCRM (the frontrunner in so many things).

  2. Nice explanation of one of the core issues here: legal responsibilities vs. moral or socially expected responsibilities.

    I think (I may be reading incorrectly) that there are a couple of important clarifications needed here:

    – The Elastic Contributor License Agreement doesn’t assign copyright – it’s similar to other CLAs in that it grants an irrevocable license to do stuff.

    https://www.elastic.co/contributor-agreement (which you need to click through to see the actual Docusign agreement underneath)

    – The ASF never asks for copyright; we only require our CLA (which many other CLAs are based off) for major contributions or committers.

    https://www.apache.org/licenses/contributor-agreements.html

    The fact that the CLA’s requested are similar just emphasizes your point: CLAs as legal documents themselves are neither socially good nor bad – the real question is: *who* are you signing the CLA over to?

    1. Thanks, Shane! I didn’t realize, the ASF only wants non-exclusive rights; I thought it was a copyright transfer, sorry! In general, all you need is a relicensing right. I also didn’t know that the ASF does not collect CLAs from everyone (the website says everyone but I guess practice varies).

Leave a Reply