Most people who publish a WordPress website, carry an Android phone or use a cloud service have never given Richard Stallman much thought. They may not know what the GNU Project is, how copyleft works or why one software license can influence an entire industry. Yet they regularly use technology built on foundations that would be difficult to imagine without Stallman’s work.
That does not mean the modern digital world follows his values. In many ways, the opposite is true. Our devices are increasingly locked down, our software is rented rather than owned, and much of our personal computing now happens on servers we cannot inspect or control. Stallman helped make source code more accessible, but accessibility alone did not guarantee freedom for the people using it.
This is what makes the relationship between Richard Stallman and free software so interesting. His philosophy succeeded well enough to become part of the invisible infrastructure of modern technology, but not well enough to determine how that technology ultimately treats its users. His code and licenses travelled further than his ethics.
Richard Stallman and Free Software Changed the Rules
The story often begins with a printer at the MIT Artificial Intelligence Laboratory. The printer was prone to paper jams, and the researchers wanted to modify its software so that users would receive a notification when something went wrong. That kind of modification had once been normal inside the collaborative programming culture Stallman knew. However, the source code for the newer printer was unavailable, and the manufacturer controlled what its users were allowed to change.
It is a memorable story, although it should not be reduced to a single cinematic moment in which the free software movement suddenly appeared. The deeper change was cultural. Software was moving away from a shared body of technical knowledge and becoming a product distributed under restrictive agreements. Programmers who had once exchanged improvements were increasingly being told that the code beneath their tools was none of their business.
Stallman did not see this merely as an inconvenience for developers. He considered it a power relationship. If software controlled what a computer did, and only its owner or manufacturer could understand and modify that software, then the user did not truly control the computer. The machine may have been sitting on the user’s desk, but an important part of its authority remained elsewhere.
In 1983, Stallman announced the GNU Project with the goal of building a Unix-compatible operating system that users could run, study, modify and share. Two years later, he founded the Free Software Foundation. The FSF’s account of the free software movement still presents software freedom as an ethical and social question rather than a development methodology.
That distinction matters. Stallman was not simply proposing a cheaper way to produce software. He was arguing that certain freedoms should remain with the user regardless of whether the software was free of charge, sold commercially or developed by volunteers.
Free Software Was Never Mainly About Price
The English word “free” created a branding problem that has followed the movement for decades. Many people naturally interpret free software as software that costs nothing. Stallman meant freedom, not price. A program could be sold and still qualify as free software, while a free download could remain completely proprietary.
The philosophy is built around four essential freedoms. Users should be able to run a program for any purpose, study how it works, modify it to meet their needs, and share original or modified copies with others. Access to the source code is necessary for several of those freedoms, but source availability is not the final goal. The goal is meaningful control.
This makes Richard Stallman and free software more radical than the familiar idea that opening source code leads to better engineering. Better code may be one result, but Stallman’s argument does not depend on efficiency. Even if a proprietary program were beautifully designed, perfectly secure and supported by a generous company, the user would still depend on permissions that the company could change.
That is why his language often sounds moral rather than technical. Proprietary software does not merely represent a different business model in Stallman’s framework. It creates a hierarchy in which developers or vendors possess powers denied to users. The free software movement tries to change that distribution of power.
This position can feel uncomfortable because it refuses the industry’s favourite escape route: convenience. A product does not become respectful simply because it is easy to use. A pleasant interface can hide a deeply unequal arrangement, just as an open repository can exist under governance that gives its community little genuine influence. This difference between visible openness and actual control also runs through our examination of open code and closed governance.
GNU Turned an Ethical Argument Into Working Software
A philosophy can criticise the world without changing it. GNU mattered because Stallman and the developers who joined the project began constructing an alternative. They worked on compilers, editors, debuggers, libraries, command-line utilities and many of the other components required for a complete operating system.
Some of those tools became foundational. GNU Emacs grew into one of the most influential programmable text editors. The GNU Compiler Collection helped make it possible to compile software across different machines and architectures. GNU Debugger, the C Library and familiar command-line tools became part of the environment in which generations of developers learned and worked.
This practical work is sometimes overshadowed by arguments over terminology. Stallman has long insisted that systems commonly called Linux should often be called GNU/Linux because the Linux kernel is frequently combined with GNU components to form a usable operating system. Many people reject the name, regard it as awkward or believe it understates the contributions of other projects. The disagreement has become almost ritualistic.
However, the naming debate can obscure the more important point. The GNU Project had built much of a free operating system before the Linux kernel arrived. Linux filled a major missing component, while GNU supplied a significant part of the surrounding system in many distributions. Modern free operating systems emerged from an ecosystem of projects, communities and licenses rather than the work of one heroic inventor.
Stallman did not create every tool that later benefited from his movement. He did something arguably more consequential: he helped establish the conditions under which many independent tools could remain available, modifiable and shareable. That required more than goodwill. It required a legal mechanism.
Copyleft Was Stallman’s Most Powerful Invention
Publishing source code is an invitation, but an invitation can be withdrawn. A company can take permissively licensed software, improve it, combine it with proprietary components and distribute the resulting product without sharing all of its changes. That approach can encourage adoption, but it does not guarantee that improvements return to the public commons.
Stallman’s answer was copyleft. Instead of abandoning copyright, copyleft uses copyright law to preserve specific freedoms. People may copy, modify and distribute the software, but distributed derivative versions must provide the same freedoms to their recipients. The restriction exists to prevent someone else from imposing a more restrictive arrangement downstream.
The GNU General Public License became the best-known expression of this idea. The GNU GPL did not ask every developer to share code out of kindness. It created enforceable obligations that travelled with the software when it was redistributed. Freedom was no longer dependent solely on the personality of the current maintainer or the business strategy of the current owner.
This was a remarkably clever reversal. Copyright had traditionally been used to limit copying, modification and redistribution. Copyleft used that same legal framework to protect those activities. It treated freedom not as the absence of rules, but as a condition worth defending with rules.
Critics sometimes describe the GPL as restrictive, and they are not entirely wrong. It restricts the ability to convert covered code into a proprietary derivative and distribute it without corresponding source code. The disagreement is really about which freedom deserves priority: the developer’s freedom to relicense and close a derivative, or the recipient’s freedom to study, modify and share the software they receive.
Stallman’s dogma answers that question without hesitation. The freedom of future users takes priority. That uncompromising answer made the GPL less attractive to some companies, but it also made the license powerful enough to shape corporate behaviour. A softer principle might have earned broader approval while producing weaker protection.
Linux Shows the Scale of Stallman’s Indirect Influence
Linux is the clearest example of why Stallman’s influence must be described carefully. Richard Stallman did not create the Linux kernel. Linus Torvalds began that project in 1991, and its development culture has never been identical to Stallman’s movement. Torvalds has often approached open development pragmatically, while Stallman frames software freedom as an ethical duty.
Nevertheless, the Linux kernel is distributed under GPLv2. The kernel’s official licensing documentation explains that the license applies to the kernel source as a whole, with specific exceptions and compatible licenses covering certain files. This decision helped ensure that distributed modifications to the kernel could not simply disappear into closed proprietary forks.
The result is one of the most important collaborative engineering projects in history. Linux runs servers, supercomputers, routers, embedded systems, televisions and phones. Companies that compete fiercely in the market contribute to a shared kernel because maintaining every component privately would be expensive and inefficient.
That does not make Linux a pure implementation of Stallman’s philosophy. Many Linux-based devices remain locked, and their owners may be unable to install modified software even when source code is available. Drivers, applications and management services can remain proprietary. A device may comply with the GPL at the level of distributed code while offering little practical freedom to the person holding it.
Even so, the license changed the starting point. Manufacturers could use Linux, but they also entered an ecosystem with obligations that did not exist in conventional proprietary development. Stallman’s role was not to design the Linux kernel. His role was to help create the legal and philosophical environment in which such a kernel could become shared infrastructure without being quietly enclosed by its most powerful users.
This is why arguing that Stallman “created Linux” would be inaccurate, while claiming that he had little influence on Linux would be equally misleading. His impact is embedded in the rules surrounding the code.
WordPress Brings the GPL Into Everyday Publishing
The influence of Richard Stallman and free software becomes unusually concrete when looking at WordPress. The software powering this website is released under GPLv2 or any later version, as the official WordPress license pagemakes clear. Every theme, plugin and modification exists inside an ecosystem shaped by that licensing choice.
WordPress demonstrates that GPL software does not have to reject commercial activity. Hosting companies sell managed WordPress services. Developers sell themes, plugins, maintenance and expertise. Agencies build businesses around installations their clients are legally free to inspect and modify.
This does not mean the WordPress economy is perfectly aligned with Stallman’s ideals. Premium services may depend on proprietary infrastructure, restrictive accounts or subscriptions. Some products technically provide source code while making practical independence difficult. Open licensing does not automatically create fair governance, good documentation or a healthy community.
Still, the underlying freedom matters. A publisher can move a WordPress website between hosting providers, modify the theme, replace a plugin, export content or hire a different developer. Those choices may require time and expertise, but they exist in a way that would be impossible inside a completely closed publishing platform.
The fact that _TECHDOGMA can modify its own WordPress theme, decide how articles appear and retain control over the publishing environment is not an abstract philosophical benefit. It is an everyday example of software freedom becoming practical agency.
Android Is Both a Victory and a Warning
Android presents a more complicated legacy. At its foundation, Android uses the Linux kernel and therefore inherits an important GPL-covered component. The Android Open Source Project also makes a large portion of the operating system available for inspection and modification.
However, most AOSP software uses the Apache License 2.0 rather than the GPL. Google’s AOSP licensing documentation identifies Apache 2.0 as the preferred license for most Android software, while Linux kernel changes remain an important GPL-covered exception.
This distinction is not legal trivia. Apache 2.0 is a permissive license. It allows companies to build proprietary products on top of AOSP without applying copyleft to every distributed modification in the same way the GPL would. Manufacturers can combine open foundations with closed interfaces, proprietary applications and tightly controlled services.
That is exactly what happened across much of the Android ecosystem. The core platform encouraged enormous adoption and experimentation, but the ordinary user often experiences Android through a device controlled by a manufacturer, mobile operator and service provider. Bootloaders may be locked, updates may end early, and essential applications may depend on proprietary Google services.
Android therefore proves both the reach and the limits of Stallman’s ideas. Free software helped make the platform technically possible and economically attractive, yet open components did not guarantee a free user experience. Code freedom at one layer can coexist with dependency at another.
The modern technology industry has become very skilled at this combination. It uses open infrastructure where collaboration lowers costs, then builds proprietary services where control creates revenue. Stallman’s dogma helps us see that architecture more clearly because it asks who ultimately possesses the freedom to change the system.
Open Source Made the Idea Easier to Sell
By the late 1990s, many developers wanted to promote collaborative software development without Stallman’s moral language. The term “open source” offered a more business-friendly vocabulary. It emphasised practical advantages such as reliability, transparency, peer review and faster innovation.
The Open Source Definition still requires far more than simply placing code in a public repository. It addresses redistribution, source availability, derived works and technology-neutral licensing. Open source is not meaningless, and it has helped bring collaborative development into companies that might have rejected the rhetoric of the free software movement.
However, Stallman has always argued that open source changes the subject. A company may adopt open development because it produces better software while remaining uninterested in whether users gain meaningful control. If the practical method stops delivering a competitive advantage, the company can reconsider its commitment without betraying any deeper ethical principle.
The free software movement asks a harder question. It does not begin with whether openness creates better products. It begins with what software users should be allowed to do. Efficiency is welcome, but freedom is not justified by efficiency.
This difference explains why Stallman can sound dogmatic even to people who support open-source software. He refuses to translate the movement entirely into the language of innovation, market growth or developer productivity. Those arguments may persuade executives, but they also allow the user to disappear from the story.
There is a useful tension here. Open source made collaborative software easier for the mainstream technology industry to adopt. Free software preserved the uncomfortable reminder that collaboration and user freedom are not necessarily the same thing. The industry benefited from both, even when it preferred to acknowledge only one.
The Cloud Exposed a Weakness in the Original Model
Traditional software licensing assumes that a program is distributed. Someone receives a copy, installs it and runs it on a machine. The GPL activates important obligations when covered software or its derivatives are distributed to others.
Cloud services changed that relationship. A company can modify GPL software, run it on its own servers and allow millions of people to interact with it over a network without necessarily distributing the modified program to those users. People receive a service rather than a software copy.
From the user’s perspective, this can create an even stronger dependency than traditional proprietary software. The program is no longer merely difficult to inspect; it is running on someone else’s computer. The service provider controls the code, infrastructure, interface, data access and terms of use.
The GNU Affero General Public License was developed to address this network-service problem. The GNU guide to GPLv3 and the AGPL explains how the Affero approach adds source-sharing requirements for users interacting with modified software over a network.
Yet AGPL adoption remains limited compared with the enormous scale of cloud computing. Many companies avoid it precisely because it reduces their ability to keep server-side modifications private. Others build services from permissively licensed components or separate open software from proprietary layers.
This created one of the strangest outcomes in modern technology. The cloud runs extensively on open-source infrastructure, but cloud users may possess almost none of the freedoms Stallman considered essential. The code beneath the service can be open while the relationship between the service and its user remains closed.
A person can access a sophisticated application from any browser without installing anything, yet cannot preserve the current version, inspect the service logic, move the complete system elsewhere or continue using it after the provider shuts it down. Convenience increases while autonomy declines.
This resembles the broader transition examined in our article on technology’s shift from ownership to permanent access. Stallman’s framework reveals that subscriptions are not only a pricing model. They can also represent a transfer of control from the user to the provider.
Stallman Won the Infrastructure but Lost the Interface
Look beneath the visible surface of modern technology and Stallman’s legacy is difficult to miss. Linux, GNU tools, GPL projects and countless open components support servers, developer environments and connected devices. Software companies depend on shared code even when their public products are proprietary.
Look at the interface presented to ordinary users, however, and the picture changes. App stores determine which software may be installed. Devices resist modification. Streaming platforms remove purchased content. Cloud applications can change overnight. AI systems offer access to outputs while revealing little about their training, rules or internal operation.
This is the central paradox of Richard Stallman and free software. The movement helped normalise the idea that developers should be able to inspect and improve shared code, but it did not establish the same expectation for the people using finished products and services.
Part of the explanation is economic. Companies recognised that open infrastructure could reduce development costs, attract contributors and accelerate standards. At the same time, control over users, data and distribution remained commercially valuable. The industry adopted the layer that encouraged collaboration and protected the layers that produced dependency.
Another part is cultural. Software freedom often demands effort. Users may need technical knowledge to modify code, install an alternative operating system or operate their own service. Companies offer convenience by managing those complexities, but management easily becomes control. The user exchanges responsibility for simplicity and later discovers that the exchange also included autonomy.
Stallman’s philosophy does not provide an easy answer to this problem. Telling every user to compile software or operate a server is unrealistic. The more useful lesson is that convenience and freedom should not be treated as natural opposites. Good technology should make meaningful control accessible rather than reserving it for experts.
The Cost of Being Uncompromising
Calling Stallman’s position a dogma is not necessarily an insult. A dogma can become rigid, difficult to question and poorly adapted to changing circumstances. It can also preserve a principle when every practical incentive encourages compromise.
Stallman’s absolutism has often limited his ability to build broad coalitions. His terminology can feel detached from the way ordinary users understand technology. Arguments about GNU/Linux naming or the precise moral status of different licenses can consume attention that might otherwise be used to explain why software freedom matters in daily life.
The movement has also sometimes treated technical purity as though it were the same as practical accessibility. A system can be entirely free software and still be intimidating, poorly documented or inaccessible to nontechnical users. Legal freedom has little value if only a small group possesses the knowledge required to exercise it.
At the same time, removing Stallman’s rigidity would change the movement itself. A philosophy designed primarily to cooperate with existing business models would have been easier to adopt, but it might never have produced copyleft. Without a clear refusal to let freedom disappear downstream, the GPL could have become another polite request that powerful organisations were free to ignore.
The fair criticism is therefore not that Stallman cared too much about user freedom. It is that a durable movement needs more than one voice and more than one style of leadership. Moral clarity must be joined by inclusive communities, practical design, patient communication and governance that does not depend on a single personality.
Software freedom should be larger than Richard Stallman. Its future depends on whether the movement can preserve the strength of his ideas while developing institutions capable of questioning their own methods.
Why Richard Stallman’s Ideas Matter Again
For a while, the free software debate could seem like a specialist argument about operating systems and licenses. Today, the underlying questions have returned in forms that affect almost everyone.
When a farmer cannot repair software-controlled equipment, the issue is control. When a phone stops receiving updates even though its hardware still works, the issue is control. When an ebook can be changed or removed remotely, the issue is control. When a subscription application holds years of personal work in a proprietary format, the issue is control.
Artificial intelligence adds another layer. A model may be described as open because weights can be downloaded, while its training data, development process or complete production system remains unavailable. Another model may expose source code around a service while keeping the model itself behind an API. The vocabulary of openness becomes flexible precisely when the distribution of power needs to be examined most carefully.
Stallman’s framework does not automatically solve these new problems. Software licenses cannot by themselves resolve questions about training consent, data rights, compute concentration or platform governance. Nevertheless, his central question remains useful: what freedoms does the user actually possess?
That question cuts through marketing language. It asks whether people can understand the systems affecting them, modify those systems, leave a provider without losing their work and share improvements with others. It also asks whether those freedoms exist only on paper or can be exercised in practice.
The answer will rarely be perfect. A modern digital service involves software, servers, data, identity systems and communities. Still, asking the question changes how technology is evaluated. It moves the discussion away from features alone and toward the relationship a product creates between its maker and its user.
That is the lasting value of Stallman’s dogma. It offers a vocabulary for recognising dependency before dependency becomes normal.
The Legacy Is Larger Than the Man
Richard Stallman did not build the modern digital world alone. He did not create Linux, Android, WordPress or the cloud. Thousands of communities, companies and individual developers produced those systems, often for reasons very different from his own.
However, his influence does not depend on claiming sole authorship. He recognised early that software would become a form of power, then spent decades trying to establish rights for the people subjected to that power. He helped turn those rights into working tools, institutions and licenses.
The result is a legacy full of contradictions. Companies use free software to build proprietary services. Open platforms support locked devices. Developers enjoy freedoms that their users never receive. The infrastructure may be collaborative even when the final experience is tightly controlled.
It would therefore be too simple to say Stallman won. The world he wanted—one in which users broadly control their computing—does not exist. Yet it would be equally wrong to say he failed. His ideas became part of the legal and technical foundation of systems used across the planet.
Perhaps the most accurate conclusion is that Stallman won the infrastructure but lost the interface. His work helped protect the freedom to build modern technology, while the products built with that freedom often restricted the people who eventually used them.
That unfinished victory is precisely why Richard Stallman and free software still matter. The purpose of revisiting his philosophy is not to treat every statement he made as unquestionable. It is to recover a question the technology industry would often prefer to leave unanswered:
When software becomes essential to modern life, who should it ultimately serve—the organisation that controls the code, or the person whose life the code controls?
