Open Source Software: Philosophy, Principles, and Licensing Explained

When you hear the term “free software,” your first thought might be about price. After all, who doesn’t love getting something for free? But in the world of technology, “free” has a much deeper, more complex, and far more powerful meaning. It’s a concept that has sparked a global movement, split into different philosophical camps, and created the legal foundation for much of the software that powers our world, from the Android in your pocket to the servers that deliver this webpage. This isn’t just about zero-cost downloads; it’s about philosophy, freedom, and the very nature of how we create and share knowledge. Understanding this world begins with its two competing ideas, its core principles, and the legal tools that bring it all to life.

The two big ideas: freedom vs. practicality 🔗

At the heart of the “free and open source” world, there isn’t one unified belief system. Instead, there are two major philosophies that were born from the same technical roots but grew to prioritize very different goals. They are often grouped together, but their advocates would be quick to point out the crucial differences in their worldviews.

The Free Software Foundation (FSF): a fight for user freedom 🔗

The story of free software begins in the 1980s with a programmer at MIT named Richard Stallman. He was part of a an early community of developers who freely shared and modified the code they wrote. When this culture began to shift toward proprietary, closed-source software-where users received programs as black boxes, unable to see or change how they worked-Stallman saw it as an ethical and social problem.

In response, he founded the Free Software Foundation (FSF) and the GNU Project. The FSF’s philosophy is built on a moral imperative. It argues that for users to have control over their own computing, software must be “free.” As Stallman famously clarifies, this is “free” as in “free speech,” not “free beer.”

The FSF’s entire philosophy is built on four essential freedoms that every user should have:

• Freedom 0: The freedom to run the program as you wish, for any purpose.
• Freedom 1: The freedom to study how the program works, and change it so it does your computing as you wish. Access to the source code is a precondition for this.
• Freedom 2: The freedom to redistribute copies so you can help others.
• Freedom 3: The freedom to distribute copies of your modified versions to others.

For the FSF, proprietary software that denies users these freedoms is fundamentally unjust. This is a social movement first and a development model second.

The Open Source Initiative (OSI): a pragmatic approach to collaboration 🔗

Fast forward to the late 1990s. Software built on the FSF’s principles, like the Linux kernel, was becoming incredibly powerful. However, the strong, often confrontational, ethical language of the FSF was not appealing to the corporate world. Many in the community felt that the “free software” branding was scaring away businesses and hampering mainstream adoption.

In 1998, a group of individuals (including Eric S. Raymond and Bruce Perens) coined a new term: “open source.” They founded the Open Source Initiative (OSI) to rebrand the idea, stripping it of the FSF’s moralizing tone and focusing instead on the practical, tangible benefits.

The OSI’s argument is pragmatic, not ethical. It champions open source as a superior development methodology. The core idea is that when many developers can read, redistribute, and modify source code (a process of “peer review”), the software becomes more:

• Reliable: More “eyeballs on the code” means bugs are found and fixed faster.
• Secure: Vulnerabilities can be identified and patched by anyone, not just the original vendor.
• Flexible: Users and companies can adapt the software to their specific needs.

The OSI presented open source as a business-friendly strategy that leads to better technology, without ever having to argue about whether a proprietary program is “evil.”

What makes software ‘open source’? The ten principles 🔗

To avoid diluting the term and to create a clear standard, the OSI established a formal definition. For a software license to be officially considered “open source,” it must comply with ten specific criteria. This definition serves as a measuring stick for all new licenses.

While all ten are important, the Open Source Definition includes several key principles that capture the movement’s spirit:

1. Free redistribution: The license cannot stop anyone from selling or giving away the software as part of a larger collection. No royalties or fees can be required for such a sale.
2. Source code: The program must include its source code, or there must be a well-publicized way to get it for no more than a reasonable reproduction cost.
3. Derived works: The license must allow for modifications and “derived works” (new programs based on the original) and must allow them to be distributed under the same terms as the original.
4. Integrity of the author’s source code: A license can require that modified versions carry a different name or version number to protect the original author’s reputation.
5. No discrimination against persons or groups: The license must be available to everyone. It cannot, for example, deny use to people in a certain country.
6. No discrimination against fields of endeavor: The license cannot restrict how the software is used. This is crucial, as it explicitly prevents a license from banning commercial use.
7. Distribution of license: The rights attached to the program must apply to everyone who receives it, without them needing to agree to an additional license.
8. License must not be specific to a product: The rights can’t depend on the software being part of a specific package.
9. License must not restrict other software: The license can’t force other software distributed *alongside* it to also be open source.
10. License must be technology-neutral: No provision of the license can be based on any single technology or style of interface.

These rules create a clear, legal framework that ensures software labeled “open source” delivers on the practical promises of accessibility and collaboration.

The licenses: how these philosophies work in practice 🔗

A philosophy is just an idea. A license is the legal tool that turns that idea into a real-world contract. These licenses are what grant users the permissions outlined by the FSF and OSI. The single most important concept that divides these licenses is known as “copyleft.”

Copyleft is a clever play on “copyright.” While copyright reserves rights and restricts sharing, copyleft *reverses* this. It uses copyright law to ensure that a work and all its future derivatives *remain* free. It’s a “share-alike” provision. If you use copyleft code in your new project, you are legally required to share your new project under the same copyleft terms. This mechanism is what the FSF uses to protect its four freedoms.

The GNU General Public License (GPL): champion of copyleft 🔗

The GNU General Public License (GPL) is the FSF’s flagship license and the most famous example of strong copyleft. When Richard Stallman wrote the GPL, his goal was to create a license that would actively defend user freedom.

The core rule of the GPL is simple but powerful: If you modify a GPL-licensed program, or if you write a new program that links to or incorporates GPL code, and you then *distribute* that new program to others, you must release the complete source code of your new program under the GPL as well.

This license is a legal guarantee that freedom is contagious. It prevents a company from taking free, community-built code (like the Linux kernel), adding their own secret features, and selling it as a new proprietary, closed-source product. The GPL ensures that the community’s work remains in the community, forever. This is why it’s sometimes called a “viral” license-it “infects” any larger work it becomes a part of with its own terms.

BSD-style licenses: the permissive approach 🔗

On the complete opposite end of the spectrum are “permissive” licenses. The most famous examples are the BSD (Berkeley Software Distribution) licenses and the similar MIT License. These licenses are aligned much more closely with the OSI’s pragmatic, business-friendly philosophy.

Permissive licenses have minimal restrictions. They essentially have only one major requirement: attribution. You must keep the original copyright notice and a disclaimer of warranty in your new work. That’s it.

What they pointedly do not have is copyleft. This is the crucial difference. You are free to take BSD-licensed code, modify it, add it to your own proprietary, closed-source project, and sell that project for a profit without *any* requirement to release your own new source code. This gives businesses and developers maximum flexibility.

This is exactly what Apple did. Its macOS and iOS operating systems are built on top of Darwin, an open source core that was based on BSD-licensed code. This allowed Apple to build its vast, proprietary ecosystem on an open foundation.

Putting it all together: GPL vs. BSD 🔗

The choice between a GPL and a BSD license is a choice between two different goals. There is no “better” license; there is only the license that best fits your project’s aims.

Let’s use an analogy. Imagine you have a fantastic community recipe for a soup:

• The GPL is a potluck recipe. The rule is: “You can use this recipe. If you change it or add new ingredients, you must bring your new soup back to the potluck, and you must share your modified recipe with everyone.” This ensures the community recipe book only gets bigger and better for everyone.
• The BSD license is a recipe from a friend. The rule is: “You can use this recipe. I don’t care what you do with it. You can sell the soup at your own restaurant and keep your new ingredients a secret. Just do me a favor and put a little note on your menu that says, ‘Original soup concept by…’”

This is the central conflict. The GPL prioritizes user freedom and ensuring the software ecosystem *remains* free for all future users. It uses a strong copyleft to enforce this.

The BSD license prioritizes developer flexibility and maximum adoption, even if that adoption is within proprietary software. It does not have copyleft.

This is also why you hear about “license incompatibility.” You cannot easily take GPL-licensed code and use it in a proprietary project, because the GPL’s copyleft terms would legally require your *entire* project to become open source. You can, however, easily use BSD-licensed code in that same proprietary project. Understanding this single difference-the power of copyleft-is the key to understanding the entire open source legal landscape.

What do you think? If you were starting a new software project today, would you be more drawn to the ethical stance of the FSF and the GPL, or the pragmatic flexibility of the OSI and a BSD license? Do you think the FSF’s hard-line focus on “freedom” is still the most important issue, or has the OSI’s business-friendly approach ultimately done more to make open source software successful and widespread?

References

1. https://www.gnu.org/philosophy/open-source-misses-the-point.html
2. https://opensource.org/osd
3. https://www.gnu.org/licenses/gpl-3.0.html
4. https://timreview.ca/article/67
5. https://snyk.io/articles/open-source-licenses/