Richard Stallman and Free Software: Ideas That Changed Code

Why Richard Stallman Still Matters

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.

What this post is (and isn’t)

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.

A balanced, accessible view

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.

What “Free Software” Actually Means

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

The four essential freedoms

Free software is defined by four basic permissions:

• Freedom 0: Run the program for any purpose.
• Freedom 1: Study how the program works and change it to do what you want.
• Freedom 2: Redistribute copies so you can help others.
• Freedom 3: Distribute your modified versions so the community can benefit.

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.

Why source code access is non-negotiable

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.

A simple analogy: recipes vs sealed food

Think of a restaurant meal.

• Proprietary software is like buying a sealed, ready-to-eat dish: you can eat it, but you don’t know the ingredients, you can’t tweak the recipe, and you’re not allowed to share copies.
• Free software is like getting the recipe: you can cook it at home, learn how it’s made, adjust it for allergies, and share your improved version with friends.

That’s the core idea: free software is about the freedoms users need to stay in control of their computing.

The Problem Stallman Was Reacting To

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.

From sharing norms to locked-down software

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.

The printer story (as an example, not a myth)

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.

Why this led to new licensing ideas

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.

The GNU Project: Building a Free OS

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.

A full system, not a single tool

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:

• Compilers (most famously GCC) so developers could turn code into runnable programs
• Core command-line utilities (the basic tools for copying files, searching text, managing processes)
• Libraries and developer tools to support building more software
• Shells and editors to actually work on the machine day to day

In plain terms: GNU was building the plumbing, wiring, and switches—not just a single appliance.

GNU + Linux: how most people encountered it

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

Infrastructure mattered as much as ideals

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 in Plain English

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.

A legal tool built on copyright

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.

The “share alike” idea (with simple examples)

Think of it as a rule that follows the code:

• Forks: You fork a copylefted project, add features, and publish your fork. You must publish the source code and keep the same license so others can also fork yours.
• Redistributions: You bundle the program in a product you ship to customers. You can charge money, but you must provide the source and the same rights to recipients.

The goal is to prevent a pattern Stallman worried about: someone taking community work, improving it, then locking the improvements away.

Copyleft vs permissive licensing

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.

How the GNU GPL Reshaped Licensing

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.

What the GPL gives—and what it asks in return

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:

• Provide the source code (or a valid way to get it) to recipients
• Include the license text and preserve copyright notices
• License your modifications under the GPL as well, so downstream users aren’t “locked out”

Source distribution obligations (when they apply)

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.

“Derivative work” in plain terms

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.

GPL variants: v2, v3, and LGPL

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.

Developer Rights—and Responsibilities—Under Free Licenses

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.

What rights you gain

Under the GPL, you can:

• Tinker confidently: read the source, change it, and run your modified version.
• Share your work: distribute copies of the original or modified program.
• Build on others’ improvements: because recipients must get the same freedoms.

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.

What responsibilities you take on

Those rights come with obligations when you distribute software:

• Preserve copyright and license notices.
• Provide (or offer) corresponding source code when the GPL requires it.
• Keep the license intact so recipients know their rights.

These responsibilities aren’t “gotchas”—they’re the mechanism that keeps collaboration from turning into one-way extraction.

A practical note on compliance

Teams should treat license compliance like release hygiene. Track:

• which open-source components you ship,
• their versions and licenses,
• where you provide source (or written offers),
• and any modifications you’ve made.

A simple Software Bill of Materials (SBOM) and a repeatable checklist for releases can prevent most problems long before lawyers get involved.

Free Software vs Open Source: A Values Split

At a code level, “free software” and “open source” often describe many of the same projects. The split is mainly about why sharing matters.

Different priorities: freedom vs adoption

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.

Why “open source” took off

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.

Same licenses, different framing

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

A simple decision guide

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.

Business Models and Real-World Incentives

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.

How companies make money with FOSS

A few common, proven models:

• Support and services: paid help desks, SLAs, training, audits, custom features, and migration work.
• Hosting and managed offerings: selling a hosted version where customers pay for convenience, scaling, backups, and compliance.
• Dual licensing: offering the same software under a free license (often copyleft) and also a paid commercial license for customers who want different terms.
• Open core (carefully): keeping a truly free base while selling proprietary add-ons. This can work, but it can also strain community trust if the “free” part feels intentionally limited.

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.

Why permissive vs copyleft affects strategy

License choice can shape who captures value:

• Permissive licenses (like MIT/Apache) make it easier for others—including large vendors—to reuse your code in proprietary products. That can boost adoption, but may reduce your ability to monetize exclusivity.
• Copyleft licenses (like GPL) require downstream redistributors to share modifications under the same terms. That can discourage closed forks and can support business models focused on services, certified distributions, or dual licensing.

“Commercial” and “free software” aren’t opposites

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

Sustainability checklist

Before adopting or betting a product on a FOSS project, ask:

• Is there an active community (issues, releases, reviews)?
• Is governance clear (who decides, how are conflicts handled)?
• Is funding visible (sponsors, company backing, foundation)?
• Is the maintainer workload sustainable (bus factor, burnout signals)?
• Are security practices documented (patch cadence, advisories)?

Common Misunderstandings About the GPL and FOSS

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.

“GPL means public domain”

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).

“Open source is always secure”

Making code visible can help security, but it doesn’t guarantee it. A project can be open source and still be:

• unmaintained,
• poorly reviewed,
• vulnerable for years before anyone notices.

Security comes from active maintenance, audits, responsible disclosure, and good operational practices—not from a license label.

The “viral license” claim

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.

“Can I use GPL code in my app or service?” (high level)

Common rule of thumb: obligations trigger mainly on distribution.

• Internal use: using GPL software inside your company typically doesn’t require you to publish changes.
• Shipping an app/device: if you distribute a GPL-licensed program (or a derivative), you generally need to provide source and license notices.
• SaaS / web services: running GPL software on your servers usually doesn’t force source release to users. (The AGPL was created to close that gap.)

When it matters, get a precise read based on how the code is combined and distributed—not just assumptions.

Critiques, Controversies, and Ongoing Debates

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.

Governance and “who decides?”

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:

• How should leadership be chosen or replaced?
• Should foundations be member-driven, board-driven, or maintainer-driven?
• When does “freedom” for maintainers conflict with the needs of contributors?

These questions matter because licenses set legal terms, but they don’t create healthy decision-making by themselves.

Inclusivity, conduct, and community standards

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.

Keeping the discussion grounded

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.

Practical Takeaways: Choosing Licenses and Contributing

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.

A simple decision tree

• Do you want others (including competitors) to reuse your code with minimal conditions? Choose a permissive license (e.g., MIT, Apache-2.0).
• Do you want improvements to your code to stay shareable when redistributed? Choose strong copyleft (e.g., GNU GPL).
• Do you want sharing to apply mainly to modifications of your library, while allowing proprietary apps to link to it? Choose weak copyleft (e.g., LGPL, MPL).

If you’re unsure, decide based on your goal: adoption (permissive) vs reciprocity (copyleft) vs library-friendly reciprocity (weak copyleft).

Practical steps for shipping software responsibly

1. Pick one license per project and state it clearly in your README.
2. Add a LICENSE file at the repo root (copy the full license text).
3. Add copyright headers where your org requires them.
4. Document dependencies (direct and important transitive ones) and their licenses.
5. If you distribute binaries, prepare required notices, source offers (if applicable), and attribution.

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.

Create a lightweight internal compliance routine

Make it boring and repeatable:

• Generate an SBOM during builds.
• Keep a notices file template and update it as dependencies change.
• Add a license review checkpoint to PRs/releases (even a 10-minute checklist).

For deeper comparisons, see /blog/choosing-an-open-source-license and /blog/gpl-vs-mit-vs-apache.