Source-available is meaningless

We've seen it play out a hundred times: a VC-backed company launches a new "open source" project, and perhaps right away, or maybe later on, they license their project under what's known as a "source-available" license. Yet they still call it "open source" — a phenomenon known as "open washing."

Assume pitchforks.

The OSI-zealots will come out of their hiding place — with torches and pitchforks at the ready — to utterly destroy this company's reputation in the public square, berating them on the misuse of the term "open source" — even if the term may or may not have changed meaning in the general vernacular over time.

Rightfully so, some would say. But whether that is right or wrong is a topic for another day —

Today, we're going to talk about the alternative term the 'zealots' recommend companies use — which is, "source-available."

What does "source-available" mean?

Well, not much, actually.

It has no meaning outside of the thin freedom to read the source code. It implies no freedom to use the code, no freedom to modify the code, no freedom to redistribute the code — it implies no freedoms at all.

Yet, in reality, most source-available software under terms like the FSL, BUSL, SSPL, ELv2, and SUL, provide freedom to read, use, modify, and redistribute, under most circumstances.

So why is "source-available" recommended?

I'd argue because there isn't a better term.

On one hand, the 'zealots' don't care about how the alternative term is perceived by users, nor should they — they just want the company to stop misusing their term, "open source."

Many of these 'zealots' also hate proprietary software — they think it unethical or even evil — so an alterative term that reflects their binary worldview — that proprietary software cannot offer any freedom — is even good to them.

On the other hand, the companies usually don't care about 'alternative' terms either, yet they should — they just want to communicate freedoms to their users in a way their users will understand.

Very often, open washing is that way.

Users understand that under "open source", they have the freedom to read, use, modify, and redistribute the code. Yes, there are limitations depending on the license, but to most users, "open source" means freedom, while "source-available" means nothing.

Assume open washing.

If you asked me a year ago how I felt about open washing, I'd say that I don't care — or rather, as a business owner, I care more about clear communication to users than I do about adhering to the OSI's definition of "open source" (which, by the way, has a unique history).

I'll even admit that I open washed my move from closed source to "source-available." Because the term sucks.

But today, I feel a bit different. Although I do actually think that the term "open source" has changed meaning in the general vernacular — to where if the code is "public on GitHub", users think it open source — I'm not going to die on that hill.

Because there's an alternative term now — one that's clear i.r.t. intent — clear to everybody, from the 'zealot' to the 'uneducated.' An alternative term that clearly communicates freedoms, yet also clearly communicates restrictions.

This term is "fair source."

Much like "open source" and "source-available", the term "fair source" implies the unrestricted freedom to read. But unlike "source-available", "fair source" also implies the freedom to use, modify, and redistribute the code, with minimal restrictions. But these "minimal restrictions" are only i.r.t. competing with the author.

The definition of "fair source" codifies this as:

Fair Source Software (FSS):

1. is publicly available to read;
2. allows use, modification, and redistribution with minimal restrictions to protect the producer's business model; and
3. undergoes delayed Open Source publication (DOSP).

Point number 1 is crystal clear — as it should be — so we'll jump straight to point number 2.

Under point 2, the "minimal restrictions" bit allows for the author to monetize their project in a way that doesn't restrict most users. (You may think point 2 is vague — and it is — intentionally. Since business models vary, this invites exploration in new licenses outside of the current suite of fair source licenses.)

Usually, these restrictions won't effect most users — because most users don't want to compete with the author.

I'd even go as far as to argue that 99% of users can treat a fair source license as a permissive open source license — but that will ultimately depend on the use-cases of the author and the user.

If you're one that would typically wield a pitchfork, you may still have yours at the ready. But then we get to point 3, and you start to see the values of fair source begin to truly blossom.

Under point 3, every fair source project will undergo what's known as "delayed open source publication", or DOSP. This means that, given enough time 𝑡, all fair source software will become open source — real open source — i.e. the license will transition from a proprietary fair source license to an OSI-approved open source license.

(This also means that the entire project will become open source, including any proprietary features under the "open core"-esque model known as "fair core.")

How this works is simple — when a commit is made, a version is cut, a package published, etc. — that "version" eventually transitions to open source, typically 2 years after the "release" event.

e.g. if commit 𝑎 is made on 01-01-2024, and commit 𝑏 is made on 01-02-2024, then commit 𝑎 will be open source on 01-01-2026, and commit 𝑏 on 01-02-2026.

This means, if a project is ever abandoned, it will eventually be open source; or if a project ever goes in a bad direction, it will eventually be open source. This allows users to steer a lost or sinking ship.

And remember — most users don't need to wait 2 years to start using the project — because again, most users don't wish to compete with the author. Rather, they can use it now, they can modify it now, they can redistribute it now.

But for those that do wish to compete, or those that think proprietary software is unethical, they will need to wait 2 years until the transition to open source. That means that anybody wishing to compete can do so with code that is 2 years behind master.

And that's okay — actually, I think that's fair.

Everybody that licenses their code under fair source loves open source. But they also want to be honest with themselves — and everybody else — that they want to reap the benefits of their hard work.

And that's okay — actually, I think that's good.

I think there's a disproportionate amount of dishonesty in commercial open source — dishonesty to users, but also dishonesty to self.

Authors may choose open source, but it's often in name only. They choose ambiguous and 'semi-dangerous' licenses like the AGPL — not out of altruism — but intentionally — to act as a way to push businesses to purchase commercial terms with them, or they start open source but later rug-pull to a proprietary license, or they proliferate abandonware through open core.

I believe decisions like this can be dishonest to everybody. Often, the author wants the social boost and distribution of open source, but deep down they also want to reap the benefits of their hard work, and they don't want to be exploited. And open source doesn't protect against exploitation — by-design.

In reality, many of these projects should be referred to as "source-available" i.r.t. intent, yet they aren't — and the 'zealots' don't care. Rather, the authors get away with using the term "open source", even though they build on top of a foundation of dishonesty.

But again, "source-available" doesn't have a meaning — it never did. So even if they wanted to be honest i.r.t. intent, they can't.

So we're left with the following terms:

• "source-available", which is utterly meaningless.
• "open source", often used dishonestly in startup-land.
• "open core", which is "open" for some, but abandonware for others.
• "fair source", which is honest on all fronts.

I'd urge authors to be honest — with others, and with themselves — and choose a term that reflects their true intent.

I know which one I choose.