Open Path

The Historical Case for Fair Source

We’re defining a new term for software sharing, Fair Source. It relates historically to Open Source (started in 1998) and Free Software (1983). In some fashion, software sharing goes back to the dawn of computing. What is Fair Source? Why do we need it now?

Fair Source is software that is safe for companies to share and developers to use. We need it because, historically, Open Source has been an ambiguous term, applied to both community and commercial projects. By introducing a new term for commercial projects, Fair Source, we can set better expectations with developers, reduce pressure to change the Open Source Definition, and free up more companies to share their core software products.

Safe for Developers and Companies Alike

One helpful lens through which to view Fair Source is safety. Fair Source software is:

1. safe for developers to read, run (in almost all cases), modify, and contribute to without undue compliance risk; and
2. safe for companies to adopt for their core software products without undue risk to their business.

At Sentry we have been applying what we are now calling Fair Source principles for 5+ years, and we have clearly been able to achieve a balance between these two.

1. Fair Source is safe for developers: we have 10,000+ organizations using self-hosted Sentry under FSL, the flagship license of Fair Source.
2. Fair Source is safe for companies: we recently announced 100,000 cloud customers and $100 million ARR.

Sentry is an existence proof of the viability of Fair Source. We’ve taken it from zero to one. Our goal now is to help other companies open up their closed-source products. FSL has allowed AnswerOverflow, Codecrafters, Convex, GitButler, and PowerSync to do just that. But FSL is not right for every company. We want to recognize and encourage alternative approaches that also combine safety for developers with safety for companies.

But why adopt a new label, Fair Source? Why is Free and Open Source Software (FOSS) not sufficient? FOSS is safe for developers, surely. Open Source is known and loved by practically the whole developer community. Is it really unsafe for companies sharing their core products?

The Limitations of FOSS for Core Products

Kubernetes is Open Source, Google Search is not. React is Open Source, Facebook News Feed is not. Linux is Open Source, Amazon Web Services is not. Open Source has carried the day for shared infrastructure, but has barely made any inroads into end-user products. Why?

Open Source licenses, by definition, give up the exclusive right to monetize, on which any viable business model depends. Non-compete licenses are not Open Source licenses, and Open Source licenses are not non-compete licenses. Companies that try to Open Source their core products habitually come up against this reality. In the ugliest cases, it leads to relicensing rug pulls. Instead, we have evolved many solutions for subsidizing Open Source projects through adjacent scarcities, but Open Source itself is not a business model.

Companies cannot control how their projects are used and still be Open Source, but they can control the roadmap—production if not consumption. Historically, this discrepancy has supported two very different understandings of Open Source: community and commercial. This ambiguity has been part of Open Source since the beginning.

How do community and commercial Open Source differ?

The Great Governance Divide

Dirk Riehle, professor of Open Source software at University of Erlangen, published an article in 2009 entitled, “The Single-Vendor Commercial Open Source Business Model.” He distinguished community and commercial projects based on “their different control and ownership structures”:

• Community open source is open source that is controlled by a community of stakeholders;
• Single-vendor commercial open source is controlled by exactly one stakeholder with the purpose of commercially exploiting it.

Notable examples of the latter in 2009 were MySQL, SugarCRM, Jaspersoft, and Alfresco. There are many more examples today, including Sentry and other FSL adopters.

Already a year earlier, in 2008, Dirk had drawn attention to the confusion and tensions that can arise from housing both models under one Open Source tent. In “The Perils of Going from Community to Commercial Open Source,” Dirk discussed the case of the now-forgotten TWiki. “[U]sing his root access privileges, Peter Thoeny changed twiki.org, the main project website, to implement a new governance model. […] A few days later, the core developers left the project and created a fork.”

Change the name to HashiCorp or Redis, and we have the same controversy over relicensing and rug pulls today as 16 years ago. Perhaps we’ll learn to celebrate relicensing, but avoiding the need seems preferable. If companies start out Fair Source to begin with, developers will know clearly up front what kind of community they’re getting into.

The Gradual Rejection of COSS

Dirk’s “single-vendor” article maintains a tone of academic neutrality. His “perils” post leaks a little more negative sentiment (“community open source is a temptation for startups to make a buck”). Dirk in that era seems guardedly suspicious of commercial Open Source (COSS) but he does not outright reject the concept. By his account, SugarCRM put COSS on the map in 2004, though the term was in use much earlier. It is still used today, most often in reference to Open Core software, most often by Joseph Jacks and OSS Capital portfolio companies. But trust has dwindled.

“What’s So Bad About the Open Core Model?” Dirk asked in 2019. “I suspect that a big part of the mistrust against the open core model is directed at the single vendor case, as users suspect that over time, the core will be turned into useless crippleware, as the open source strategy to drive market adoption has run its course for the vendor.”

By 2020, Dirk had grown comfortable shifting from neutrality to value judgement (emphasis his):

Community open source is the proper open source, open both in license and process. If you want to chide single-vendor open source as “not being proper community open source”, calling it closed source will only confuse.

I offer neo-proprietary as a better term. Neo-proprietary captures the dominance and control of a proprietor in both the traditional closed source and the single-vendor open source case without confusing the two.

In 2023, he observed efforts to outright exclude commercial Open Source from the Open Source Definition (OSD):

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.

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.”

Dirk is not alone. Thierry Carrez, vice-chair of the Open Source Initiative (OSI), recently took up Dirk’s offer of a term with which “to chide single-vendor open source as ‘not being proper community open source’”:

Beware of single-vendor Open Source software, it’s a proprietary development model that happens to temporarily use Open Source licensing. So yes, let’s all agree: Single vendor is the new proprietary.

Where did single-vendor come from? When did this tension arise?

The Divide Was There All Along

Mozilla was the first Open Source project. Competing with Microsoft and losing badly, Netscape sales engineer Frank Hecker wrote a 20-page proposal to release the source code for their products. He did not go the whole way to Free Software. Rather, he had Netscape generating revenue, “at the point that the customer used the source code to create their own derivative work.” A year later he expanded on the memo in a paper, “Setting Up Shop: The Business of Open-Source Software,” but he did not publish the memo itself until now, in response to this present post(!).

Jamie Zawinski (jwz) and other Free Software advocates at Netscape picked up on Frank’s memo (which jwz had partially inspired), and convinced CEO Jim Barksdale and his management team to attempt a desperate gambit, and go the whole way to Free Software. In a press release dated January 22, 1998, they announced their intention to release the source code for Netscape Communicator in order “to harness the creative power of thousands of programmers on the Internet[.]”

Product lead Michael Toy said at the time, “We’re probably doomed. We’re probably gonna fail. Microsoft is probably gonna squish us like a bug anyway.” Releasing the code for Communicator was a marketing and product development Hail Mary that Netscape agreed to out of desperation.

Free Software advocates outside the company, including Eric Raymond (ESR) and Bruce Perens, eagerly jumped in to help, but the parties had different motivations. Netscape was making a last-ditch attempt to save the business. ESR, jwz & co. were capitalizing on an opportunity to advance the community-minded Free Software movement. Along the way they realized that “free software” confused people, so they changed to “open-source software.” It worked. The story caught fire, and Eric and Bruce quickly formed the Open Source Initiative (OSI) to steward the new movement.

Consider this, though: Netscape published Mozilla under the Netscape Public License, yet this license was either never submitted to OSI or rejected. Why might OSI have hesitated to approve the license of its flagship first project?

Richard Stallman (RMS) documented the reasons. Richard had founded the Free Software movement in 1983. He did not participate in the Communicator source code release, and he carefully distinguished between Free Software and Open Source. RMS pointed out that NPL-1.0 subtly privileges Netscape:

The first problem I noticed in the NPL was that it does not give Netscape and the rest of us equal rights, as the GNU GPL does. Under the NPL, we can use Netscape’s code only as specified in the NPL, but Netscape can use our changes in any way at all—even in proprietary licensed versions of the software.

[…]

It denies the idea of cooperation among equals that our community rests on, and says that working on a free program means contributing to a proprietary software product.

Here is the relevant text from NPL-1.0:

V.2. Other Products. Netscape may include Covered Code in products other than the Netscape’s Branded Code which are released by Netscape during the two (2) years following the release date of the Original Code, without such additional products becoming subject to the terms of this License, and may license such additional products on different terms from those contained in this License.

V.3. Alternative Licensing. Netscape may license the Source Code of Netscape’s Branded Code, including Modifications incorporated therein, without such additional products becoming subject to the terms of this License, and may license such additional products on different terms from those contained in this License.

Granted, Mozilla did encourage contributors to publish new code under the Mozilla Public License (MozPL or MPL), equivalent to NPL without “amendments granting Netscape additional rights.” The compromise between old (NPL) and new (MPL) code got as close to Free Software as possible given the complex legal realities they were under. It wasn’t until late 2001, after the dot-com bubble had burst and Netscape had lost all relevance, that the community could convince then-owner AOL Time Warner to fully relicense Mozilla under proper, OSI-approved licenses.

Open Source was born precisely as a tenuous alliance of community and commercial interests. The first Open Source project, Mozilla, looks more like a single-vendor commercial Open Source project than one might expect. If single-vendor is to be written out of the OSD, however, then perhaps the alliance has run its course.

Fair Source Is a Good Way Forward

Fair Source supports the community view of Open Source, defining a new term for single-vendor commercial projects. In the words of Matt Wilson, early Red Hat employee and long-time FOSS advocate:

Fair Source provides as many of the benefits of Open Source that its producers are comfortable giving, while reserving and asserting a minimal set of exclusive rights to help achieve a sustainable business model.

How does Fair Source operate? By combining non-compete licenses with delayed Open Source publication, also called eventual Open Source.

Non-compete Software Can Provide a Lot of Value

Though they fall short of the threshold of Free and Open Source Software, non-compete licenses nevertheless offer a high degree of value for developers. Under non-compete licenses, individuals and companies are generally free—in terms of the four freedoms—to read, run in ways that do not undermine the producer, modify, and contribute back to the producer of the software. It’s not everything, but it’s not nothing. Again, 10,000+ self-hosted Sentry users are proof that a non-compete license can confer real benefits to developers.

Along with that, non-compete licenses can support wide adoption by many compliance departments. This is amply demonstrated not only by Sentry (FSL), but also MongoDB (SSPL) and Elastic (ELv2). All have tens of thousands of users under their respective non-compete terms, which generally prevent harmful free-riding by hyperscaler cloud vendors, while allowing individual companies to self-host. Open Core can be seen as a variation of this, in that it has the same goal of protecting the business model of a primary project owner.

But what about eventual Open Source?

Eventual Open Source, Better Than Closed

Delayed Open Source publication is a key element of Fair Source. Karl Fogel and coauthors defined the term in a whitepaper for OSI (underwritten by Sentry):

Delayed Open Source Publication (DOSP) is the practice of distributing or publicly deploying software under a proprietary license at first, then subsequently and in a planned fashion publishing that software’s source code under an Open Source license.

Also called eventual Open Source, the approach is gaining popularity through the BUSL and Sentry’s FSL. Some, such as Thierry, have been dismissive:

Imagine a world where you have to run a buggy two-year-old version with known vulnerabilities because that’s the Open Source one.

This is a strawman argument. The expectation is that you run today’s version today. As mentioned above, 10,000+ self-hosted Sentry users do just that. Then what’s the point of the eventual conversion? Eric Raymond recognized the value of DOSP when he said (my emphasis):

It’s the guarantee of a timed flip to full open source that puts a bound on the business and legal risk. That’s very clever.

In other words, delayed Open Source mitigates against vendor lock-in and platform decay. If push comes to shove, another party—community or commercial—can fork an older version of the software and take it in a different direction. If a project has decayed, the difference between an old version and the latest version may be minimal, or the older version may be better than the newer version. You could even fork a version less than two years old, and work on it privately until the future license date. Fair Source offers real benefits, and meaningfully protects both developers and companies against worst-case scenarios.

The Answers Were There All Along

The DOSP paper authors credit GhostScript as the first to go this route, “around 1998” (p. 6), but the idea is on record even earlier. Richard Stallman suggests it, in his March, 1998 response to the release of the Netscape Communicator source code(!). After observing the asymmetry in Netscape’s license that effectively made Mozilla a single-vendor commercial project, he offered this:

One proposed solution for this asymmetry is to put a time limit on it—perhaps three or five years. That would be a big improvement, because the time limit would deny the problematical deeper message.

What’s more, if I’m reading the NPL right, they do have a time-box built in: “during the two (2) years following the release date of the Original Code[.]” Coincidentally, two years is what we settled on for FSL, tightening from the four-year default in BUSL.

Frank Hecker seems to have developed the theory the furthest the earliest. In May of 1998, in “Setting Up Shop,” the extensive paper based on his original Netscape memo from the year before, he put forth the “Sell It, Free It” business model. “[A] company’s software products start out their product life cycle as traditional commercial products and then are continually converted to open-source products when appropriate[.]” He also discusses “hybrid business models,” using, “licenses that are not quite open-source in the strict sense, but are also not as restrictive as traditional proprietary licenses[.]” Fair Source is the combination of these two insights from the dawn of Open Source.

Early Feedback Is Guardedly Positive

Others in the community are seeing the potential for Fair Source to resolve the tension between community and commercial interests that has characterized Open Source since the beginning.

• I mentioned Matt Wilson’s and Eric Raymond’s feedback above.
• Adam Jacob, co-founder of Chef and founder of System Initiative, gave the call to adventure a year ago that began this story arc, and he recently agreed, “I think ‘Fair Source’ is a good enough name.”
• Dan Brown, maintainer of Open Source Confusion Cases, has started recommending Fair Source as an alternative term.
• Dirk Riehle himself recently noticed FSL adopter GitButler:

  It will be interesting to see whether GitButler can build a [Fair Source] community like commercial open source firms were able to build an open source community around their software.”

My hope is that over time even strident voices such as Thierry Carrez can accept Fair Source as a good-faith attempt to resolve the tension in which Open Source was born, “to go beyond the rant & provide an alternative.”

Help Shape Fair Source

Dirk asked in 2021, “What’s next after ‘source-available’?” Our answer is Fair Source. I’ve made the case that it is a good way to resolve tensions that have been present in Open Source since the beginning. The net effect can be more closed-source code released to the world, and less pressure to change the Open Source Definition one way or another.

The basic characteristics of Fair Source are non-compete licensing and eventual Open Source, but there is much more to define and design. Join us on GitHub to participate. You can also subscribe there or on X for updates.

The alliance of community and commercial project owners in Open Source has taken us really far. Let’s see it as a sign of maturity and success that we’re now ready to go even further in parallel: Open Source and Fair Source.