In the software development landscape, licensing continues to play a pivotal role in shaping how technology is shared, built, and maintained. In this roundup, we’ll explore some of the most significant licensing stories of fall 2024, including Elastic’s return to open source, the new fair source licensing model, and the controversy surrounding PearAI.
Elastic Returns to Open Source
Elastic, the company behind the popular Elasticsearch search engine, has made a significant shift by returning to open source. Elastic is now offering its Elasticsearch and Kibana products under AGPL v3 (in addition to the SSPL and Elastic License).
The introduction of AGPL is the latest evolution in Elastic’s years-long licensing journey.
The company initially released Elasticsearch and Kibana under the permissive Apache 2.0 license. But in 2021, Elastic relicensed Elasticsearch and Kibana to be dual-licensed under the Server Side Public License (SSPL) and the Elastic License, giving users the choice of which license to apply.
This re-licensing change was the result of a trademark conflict with AWS. In 2015, AWS claimed to have launched Amazon Elasticsearch Search in a partnership with Elastic; however, that was not the case. This created a lot of confusion for users about the relationship between AWS and Elasticsearch.
After multiple attempts by Elastic in the courts over several years, the company decided that a license change was their solution to prevent companies from taking Elasticsearch products and providing them directly as a service without collaborating. For example, the SSPL license explicitly requires that any company offering the software as a cloud service must open source its entire infrastructure stack, not just modifications to the software.
Following this license change, in early February 2022, Elastic and AWS agreed on the trademark and eventually moved forward. Once enough time had passed to erase any confusion, Elastic decided it was time to return to open source.
This belief led Elastic to announce on August 29, 2024 that it was introducing the AGPL v3 license option alongside their existing SSPL and Elastic licenses. AGPL v3's source code sharing requirements cover distributed software (like the GPLs) but also software made available over a network (a potential loophole in the GPLs). This, for example, means that if a company has a SaaS app with AGPL-licensed components, that company must make the corresponding source code available as well.
Moving forward, it will be interesting to see how the open source community responds to this change, as well as which licensing option (AGPL, SSPL, Elastic) ends up being the most popular choice for users.
Introducing “Fair Source” Licensing
In recent years, we’ve seen an uptick in the popularity of source available software licenses. Source available refers to a licensing category where source code is made available — but with certain restrictions on its use. (In contrast, open source licenses do not place restrictions on use, only conditions, such as source code disclosure and attribution provisions.)
The intent behind many source available licenses is to provide a level of transparency while at the same time protecting against direct threats to business; for example, Hashicorp’s implementation of the Business Source License specifically prohibits competitors from using the licensed code in production.
These considerations prompted Sentry, an application performance and error monitoring company (and FOSSA customer), to recently introduce a new licensing model called “fair source.” Fair source is similar to source available, but with two notable differences:
- The fair source category has a formal definition (much like how the OSI has a formal definition for what is considered open source).
- Fair source licenses have a delayed open source publication (DOSP) provision, where the software transitions into being covered by a fully open source license after a specific period or under certain conditions. (Some source available licenses do have DOSP terms, but some don’t.)
Open Source vs. Fair Source vs. Source Available
Open source licensing is the most recognized and understood of these licensing models. Open source software is governed by licenses that allow anyone to freely access, use, modify, and distribute the software. The core philosophy is that software should be freely available for collaboration and improvement, and there are no restrictions on how the software can be used, including for commercial purposes. (Although, to reiterate, open source licenses do place conditions on usage of the licensed code.)
Fair source licenses provide access to the software's source code but impose certain restrictions, typically around commercial use. Fair source licenses are a hybrid approach, allowing public access to the code while giving the company control over how and when the software can be commercially implemented. These licenses often include provisions that convert the software to an open source license after a set time or limit the number of users who can use the software for free.
As previously discussed, fair source and source available are similar except for fair source’s formal definition and delayed open source provision.
Examples of Fair Source Licenses
Fair source licensing encompasses a few key licenses that offer varying degrees of control and openness, designed to suit different business needs:
Business Source License (BUSL): Initially introduced by MariaDB, the BUSL allows free use of the source code while restricting the ability to offer a commercial software version for a specified period. After this period, the software converts to an open source license. Although the Business Source License has most often been thought of as a source available license (and this categorization is correct), it also fits the fair source definition.
Functional Source License (FSL): Introduced by Sentry, the FSL is a simpler alternative to the Business Source License. It prohibits any "competing" use of the code to preserve the author's rights to economically exploit it, but this restriction applies only for a limited time. After this period, the code becomes available under an open source license.
PearAI Controversy
The open source community thrives on collaboration, transparency, and respect for licensing. Recently, PearAI, a Y Combinator-backed AI-powered code editor, found itself at the center of a controversy that serves as a critical reminder of why open source licensing matters — not just for legal reasons, but for ethical and reputational ones, too.
What Happened
PearAI made headlines after users on X discovered the company had forked the open source project Continue.dev, an AI code assistant, along with VSCode, and rebranded it as PearAI. Additionally, PearAI replaced Continue.dev's original Apache open source license with the closed source "Pear Enterprise License."
This drew significant criticism from the open source community (and beyond) for several reasons:
- The Pear AI codebase seemed to be largely a direct copy and paste, just with Pear AI replacing references to the original Continue.dev. The idea that a startup could get funding for a project with seemingly so few original contributions rubbed many the wrong way.
- Many also found Pear AI’s licensing choice highly problematic. There’s nothing preventing someone from forking an Apache-licensed project and licensing that fork under a closed-source license. But given the amount of copy-and-paste in Pear AI, using a closed-source license for it certainly ran counter to the open source ethos.
- There were very real legal questions about whether Pear AI violated the terms of Apache 2.0. Apache is a permissive license, but it does require proper attribution and to state significant changes to the licensed code. Although Pear AI did appear to make some mention of Continue.dev and VSCode in its GitHub, we’re skeptical Pear AI was fully complying with all of Apache’s attribution requirements.
Further fueling the controversy, PearAI's founder, Duke Pan posted that the Pear Enterprise License was generated using ChatGPT, demonstrating a clear lack of consideration for the open source community and the importance of licensing. (There was another stream of controversy related to Pear AI’s claims about its number of contributors, but we won't get into those details here.)
Why Open Source Licensing Matters
Facing mounting pressure, founder Duke Pan issued a public apology and updated Pear AI to the Apache 2.0 License. But the incident still highlights a crucial point: software licensing is not just legal fine print.
At their core, software licenses — in particular open source licenses — are the foundation for the vibrant open source ecosystem that fuels modern application development. Open source licenses are what give developers and maintainers the ability to ensure their contributions are credited and, for certain types of licenses (copyleft), will remain open source forever. When licenses are ignored, it devalues and disincentivizes open source participation.
Second, beyond ethical considerations, respecting open source licenses is also good business. Failing to do so can lead to more than just legal consequences — it can result in significant reputational harm, as we’ve seen with PearAI. Missteps in licensing can shake the trust of your users, partners, and the broader tech community, which can be even more damaging than certain legal penalties.
