Free Software is an Abject Failure

Author: Jake Bauer | Published: 2021-11-08

Free Software is an abject failure. It may sound like a good concept on its face—especially with the kind of language often used to describe the movement and its opponents—but, when put under scrutiny, the institutions and practices that make up the Free Software movement fundamentally fail at their stated goals. Free Software is an ideological mess, Free Software hampers collaboration, Free Software is legally ineffective, Free Software makes the lives of developers harder, and Free Software fundamentally gets in the way of a thriving software ecosystem.

The Failure of the Free Software Ideology

Why Software Should Be Free by Richard Stallman presents an argument against having owners of software and explains the harm done by obstructing software development through proprietary licensing. He posits that software with obstructions results in fewer users, the inability for users to fix programs, and the inability of developers to build upon prior knowledge or work. He also states that the justifications one uses for keeping ownership of the software (which he equates with keeping the software proprietary) are emotional (i.e. “This software is mine, and I wish to control it”) and economical (i.e. “I wish to become wealthy by programming.”). He shuns these excuses and spends the rest of the document refuting those excuses and explaining why the existence of proprietary software is bad and why the alternative—software not having owners—is better.

However, in nearly every Free Software project which exists today, there is a clear “owner” of the software—someone who is the copyright holder, benevolent dictator for life, or simply de facto leader of the project and through whom all contributions must flow. Whether we’re talking about large projects too large to fork and maintain by anybody but large, well-funded groups such as the Linux kernel (in which Linus still has complete veto power by the way), Qt (in which the company controls the development of the software and simply allows older versions to be used under a free license), or Android (where Google maintains pretty solid control), or smaller projects which have simple leaders. As long as there is a copyright statement, there are one or more owners to be aware of.

Additionally, the GNU Manifesto, aside from calling the Open Source movement an “amoral approach”, goes on to say that GNU “is not in the public domain” and will have restrictions placed on further modifications (in the form of disallowing proprietary modifications), with the justification given by Stallman being: “I want to make sure that all versions of GNU remain free.” With that, Stallman falls upon the same behaviour that he previously shunned in Why Software Should Be Free. He uses his emotional attachment to the software, something he said was an excuse to defend why software has an owner, to justify his want to control how others can distribute and modify his code. He is effectively saying “this is my creation, and I wish to control what others can do with it” as well as clearly assigning an owner to the software.

Update 2021-12-13: I was recently made aware of an article in which Richard Stallman advocates against positive change to copyright laws because of how it would hurt Free Software. Instead of making software free of copyright after 5 years, he advocates for maintaining copyright control because it would hurt the control that Free Software licenses would have over the distribution of software later on. It’s not enough that the software would still fulfill the four pillars of free software after the 5 years is up, control must be maintained over how other people can distribute and use the software in their products in case they ever decide to fork it and make something proprietary from it. Not only does he not trust that people would use only the Free version (as if we need to be protected by Free Software licenses lest we use some proprietary software), he is, in essence, advocating for maintaining ownership over software even though the change to copyright legislation would be positive for society overall. The article is called: How the Swedish Pirate Party Platform Backfires on Free Software.

If software is not in the public domain, then, by definition, it has to have at least one other owner. If Stallman can dictate how others can use his software—even if it is more freely than most proprietary software—then it clearly has an owner.

Simply put, Stallman and others in the Free Software community use the exact same excuses criticized in Why Software Should Be Free as justification for their actions. GNU, the GPL, and seemingly the entirety of Free Software as it stands today are all based on the same premises as proprietary software. They use existing copyright systems in what they deem the “right” way while simultaneously criticizing the way others use them as wrong.

To be frank, the Free Software movement comes off as both a “cult of personality"—worshipping Richard Stallman and his teachings, as well as a “cult of ideology"—shunning those who disagree with the manifestos and the “way of life” that the movement espouses to an extreme degree. As long as you, as a developer, do everything within the framework of the GPL and the culture of Free Software, you are ethical and good. As soon as you wish to do something outside of this domain—even by using a more open, permissive license—you are considered unethical.

In an article where Linus Torvalds criticizes the GPLv3, Torvalds even says:

“I think the GPLv3 is expressly designed to not allow [the meeting between open source and free software people]. Exactly because the FSF considers us open source people ‘heretics.’”

The Failure of the GPL

One of the stated goals written in the GNU Manifesto is:

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

One look at the GPL will tell you that they have utterly failed at this. The GPL, especially with version 3, has become so complicated that only a programmer with relatively advanced legal knowledge and ability to read and properly understand “legalese” will be able to decipher it to know what they are able and unable to do with it. There exist websites which explain the license in plain English, but even those say their explanations are no substitute for reading the license. This is because of the very specific meaning that many of the words in the license take on when put in the context of our modern legal system. So, while you may be able to read the GPL and think that you understand it, unless you are well-educated in “legalese”, you probably don’t fully understand the true meaning and effect that the words of the license would actually have in court.

The ramifications of the GPL are still not even fully understood by lawyers themselves. Many large companies will shy away from the GPL simply because they don’t want to take the risk of using GPL-licensed code improperly and being forced to reveal their proprietary software. While I don’t agree with proprietary software as a concept, the fact that even lawyers—who are supposed to be expertly trained in the kind of language used in the license—are uneasy about its terms further reinforces just how unapproachable it is to the everyday software developer. GNU and the GPL have done nothing to remove the overhead of considering who owns software and how it can be used.

Since the development of the GPL is reactionary—that is to say, its development and growth over time was in response to discovered workarounds—there is now even more overhead by way of the extra complication of the “-or-later/only” clauses. This is a license which has multiple versions which are not backwards compatible. A project licensed under the GPLv2-only cannot integrate GPLv3-or-later code without being re-licensed as GPLv3. The Linux kernel is an excellent example of this.

Linus Torvalds even came out strongly against the GPLv3 and the process by which the FSF created the license. Many others in the industry also saw this as an extreme and unnecessary move by the FSF to wield the ultimate power over the GPLv3; all because a manufacturer put Linux in their products and blocked users from running their own modified software on that hardware which, by the way, had absolutely nothing to do with the Linux kernel itself since the bootloader is the software that would stop users from running some other software. This led to people thinking that this was basically just an excuse to expand the scope and powers of the GPL over what could be seen as something completely out of the scope of the GPL-licensed software. The move by the FSF, the actions of Stallman, and the “tivoization” rhetoric are even heavily criticized by Software Freedom Conservancy member Bradley M. Kuhn.

Putting aside the political manoeuvrings of the FSF, the mere existence of an “-or-later” clause is a ridiculous thing to attach to a license. Anybody who licenses their project under a GPLv3-or-later license puts a lot of trust in the stewards of the GPL that the next version of the GPL will align with their values and goals; a GPLv3-or-later project will be able to be licensed under a GPLv4 license whatever the clauses of that GPLv4 license. This is a lot of stock to put into a group of people like the FSF who were so dogmatic and exclusionary in their development of the GPLv3.

The reality of the GPL is that there is still a lot of overhead in considering who owns the software and how it can be used. Not only in whether or not a developer should choose version 2 or version 3 of the license depending on their goals, but also for developers and users alike who try to understand the language of the license to determine what they can do with the software and, if they are integrating some GPL-licensed code into their own product, who actually owns and has copyright over that software.

Those who wish to integrate GPL-licensed code into their otherwise non-GPL-licensed projects are faced with the decision to relicense their code under the GPL, remake the functionality of the library under a more open license, or otherwise abandon those efforts altogether. While the GPL may “prevent” corporations or people from taking GPL-licensed code and integrating it into a proprietary product, it also prevents literally any other non-GPL-licensed project from using GPL-licensed code, even other FOSS projects.

Even so, it’s not like the GPL actually prevents corporations from stealing GPL-licensed code and integrating it into projects. While there are plenty of corporations who freely comply with the GPL, there are plenty more, such as VMWare, who don’t comply and yet don’t face consequences. Even if a lawsuit is successful, it is usually at the cost of members of the FOSS community who burn out or are left disenchanted by the whole process. Being GPL-licensed also doesn’t prevent a project from being bought and therefore having all control handed over to a corporation. This was most recently seen in the acquisition of Audacity by Muse Group in which Muse Group bought the rights to the Audacity code and project. (Note that if this software actually didn’t have owners, this could not happen.) Users have since forked the project, but this doesn’t necessarily stop something like this from happening in the future, and certainly doesn’t stop it from happening to other projects.

Update 2022-10-23: It just happened to Gitea!

The GPL-family of licenses attempt to solve a societal problem by restricting the distribution of software in a manner not unlike the so-called Ethical Software movement. The GPL acts effectively as a proprietary license that allows you to do the things it deems ethical, so long as you abide by the terms of the license with regards to the distribution and re-licensing restrictions. As long as you are in this “club”, everything is fine and dandy and you can make your changes and push them to your favourite projects. As soon as you leave this club and want to pull code from a GPL-licensed project into your MIT-licensed project, well, sorry, too bad for you.

While the GPL may not cause as much of an obstruction or be as unethical as proprietary software, it is frankly not that much better. It causes distress and conflict in the software community, is difficult for non-lawyers to fully understand, and harms developers of non-GPL-licensed FOSS software. It is, for example, the reason why the BSDs cannot take improvements made in the Linux kernel and directly integrate them into their own kernels and it is the reason why ZFS cannot be integrated into the Linux kernel, but can be shipped with FreeBSD.

For all this talk of Free Software being the ethical option and the GPL being the ultimate defender of user and developer rights, it completely goes against the ethical principles laid out in Why Software Should Be Free. So much for “free as in freedom”.

The Failure of the Free Software Culture

The GNU Manifesto speaks a lot about how:

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

But a cursory look at the current landscape of Free Software will tell you that this is simply not the case at all.

Users are absolutely at the mercy of the maintainers of software projects to integrate their changes in the current landscape of software development, especially with software projects as complicated as a many of the popular GUI toolkits, kernels, or desktop environments. In fact, the reality is that Free Software project issue boards and forums are not much better than corporate support forums. Often when one opens an issue in a large software project it can take months or even years for those issues to be worked out. It’s also not uncommon for those issues to simply go unsolved for many years. A great example of this is the ‘Add an “icon view with thumbnails” mode’ GNOME issue which was opened in 2004 (it’s almost old enough to vote!) and is still not actually fixed despite many users expressing how useful it would be to have this feature.

Users simply cannot maintain such complex software on their own and, if they have limited programming ability, cannot be expected to fork a project, make their fix, test their fix, act on feedback from the maintainers (if they’re lucky enough to get their patch or pull request noticed), and so on. The current software development ecosystem makes this impossible, regardless of the license of the project. Software is not yet simple enough for that and GNU and Free Software did nothing to solve this. In fact, it can be argued that they made this worse by contributing to the creation of a culture of “elitists” who expect all the users of their software to have the ability to read code and very technical discussions or documentation in order to understand and fix problems.

If an experienced user does come along and is dis-satisfied with their corporate support forum-like experience, they might be inclined to fork the project. However another very common sight in the Free Software community is to see accusations towards groups or companies who fork projects of making “hostile forks” or committing “theft” of Free Software. For example, Members of the Free Software community shunned and criticized the group of developers who forked Gogs to make Gitea when they forked a Free Software project to extend it for their own needs because of an unresponsive maintainer. They even still kept the project under the same license (an “unethical” Open Source license, no less).

Update 2022-09-13: I recently learned of the XFree86 fiasco in which another, similar incident occurred where one of the original developers of the X window system felt that the current state of things was untenable and that the project needed to be forked and replaced. He was summarily shunned and kicked from the project for his actions. While XF86 was not under a Free Software license, instead being under the MIT/X11 license, this is still an example of how forking is viewed by many groups who wish to maintain control over their particular software.

If software is not supposed to have an owner, as Why Software Should Be Free advocates, what exactly is being stolen? Why do they, as the creator of some piece of software, care if some company or even another FOSS developer takes it and uses it in their product or makes proprietary modifications with it? Why Software Should Be Free specifically outs this need to control what happens with one’s software as one of the main justifications for proprietary licensing and something to be avoided, yet it is seen everywhere in the Free Software culture. In fact, an article entitled Don’t fear the fork: How DVCS aids open source development perfectly exemplifies how the Free Software culture views forks (of course, it’s written from the perspective of “unethical” Open Source movement).

The goal of Free Software as laid out by Why Software Should Be Free was to create a world in which there were no owners of software and in which distribution was not restricted. Yet, despite this, the way the GPL family of licenses puts restrictions on the distribution of GPL-licensed software combined with the culture of Free Software actively encourage both of those things and actively discourage forking software and modifying it to suit your own needs. From the point of view of Why Software Should Be Free, the GPL combined with this culture is, in reality, hardly much better than the world of proprietary software we had before.

The degree of openness which exists in the current software landscape can be, to a large degree, attributed to the Open Source movement. It happened in spite of the Free Software movement, not because of it.

The Failure of Free Software to Remain Relevant

Free Software and the surrounding culture and institutions are often viewed as a farce outside of the dedicated Free Software cult community. The FSF has been slowly descending into irrelevancy for the past two decades as they struggle to do anything meaningful with their time and resources; instead opting to make a lot of unproductive noise. Take, as recent examples, how they mailed a hard drive to Microsoft telling them to put the Windows 7 source code on it, or how they accuse Apple of “censoring free software” —despite the fact that Apple isn’t actually censoring anything and plenty of Free Software projects such as Telegram are on the App Store—and also criticizing them for not supporting their specific chosen free media codecs—once again, ignoring the plenty of other free media codecs which are otherwise perfectly supported.

To expand on that last point about Free Software projects on the App Store, the Apple App Store EULA contains restrictions that the GPL doesn’t allow (see section 10 of the GPLv3 and section 6 of the GPLv2). It says:

Except as provided in the Usage Rules, you may not distribute or make the Licensed Application available over a network where it could be used by multiple devices at the same time. You may not transfer, redistribute or sublicense the Licensed Application […] You may not copy (except as permitted by this license and the Usage Rules), reverse-engineer, disassemble, attempt to derive the source code of, modify, or create derivative works of the Licensed Application, any updates, or any part thereof…

Note that this only applies to the application you purchased in the App store, as bundled by the App Store. It doesn’t prevent you from going to GitHub and modifying the software there, only modifying the software you got from the Apple App Store. Sure, this isn’t a good thing and it can be easily argued that this is unethical because you don’t ever own the apps you purchase, yet it is hardly “censoring free software” given that, as the owner of a Free Software project, you can freely submit GPL-licensed software to the App Store and Apple assumes you have the rights to provide them with a non-GPL-licensed build. If you don’t have that ability because you don’t own exclusive rights to the software and it’s not feasible for you to get the permission of every contributor with their name attached to the project, well, that’s not Apple’s problem. The FSF words their article like Apple is attacking them when, in reality, Apple doesn’t care what license you’ve chosen, only that you grant them the ability to distribute your app under the terms of their EULA. The wording in that blog post is yet another example of why the FSF are seen as a farce. They should know better.

This reputation of preferring ideological book-thumping over meaningful action is nothing new. Most who are familiar with Linux are likely familiar with Richard Stallman’s “GNU+Linux” rant in which he squabbles and nitpicks over the relevancy of GNU to the Linux name. Ignoring that the only significant contributions to the Linux system GNU can claim is the compiler, the coreutils, and the C library. While these used to be relatively significant in the early 90s, most Linux systems today run far more non-GNU software than GNU software.

In fact, even those base GNU components are quickly fading into irrelevancy as projects like Clang/LLVM, rewrites of coreutils to be faster and cleaner (e.g. Busybox or various Rust projects), and other libc’s such as muslc are gaining more and more traction each passing day. GNU is simply failing to make any meaningful and actual progress, and is grasping at straws in an attempt to remain relevant. Not only have other projects such as OpenBSD long since abandoned things like modern GCC due to later versions becoming unmaintainable, buggy behemoths, GNU themselves haven’t even released their HURD kernel in any meaningful capacity despite promising to create such a thing since before Linux existed.

Speaking of fading into irrelevancy, many of the Free Software institutions such as the Software Freedom Conservancy and Free Software Foundation Europe have either been reliant on GPL violation lawsuits as one of their primary means to exist, or have been relatively ineffective at carrying out their mandates with regards to litigation. It has gotten so bad that the SFC have tried to bring lawsuits on behalf of the users of GPL software; something which has little basis in actual copyright law, but is the only option they have left when companies either skillfully hide their GPL violations or the owners of GPL software are unwilling to enforce their license against large opponents. A cursory glance on the SFC’s website reveals a lot of information about this Vizio lawsuit, but not much information about previous lawsuits or successes. No wonder these institutions also tend to only go after small opponents from which they can continue to justify their existence. Even very public violations such as those committed by OnePlus have still gone unanswered for. If such violations are clearly allowed to continue with such ineffective enforcement, what use even is the GPL in reality?

Regarding the quality of GNU software, outside of the Free Software community, GNU code has a reputation for being resource-hungry, buggy, bloated, or annoying and frustrating to work with, as many who have had the pleasure of using alternative libc’s, compilers, utilities, or programs will attest. GNU creations have a reputation for being needlessly complex—solving problems which don’t really exist in the first place if you write good software (or documentation)—and having obtuse source code. The GNU Info system and the code found in many of the coreutils are good examples of this.

Finally, we can talk about how the conduct of Richard Stallman himself reflects on the whole Free Software movement. The Free Software movement went through its own little “constitutional crisis” over the question of whether or not to keep him on as the face of Free Software after he made some comments on an MIT mailing list about a sensitive topic. I won’t go into specifics about that situation here, since it has been covered to death in other media outlets and can be easily searched for (search “stallman mit mailing list”), but, suffice to say, Stallman acted in a completely unprofessional and inept manner. In fact, that is far from the only example of him behaving in such a way.

In 2007, Stallman sent a message to the OpenBSD-misc mailing list entitled “Real men don’t attack straw men” in which he accuses the OpenBSD folk of making straw-man arguments about himself, and then using those arguments to attack his credibility. If you read through this mailing list thread, you don’t have to go far to realize that Stallman has absolutely no clue what he’s talking about. He bases his opinion of OpenBSD on “what I have heard” and presumes that the OpenBSD folk care whether or not he recommends their system. He proceeds to have everything he said get taken apart by the replies which point out all the inconsistencies in his own arguments and stances.

After seeing just how ineffective this culture is at advocating for and enforcing its principles in a meaningful way, as well as seeing the conduct of one of its top-most members, how could anyone view this as a movement to be appreciated, let alone joined and celebrated?

Where Do We Go From Here?

I think, by now, it is accurate to say that Free Software is an abject failure.

It has failed at its stated goals through both the licenses and the culture it has created and has instead perpetuated the paradigm of software ownership and the use of unethical and flawed copyright legislation. It has done very little to prevent corporate takeover of projects, improve the software development landscape, or make the lives of developers or users easier. It has done nothing that more ethical, permissive software licenses and the culture of collaboration born out of projects such as BSD Unix didn’t already do, except to create a toxic subculture of Free Software cult worshippers.

One cannot solve the copyright, ownership, or restricted distribution problems of software through playing into the exact same flawed systems that allow such problems to exist in the first place. These are problems which must be solved on a societal level, not on the level of individual software projects through an obtuse license. Free Software, as it stands today, has the very real effect of restricting innovation, sharing, and collaboration between developers.

None of this is to say that proprietary licenses are okay or even that the Open Source movement is the alternative. In fact, the Open Source Initiative is not all that much better than the Free Software Foundation, it just has a mostly different set of problems which are out of scope for this essay.

For the most part, I agree with Why Software Should Be Free. Stallman has perfectly valid and good ideas in that essay, yet he misses the mark with their implementation. I mainly agree with Stallman’s points that software should not have owners and that restricting software distribution is unethical. I believe that software shouldn’t have owners and nobody should get to control how their software is used, studied, distributed, or hacked upon.

The only licenses which truly meet all these criteria and would be considered ethical under that framework are public domain-equivalent licenses. Licensing your code under the Unlicense, the 0BSD License, or the CC0 License means that you do not place any restrictions on the software whatsoever. People don’t even have to mention your name or your project when they use your code because you are no longer the owner of that software.

If you do at least wish to have your name attached to the code (something that I personally want if I care about the software I’m writing), commonly used permissive licenses are the best option. Licenses such as the MIT License or the ISC License (my preferred license) impose no further restrictions other than maintaining a copyright and permission notice for that code if used in other projects. People are free to do whatever they want with your code, so long as they keep your name on parts that you wrote.

Not only do these options provide far more real freedom to developers, they remove the overhead of having to think about who owns the software. In the case of software in the public domain, you don’t have to worry at all because there is no owner. In the case of permissively-licensed software, it’s a simple matter of copy-pasting the necessary notice(s) wherever that code is used. These licenses are also simple, easy to understand, and the culture surrounding them is such that you don’t have to worry about a mob coming after you for forking a project and morphing it into something that serves your needs, nor do you have to worry about being sued for an accidental violation of a license that even lawyers aren’t confident about getting right.

You’ll notice that those licenses, however, do not address the issue of corporations controlling software development and distribution, people using software in ways you may deem bad or harmful, or the existence of megasoftware. This is because those are problems that cannot be solved or even effectively addressed by software licensing. These are societal problems that must be tackled on a societal level. Attempting to do otherwise simply harms and imposes more restrictions on small teams, independent developers, and hobbyists who don’t have the resources to ignore your restrictions or buy your development team.

In reality, by licensing your project under the GPL and participating in Free Software culture, instead of limiting the harms that corporations inflict, you end up limiting the good that the rest of us can do. Free Software has failed.