In Search of Foundational FLOSS Freedom(s)

A few days ago, a vulnerability in xz-utils named CVE-2024-3094 was discovered, and since then the open source community as well as security pundits fall over themselves and each other to provide the best analysis of this incident.

Don’t worry, this post isn’t another one of those.

Because while all the speculation about what motivates such a long-term attack is fun, the underlying issue is way, way simpler.

In a tweet¹, Heather Adkins of Google posted an “unpopular opinion: if your hobby is now responsible for running the modern world, it’s no longer a hobby”.

I felt inclined to be kind that day, and chose to interpret these words to mean that she feels a person maintaining such a project should be paid a living wage for it. Surely that’s what she meant, right?

I’m not writing this to be snarky. Well, OK, I am. But that’s not the only reason.

The CVE on the one hand, and this tweet on the other, represent a fundamental issue in the relationship between the FLOSS community on the one hand, and corporations on the other: FLOSS is built upon reciprocity, but corporations treat it as a resource they can extract.

Of course, as in all of these things, there are corporations that do better and those that do worse. But from the first invention of Open Source – as a derivative of and distinction to the previous Free Software – the aim has been to make FLOSS more friendly for corporations. In licensing terms, the more permissive licenses of OS differ drastically from the copyleft style licenses in that they no longer require reciprocity.

When I bring this up in any group of FLOSS contributors, the arguments invariably follow the same paths. There’s no surprise here, given that we’ve been having and re-hashing these arguments for decades now. Rather than repeating them here, let’s just say that I actually understand and agree with all of them.

That is to say, each of these arguments have their time.

When Stallman invented Free Software, it was in response to objectionable business practices. When the Open Source term was coined, it was to help bring the benefits of Free Software to a wider audience, which in this case meant businesses struggling with the existing closed source offerings.

At their respective points in time, each of these developments as well as a myriad of smaller events leading up and branching off them make perfect sense.

But the world is ever changing, and has changed since then. Which means that the old arguments, those that led to changes made decades ago, no longer apply.

Let me rephrase this more carefully: they need no longer apply.

What we can say with more certainty is that the reality they have helped construct is far more brittle than intended. A failure such as the xz vulnerability is, above all else, a call to re-examine the values we’ve constructed this reality on.

And this leads me to Sir Isaac Asimov.

And that’s why I picked this picture of robots sharing power in reciprocity.

You might know Asimov wrote a bunch of stories about robots. With the rise of LLMs and the related popularity of the “AI” term, he’s gained more visibility again. What you may not know is that he formulated three laws under which robots could be helpful to humanity, rather than harmful:

• The First Law: A robot may not injure a human being or, through inaction, allow a human being to come to harm.
• The Second Law: A robot must obey the orders given it by human beings except where such orders would conflict with the First Law.
• The Third Law: A robot must protect its own existence as long as such protection does not conflict with the First or Second Law.

Never mind how much reasoning it takes to consider these laws, and that humans struggle with the complexity of that – he was writing fiction to explore these ideas, after all, not actually programming robots.

I feel there is a spiritual kinship between these three laws and the four freedoms of FLOSS:

• The freedom to run the program as you wish, for any purpose (freedom 0).
• The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.
• The freedom to redistribute copies so you can help others (freedom 2).
• The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.

Both focus on ideals, and try to describe the ethical framework within which decision making should move – even though the topics of the respective decision making processes are rather different.

For the purposes of my argument here it is important to understand that both permissive licenses as well as copyleft licenses fulfill those four freedoms. That isn’t to say that all licenses do – rather, that the question of whether those freedoms are fulfilled governs whether or not a license becomes OSI approved.

What’s striking to me is the history of Asimov’s Laws. Because in the course of exploring them in his writing, he also modified the laws. Some modifications were small, but one modification in particular is pertinent here, namely his introduction of a later Zeroth Law:

• The zeroth Law: A robot may not injure humanity or, through inaction, allow humanity to come to harm.

Asimov realized, in the course of his writing, that sometimes it isn’t at all about whether individual humans are harmed. Because acting according to the three laws, a robot would, essentially, save Hitler from an assassination attempt.

Mixing SF franchises is a risky business, but I’ll cross the time streams now and quote Spock here: “The needs of the many outweigh the needs of the few, or the one.”

That line may encapsulate the meaning of this new zeroth law better than the law itself.

But what does this have to do with us?

Well, if FLOSS is built on the four freedoms, and FLOSS has created an environment that is brittle, i.e. prone to cracks and failures – then just like Asimov reviewed his three laws and added another to supersede them, perhaps it’s time for FLOSS to similarly augment the four freedoms.

It is, in fact, these words of Spock’s that ring in my mind the most. They are not particularly well reflected in the four freedoms, in my opinion.

The freedoms as formulated build upon each other, and freedoms 0 and 1 – the more fundamental ones – speak only about the one. YOU should be free to run and study software.

Freedom 2 introduces the many, in focusing on YOUR ability to help. Only freedom 3 speaks of community.

Compare this to Asimov’s Laws, where the original three laws also speak only about individual robots. In a sense, they were more badly formulated in this respect than the four freedoms are. But in amending them, he prioritized community over the individual by making the new law not an addendum, but the foundational principle.

I think that reciprocity needs to be similarly foundational in the four freedoms. Perhaps we have to add a -1th freedom, or perhaps we just need to amend the ones we have.

But it’s clear that freedom to extract value from OS that permissive licenses grant is not balanced by anything that guarantees reciprocity in a way that keeps FLOSS communities sustainable. That permits “hobby” maintainers to work in a way that doesn’t burn them out, so that the world can continue to depend on their efforts.

We have to address this in a fundamental way. The alternative may well be the (eventual) end of FLOSS as we know it.

I actually struggle to formulate a -1th freedom. But in part, this is because this framing of the issue in terms of “freedoms” is somewhat problematic.

There’s a reason the Universal Declaration of Human Rights does not deal in freedoms. More precisely, it does not exclusively deal in freedoms, but also in rights.

Freedoms grant everyone a choice. That is what freedom means: just because I have the freedom to run a program as I wish, I have no obligation to run it, nor to run it according to my wishes.

Rights are stronger: they permit people to demand that they can exercise the freedoms granted to them. Laws that respect the fundamental human rights understand that in practice, there is a balance to be made between the freedoms of one person and those of the other. Both have the right to their freedoms, but such freedoms must be moderated where it may impact someone else. This is encapsulated by the adage that you have the right to swing your fists how you like, but this right ends at my nose.

What this means is that the rights of others turn into obligations of yours, or that the freedom of others restricts your own. This is a necessary component of a fair system, even if it is less idealistic than speaking merely about freedoms.

I would therefore be inclined to formulate an addition to the four freedoms as a right, in order to bound the four freedoms within a framework of reciprocity.

This begs the questions of who to grant a right to, and which right to grant?

The issue with the freedoms as formulated is that “the many” are poorly reflected. Who are those “many”? Other participants in FLOSS projects?

I think that the motivation of freedoms 2 and 3 is to explicitly offer help to those who do not actively participate in projects. This, at any rate, is the impression I’m left with after a number of other discussions on this topic. I would therefore be inclined to grant a right to the general public.

Which right should that be? It must be their right to access, and to keep accessing, the benefits of a FLOSS software. That is, after all, what reciprocity implies for “them” as mentioned in freedoms 2 and 3.

Any license permits access in principle, but if the software is no longer hosted anywhere, access is effectively denied. Similarly, access in the form of a file upload somewhere is of little use to the general population; it takes a person versed in evaluating FLOSS projects to even start any process that may end with meeting the needs of the general public.

On the other hand, we cannot obligate a hobby project maintainer to provide professional support and guarantee archiving of software assets. So how do we go about this?

It brings me back to the bad ecosystem actors, those corporations who extract value without “giving back” from FLOSS. And it brings me to Karl Marx, who has stated as a reciprocal ideal “from each according to his ability, to each according to his needs”.

If we try to apply this ethos to the FLOSS ecosystem, we can fairly easily define what each participant needs, as well as what each participant can give. As an incomplete sample, consider the following table:

Of course, for illustration purposes, I’ve limited the table to a subset of the needs and abilities each participant brings to the table. It’ll be easy to fill the table with more examples.

But this set of examples does illustrate how contributors and users alike supply the corporation with labor that they wish to outsource. Conversely, corporations are designed to generate revenue, which can pay both for labor and infrastructure that developers need.

The basic model of reciprocity that FLOSS needs to be sustainable is right there.

What’s missing is the obligation, derived from participant rights, to act accordingly.

Recall that we’re discussing an addition to the freedoms here, not (yet) how this may be reflected in licensing. That’s a discussion that is much more difficult, especially if one is not a copyright lawyer. But this also gives us a lot of freedom in formulating such an addition.

I would, in the end, lean into Marx’s model of reciprocity and formulate an overarching right like this:

Every participant in the FLOSS ecosystem has the right to have their needs met according to the abilities of the other participants.

Note that if applied in a licensing scheme, this strengthens the contributor’s right, in that they can demand some kind of financial and infrastructure support in exchange for their labor.

It also strengthens the end user’s right to demand that their needs be met. A well-funded project then has little excuse not to fix bugs, improve stability and documentation, or perform other bothersome tasks.

Finally, it also strengthens the corporations’ ability to extract value from FLOSS software. I think this should address what corporations fear with copyleft licenses, that they lose this ability.

But all three participants are also required to feed into the ecosystem that which they can, in order to keep the wheels turning.

It is not OK to ask FLOSS contributors for labor without supporting them, directly or indirectly.

It is not OK to ask users to submit well crafted bug reports and user stories without also deriving from those work packages that address their needs.

It is not OK to ask FLOSS contributors or users to supply labor, if it is not compensated either by financial or infrastructure contributions.

Above, I have tried to address the fundamental issues plaguing the FLOSS ecosystem by re-examining the core tenets on which it was built, and adjust them to the current age.

We no longer live in a world where FLOSS is rare, a novel idea. Instead, we live in a world where it is indispensable. To take it away would be to regress by decades.

So rather than carving out a niche for FLOSS, its core tenets should be about sustainability. Support, and continue supporting, what is already there while permitting new projects to thrive.

I doubt that this blog post is the contribution to this debate that resolves all issues. But I hope it provides a direction forward. Too much of the debates that I witness circle around ideals made for a set of circumstances that are now lost in time.

We need to look forward instead.

Update 2024-04-25

There is an adjacent conversation going on these days that I think is relevant here, which is whether it is ethical to use FLOSS code in LLMs, and under which conditions. This thread by @onepict@chaos.social makes an excellent entry point into the debate.

On the one hand, the four freedoms clearly allow this. On the other, folk such as @abucci@buc.ci state:

By my read FOSS freedoms do not cover the case of large scale agglomerates of codebases for the purpose of generating more code that could lie in competition with the constituent codebase. That’s new, and should be treated as such. Complacency is not an appropriate response.

• On the one hand, it’s worth understanding that copyright law can be interpreted to permit this. If I read source code, and write similar source code from memory, this isn’t a violation of copyright – unless the input and output are so similar that it’s difficult to distinguish from a straight copy & paste job.²
• On the other hand, comparing this human endeavour to a LLM is questionable, if only because of what the above quote states: this could allow a competitor to effectively fork a code base without copying anything verbatim, and then claim rights on the result. That would certainly set a bad precedent.

While I still think that the above formulation of a right in addition to the four freedoms can be improved significantly, I do think that the spirit of it does prevent the second kind of scenario – or rather limit its damage by having positive side effects.

If the licensing scheme on code requires that all participants in the FLOSS process benefit, a company engaging an LLM to generate competing code clearly demonstrate its ability – and so its obligation to contribute back.

A firmly reciprocal license should not prevent use in an LLM per se, but specifically ensure that there is no path by which a company can use an LLM to generate code in competition to its inputs, and without paying the authors of its inputs appropriately.

Such a contribution should be measured in the person hours they saved in using the LLM – by applying something like COCOMO to the inputs.

I suspect that would effectively prevent these cases. And if not, be a boon to FLOSS projects.