Dirk Riehle, dirk@riehle.org
An edited version has been published in Computer magazine in December of 2023.
Abstract
The definitions of what free and what open-source software is are major cultural achievements. They have inspired similar definitions for data, content, and other types of resources. Still, many forces pull, sometimes with compelling arguments, to change the definition. This article will look at these forces and speculate what the future holds in store for the definition of open-source software.
1. The open source definition
The definitions of what free software and what open-source software is use different words but are essentially the same.
Both free and open-source software can summarily be defined as:
Free and open-source software is software that is available under a license that grants everyone the right to use the software, to modify the software, and to pass on the software to third parties, modified or not, all for free.
My own wording
The availability of source code is implied by the ability to modify the software to one’s liking.
The free software definition was first written in 1986 by Richard Stallman for the Free Software Foundation.1 It defines the four “essential” freedoms of software. In 1998, the newly founded Open Source Initiative defined open-source software using a ten-item bullet list of criteria that a license must fulfill to be considered an open source license.2
In an earlier instance of this column, Jesus M. Gonzalez-Barahona provided an excellent overview of the history of free/libre, and open-source software [1].
For this article, two aspects are notable about the open source definition:
- It does not say anything about the development process
- It does not restrict the use of the software in any way
In the remainder of this article, I will use the term open-source software to include all variations that the various communities use: Free software, free/libre software, free/libre, and open-source software, etc.
2. Use of the definition
The website of the Open Source Initiative (OSI) provides us with the definition of open-source software in a formal and structured way, as a list of ten bullet items. The OSI also operates the license-review and license-discuss mailing lists, which serve as the arbiter and decider of whether a particular software license is an open source license or not. Any license that passes the review will be added to the public list of open source licenses on the OSI’s website.
When reviewing a software license for inclusion in the approved open source license list, those who argue regularly go back to the open source definition and compare and evaluate the proposed license against its ten criteria. This way, the open source definition serves as a specification. It has proved its value time and again as a practical and sharp tool for making decisions. I view the definition as a significant cultural achievement.
Showing up as an open source license on the OSI’s website constitutes a stamp of approval of the license, bestowing the goodwill that comes with the term “open source” on any software provided under such a license. Many organizations have tried to get licenses they created (for their own purposes) approved as open source licenses and failed.
3. Open project governance
One important aspect that the open source definition does not address is how open source projects are governed. Governance are the practices and processes of how a project operates, how decisions are made, who can contribute, etc. The open source definition is solely about software, the artifact. It does not mention how a project conducts its business, that is, how the software is being developed.
Still, the open source development processes were on the minds of the founders of the Open Source Initiative. For most of its lifetime, and still today, another section on the OSI’s website has this to say about open-source software:3
Open source enables a development method for software that harnesses the power of distributed peer review and transparency of process. The promise of open source is higher quality, better reliability, greater flexibility, lower cost, and an end to predatory vendor lock-in.
From the website of the Open Source Initiative
This paragraph clearly states in that the authors’ minds, open-source software is developed in a communal way. For most of open-source software’s early life, this was the case. Most important open-source software was and is being developed in an open way, following the principles of open collaboration: Everyone can participate, decisions are made based on the merits of arguments, and participants decide about their own processes.4
Every project is different, but there are clearly established patterns as well, be it the peer group model explored by the original Apache web server team, or the benevolent dictator for life (BDFL) model explored by Linus Torvalds.
Open source, the artifact, and open source, the governance process, create the two dimensions by which we can classify software development projects. Figure 1 displays this 2×2 matrix.
The first two types of software development projects are:
- Community open source is open-source software (by license) that is being developed in an open and transparent way following the principles of open collaboration.
- Tightly controlled open source, here reduced to vendor-owned open source, is open source by license developed in an intransparent process, for example, behind the closed doors of a vendor.
The two remaining types of software development projects are proprietary, by license, and owned by the developing organization.
- Inner source is proprietary software developed using the principles of open collaboration within an organization.
- Closed-source software is the traditional proprietary software developed using established engineering processes like Waterfall or Scrum.
4. Vendor-owned open source
In the early noughties software vendors discovered that open-source software is a great method for getting a foot in the customer’s door. Making their product available as open-source software affords them so-called friction-less distribution. In a past instance of this column I explained how vendors turn “free-loading users” into paying customers [2].
The vendors of vendor-owned open source are traditional software vendors like Elastic, MongoDB, or HashiCorp, and not open source distributors like Suse, Red Hat, or Univention, which typically don’t own the open source code they are building their distributions from.
The owner (copyright holder) of some software can license out the software under one or more licenses. A vendor can make the same software available under an open source license and under a commercial license. To be able to sell a commercial license to their software, a vendor cannot allow that their rights to the software get diluted.
For this reason, most vendors require that any potential contributor to the open-source software sign over the rights to their contribution to the vendor. The required type of contract is called a contributor license agreement (CLA). CLAs are used by an organization to centralize all needed rights to the software, for example to represent it in court. They were originally invented by the open source foundations, but like many legal tools are now used by vendors as well.
Foundations and vendors use CLAs differently though. While foundations don’t take contributions private, vendors can (and do).
Not surprisingly, the practice of acquiring copyright to tightly control it is disenchanting to developers. Vendors typically don’t receive many contributions and therefore develop most if not all of their code themselves. They don’t do so in the open but keep their road-maps secret to hinder competition. In contrast to open source projects run under an open source foundation, the governance of projects run by a vendor is typically closed, not open.
5. Strengthening the definition
Both the closed governance and the copyright assignment are bothersome, even infuriating, to true open source enthusiasts. Vendor-owned open source has been called “faux-pen source software” (fake open-source software) or simply just a fraud.5
As a consequence, many such enthusiasts have asked that open source governance be added to the open source definition. Not just the artifact, but also the development process should be open, before some software should be called open-source software, and nobody should centralize the rights in the software in one controlled place.
These calls for extending the definition have led nowhere. Obviously, the vendors oppose it, and they are clearly members of the community. Open-source software development today is mostly paid for by companies, so it has become vendor friendly, and attacking business strategies through a changed definition of what constitutes open source has received little support.
I think that it would be quite hard to come up with actionable definitions of what makes a governance process open or not. It may not be impossible, though: The Apache Way is a codification of some process principles that could lead the way to an open source definition that includes open governance as an key aspect.6
I don’t hold my breath, though, for an extension of the definition to include open governance. Things are too established with too many invested forces for anything to change quickly.
6. Discriminatory licenses
A key aspect of the open source definition is that it does not discriminate against specific uses or parties.
There is plenty of people-killing machinery like rockets and drones that run Linux. This is fine by the open source definition! It is not fine by some software developers. For this reason, Coraline Ada Ehmke founded the Organization for Ethical Source, which tries to mirror the Open Source Initiative in defining and approving so-called ethical licenses.7 Ethical licenses encode the authors’ value system, most notably by disallowing specific uses. This then discriminates against these uses and by definition makes ethical licenses not open source licenses.
Unrelated, but in a similar way, vendors with a vendor-owned open source strategy always want to prevent anyone else from competing with them using their own software. For most of the early life of a product, open sourcing using an aggressive copyleft license and providing a separate commercial license does the trick and keeps the competition away.
This changed, however, when vendor-owned open source became popular and the large cloud service providers (Amazon Web Services, Microsoft Azure, Google Cloud) started providing the vendor’s open-source software as a cloud service. The existing open source licensing strategies were not enough to keep the hyperscalers away. According to the vendors, competition by the hyperscalers is unfair and needs to be prevented.
To stop the hyperscalers (and anyone else) from competing with them, these vendors invented so-called source-available licenses, also known as non-compete licenses. These licenses basically say that the software is like open source, unless you want to compete with the vendor, in which case you are not allowed to use the software (hence non-compete). Obviously, by the open source definition, source-available licenses are not open source licenses.
Vendors license away from open source to source available typically only if they feel they need the goodwill of open source less urgently than before. As a business, these vendors’ products probably matured and already reached channel-product fit. Examples of vendors, which relicensed from open source to source available, are MariaDB, MongoDB, and Elastic, and more recently Akka, HashiCorp, and Cockroach Labs.
These source available licenses sometimes put in an effort to make the license more palatable. For example, some source available licenses revert to the venerable Apache license for code that is older than two years. Still, its discriminatory nature remains.
I consider the relicensing of a product that is available as open-source software by its vendor to a source-available non-compete license a foregone conclusion. Once a product matures the open source strategy will lose some significance and the need to increase profitability and return on investment for the venture capitalists behind the vendor will take over.
As Figure 2 illustrates, only community open source, if run well, will stay open and transparent. Vendor-owned open source will get less and less open over time.
7. Weakening the definition
Open source has matured; it is now a household name that carries a good even a sterling reputation. Open source is good! Companies and private users alike love using high-quality open-source software! The governments of the world increasingly are pushing for open source in public tenders!
Not surprisingly, vendors like the goodwill that open source bestows on them, even if some in the open source community consider their work fake open source.
As a consequence, the drumbeat of public articles, vendor blog posts, and conference presentations has been increasing to weaken the definition of what constitutes open-source software. Proponents are asking to revise the definition to include, most notably, source available licenses.
While the pressure is mounting, I see no wavering in the Open Source Initiative’s stance to not accept any discriminatory language in the open source definition, and I am very happy about this. As the saying goes: Vendors will have to pry the open source definition from the OSI’s cold dead hands, and that would be such a pyrrhic victory that I don’t expect it to happen.
There are enough other vendors who benefit from community open source to oppose those vendor-owned open source firms that would temporarily benefit from weakening the open source definition.
8. Stemming the trust erosion
Some argue that vendors licensing away from an open source to a discriminatory license have been eroding the trust in open source. I beg to differ. As explained, open governance and community participation were never part of the original open source definition, and this has been obvious in these vendor’s behavior.
It is a vendor’s prerogative to define and execute their business strategy. Nobody can tell them how to go about it. Contributor license agreements and lack of community participation are clear signs of commercial intentions to acquire a superior return on investment like traditional closed source vendors could have them.
Anyone who uses open source, whether for in-house use only or as a component in products, creates a dependency on this open-source software. Such dependencies need to be thought through. It was always clear that vendors would eventually try to tighten the screws. Anyone who uses vendor-owned open source needs to recognize that payday will come, sooner or later.
Thus, users need to think through their use of open-source software. What is the impact of adding a specific dependency? If the conclusion is to use vendor-owned open source, fine! If not, fine as well.
9. Open source, what next?
The vendor-owned open source firms will not succeed in weakening the open source definition. I expect them to move on and utilize secondary devices to bestow goodwill onto their products. An obvious choice for a secondary device are open source foundations. I expect real or fake foundations with the goal of channeling goodwill and marketing attention to the products of the commercial firms backing them.
The open source world at large would be well advised to come up with their own commercial open source foundation. The essence of the foundation would be to provide independent specifications and certifications of good behavior. Certification marks could be acquired (and lost) by vendors who seek such certifications to win user trust. This way, open source could safe-guard its sterling reputation.
References
[1] Gonzalez-Barahona, J. M. (2021). A brief history of free, open source software and its communities. Computer 54(2), 75-79.
[2] Riehle, D. (2020). Single-vendor open source firms. Computer, 53(4), 68-72.
Footnotes
1 https://www.gnu.org/philosophy/free-sw.en.html#fs-definition
3 https://opensource.org/about/
5 https://meshedinsights.com/2021/02/02/rights-ratchet/
6 https://www.apache.org/theapacheway/
Updates
2023-12-30. A previous version of Figure 2 showed an incorrect logo. Kudos and thank you to Cooper Pierce for catching it.
2023-09-18. A previous version of the article suggested that Stallman’s four essential freedoms of software may have been a play on Roosevelt’s four essential freedoms.
It defines the four “essential” freedoms of software, presumably a play on the four freedoms articulated by former U.S. president Franklin D. Roosevelt.
Earlier version of this article
According to Ian Kelling of the Free Software Foundation (private communication), Richard Stallman confirmed to him that this was not the case; no intentional relation was sought.