Why Open Source Matters

Is it “open source”? The question doesn’t really matter. – Matt Asay

When we as an industry talk about whether the term open source matters, we need to talk about that question on more than one level. There’s the obvious question of the licensing for a given project. Often ignored, however, are the wider industry implications.

Before we get there, however, let’s accept up front that developers don’t care about licensing particularly, and they never have. Many developers, for example, historically selected licenses for their projects not by evaluating their relative merits but simply by choosing the same license of projects they admired and used. They enjoy open source, but for better or for worse, they don’t particularly care about it.

It’s worth pointing out two things at this point, however:

• First, developers don’t care about the definition because they don’t have to, and the reason they don’t have to is because of said definition. Developers don’t have to worry, among other concerns, about royalties or what size their user base is or what their revenues are when using open source software because the open source definition does not permit restrictions on use. Ironically, the very meaning of open source that developers imperil with their neglect is what has allowed open source to become what it is today.
• Second, developers caring about something is, as has been argued here previously, meaningful and important. This does not imply that the reverse is true, however. Developers don’t care because they don’t have to, as stated above, and also because their focus is, quite understandably, myopic. They worry about the software they’re directly using and working on that day, not the wider implications of a licensing shift over the long term from an industry perspective, because they get paid for the former and not the latter. That does not mean, however, that the latter is unimportant. Arguing that the definition of open source doesn’t matter because developers don’t care about it is like arguing that climate change doesn’t matter because citizens don’t care.

The definition of open source that the industry has relied upon and thrived under for better than two decades was born in contention and has lived its life under constant pressure. The pressure on it may be more acute at present, but the desire of vendors to push the the boundaries of the license are not new. Such conversations have been happening for years, and will continue to happen whatever the fate of the term open source.

What is relatively new is what appears to be an emerging consensus from commercially motivated parties, typically single party commercial open source vendors and especially their investors, to act collectively – explicitly at times, implicitly in others. No one vendor or third party could work to change the definition of open source on its own. If a large enough group of commercial parties works in concert, and they are not actively opposed by other commercial interests, foundations and other interested industry participants, it might be possible. There are long time industry people asking, in fact, whether this has already happened.

While the view here is that final outcome has yet to be decided and there are paths down which the definition of open source can recover and be restored, it is certainly possible to argue at present that the direction of travel from an industry licensing standpoint suggests that open source is at a crossroads, and that those seeking to break the definition of open source to one that permits their particular desired behavior(s) are closer to achieving their goal than they have been in many years.

From the sea of formerly open source re-licensed databases to Meta’s repeated poor behavior with respect to its open source licenses to an as yet unannounced but pending major relicensing effort to even the long time open source standard bearer, Red Hat, flirting with the limits of license compliance, the definition of open source is besieged.

It is clear, however, that many arguing that the definition is or should be changed have not followed the line of reasoning beyond the implications for a single project. For whatever the reason, they stop short of asking the question of what happens when the behavior is common, or contemplating what a world with a compromised definition of open source might look like.

When it comes to the definition of open source, there are three main camps:

• Those that don’t care: by far the largest group, as discussed above.
• Those that want to protect the definition: a much smaller group, many of whom have fought over a period of decades to help advance the cause of open source to where it is today, a group that these days are being pilloried – typically by commercial providers or their investors – as little more than pedantic ideologues.
• Those that want to change the definition: Just like another group, those claiming that the open source definition does not matter are likely trying to sell you something. Generally, what they are trying to sell you is a license that allows them to have their cake – the immensely successful and popular brand that is “open source” – and eat it too, which is to say the benefits without any of the costs of open source. Typically this means the addition of the ability to restrict a behavior, use or model that they feel impinges on their ability to exclusively monetize an asset.

At the most basic level, open source works and has been successful for one simple reason: its boundaries are narrowly prescribed, and are universally understood. Any developer or enterprise can look at a license – be that permissive or copyleft – and understand simply what their rights and responsibilities are, no lawyer needed. They also are free from arbitrary and variable restrictions.

When vendors willfully and knowingly apply the open source term to code that is open but carries some restrictions that the currently accepted definition of open source would not permit, what they’re implicitly asking for is the marketing bump from open source with the exclusivity of a proprietary software model. To be clear, vendors are and should be free to license their code as they wish, with whatever restrictions they deem necessary, up to and including closed, proprietary models. All that those who care about open source ask is that they do not use that specific term where the software is not made available on that basis. There are numerous alternatives available from source available to non-compete to shared source, all of which accurately describe models in which the code is available but there are some restrictions which prevent the code from being open source. But vendors prefer the marketing value of open source, and thus are willing to apply it even if it’s not accurate, and even if it ultimately destroys the very marketing value they crave.

The impact of any single project carrying a restricted, source available license and being called open source by its creator is, in and of itself, limited. The technology ecosystem is too big and broad to be disproportionately impacted by a license decision, even for an important project. Which is why you see vendors arguing that their use of open source for code that is not actually open source is not an issue for their developers. That may or may not be the case – certainly more than one such licensing controversy has triggered a substantial community, and occasionally commercial, backlash. But let’s accede the point for the sake of argument.

The problem, then, is not with any individual vendor but rather in the aggregate behavior. As referenced previously, Kant’s Categorical Imperative simply describes the nature of the problem:

“Act only according to that maxim whereby you can at the same time will that it should become a universal law.”

The question for a vendor, then, is not whether their non-open source license is a problem, but what would the industry look like if every project followed suit?

The answer is that instead of the embarrassment of riches of open source projects we have today that developers may take up and use for whatever they choose without reference or restriction, we’d have a world dominated by projects carrying varying, conflicting usage restrictions that would render the licenses incompatible with one another and not usable by some. Imagine a world where Linux was only usable by Facebook but not Amazon, Google or Microsoft; that is the world that Llama’s license, at least, points to.

And that’s the best case outcome, in fact, one in which these non-open source licenses at least remain consistent in the number and nature of their restrictions. But given that vendors have already shown a willingness to unilaterally relicense their projects – some multiple times – and the reality that licenses are coming with more restrictions over time, that seems like a questionable assumption. If vendors are successfully breaking open source’s strict and hard won definition and its fundamental promises by inserting qualifications and restrictions into it today, what is to stop them from introducing more onerous restrictions over time?

A world in which non-compete licensing grows at the expense of open source is problematic enough. A world in which vendors blur the definition of open source such that regular users can no longer differentiate between the two is much, much worse.

Pedantic as it may seem, then, the question of whether something is actually open source really does matter, as those who would redefine the term will find out if they get their way.

Disclosure: Amazon, Google, Microsoft and Red Hat are RedMonk customers. Meta is not a RedMonk customer.