Free software vs open source sounds like a debate about terminology. In practice, it is a debate about what software is for, who should control it, and which arguments are most likely to change the way technology is built.
The confusion is understandable. The same program can usually be described as both free software and open source software. The developers may collaborate in public. The source code may be available. People may be allowed to study it, modify it, share it, and build new products from it. From the outside, the two labels can appear interchangeable.
Then someone insists that they are not the same, and a simple conversation about software suddenly becomes political.
That tension is not an accident. Free software and open source emerged from overlapping communities, but they tell different stories about why accessible source code matters. One begins with the freedom of the person using the program. The other became popular by explaining the practical advantages of an open development model: better collaboration, faster improvement, greater reliability, and less dependence on a single supplier.
Both stories have shaped modern computing. Much of the internet runs on code developed under licenses recognized by both camps. Companies build profitable services on it. Governments, universities, independent developers, and ordinary users depend on it every day.
Yet the philosophical difference remains useful because technology is never defined only by what it can do. As discussed in the broader philosophy of technology, every technical system also creates a relationship between the people who build it and the people expected to live with it. Software licenses help determine the terms of that relationship.
The real question, then, is not whether “free software” or “open source” is the correct phrase in every situation. It is what each phrase teaches us to notice.
The Same Code Can Carry Two Different Stories
Imagine a useful application whose source code is publicly available under a license that permits copying, modification, and redistribution. A free software advocate may praise it because users are not trapped inside a program controlled exclusively by its original developer. An open source advocate may praise the same application because outside contributors can inspect bugs, propose improvements, adapt it for new purposes, and share the cost of development.
Neither description is necessarily false. They focus on different reasons for valuing the same legal permissions.
The free software argument is primarily ethical. It asks whether users have enough freedom to control their own computing. If a program performs important work in someone’s life, that person should not be completely dependent on a distant company or developer whose decisions cannot be examined or challenged.
The open source argument is often practical. It asks which development model produces useful, reliable, flexible software. Opening the code can invite more contributors, reveal problems, prevent duplicated effort, and allow organizations to build on existing work instead of starting again.
This difference in emphasis changes the conversation. If software freedom is the goal, a technically excellent proprietary product still raises a moral concern because users remain subordinate to its owner. If effective development is the goal, the strongest argument for openness may be that it creates better outcomes than a closed process.
The distinction does not place every participant neatly into one camp. Many developers care about both freedom and engineering quality. Companies may adopt open source for practical reasons while supporting user rights. Free software communities still want programs that work well. Real people are less orderly than philosophical categories.
Even so, the categories matter. Language decides which questions reach the center of the discussion and which remain at the edge.
What Free Software Means
The phrase “free software” does not mean software that must be given away without charge. It refers to freedom rather than price. A free program can be sold, supported commercially, included in paid products, or developed by employees earning ordinary salaries.
The GNU Project’s definition of free software is based on four essential freedoms. Their numbering begins with zero, a small detail that reflects the culture of programming and the history of the definition.
Users must be free to run the program as they wish, for any purpose. They must be free to study how it works and change it. They must be able to redistribute copies. Finally, they must be able to distribute modified versions so that other people can benefit from their changes.
Access to source code is necessary for studying and modifying a program, but access alone is not enough. A company could publish code while using a license that forbids redistribution, commercial use, or the creation of modified versions. The code would be visible, yet the user would not possess the freedoms required by the free software definition.
This is why “source available” is a useful separate term. It describes code that can be viewed but does not necessarily meet the standards of free software or open source. Transparency is valuable, but permission determines what people are actually allowed to do with what they see.
The free software philosophy treats these permissions as rights rather than gifts. Users should not have to depend on the continuing generosity of the original developer. The license should provide durable legal protection.
That idea becomes easier to understand when software is essential. If a school organizes learning through a program, a business stores its operations inside it, or a public institution uses it to serve citizens, control over that software becomes a form of power. The ability to inspect, maintain, and replace it is no longer merely a hobby for programmers.
Most individual users will never edit source code. That does not make the freedom meaningless. People benefit when independent experts, local organizations, security researchers, or new developers can act on their behalf. A right can protect a person even when someone else has the knowledge needed to exercise it.
Free Software Is Not Anti-Business
One of the most persistent misconceptions is that free software must exist outside the market. If people are allowed to copy a program, the argument goes, no company could possibly earn money from it.
The history of the industry shows a more complicated picture. Free software licenses allow commercial use, paid distribution, consulting, customization, hosting, certification, training, and technical support. Companies can employ developers to improve shared code because reliable infrastructure is valuable to their own products and customers.
What changes is not the possibility of earning money, but the source of control. A business cannot rely entirely on preventing every recipient from studying or sharing the software. It needs to create value through expertise, service, integration, convenience, hardware, or continued development.
That model has strengths and weaknesses. Users gain more independence and competing providers may support the same program. At the same time, projects can struggle when everyone benefits from maintenance but too few contribute money or work. Critical software may be widely used while depending on a surprisingly small group of maintainers.
Proprietary licensing has funding problems of its own. A successful product can be abandoned because it no longer matches corporate strategy, regardless of how much users still value it. Neither model automatically creates sustainable development.
The important distinction is that “commercial” and “proprietary” are not synonyms. Free software can be commercial, and proprietary software can be distributed at no financial cost. Price tells us how a product is funded at a particular moment. Freedom tells us what users are legally permitted to do with it.
Why the Open Source Label Appeared
The term “open source” entered wider use in 1998. According to the Open Source Initiative’s history, the label was proposed during a moment when advocates wanted to present collaborative software development to a larger commercial audience. The phrase was originally suggested by Christine Peterson, and the Open Source Initiative was formed that same year.
Part of the problem was linguistic. In English, “free software” can easily be misunderstood as “software that costs nothing.” That confusion makes it difficult to explain a movement concerned with freedom, particularly in a business meeting where “free” may sound like the absence of a sustainable commercial model.
Open source offered a clearer route into those conversations. Instead of beginning with ethics, advocates could point to observable development benefits. When code is open to inspection and contribution, errors may be found by more people. Organizations can adapt a tool instead of waiting for a vendor. Competing companies can collaborate on shared infrastructure while building separate products above it.
This framing helped openness move into mainstream technology. Today, companies that would never describe themselves as part of a political movement depend heavily on open source projects. The model is present in operating systems, programming languages, web infrastructure, databases, development tools, and countless libraries hidden beneath familiar applications.
Commercial adoption does not mean companies accepted every argument made by the free software movement. Many embraced the practical method without adopting the larger claim that proprietary software creates an unjust relationship with users.
That separation was partly the point. Open source made it possible to support open development without agreeing on a single moral theory.
What the Open Source Definition Requires
Open source does not simply mean that code can be found on a public website. The Open Source Definition sets specific conditions that a software license must satisfy.
Among other requirements, the license must allow free redistribution, provide access to source code, permit derived works, and avoid discrimination against people, groups, or fields of activity. Rights must continue when the software is redistributed, and the license cannot depend on the program remaining part of one specific product.
These requirements explain why a project does not become open source merely by publishing its repository. If the license says the code cannot be used commercially, cannot be modified, or cannot be redistributed, it falls outside the official definition.
This distinction matters because “open source” is frequently used as a vague synonym for transparent, collaborative, or publicly visible. Those qualities may be positive, but software licensing is more precise. A person needs to know not only whether code can be read, but whether it can legally be used, changed, and shared.
The Open Source Definition was derived from the Debian Free Software Guidelines, and its practical requirements overlap strongly with the free software definition. That is why most software recognized as open source is also recognized as free software, and most free software licenses are accepted as open source licenses.
The two movements spend much of their time using, improving, and defending the same code. Their most visible disagreement is usually not over whether a particular program qualifies. It is over why anyone should care.
Where Free Software and Open Source Agree
The areas of agreement are substantial.
Both reject the idea that merely seeing source code is enough. Both require meaningful permission to modify and redistribute software. Both support the possibility of commercial use. Both have produced legal tools that allow individuals, communities, and companies to collaborate without surrendering every right to one central owner.
Both also provide an answer to technological abandonment. Proprietary software can disappear when a company closes, changes strategy, or decides that maintaining an older product is no longer profitable. If no one else has the legal right and practical ability to continue the work, users are left with few options.
Openly licensed code does not guarantee survival. A project still needs people, skills, time, infrastructure, and sometimes money. A neglected repository is not magically maintained because its license permits contributions. But permission keeps the door open. Another group can continue the project, create a fork, or reuse important parts elsewhere.
The two traditions also share a belief in learning through access. Developers become better by reading existing code, experimenting with it, and understanding how real systems are assembled. Closed software can teach through documentation and interfaces, but open code provides another layer of knowledge.
These common benefits explain why the phrase FOSS—free and open source software—is often used as a practical umbrella. Another variation, FLOSS, adds “libre” to emphasize freedom without the English ambiguity around price.
Umbrella terms are useful when cooperation matters more than philosophical alignment. They allow people to work together without pretending that every motivation is identical.
Where the Philosophies Separate
The clearest disagreement appears when openness does not produce the best immediate product.
Suppose a proprietary application is more polished, easier to use, and more reliable than its free alternative. An open source argument based mainly on development quality becomes harder to make. If openness is defended because it usually creates better software, what happens when it does not?
The free software answer is that freedom remains important even when it is inconvenient. A program can be technically impressive while leaving its users with little control. Quality and freedom are both valuable, but one cannot always replace the other.
An open source advocate might respond that practical adoption matters. Software that respects every theoretical ideal but remains difficult for ordinary people may fail to change the wider market. Better usability, documentation, funding, and commercial participation can spread open software further than moral criticism alone.
Both concerns are legitimate. Freedom that exists only on paper may not help people who cannot realistically use the program. Convenience that depends entirely on a vendor may work beautifully until the company changes its prices, policies, compatibility, or support.
The disagreement is therefore not a simple contest between idealism and realism. It is a disagreement about what must remain non-negotiable when values conflict.
The GNU Project’s essay “Why Open Source Misses the Point of Free Software” argues that the open source framing pushes user freedom out of the center. From this perspective, practical benefits are welcome but insufficient. If the public learns only that open development is efficient, it may accept proprietary control whenever a closed system appears more efficient.
Open source supporters can reasonably argue that a broad coalition does not need one ethical doctrine. Developers may support open licensing for scientific reproducibility, business independence, security review, education, public accountability, or simple engineering convenience. The shared rules make collaboration possible despite different beliefs.
One movement wants the language to preserve a moral conclusion. The other wants the development model to remain available to people who may not share that conclusion.
Copyleft, Permissive Licenses, and Two Ideas of Freedom
The contrast becomes more concrete when looking at licenses.
Copyleft licenses, such as the GNU General Public License, allow software to be used, studied, modified, and shared, but require redistributed modified versions to preserve the same freedoms. A company can sell the software or build a business around it, yet it cannot distribute a modified version under terms that remove those rights from the next recipient.
Copyleft treats freedom as something that should travel with the code. The first user’s freedom should not become the next user’s restriction.
Permissive licenses, such as the MIT, BSD, and Apache licenses, generally impose fewer conditions on redistribution. They allow code to be incorporated into proprietary products, provided the limited requirements of the license are followed.
Supporters view this flexibility as a form of freedom for developers. Code can travel widely, including into products that would not adopt it under copyleft terms. Companies may contribute because they know the license will not require every larger product to be released under the same conditions.
Critics reply that permissive licensing allows shared work to be enclosed inside proprietary systems. The original code remains open, but improvements distributed within a closed product may not return to the public.
Both license families can qualify as free software and open source. The disagreement is about how freedom should be protected: by giving the current developer maximum flexibility, or by ensuring that future recipients inherit the same rights.
There is no universally correct license for every project. A small library, a desktop application, a public database, and critical infrastructure may have different goals. Choosing a license is not administrative housekeeping. It is a decision about the future social life of the code.
Can Open Code Still Leave Users Without Control?
An open license solves important problems, but it does not solve all of them.
A project can publish its code while concentrating real decision-making among a small number of maintainers. A company can control trademarks, infrastructure, official distribution channels, and the direction of development even when others are legally allowed to create a fork. The right to leave matters, but leaving may still be expensive.
Software can also be open while the service built around it remains difficult to replace. A platform may depend on enormous datasets, specialized hardware, network effects, private configuration, or an established community that cannot be copied with a repository.
Cloud computing makes this especially visible. Traditional licenses are triggered mainly when software is distributed. A company may modify free software and run it on its own servers without distributing the modified program to users. People interact with the service, but they never receive a copy of the software operating behind it.
This means source code freedom and user autonomy are related but not identical. A person can use an open source application while remaining locked into a particular hosting provider, data format, identity system, or social network.
Good licensing should therefore be considered alongside interoperability, data portability, open standards, privacy, governance, and the ability to run a service independently. The source matters, but so does the entire system surrounding it.
This is not an argument against free or open source software. It is a reason to take their principles seriously enough to notice where licenses stop.
Why the Difference Matters in the Age of AI
Artificial intelligence has reopened many old questions in a less familiar form.
For conventional software, source code is usually the preferred form a developer edits. An AI system may also depend on model weights, training methods, datasets, data documentation, evaluation tools, and substantial computing resources. Publishing a small piece of inference code does not necessarily give others enough information or permission to understand and reproduce the system.
As a result, terms such as “open AI,” “open model,” and “open weights” are often used for very different arrangements. A model may be downloadable but restrict certain uses. Its weights may be available while its training data remains unknown. Developers may permit research but prohibit commercial deployment.
The Open Source Initiative created an Open Source AI Definition to adapt established ideas of use, study, modification, and sharing to machine learning systems. Debate continues because AI makes the boundary of “source” harder to identify than it is for an ordinary application.
Here the philosophical difference returns. A practical open source approach may ask whether openness produces more innovation, competition, research, and technical scrutiny. A freedom-centered approach asks whether people and communities have meaningful control over systems that increasingly influence work, education, media, and public decisions.
Those questions overlap, but they are not identical. A model can stimulate innovation while concentrating power. It can be useful to developers without being understandable to the people affected by its decisions.
The vocabulary developed around software freedom remains relevant because it prevents “open” from becoming a decorative label. It forces us to ask what has actually been opened, to whom, under which rights, and with what practical ability to act.
Which Term Should We Use?
There is no need to police every casual use of language. Context matters.
“Open source” is widely understood in business, government, and technical communities. It connects a project to a recognized licensing definition and a broad development ecosystem. When discussing collaboration, procurement, security review, or industry adoption, it may be the clearest term.
“Free software” is more direct when the subject is user autonomy, ethical responsibility, or the unequal power between a software owner and the people who depend on a program. Its ambiguity around price requires explanation, but that explanation opens the philosophical conversation the term was designed to preserve.
FOSS or FLOSS works when both traditions are relevant and the distinction is not the main subject. “Source available” should be used when code can be viewed but the license does not provide the freedoms required by the free software and open source definitions.
The important thing is accuracy. A public repository is not automatically open source. Software that costs nothing is not automatically free software. A product does not respect user freedom merely because it uses open source components somewhere beneath a proprietary service.
Words should clarify the relationship, not decorate the marketing.
Software Is Also a Relationship of Power
The free software vs open source debate has lasted because it is not really about branding. It reflects two ways of explaining why control over code matters.
Open source showed that collaborative development could become a mainstream foundation for modern technology. It gave companies, institutions, and developers a language for cooperation across organizational boundaries. Its practical success is difficult to overstate.
Free software kept a more uncomfortable question alive: even if open development produces excellent code, what does the user deserve? It insists that software should be judged not only by performance, reliability, popularity, or economic value, but by the freedom it gives—or withholds—from the people running it.
The strongest understanding does not require pretending that one tradition contributed everything and the other nothing. Practical success can expand freedom. Ethical principles can prevent practical success from becoming the only measure that matters.
The same code can be efficient and emancipating. It can create a better development process and a fairer relationship with users. But those outcomes do not happen automatically, and they are not guaranteed by using the word “open.”
Whenever software becomes important, someone gains the power to decide how it works, how long it survives, and what users are allowed to do with it. Licenses distribute part of that power. Communities and companies distribute the rest.
That is why the distinction still matters. Open source asks what becomes possible when code is opened. Free software asks whether the people using that code are genuinely free.
Modern technology needs both questions, but it should never confuse them.
