How to destroy open source with fauxpen license shifting

While tall technical tales often celebrate the lone wolf innovator, in my opinion, it’s free and open source software (FOSS) that profoundly changed the technology landscape for the better. Open source enables all of us to collaborate out in the open to solve technical problems so vast in scale that no single developer – and very few single companies – could dream of solving alone. Open source is a force multiplier.

The rise of open source

The GNU General Public License (GPL) was created in ‘89 as part of the GNU Project to promote the free use, modification, and distribution of software. The GPL was profound because it squarely aimed to protect users and developers’ rights to freely use, modify, and distribute GPL-licensed software, cornerstones of the open source ethos to this very day. GPL helped to turn a DIY free software ethos into a legally protected free software movement, backed up by a solid legal framework.

Initially, when Linux launched in ‘91, the Linux kernel had its own license, explicitly restricting commercial redistribution. However, in ‘92, Linux shifted to the GPL, which better aligned with Linus Torvalds’ vision of free and open source software, including the freedom for developers to make a living from their own technical contributions. The GPL more accurately highlighted the critical role of the GNU ecosystem, including tools such as GCC (GNU Compiler Collection), in the success of Linux. The license shift significantly boosted collaboration and contributions, and helped to establish the “Linux development model” as a standard in open source development. Even our modern collaboration tools like Git are based around the early ideas of this development model, like branching and forking. I offer this as proof that not all license shifts are toxic, and that seemingly boring topics like licenses can have a profound influence on long-term technical innovation.

Linux started off with humble beginnings, with the original idea for Linux posted to Usenet in August of ‘91. Linux originally launched under its own license before shifting to the GPL in ‘92. Source, Google Groups.

Try to fathom the cost of a project like Linux built within a closed-source, proprietary development model. Even if a single company funded such an undertaking, the quality and market share would be a fraction of what it is today. Think about how many success stories that open source has helped to manifest, and how many of those startup founders went on to become extraordinarily wealthy thanks to the seeds planted by early open source pioneers – but wealth generation was never the beating heart of the open source software movement. Quite the opposite.

A complete discussion of open source software as an ethos and movement needs to include the contributions of Tim Berners-Lee, which significantly influenced the open source movement far beyond GNU, GPL, and Linux. He invented fundamental web technologies like URL, HTML, HTTP, and the first website, laying the groundwork for the World Wide Web. Not only that, he ensured that his ideas would be available freely with no patents or royalties. To help accomplish this he founded the W3C in ‘94, which advocates for web standards, and also ensures those standards are based on royalty-free and open technologies. His commitment to open and royalty-free standards, plus his stance on net neutrality as a type of human right, embodies the ethos of open software for the public good. It’s this wonderful combination of technical innovation along with a dedication to human progress that is the true essence of “free and open”. You will hear this same term later, but in a much different context.

The original proposal from Tim Berners-Lee to join hypertext with the Internet, in March ‘89. Mike Sendall, his manager at CERN, called the proposals “vague, but exciting”. Tim Berners-Lee would later found the W3C to keep his innovations in the public realm for the public good, free of patents and royalty-free.

The rise of fauxpen

Fast forward to the 2010s, when we saw the introduction of the Business Source License (BSL). This was a new type of commercial, propriety license, one that mimicked open source licenses without offering the same freedoms. Notably, “the BSL prohibits the licensed code from being used in production — without explicit approval from the licensor.”¹ While some of its most egregious flaws that mimicked open source licenses were eventually fixed, its creation kicked off a chain reaction of similar license introductions over the coming years. In my opinion, the introduction of the BSL was a canary in the coalmine for the challenges that open source culture was about to face. We’ll get to more details about the BSL shortly. But why was it created?

Throughout the 2010s, an influx of venture capital driven partially by low interest rates sparked a boom in commercial open source software (COSS) companies. COSS companies vary widely in their style of engagement with the free and open source software (FOSS) community; some genuinely enrich open source while also turning a profit, while others stray from open source values under the first signs of pressure.

This brings us to fauxpen. “Fauxpen” is the illusion of being committed to open source without aligning to any of its principles, as measured by actions rather than words. Some think fauxpen is a debate about licenses, but it’s much deeper than that. Claiming a license shift as “fauxpen” requires more than a change of license, it requires a company, once an advocate for open source, to strategically distances itself from open source principles while claiming the total opposite. Fauxpen is what happens when a company tries to maintain the marketing benefits of being an open source advocate, while performing actions at total odds with the open source ethos. That’s why fauxpen is such a complex form of technical propaganda, because it balances perfectly between maintaining a facade of open source advocacy while aggressively pursuing commercial gains.

Much like the old adage “a wolf in sheep’s clothing”, a fauxpen license shift is a deceptive ploy to reap the benefits of being associated with open source while undermining the ethos of it for commercial gain. This digital illustration was created by Kurtis Chang, CC BY-NC-ND.

The fauxpen playbook goes something like this:

1. A company decides to distance itself from the free and open source software licenses that it once embraced
2. To do this, it adopts proprietary licenses that aim to limit competition or remove freedoms from a project it owns
3. After the license shift, it launches a public relations campaign to manipulate public opinion and position itself as a champion of open source

The first two business decisions are valid in a commercial context. COSS companies do not owe the market free software any more than developers owe for-profit corporations (or anyone else) their free time. Leveraging copyright law to limit competition is a valid maneuver in the for-profit playbook, but one that certainly won’t win many fans in the open source developer community.

That cuts to the core motivation for a fauxpen shift: there’s a clear business incentive for technology companies to appear to be supporters of open source software, even when their actions say otherwise. It’s the actions behind the scenes that run counter to open source principles, and the public relations campaign after a license shift, that truly defines fauxpen – without one or both, a license shift isn’t fauxpen.

This essay will mostly focus on the third point above, while not casting judgement on the first two. As we outlined in the story of Linux, a license shift is neither good nor bad. It’s the actions and public relations that follow that are either generative or pathological.

The Open Source Initiative (OSI) and Open Source Definition (OSD)

The Open Source Initiative (OSI) has taken a strong stance against these types of fauxpen license shifts.

“We’ve seen that several companies have abandoned their original dedication to the open source community by switching their core products from an open source license, one approved by the Open Source Initiative, to a “fauxpen” source license. The hallmark of a fauxpen source license is that those who made the switch claim that their product continues to remain “open” under the new license, but the new license actually has taken away user rights.” – OSI Board of Directors ²

Why is OSI approval so important? What is the OSI, exactly?

The Open Source Initiative (OSI) was founded in 1998 by Eric Raymond and Bruce Perens. It was established to advocate for the benefits of open source software, and to help the corporate world understand and adopt open source principles.

The OSI helps open source in a number of ways, notably through the following:

1. The OSI provides and maintains a clear definition of open source
2. The OSI standardizes how open source licenses are evaluated
3. The OSI ensures that the term “open source” is used consistently and accurately within the software industry

Let’s step through each of these points in a little more detail.

The OSI ensures that a new license that claims to be “open source” is congruent with the Open Source Definition (OSD) through a formal license review process.³ The OSI only approves open source licenses which adhere to the OSD’s criteria, and a core criterion is that the license aims to protect software freedom for users and developers. The certification process fosters trust and legal clarity, making it easier for individuals and organizations to adopt and contribute to open source projects confidently. The industry can be confident that any license officially listed by the OSI as “open source” is open source, and the OSI Board of Directors also helps to ensure this by advocating for the proper use of the term “open source”, especially by COSS companies.⁴

This is why it’s so destructive to the foundation of open source when a corporation shifts licenses to a proprietary license that does not gain OSI approval, but continues to call the proprietary license an open source license, and the software licensed under proprietary licenses as open source software.

“Proprietary software masquerading as open source—what has been termed fauxpen source—is toxic. It’s an intentionally deceptive hybrid that seeks to give its proponents the best of both worlds—the positive vibe and broad distribution of open source, together with the commercial leverage of proprietary software.” – Donald Fischer, Fauxpen source is bad for business ⁵

To try and sidestep controversy, some vendors have stopped labeling their products as “open source” altogether, and have instead opted for terms not aligned with the OSD. This includes Elastic’s rebranding of Elasticsearch and Kibana as “free and open” rather than “open source” following the license change of both projects to (a choice between) SSPL-1.0 and ELv2, which are two “flavours” of business source licenses. Elastic’s word-smithing doesn’t sidestep the fauxpen controversy, it only makes it worse. “Free and open” sounds even more permissive than “open source”, and even worse than that, it’s much closer to the term “free and open source software” (FOSS). SSPL-1.0 and ELv2 licenses contain non-trivial commercial encumbrances aimed to limit competition from service providers other than the copyright holder of a project licensed with one of these licenses, which is the total antithesis of the license choices Elastic has made. Elastic’s co-opting of the term “free and open” is an attempt to conflate proprietary commercial licenses with FOSS.⁶

It’s actually this type of word-smithing that’s at the heart of the fauxpen debate, and why drawing a line between marketing spin and propaganda is so nuanced.

So let’s simplify the topic: a company’s genuine commitment to open source is expressed directly in their license choices, such as by licensing their projects with Apache-2.0, GPL-2.0, BSD-3-Clause, and LGPL-2.1, which are all OSI approved licenses. Open source licenses along with the ethical use of contributor license agreements (CLAs) is the best expression of support for open source.

Let’s unpack the role of CLAs in open source and how CLAs fit into the fauxpen debate.

Licensing versus copyright

Without signing a Contributor License Agreement (CLA) that says otherwise, the code that you write in your free time (outside the scope of an employment contract) is your own copyrighted intellectual property, even after merged into an open source project. CLAs exist to spell out a more formal agreement between volunteers and a project’s owner, which typically includes a term about copyright. Most CLAs include a provision that transfers the complete ownership of contributed code to another party – the project’s owner. The project’s legal owner might be another individual, a company, or a foundation.

There are really two types of projects that open source developers contribute to:

1. Projects owned and governed by COSS companies, where CLAs transfer all copyright of donated code to these for-profit businesses
2. Projects owned and governed by a foundation like Apache, where CLAs transfer all copyright of donated code to the not-for-profit foundation

The copyright holder – typically the owner of a project – has the freedom to re-license any code contributions covered by a CLA under new license terms in the future. This is why the choice of license is so important, as its a clear signal to contributors that they have the option to benefit from their contributions without commercial restriction, even if they no longer legally own the copyright of that code.

This is also why fauxpen has the potential to be so controversial. Imagine contributing to an open source project for years under the belief that it’s open source, only to watch the project owner change licenses. Now you find yourself restricted from profiting from your own code in the future, like being restricted from launching a competitive managed service using some of the very code that you originally wrote. The only recourse is abandoning the original community to perform a hard fork of the last known open source version of a project, which is a sad outcome for all involved. This doesn’t embrace the spirit of open source, which is why this behaviour is not congruent with the OSD, and such licenses are not approved by the OSI. Shifting from a permissive to restrictive license should never be taken lightly.

Let’s explore what has changed in open source over the last decade and how we arrived at the fauxpen debate.

How did we get here?

Let’s explore a brief, condensed timeline of events. There are many other examples of fauxpen we can draw from, but I’ve selected a few that I think clearly outline the lineage of the fauxpen debate.

As you read, remember that license shifting in and of itself is neither a bad nor a good thing. The context is crucial. I will share my own opinions, but examine the examples below and form your own opinions as to whether or not the example is a fauxpen license shift, or simply a license shift.

2013 – MariaDB and the Business Source License (BSL)

The Business Source License (BSL) is a hybrid license model that combines elements of proprietary and open source licenses. First implemented by MariaDB Corporation in 2013 and proposed by MySQL’s original developer, the BSL was designed to tackle monetization challenges in open source projects by temporarily restricting certain commercial uses.

A Business Source License (BSL) differentiates from open source licenses by restricting competitors from offering services using the licensed project, often requiring a commercial relationship for production use. This model supports the software’s financial sustainability by controlling usage while keeping the source code accessible.

The BSL doesn’t fall into the fauxpen category because it doesn’t masquerade as open source, avoiding any misleading aspects of a license shift. While transitioning from an open source license to a business source license doesn’t always sit well with the open source community – especially those who contributed under the assumption of ongoing open source status – this shift alone doesn’t meet the criteria for a fauxpen maneuver.

Bruce Perens, co-founder of the OSI, even engaged with MariaDB to address and rectify initial concerns with the BSL, showcasing a collaborative effort to refine its licensing approach without misleading the community.⁷

The core reason I don’t personally consider the latest version of the BSL fauxpen is because it acknowledges the temporary nature of its restrictions as a necessary evil for commercial viability. The license eventually transitions the software back to the open source community, typically under the GPL, after a set time, often three years. The main goal of the BSL is to support the sustainability of projects by requiring financial contribution from large companies who have used and profited from the software, but have not contributed back. The BSL compels those companies to abandon the software in production, hard fork the last open source version, or engage in some type of relationship with the project’s owner.

2018 – MongoDB and the Server Side Public License (SSPL)

The Server Side Public License (SSPL) introduced by MongoDB Inc. in 2018 dramatically alters the landscape of open-source licensing, shifting away from the relative clarity of the BSL toward something far more complex and unreasonable. This pivotal change not only marked a departure from MongoDB’s previous licensing approach, but set a terrible precedent for license shifts. It’s what truly planted the seeds for fauxpen in my opinion.

While the BSL permits commercial use under specific conditions, and eventually transitions back to fully open source, the SSPL introduces a requirement that is more like a poison pill. The SSPL requires any service provider offering MongoDB as a managed service to disclose their entire service infrastructure’s source code, including unrelated proprietary code. This effectively discourages competitors from offering MongoDB services by tightly controlling competition.

Percona, a database service provider, calls the SSPL “anaconda like”.⁸ They make the observation that the spirit of the SSPL was so damaging to open source that it caused a domino effect among other vendors. Since the introduction of the SSPL, a number of vendors have embraced similar licensing strategies, in some ways setting a precedent that projects would only remain open source until commercially viable, before eventually adopting similar aggressive and competitive business models that are the complete antithesis of open source. In other words, this new breed of commercial fauxpen company aims to extract as much value as possible from the open source community before permanently reverting to a proprietary software model.⁹ While the BSL is about ensuring the commercial survivability of a project in the short term, companies that adopt SSPL-like licenses have made this shift permanent and in a more profoundly toxic way.

In my view, the SSPL falls squarely into the fauxpen category. MongoDB Inc., while not launching an aggressive campaign against the OSI or OSD, embedded a highly restrictive clause in the SSPL. This clause, which requires companies to open source their entire codebase if using MongoDB in certain ways, deviates sharply from open source principles. Open source licenses are intended to govern the software to which they’re directly applied, not to exert control over a company’s unrelated software due to usage or integration patterns. This overreach contrasts with the foundational ethos of open source, where contributions are freely made and used without encumbering additional unrelated projects. This is essentially a slap in the face to all open source developers who contributed to the project before the SSPL.

2021 – Elastic Co. and the Elastic License (ELv2)

In 2021, Elastic shifted Elasticsearch’s licensing from Apache 2.0 to SSPL-1.0, and then to the proprietary Elastic License 2.0 (ELv2), aligning somewhat with MariaDB’s Business Source License (BSL) but with stricter terms. ELv2’s notable clause, effectively a non-compete, prevents third-party managed services, contributing to its non-recognition by the OSI as open source.¹⁰

Elastic’s CEO has publicly addressed the licensing change as partially a response to Amazon’s Open Distro for Elasticsearch, which offered its own set of advanced Elasticsearch features to AWS customers under an Apache 2.0 license, features that were previously only available to Elastic customers behind a paywall. This competition led to a trademark lawsuit over the “Elasticsearch” term, and settled with Amazon’s fork being renamed to OpenSearch in 2021.¹¹¹²

“As previously mentioned, over the last three years, the market has evolved and the community has come to appreciate that open source companies need to better protect their software in order to maintain a high level of investment and innovation. With the shift to SaaS as a delivery model, some cloud service providers have taken advantage of open source products by providing them as a service, without contributing back. This diverts funds that would have been reinvested into the product and hurts users and the community.” – Shay Banon, CEO, Elastic Co. ¹³

Version 7.10.2 marked the last Elasticsearch release under Apache 2.0, with a shift to SSPL-1.0 in version 7.11. Eventually, Elastic introduced ELv2 and SSPL-1.0 as dual options, an attempt to address concerns over the poison pill in the SSPL.

Following the license shift, Elastic persisted in labeling Elasticsearch as “open source” through blog entries notably titled “Doubling Down On Open (Part I and II).” Over time, the controversy in the open source community around their reluctance to admit a departure from open source principles led to a reevaluation, and their eventual preference for the term “free and open” to depict their offerings.¹⁴

These actions arguably helped to grow and entrench the popularity of OpenSearch, which continues to be licensed under Apache 2.0. In December 2023, the OpenSearch project created a leadership committee to ensure the health of the fork, and to ensure that OpenSearch remains true to its open source roots.¹⁵

The OSI disputed Elastic’s justification for its license change, highlighting that open source licenses are designed to protect software freedoms, not accommodate for-profit business models. The contention, superficially about the “Elasticsearch” trademark, was rooted in competition and the commercial gating of certain features. Elastic and others have benefited from the open source community, whose contributions have been crucial to their success. Arguments that open source licenses allow exploitation by service providers overlook the substantial investments many such providers contribute to the ecosystem. Gating features is absolutely a valid choice for a COSS company, and forking the project is a valid choice for the FOSS community. Tension only arises when the two communities are not honest and transparent about their actions and motivations.

“But Elastic’s relicensing is not evidence of any failure of the open source licensing model or a gap in open source licenses. It is simply that Elastic’s current business model is inconsistent with what open source licenses are designed to do. Its current business desires are what proprietary licenses (which includes source available) are designed for.” – The OSI Board of Directors

This particular license shift illustrates the difficult balance between a genuine commitment to open source, and the pressure of turning a profit. Adopting business models that prioritize revenue over community principles is not open source, and that’s okay, as long as claims are not made to the contrary. Elastic’s decision to change Elasticsearch’s license highlights the divide between those who live by the open source ethos, and those who use open source as a strategic commercial tool. In my opinion this shift exemplifies the concept of fauxpen licensing, where an outward commitment to open source principles is compromised by actions that suggest otherwise at nearly every turn.

Where do we go from here?

In my humble opinion, license shifting should be approached with understanding by the community before a rush to judgement. Behind every project are a team of developers who may have very little to do with license change decisions. Remember that while fauxpen license changes are infrequent, transitioning to non-fauxpen BSL licenses can be crucial for some organizations’ survival. It’s reasonable for companies benefiting financially from open source projects to contribute back to their maintainers. This approach does not undermine open source ideals unless it falsely claims adherence to open source while contravening its core values.

The real dilemma arises when a project shifts its license unexpectedly after years of accepting open source contributions. For some projects, where volunteer input was minimal, a shift to a BSL might be driven by reasons so existential that the project may have died otherwise. However, when community contributions have been significant, such a shift can be controversial, and the community may need to step up. Community members can always fork the last open source version of such a project, ensuring its open source legacy and principles continue independently of COSS interests.

If you only take one thing from this essay, I hope its the importance for open source contributors to be vigilant about the Contributor License Agreements (CLAs) they sign. Open source contributors should be fully aware of where their efforts are going, and who ultimately benefits from their volunteer time and energy. Projects under stewardship of foundations that uphold open source values are (in my opinion) more reliable and worthy of long-term commitment compared to projects that may shift towards proprietary models, especially in light of recent fauxpen license changes. I’m not advocating against such contributions, but I advise that developers invest their time wisely. Favouring projects that align with open source principles and contribute positively to the open source community over the long term are worthy of our time and attention as a FOSS community. Otherwise, spend some time on other hobbies, or with friends and family. Stop subsidizing well-funded COSS companies with your free time.

Conclusion

For open source developers, as we enter a more challenging economic environment, I feel that it’s crucial to focus on technological innovation rather than engaging in conflicts with well-funded COSS entities after a shift towards faux open source models.

As discussed in the context of benchmarketing and the intricacies of public relations, engaging in disputes with these types of entities can be a drain on emotions and morale. Fauxpen isn’t a single action, its an entire change in stance towards open source, and it stands to reason that a stance may become extremely competitive after a license shift. Maintaining a focus on innovation and avoiding PR battles is better and more healthy for FOSS in the long run.

Our collective goal as a community should be to preserve the integrity and enthusiasm for open source development, allowing for genuine contribution and enjoyment, rather than the “corporate vampirism” of endless marketing wars. Technical leaders and decision makers are becoming more discerning, and fauxpen propaganda is increasingly recognizable. Remember that over the long term, innovation wins over bullshit politics, so let’s preserve our cycles for what’s important. Refuting a single piece of benchmarketing is almost pointless; more will exist tomorrow. Instead, I’m interested to continue exploring why these works are being created at (what feels like) an accelerated rate, and what FOSS projects might do when faced with such styles of direct competition from well-funded COSS companies.

My main takeaway is that we should be vigilant about the CLAs we sign, vigilant about the projects we dedicate our time towards, and vigilant about the projects we advocate for internally when the time comes to weigh in on an adoption decision.