Nov 07, 2025·8 min
Richard Stallman and Free Software: Ideas That Changed Code
Explore Richard Stallman’s free software philosophy, the GNU project, and the GPL—and how they reshaped licensing, developer rights, and open source.
Explore Richard Stallman’s free software philosophy, the GNU project, and the GPL—and how they reshaped licensing, developer rights, and open source.
Software isn’t just a technical product—it’s also a set of permissions. Who can run it, copy it, share it with a friend, fix a bug, or build something new on top of it? Those questions are answered less by code and more by licensing. As software became central to work, communication, and research, the rules around “what you’re allowed to do” started shaping innovation as much as the features did.
Richard Stallman (often called “RMS”) matters because he made those rules impossible to ignore. In the early 1980s, he watched a shift: more programs were distributed without source code, and users were increasingly told they could use software only on someone else’s terms. Stallman framed this not as a minor inconvenience, but as a loss of user and developer freedom—and he responded by proposing a clear set of principles and legal tools to protect those freedoms.
This article focuses on Stallman’s ideas and their practical consequences: the Free Software definition, the GNU Project, copyleft, and the GNU General Public License (GPL)—and how these shaped the modern open-source ecosystem and software licensing norms.
It’s not a biography, and it’s not a technical deep dive into compiling kernels or managing repositories. You don’t need a programming background to follow along.
Stallman is influential and also controversial. The goal here is to stay factual and readable: what he argued for, what legal mechanisms emerged, how businesses and developers adapted, and where debates continue today—so you can see why his work still affects everyday software choices.
“Free software” is easy to misunderstand because the word free sounds like a price tag. Richard Stallman used free to mean freedom—the user’s ability to control the software they rely on.
If a program costs $0 but you’re not allowed to inspect it, change it, or share it, it can still be “free as in beer” while being unfree in the sense Stallman cared about.
Free software is defined by four basic permissions:
These freedoms are about agency: you’re not just a consumer of tools—you can become a participant who can verify, adapt, and improve them.
Freedoms 1 and 3 are impossible without access to the source code—the human-readable instructions. Without it, software is more like a sealed appliance: you can use it, but you can’t understand what it’s doing, fix it when it breaks, or adapt it to new needs.
Source code access also matters for trust. It enables independent review (for privacy, security, and fairness) and makes it feasible to maintain software even if the original developer stops supporting it.
Think of a restaurant meal.
That’s the core idea: free software is about the freedoms users need to stay in control of their computing.
Before “software licensing” was something most people argued about, a lot of programming culture—especially in universities and research labs—ran on an assumption: if you could improve a tool, you shared the improvement. Source code traveled with software, people learned by reading each other’s work, and fixes spread through informal collaboration.
That culture started to change as software became a product in its own right. Companies (and even some institutions) began treating source code as a competitive advantage. Distribution came with “no sharing” terms, code stopped shipping with programs, and nondisclosure agreements became normal. For developers who were used to solving problems collectively, this shift didn’t just feel inconvenient—it felt like a rule change that made community problem‑solving legally risky.
One of the most repeated origin stories involves a printer at MIT’s AI Lab. Stallman has described how a new printer arrived with software that was distributed only in binary form, without source code. The practical problem was mundane: the lab wanted to modify the program to handle issues like notifying users about jams or routing jobs more intelligently. Under the older “hacker” norms, someone would patch the code and share the fix. Here, they couldn’t—because they weren’t allowed to see or change the source.
It’s worth keeping this in proportion: it wasn’t that one printer single‑handedly created a global movement. It was a clear, relatable example of a broader trend—tools people depended on were becoming unfixable by their users.
For Stallman, the core issue wasn’t only technical access; it was the loss of freedom to cooperate. If you can’t study how a program works, you can’t really control it. If you can’t share improvements, communities fragment, and everyone ends up reinventing fixes privately.
That motivation shaped the licensing innovations that followed. Instead of relying on goodwill or informal norms, Stallman wanted rules that preserved the ability to use, study, modify, and share software—so collaboration couldn’t be withdrawn the moment a program became commercially valuable.
Stallman’s big move wasn’t just writing a manifesto—it was starting a practical engineering effort. In 1983 he announced the GNU Project, with an ambitious goal: build a complete operating system that anyone could use, study, modify, and share, while staying compatible with Unix so people could run familiar programs and workflows.
An operating system isn’t one program—it’s a whole stack. GNU set out to create all the everyday pieces you need to make a computer useful, including:
In plain terms: GNU was building the plumbing, wiring, and switches—not just a single appliance.
By the early 1990s, GNU had produced a huge portion of this “userland,” but one critical piece lagged behind: the kernel (the part that directly manages hardware and system resources). When Linux appeared in 1991, it fit into that gap.
That’s why many popular systems today combine GNU components with the Linux kernel—often referred to as “GNU/Linux.”
GNU made the free software idea real by creating a working base that others could build on. Philosophy explained why freedom mattered; GNU delivered the tools that made freedom practical, repeatable, and scalable.
Copyleft is a licensing strategy designed to keep software free (as in freedom) not just in its first release, but in future versions too. If you receive copylefted code, you’re allowed to use it, study it, modify it, and share it—but when you distribute your modified version, you must pass along the same freedoms to others.
Copyleft sounds like “anti-copyright,” but it actually relies on copyright law. The author uses their copyright to set permission rules in a license: “You may copy and modify this, but if you redistribute it, you must keep it under this same license.” Without copyright, there would be no legal mechanism to enforce those conditions.
Think of it as a rule that follows the code:
The goal is to prevent a pattern Stallman worried about: someone taking community work, improving it, then locking the improvements away.
Permissive licenses (like MIT or BSD) generally let you do almost anything with the code, including redistributing modified versions under a closed, proprietary license. Copyleft licenses (like the GNU GPL) still allow broad use and modification, but they require redistributed derivatives to remain under the same copyleft terms—so the freedom is preserved downstream.
The GNU General Public License (GPL) changed software licensing by turning “sharing” into an enforceable rule, not just a nice gesture. Before the GPL, you could receive source code, improve it, and then ship a closed version that users couldn’t study or modify. The GPL flipped that dynamic: it protects users’ freedoms by attaching conditions to redistribution.
At a practical level, the GPL grants users the right to run the program for any purpose, read and modify the source, and share the original or modified versions.
If you redistribute GPL software (especially in a product), you must pass on those same freedoms. That typically means:
The GPL’s obligations mainly trigger when you distribute the software to others—shipping binaries, selling devices with the software, or giving copies to customers. If you modify GPL code for private internal use and don’t distribute it, you generally don’t have to publish the source.
You don’t need legal theory to get the gist: if your program incorporates GPL code in a way that creates a combined work (for example, by linking it into your application), the result is usually treated as a derivative work and must be distributed under the GPL. Simply running a GPL program, or talking to it as a separate process over standard interfaces, is often different.
GPLv2 is the classic widely used version. GPLv3 adds protections around patent deals and “tivoization” (shipping hardware that blocks modified software). The LGPL is designed for libraries: it allows linking from proprietary programs under certain conditions while keeping the library itself free.
Free licenses (especially the GNU GPL) don’t just “allow” sharing—they protect the right to study, modify, and redistribute software in a way that’s hard to take back later. For developers, that means your improvements can remain available to others under the same terms, instead of being absorbed into a closed product with no way for the community to benefit.
Under the GPL, you can:
This is why the GPL is often described as “enforceable reciprocity.” If someone distributes a GPL-covered program (or a derivative work), they can’t add restrictions that block downstream users from doing the same kinds of modifications and sharing.
Those rights come with obligations when you distribute software:
These responsibilities aren’t “gotchas”—they’re the mechanism that keeps collaboration from turning into one-way extraction.
Teams should treat license compliance like release hygiene. Track:
A simple Software Bill of Materials (SBOM) and a repeatable checklist for releases can prevent most problems long before lawyers get involved.
At a code level, “free software” and “open source” often describe many of the same projects. The split is mainly about why sharing matters.
The Free Software movement (associated with Richard Stallman and the Free Software Foundation) treats software freedom as an ethical issue: users should have the right to run, study, modify, and share software. The point isn’t just better engineering—it’s protecting user autonomy.
The Open Source approach emphasizes practical outcomes: better collaboration, faster iteration, fewer bugs, and improved security through transparency. It’s comfortable pitching openness as a superior development model, without requiring teams to adopt a moral stance.
In 1998, the Open Source Initiative (OSI) popularized the term “open source” to make the idea more business-friendly. “Free software” was frequently misunderstood as “zero cost,” and some companies were wary of a message framed around rights and ethics. “Open source” gave organizations a way to say “we can work this way” without sounding ideological.
Many projects that call themselves open source use the GNU GPL or other copyleft licenses, while others pick permissive licenses like MIT or Apache. The legal text can be identical; the story told to contributors, users, and customers changes. One message is “this protects your freedoms,” another is “this reduces friction and improves quality.”
If your team’s priority is ensuring downstream users keep the same freedoms, lead with the free software framing and consider copyleft.
If your priority is maximizing adoption (including by companies that may not want reciprocal obligations), the open source framing—and often a permissive license—may fit better.
If you want broad collaboration but also want improvements to flow back, use open source language for approachability while choosing a copyleft license for the outcome.
Free software doesn’t mean “no one gets paid.” It means users have the freedom to run, study, modify, and share the code. Plenty of companies build healthy revenue around that freedom—often by charging for the things organizations actually struggle with: reliability, accountability, and time.
A few common, proven models:
A modern twist on the “managed offering” model is the rise of platforms that generate and run applications quickly. For example, Koder.ai is a vibe-coding platform that helps teams build web, backend, and mobile apps via chat—while still supporting source code export. That combination (fast iteration plus code ownership) fits naturally with the values behind software freedom: the ability to inspect, change, and move your software when you need to.
License choice can shape who captures value:
“Commercial” describes how it’s sold; “free software” describes the user’s rights. A company can sell free software, charge for support, and still respect software freedom.
Before adopting or betting a product on a FOSS project, ask:
The GPL and “FOSS” get discussed a lot, but a few recurring myths muddy the waters—especially for teams that just want to ship a product without accidentally breaking a license.
It doesn’t. Public domain means there’s no copyright owner enforcing conditions—anyone can reuse the work with no obligations.
The GNU GPL is the opposite of “no strings attached.” The author keeps copyright and grants broad permission to use, modify, and share—but only if you follow the GPL’s terms (most famously, sharing source code when you distribute covered binaries).
Making code visible can help security, but it doesn’t guarantee it. A project can be open source and still be:
Security comes from active maintenance, audits, responsible disclosure, and good operational practices—not from a license label.
People often call the GPL “viral” to suggest it spreads uncontrollably into everything it touches. That’s a loaded metaphor.
What it usually refers to is copyleft: if you distribute a derivative work of GPL code, you must provide the corresponding source under the GPL. That requirement is deliberate: it preserves user freedoms downstream. It’s not “infection”; it’s a condition you can choose to accept—or avoid by using different code.
Common rule of thumb: obligations trigger mainly on distribution.
When it matters, get a precise read based on how the code is combined and distributed—not just assumptions.
Richard Stallman is a controversial figure. It’s possible to acknowledge that—and still talk clearly about the lasting influence of the ideas and licenses associated with him.
A useful starting point is to separate two conversations: (1) debates about Stallman as a person and community member, and (2) the measurable impact of free software principles, the GNU Project, and the GNU GPL on software licensing and developer rights. The second can be discussed with primary sources (license texts, project histories, adoption patterns) even when people disagree strongly on the first.
One recurring critique isn’t about licensing at all, but about governance: how projects make decisions, who has authority, and what happens when founders, maintainers, and users want different things. Free software communities have wrestled with questions like:
These questions matter because licenses set legal terms, but they don’t create healthy decision-making by themselves.
Another ongoing debate focuses on inclusivity and community norms: how projects set expectations for respectful behavior, how they handle conflict, and how welcoming they are to newcomers. Some communities emphasize formal codes of conduct; others prefer minimal rules and more informal moderation. Neither approach is automatically “right,” but the trade-offs are real and worth discussing without personal attacks.
If you’re evaluating Stallman’s legacy, it helps to keep claims verifiable: what the GPL requires, how copyleft changed compliance practices, and how these ideas influenced later licenses and institutions. You can be critical, supportive, or undecided—just aim for precision, respect, and clarity about what’s being criticized.
Stallman’s biggest practical gift to everyday teams is a clear question: what freedoms do you want to guarantee downstream? Answering that turns “license choice” from a vibe into a decision.
If you’re unsure, decide based on your goal: adoption (permissive) vs reciprocity (copyleft) vs library-friendly reciprocity (weak copyleft).
LICENSE file at the repo root (copy the full license text).If you build products using AI-assisted development (including chat-based platforms like Koder.ai), this checklist matters even more: you still ship real dependencies, real artifacts, and real license obligations. Speed doesn’t remove responsibility—it just makes repeatable compliance routines more valuable.
Make it boring and repeatable:
For deeper comparisons, see /blog/choosing-an-open-source-license and /blog/gpl-vs-mit-vs-apache.
“Free software” means freedom, not price.
A program can cost $0 and still be unfree if you can’t inspect, modify, or share it. Free software focuses on the rights to run, study, change, and redistribute the software you depend on.
The definition is based on four permissions:
If any of these are missing, users lose control and collaboration becomes harder.
Because you can’t realistically study or modify software without it.
Source code access enables:
Copyleft uses copyright law to require “share alike” when you redistribute.
You can use, modify, and even sell the software, but if you distribute a modified version, you must provide recipients the same freedoms (typically by releasing corresponding source under the same license).
The GPL gives broad rights (use, study, modify, share) and asks for reciprocity on distribution.
If you redistribute GPL-covered binaries, you generally must:
Often, no.
For GPL software, obligations usually trigger on distribution. If you modify GPL code for internal use and don’t give copies to anyone outside your organization, you typically don’t have to publish your changes.
(Edge cases exist—treat this as a rule of thumb, not legal advice.)
It depends on how the code is combined.
In general:
When it matters, map the exact integration pattern before shipping.
They target different concerns:
Choose based on whether you want strong reciprocity (GPL) or library-friendly reciprocity (LGPL).
Usually not under the GPL.
If you run GPL software on your own servers and users only interact over the network, you typically aren’t “distributing” copies, so GPL source-sharing obligations usually don’t trigger.
If you want network-use to require source sharing, look at the AGPL and evaluate it carefully for your deployment model.
Yes—many companies monetize free/open-source software through services and delivery, not by restricting user rights.
Common models include:
License choice affects strategy: permissive can maximize adoption; copyleft can discourage closed forks and support reciprocity-based models.