Free and open-source software
Based on Wikipedia: Free and open-source software
The Code Rebellion
In 1983, a programmer at the Massachusetts Institute of Technology got so frustrated that he started a revolution. Richard Stallman wasn't angry about politics or economics in the traditional sense. He was angry about software. Specifically, he was angry that he couldn't fix his office printer.
The printer kept jamming. Stallman knew he could write code to alert users when paper got stuck, saving everyone countless wasted trips to the machine. But there was a problem: the printer's manufacturer wouldn't give him the source code—the human-readable instructions that make software work. Without it, he was helpless. The machine belonged to his lab, but the invisible instructions controlling it belonged to someone else.
That frustration launched what we now call free and open-source software, or FOSS for short. It's a mouthful of a term, but it represents one of the most consequential ideas in modern technology: the belief that software should be something you can see, study, change, and share—not a black box controlled by corporations.
What "Free" Actually Means
Here's where things get confusing. When programmers talk about "free software," they don't primarily mean free as in "no cost." They mean free as in "freedom." Think free speech, not free beer.
Stallman articulated this through what he called the Four Essential Freedoms, numbering them in the way programmers love to do—starting from zero:
- Freedom Zero: Run the program however you want, for any purpose
- Freedom One: Study how the program works and modify it to suit your needs
- Freedom Two: Redistribute copies to help others
- Freedom Three: Distribute your modified versions so the whole community can benefit
Notice what these freedoms require. You can't study or modify software if you can't see how it's built. You need access to the source code—the actual written instructions, not just the compiled program that computers run. This is why source code availability is fundamental to the entire concept.
The opposite of free and open-source software is proprietary software, sometimes called closed-source. With proprietary software, you get a finished product, but you can't peer inside. You can't fix bugs yourself. You can't add features you need. You're dependent on the company that made it, hoping they'll address your concerns—if they even still exist.
A Brief History of Sharing
Here's something that surprises people: sharing code used to be the default.
In the early decades of computing, from the nineteen-fifties through the seventies, software flowed freely between universities, research labs, and even companies. The reason was practical: hardware was where the money lived. Computers cost millions of dollars. Software was just the stuff you needed to make those expensive machines useful, so companies bundled it for free and let everyone tinker.
Academics passed programs around like recipes. If you improved something, you shared the improvement. The culture resembled the open exchange of ideas that defined scientific research—because, in many ways, that's exactly what it was.
Then the economics shifted.
By the late nineteen-sixties, software had become valuable enough to sell separately. Companies started treating code as a trade secret. They distributed programs as compiled binaries—the machine-readable version that computers execute, but that humans can't easily understand or modify. If the original source code was a recipe, the binary was a frozen dinner. You could eat it, but you couldn't see the ingredients or cook it yourself.
A pivotal moment came in 1980, when United States copyright law was formally extended to cover computer software. Suddenly, code had the same legal protections as books and music. Three years later, IBM announced its "object code only" policy, refusing to share source code for its system software.
The era of closed software had arrived.
Stallman Strikes Back
Richard Stallman responded to this shift with characteristic intensity. In 1983, the same year IBM locked down its code, he announced the GNU Project. The goal was audacious: create an entire computer operating system—the foundational software that makes everything else run—that would be completely free. Free to use, free to study, free to modify, free to share.
The name GNU is a recursive joke beloved by programmers. It stands for "GNU's Not Unix," referencing the proprietary operating system it was designed to replace. Programmers love this kind of self-referential humor.
Two years later, Stallman founded the Free Software Foundation to support the project. He wrote the GNU Manifesto, laying out the philosophy in detail. Software, he argued, should serve users, not control them. Restricting code was ethically wrong, a violation of the user's fundamental rights.
By the early nineteen-nineties, the GNU Project had built most of an operating system—editors, compilers, utilities—but was missing the most crucial piece: the kernel. The kernel is the core of an operating system, the part that manages hardware and lets all the other programs run. It's like the foundation of a house; without it, nothing else stands.
That's when a Finnish university student named Linus Torvalds entered the picture.
Enter Linux
In 1991, Torvalds was a twenty-one-year-old student at the University of Helsinki. He started writing his own operating system kernel as a hobby project, just to learn how computers really worked. He posted it online with a now-famous message that drastically undersold what he'd created:
I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu).
He called it Linux, combining his first name with Unix. A year later, he made a decision that changed computing history: he released Linux under the GNU General Public License, the legal document Stallman had created to protect free software.
The GNU General Public License, often abbreviated GPL, is a clever piece of legal engineering. It's what's called a "copyleft" license—a pun on copyright. While copyright restricts what you can do with creative works, copyleft uses copyright law's own mechanisms to guarantee freedom. If you distribute GPL-licensed software, you must include the source code and grant recipients the same freedoms. The license is, in a sense, viral: freedom spreads with the code.
Combine the GNU tools with the Linux kernel, and you had something remarkable: a complete, free operating system. What people commonly call "Linux" is technically "GNU/Linux," though this naming debate has generated more heat than light over the years.
The Schism: Free vs. Open
By the late nineteen-nineties, free software had proven it could work. But some advocates worried the movement was limiting itself.
The problem was the word "free." In English, it's ambiguous. Companies kept misunderstanding it as "no revenue possible" and staying away. Stallman's ethical arguments, while principled, sounded anti-business to corporate ears.
In 1998, a group including Eric Raymond, Bruce Perens, Tim O'Reilly, and Linus Torvalds rebranded the concept as "open source." They founded the Open Source Initiative to promote this new term. The philosophy shifted: instead of emphasizing ethics and user freedom, they highlighted the practical benefits of collaborative development. Many eyes make all bugs shallow, they argued. Companies could profit while still sharing code.
Stallman objected. He saw the rebranding as a retreat from the movement's core values. Open source advocates, he argued, had stripped away the moral argument that made free software meaningful. They were selling the method but abandoning the mission.
This created a lasting rift. The Free Software Foundation and its supporters use the term "free software" or sometimes "free/libre software," with "libre" borrowed from Romance languages to emphasize liberty over price. The Open Source Initiative and its community prefer "open source." The umbrella term "FOSS"—free and open-source software—or sometimes "FLOSS" (free/libre and open-source software) tries to bridge the divide.
In practice, the licenses overlap almost completely. The philosophical disagreement, however, runs deep. Is shared source code a practical development methodology, or a moral imperative? The answer depends on whom you ask.
Why It Matters
You might wonder why any of this matters if you're not a programmer. Here's the thing: you almost certainly use free and open-source software every day, whether you know it or not.
The servers that power the internet run overwhelmingly on Linux. When you visit a website, you're likely connecting to machines running free software. Android, the world's most popular mobile operating system, is built on Linux. Mozilla Firefox, the web browser that helped break Microsoft's monopoly on internet access, is open source. So is the VLC media player that handles every video format imaginable. The list goes on.
Even companies that sell proprietary products often build on open-source foundations. Apple's macOS and iOS contain significant code derived from BSD, another family of free operating systems. Microsoft, which once called open source "an intellectual property destroyer," now embraces it, hosts the world's largest repository of open-source projects on GitHub (which Microsoft owns), and even runs Linux on its Azure cloud platform.
The practical benefits are substantial:
Cost. Free and open-source software is often available without charge. This matters enormously for individuals, nonprofits, schools, governments, and companies in developing countries. When software is free, more people can use it.
Security. With proprietary software, you trust the vendor. You hope they haven't built in backdoors, either deliberately or under government pressure. You hope they've found and fixed all the bugs. With open source, anyone can inspect the code. Security researchers routinely audit popular projects. Vulnerabilities get exposed and patched in public, not hidden and exploited in secret.
Reliability. When the company behind proprietary software goes bankrupt or discontinues a product, you're stuck. Your data might be trapped in formats you can't read. Your workflows might be broken with no fix available. With open source, the code persists. If the original maintainers walk away, others can pick up the project. You can even hire someone to maintain it yourself.
Innovation. Open-source projects can evolve in unexpected directions. Anyone with a good idea can contribute. This distributed model of development has produced solutions that no single company would have built.
The Counterarguments
It would be misleading to pretend open source solves everything. Critics raise legitimate concerns.
Visibility cuts both ways. If security researchers can examine code for vulnerabilities, so can malicious hackers. The question becomes whether the good actors outnumber the bad—and whether the transparency that enables attacks also accelerates fixes.
Sustainability is a real challenge. Many crucial open-source projects depend on unpaid volunteers working in their spare time. Some are maintained by a single person. When that person burns out or moves on, critical infrastructure can be left unmaintained. This has led to serious security vulnerabilities in widely-used software that everyone assumed someone else was watching.
Proprietary software often has better polish. Companies with revenue can hire designers, user experience researchers, technical writers, and support staff. The result is frequently easier to use, especially for non-technical people. Many open-source projects are built by programmers for programmers, with interfaces that assume expertise.
Hardware compatibility can be frustrating. Some manufacturers refuse to share the specifications needed to write open-source drivers for their products. They might want to lock users into proprietary software ecosystems, or they might have partnership agreements that prevent disclosure. Either way, users of free operating systems sometimes find their hardware doesn't work properly.
And market share matters. Because Linux has a smaller share of the desktop market than Windows or macOS, some commercial software isn't available for it. If you need specific applications for your work, you might not have a choice.
The Legal Architecture
Free and open-source software lives or dies by its licenses. These legal documents specify exactly what you can and can't do with the code.
The GNU General Public License, mentioned earlier, is the most famous copyleft license. Its key provision: if you distribute software that contains GPL code, you must release the entire combined work under the GPL, including your modifications. This prevents companies from taking free code, adding proprietary improvements, and locking up the result. Freedom propagates.
Not everyone likes this approach. Some developers prefer permissive licenses that impose fewer requirements. The MIT License and BSD licenses let you do almost anything with the code, including incorporating it into proprietary products without sharing your changes. These licenses maximize freedom for developers at the potential cost of freedom for users.
Which approach is better depends on your values. Copyleft ensures that improvements stay free. Permissive licenses maximize adoption by removing barriers. Both have produced successful projects.
The GNU General Public License has evolved through several versions. Version two, released in 1991, became wildly popular and remains in use today. Linux itself uses GPLv2. But as technology changed, new threats emerged that the original license didn't anticipate.
Digital Rights Management—technologies designed to control how people use media—created a loophole. Companies could build GPL software into devices but use hardware restrictions to prevent users from running modified versions. You had the source code and the theoretical right to modify it, but the device wouldn't accept your modifications. The letter of the license was followed; the spirit was violated.
Software patents posed another threat. A company could release code under the GPL but then sue anyone who used it for patent infringement. The code was free, but using it was legally dangerous.
Version three of the GPL, released in 2007, addressed both issues. It explicitly requires that users be able to install modified versions on the hardware, closing the Digital Rights Management loophole. It includes patent grants, so contributors can't later sue users over patents. Some projects, including Linux, chose to stick with version two. Others upgraded. The debate over which version is better continues.
The European Experiment
Governments have noticed the benefits of open source. The European Commission has been particularly active.
In 2017, the Commission stated that European Union institutions should become open-source users themselves, listing open-source software as one of nine key drivers of innovation alongside big data, cloud computing, and the internet of things. In 2020, they adopted a formal Open Source Strategy, committing to share and reuse software and to publish the Commission's own source code.
They weren't just talking. In 2020, the Commission set up an Open Source Programme Office. By 2022, they launched their own repository for sharing code at code.europa.eu. A 2021 decision established that the Commission can release its software under the European Union Public License or other appropriate open-source licenses.
The reasoning is straightforward. Taxpayer-funded software should benefit taxpayers. When governments share code, they avoid duplicating effort. When specifications are open, citizens aren't locked into specific vendors. Interoperability—the ability of different systems to work together—becomes possible.
In 2022, an expert group published recommendations to strengthen interoperability across European public administrations. Open source plays a central role in that vision. If government systems can share code and data, services become more efficient and citizens benefit.
How Open Source Gets Made
Open-source development looks different from traditional software engineering. There's rarely a single company calling the shots. Instead, distributed communities of contributors—some paid, some volunteer—collaborate across time zones and organizational boundaries.
Communication happens through email lists, web forums, instant messaging, and wikis. Version control systems, particularly Git, let thousands of people work on the same codebase without stepping on each other's toes. Every change is tracked. Every modification can be reviewed. Anyone can propose improvements, though getting them accepted may require convincing the project's maintainers.
The development model tends to favor early and frequent releases rather than long, secretive development cycles. Eric Raymond captured this in his famous essay "The Cathedral and the Bazaar," which contrasted the traditional closed-door approach to building software with the bustling, chaotic, but ultimately productive marketplace of open-source development.
That essay influenced Netscape's 1998 decision to release the source code for its web browser. That code eventually became Mozilla Firefox, proving that Raymond's ideas could work at scale. The bazaar model had built a world-class browser.
The Deeper Question
Beneath all the technical details lies a profound question about how society should organize the creation and distribution of knowledge. Software is, in a sense, crystallized thought—human intelligence encoded in a form that machines can execute. Should that thought be owned and controlled? Or should it flow freely, building on itself, available to all?
Richard Stallman has always been clear: for him, it's an ethical issue. Restricting software is wrong in the way that restricting speech or restricting scientific knowledge would be wrong. The Four Essential Freedoms aren't just convenient; they're moral imperatives.
The open-source camp is more pragmatic. Sharing works better. It produces better software faster. It's a development methodology that happens to have profound social effects.
Both perspectives have shaped modern computing. The servers running the world's infrastructure, the phones in our pockets, the tools that build our digital lives—these rely on code that people chose to share. Whether they shared it for ethical reasons or practical ones, the result is the same: a vast commons of human knowledge, freely available, continually improving.
That frustrated programmer at MIT, angry about his printer, helped build something larger than he could have imagined. Today, billions of people benefit from free and open-source software every time they go online. Most of them have no idea. But the code keeps running, shared by millions of contributors across decades, a quiet revolution that changed how we build and share technology.
The printer still jams sometimes. But now, at least, you can see the code.