paritybit.ca

A Critique of Free Software

Written By: Anonymous | Posted: 2021-08-05

This essay was not authored by me. It is licensed under the CC0 license (i.e. it is effectively in the public domain).

Free Software fundamentally misses the point. It fails on a practical, ideological, economic, and political level. Let’s examine precisely how (in a slightly different order for the purposes of presentation).

Ideological

Ideologically, Free Software is a bit of a jumbled mess. Let’s begin by reading the following two documents, one after the other: Should Be Free followed by the GNU Manifesto.

In the first, Stallman declares his goal to be the prosperity and freedom of the public in general. These are, of course, loaded terms, so we must read the rest of the document to understand what he means.

First, he goes over the two owner arguments - emotional attachment (which is willingly signed off) and economic gain, an effective threat to stop making software. He speaks out against giving software an owner that controls its development (something he considers to exclusively happen in the case of proprietary software). He also gives an example of a road paid by toll booths at every corner, and complains that it is an obstruction to smooth driving - pointing out that a toll booth does not merely help raise funds. He names three problems from such obstructions applied to software: fewer users, user inability to fix programs, and the inability of developers to build upon the existing work. Furthermore, he talks about wider societal effects (see the section on damaging social cohesion), and mentions that the mechanism via which sharing is restricted isn’t relevant. We end the paper with two quotes of import: “We thus have a paradox: the developer of useful software is entitled to the support of the users, but any attempt to turn this moral obligation into a requirement destroys the basis for the obligation. A developer can either deserve a reward or demand it, but not both.” and “I make the assumption in this paper that a user of software is no less important than an author, or even an author’s employer. In other words, their interests and needs have equal weight, when we decide which course of action is best.”

Keeping this in mind, let us move on to the GNU Manifesto. We must compare and contrast the actions taken to the ideology as it is presented.

First, the software project (GNU itself) is introduced. He explains his personal motivations for sharing GNU (the Golden Rule), as a method of solidarity. However, as the follow-up, there is a proclamation that GNU is not in the public domain, and that modifications are going to be restricted (insofar as it comes to the rules of making further modifications). As the ultimate goal, we have these quotes: “Users will no longer be at the mercy of one programmer or company which owns the sources and is in sole position to make changes.” and “Finally, the overhead of considering who owns the system software and what one is or is not entitled to do with it will be lifted.” The rest of the document speaks to common counter-arguments. Of these, the following quotes are of interest to us:

How are these two documents separate? One must look into the methods spoken of in the second document. How exactly are the variants becoming un-free enforced? What does this have to do with the former document (after all, as he himself mentions, it’s about creating a copy, it does not remove the original). Let us deconstruct both documents.

The fundamental basis for the GNU worldview is the original emotional argument leveled against owners - emotional attachment to one’s own work. As he says: “I want to make sure that all versions of GNU remain free.” - i.e he wishes to control other people’s lives (as mentioned in the second document), on the basis of personal attachment to GNU - “I made it, I get to make sure all copies are as I want them to be.” In this way, the very core of the GNU philosophy is based upon the same premises as those of proprietary software - i.e on IP. While GNU is happy to condemn copyright and similar laws, it consistently does so while pointing out uses of it by the bad guys - proprietary developers. Meanwhile, the GPL fundamentally relies on copyright law in order to enforce itself - so long as the good people use it in the correct way, it becomes good. Consequently, we must view the dislike of IP law by Free Software to be a sham - something reinforced in ideological discussion by them.

Proponents of Free Software will regularly talk about the “stealing” of projects (there are many examples, for instance, consider this article - the author never says the word “steal”, but the reaction of the community (such as this magazine, but also commenters) is unambiguous; I encourage you to look around and talk to people about these subjects and see what is said, how, and why). While this has further issues and implications in practical terms, this is the section on ideology. What does it mean to “steal” a project, within these discussions? It means making a non-free version of a given project. How can one steal by copying and modifying? If we do not believe in property rights for software (as per the second document), then there is simply no one to steal from. The only fundamental thing becoming proprietary are the modifications made by the new author, as the original variant remains intact. This internal framing reveals a worldview within which the author does have moral rights over their creations (this is unsurprising, given such internal justification is necessary for the GPL to not be resisted). This exact framework is similarly present in the existing documents, as mentioned above, though in less overt terms.

We must then ask the question - does this make people’s lives more or less difficult? After all, if we purport that the GNU worldview includes acceptance of IP, so long as it is used by “the good guys”, perhaps the argument would be that the GNU use is fundamentally positive.

Thankfully, there are plenty of samples of how this use is unhelpful, even in the documents themselves. Now that we are restricting uses, this must be done within the existing legal framework. The GPL is a lengthy document, that is understood neither by lawyers (who do not comprehend programming to a sufficient degree to know what it intends to mean) nor by programmers (who do not know the myriad of special meanings in court). When it comes to regular people - those that GNU is supposed to be serving - they haven’t even a chance. What happened to “Finally, the overhead of considering who owns the system software and what one is or is not entitled to do with it will be lifted.”? Now, all people but the few lawyers that know programming fall into this category.

If you doubt this and believe yourself to be someone that understands the GPL and its variants fully, answer these questions:

Many more can be said on this topic, but it’s about time to move on. If you would like some more reading consider this post (and others!) by an actual lawyer and programmer, as well as this thread by a free software developer.

Now that the same negative side-effects arise out of the GPL’s use of copyright for restriction of modifications (something that is on its own not ideologically coherent) as they do of proprietary software, when it comes to the users, we must then ask: do the users of GPL deserve this? The answer, similarly, is found in the documents. “We thus have a paradox: the developer of useful software is entitled to the support of the users, but any attempt to turn this moral obligation into a requirement destroys the basis for the obligation. A developer can either deserve a reward or demand it, but not both.” Now that we’ve determined that the GPL causes an obstruction (albeit of a lesser degree than proprietary software), it is not deserved. If it is not deserved, the prior paradox kicks in. In order to justify this, GNU (and the FSF) has two possible paths. They could either make the argument that their approach is better in some other regard. Alternatively, they could double down on ideological aspects of it as-is (e.g accusing people making free software (simply not under the GPL) of being evil). They take the latter approach, since they are similarly failing in the other spheres. For an example, see what an FSF Board member does in terms of contributions (I encourage you to look at the other contributions by him in the GNU software repositories as well).

In short, for internal consistency, GNU and the FSF fundamentally operate primarily on ideological coherence (i.e being a true believer), moreso than any single other attribute. A sort of purity war, where only the upmost is acceptable. Is it any surprise that, ideologically, Free Software has been bleeding out?

Economic and Political

As we have read previously, one of the goals of Free Software is to eliminate competition. GNU was to do this for operating systems, for instance. This largely has not happened.

For all of their qualms about “GNU+Linux”, Linux represents a small part of the desktop userbase, while on the servers, it’s largely unused (even if installed), instead simply running an existing service. Even when within the desktop userbase, plenty of desktops do not utilize GNU as their userland provider. Even within the group that does, most of the actual work is no longer done using the userland, but rather in browsers and similar. Meanwhile, more people use MacOS (a known-niche set of systems!), including prolific figures of operating system development from the past (e.g most people from Bell Labs, such as Rob Pike). All GNU has done is create an implementation of an old idea, leaving it to suffer from, mostly, lack of use (something we know they care about from the documents we read previously).

The FSF has been slowly descending into irrelevance, as it continually loses donation funds. They will eventually need to follow in the footsteps of FSFE (start litigating anyone and everyone they can think of, to make just enough money for the next case), or reinvent themselves. So far, they’ve been making (rather damaging) videos, trying to capture the young student demographic. Unfortunately, this too, has not had very much success. Due to the complete disregard for practical concerns in favor of ideological bookthumping (something they ultimately have to do due to existing ideological deficiencies, as we mentioned), they have to rely on people either not thinking the problem through (something that will usually have people default to the status quo anyway), or be indoctrinated (leading to rather inappropriate conduct - which is then normalized as a form of reward).

This, though, is more than about the FSF - what about other Free Software projects? Those using the GPL and similar? The reality is simple - they are owned by corporations.

Free software development has become a story of feast or famine. You either sell board member seats to corporations, or you barely coast off of user donations (which happen very rarely). The former, of course, means the corporations exert huge amounts of control. So, for the purposes of demonstration, here are some corporation controlled GPL (or other Free Software) projects, as well as the consequences thereof:

The examples simply keep going on and on. Look up any large well-known GPLd project you know about. Then look at where their money comes from. Think about the consequences of this to the project.

When a project is “stolen”, the original may continue to serve its users. When a project is taken over, the original now serves new masters, who have different priorities to mere users.

There is, however, an open question here - why do corporations do this? This is certainly a lot of money to put into Free Software (and other) projects. This actually comes down to a question of economics. Consider a company that wishes to offer service Foo, with some specific features. They have the following options:

As you can see, of all these options companies have, the one that GNU would have you do is the one that will happen most rarely. Even “good” companies (like MongoDB was considered prior to the SSPL) don’t keep it up, for the simple reason that other (usually bigger) corporations exist to gobble them up.

In short, sure, much of the world now runs on “approved” licenses. However, they have fundamentally failed at addressing the significant and legitimate concerns of the Free Software world. Instead, this situation grows even worse still, as you will see in the practical section. Free Software has essentially become a puppet, dancing on strings to the tune of those who know it’s not just about the license.

Practical

How does Free Software turn out in practice? The purported (practical) goals of Free Software are, from what we can gather above:

How well does it achieve all of these?

It thoroughly fails on caring about users. Basically any user that has participated in an issue board of a software project knows what the process looks like. You report the bug, it sits there for months, sometimes years, only to be closed for inactivity. If anyone complains, they’ll be told to learn to code and fix the problem themselves - something that may not be feasible to most users under current socioeconomic conditions (nor paying someone to do it). In fact, if you’re used to looking through issue boards (regardless of who you are), sufficient experience might make you notice something interesting: they are extraordinarily similar to corporate “support forums” and similar instances. There’s often someone that has no idea what you’re talking about, but assumes there is nothing actually wrong. Action is rarely taken to address any actual issues. The opinions of users are discarded in favor of louder voices in the community (based on social capital, which is granted differently between Free Software and corporations, but fundamentally works similarly under the hood).

This is hardly surprising. Free Software does not actually gain very much from userbase. No one is saying emacs is worth nothing because only a few people use it. There is fundamentally no incentive for the maintainers of any Free Software project to care about their users. Let alone users that, for example, need extensive accessibility options - something Free Software is notoriously bad at. So they don’t. Free Software is ultimately, in practical terms, a movement for developer comfort, first and foremost.

Alright, so let’s think about developers - are their lives any easier? Let’s consider a theoretical scenario. A developer sees a project and dislikes some aspects of it. They use the rights granted to them by the GPL (or other Free Software license) and make a fork. They publish all of their modifications under the same license. This should be kosher, right?

Unfortunately, this has happened several times, and we get to see how the community reacts. The reactions are negative, almost universally so. Gitea was called a hostile fork by SourceHut developer Drew Devault. The GNU Assembly was called a mutiny (by Leah, a personal friend of Stallman) and a coup (this is a preview of the, at the time of writing, yet to launch site https://savegnu.org/). A fork of RuboCop in the face of the summer protests of 2020 resulted in this incredible quote: “I was quite disappointed by the hasty creation of two RuboCop forks, without discussing any specifics with our team.” - apparently one must first negotiate with the forkee before making a fork, even though the project had already decided on not accepting the suggestions the forks implemented. However, when one does submit a patch to such a project (as in the previous example), they become a persona non grata.

None of this, however, is surprising: the actual goal of the GPL (codified as “eliminating competition”) can be surmised better as a grab for central control and authority. This is plainly obvious in, for example, the Signal project, whose maintainer explains that they are against third party clients because they don’t have absolute control over them. Ultimately, it’s not adherence to the license or to the stated goals of Free Software that count, in these cases, but ideological unity with the group (whether it be the FSF, the specific project, or other).

It’s also not just about the license (at least, not directly). Because GPL projects end up trying to be more central (see everything above), and therefore have to cover all use-cases, the code quickly becomes a jumbled mess. Consider, for example, the GNU version of the POSIX yes utility, which has been modified over time to be “ever-faster”, even though this is of no use in the context of what it’s for. The only material consequence of this was that it is now more difficult to modify. So it is with many other projects, to the point that forking major GPL projects is unfeasible - there’s no major Linux fork, not because no one wants one, but because even people whose job it is to work on it struggle to keep the basic architecture of that behemeoth in their minds.

In short: When you want a project changed, you are told to go make a fork. When you make a fork, you are vilified for taking away from the power of the copyright holder. Even if you do make a fork, the sheer quality (or, rather, lack thereof) of the sources, on average, will make it difficult to do anything useful with it to begin with. Developers as a whole are not the true beneficiaries of the GPL way - copyright holders are.

Regardless though, at least any entity that doesn’t need to worry about this will have to give back to the central community, right? Well, that depends. In practice, GPL litigations end in one of three ways:

In the busybox case, there wasn’t even a court precedent set, because it was settled out of court, so that the SFCL (the non-profit corporation that handled the litigation) would get more money that way! And of course, even when code sharing does happen (it’s usually voluntary, see the section on economics as to why corporations do this), it isn’t always to the benefit of the project.

To summarize: the GPL fails on all of its material, practical promises. Instead, it mostly serves copyright holders. Though it does this pretty well for those of them that realize they’re in this position without being a corporation.

Now What?

While GNU philosophy and the GPL fail for a number of reasons, not all is lost. It is possible to create good software, that helps people, while resisting foreign malign influence. Let’s start by addressing the most obvious issues.

First off, we have to address the scaling question. For every condition applied to one’s use or modification of a project, users and developers become more disadvantaged. Every user and developer must individually keep these in mind and figure out the exact ramifications. Most of these are not lawyers. Corporations have lawyers that will do this for them, only need to do it once, and can find loopholes. Every condition of use placed upon a project puts corporations in an advantageous position relative to the people. Consequently, as few conditions as possible within the societal framework one is operating within must be set.

This is not simply a matter of license however, but also of resource availability. While centralized systems help prevent duplicate work, duplicate work is hardly a concern for regular people. How many projects are out there that essentially do the same thing, because their developers wanted it done their way? In other words, optimizing for deduplication of work does nothing to help users or developers. On the other hand, optimizing for ease of understanding and modification makes much more sense. These desires are at odds. Optimizing for ease of understanding and modification requires smaller, more succinct, often less performant code, meant for fewer use-cases. Optimizing for deduplication means that all use-cases must be covered. Covering all use-cases bloats the code, cannot definitionally be succinct and requires it to be more performant (and thus include cursed inner working incantations).

This shows us a somewhat different picture. It is an environment where people make projects for themselves and those close to them - those whose use-cases they truly know, rather than guess about. They keep their code lean and without any strings attached, so that any component thereof (or even the whole thing) can be reused to make a similarly small-scoped project for a different group. There is no goal of having everyone use the same central system, and therefore no point in pushing for its inclusion, or anything that can be reliably purchased, co-opted, or taken over. By fully minimizing the cost of admission - not only in cognitive overhead of the meta-work (licensing), but also in the code itself, we maximally empower users and developers to do as they will, to the maximal possible extent. While it is impossible to make programming fully trivial, by its very nature, we can make it as close as possible to a craft people can participate in recreationally.

This does leave a question open. What stops corporations from taking over and taking advantage of these systems? There are a few factors. First off, them simply using the product is no longer a concern. Because each project concerns itself exclusively with the small group for whom it was developed, even a hypothetical scenario where the proprietary alternative gets mass market appeal has no effect on the project’s target demographic. It doesn’t end there, though. The needs of corporations are wildly different from those of regular people. They want SSO, they want huge integrations, they want Enterprise Features. Small projects, built for a few people, do not have this. It is uneconomical to take such a small project and try to scale it up into a monstrosity (see the prior economic section). Corporations might as well simply build brand new solutions from scratch than use such projects. Finally, this is even resistant to a corporate buyout. After all, over time, the amount of forks (which are not only to be accepted, but encouraged, instead of contributing to the “main” project) grows faster than corporations can (or want to) consume them. The proprietarization of one fork does not affect its users (they already have a working system and can easily fork it), and does not affect any forks.

Instead of seeking to make a blessed cathedral that all shall go to, and hoping that the blessing will protect it from invaders, we empower everyone to make a doghouse. To turn programming into a craft like woodworking, where making your own chair or table, while not free, is feasible for the everyman.