Free software and open source describe a broad area of software distributed under licences that allow people to access, use and share code under defined conditions. The terms do not start with exactly the same question: free software focuses on the freedoms of the people using a program; open source highlights the practical value of examining, reusing and improving its code. Many licences meet both definitions. They are not two technical camps that are always separate, nor two levels of quality.
Two terms, with a large area of overlap
The Free Software Foundation describes free software through the freedoms a licence gives its users. The Open Source Initiative sets criteria a licence must meet to qualify as open source, including source-code access, permission to create derivative works and rules against discrimination based on people or fields of use. In neither case is being able to read code enough: the licence must grant rights. The definitions overlap widely and many licences are recognised by both; the terms mainly express different priorities and ways of explaining why those rights matter.
The four freedoms of free software
- Freedom 0: run the program for any purpose.
- Freedom 1: study how it works and change it to do the work you need. Access to the source code is a prerequisite.
- Freedom 2: redistribute copies so you can help others.
- Freedom 3: distribute copies of your modified versions so others can benefit from the changes. Source access is also required here.
Free refers to these freedoms, not to price. Free software can be sold, used commercially or supported by paid services. A no-cost program, by contrast, may be proprietary and give no right to study or modify it. Price and freedom are separate questions.
Open source: a practical language for collaboration
The term open source has helped make the practical benefits of code collaboration easier to discuss with businesses and developers: inspect a project, reuse parts, propose fixes and build versions for other settings. The OSI definition does not mean merely that code is visible. A qualifying licence must grant specific rights, including the ability to distribute changes, and cannot arbitrarily restrict people or fields of use. A public repository without a licence, for example, does not automatically grant the usual rights to reuse and modify its code.
Fanatics and traitors? Labels do not help
The conversation loses nuance when people who insist on user freedoms are dismissed as fanatics, or those who prefer the open-source vocabulary are called traitors. These are caricatures of a real difference in emphasis, not useful descriptions of people or software. The free-software perspective reminds us that users should retain control and choice; open source shows how those rights can support collaboration, maintenance and reuse in business projects. The perspectives can coexist and often reinforce each other: one asks what relationship with technology we want, while the other helps design workable ways to get there.
A lighthouse and a practical route
Free software can be seen as a lighthouse: an ambitious horizon that puts autonomy, sharing and people's ability to understand their tools first. Open source can be a pragmatic route for bringing some of those values into everyday work, products and organisations without requiring every technical choice to be perfect from day one. An ideal is useful before it has been fully reached: it helps guide concrete decisions and identify which compromises are worth making.
What these freedoms can mean for a business
Being able to study software can make independent technical review, a targeted change or a better-informed assessment possible before a company entrusts it with important data and processes. The freedom to run it for any purpose avoids unjustified limits on use; the ability to share copies or modified versions can support collaboration and continuity. These are possibilities, not automatic guarantees: they still require skills, time, maintenance, usable formats and a licence compatible with the intended use. Source access alone does not prove that software is secure or correct. Security also depends on how it is developed, reviewed, updated and operated; independent checks and a vulnerability-response process remain important.
In the AI era, these freedoms are not a footnote
Generative tools lower the barrier to producing code, prototypes and integrations. That makes it more useful to ask where components come from, which licences apply, who can review what is shipped and how it can be fixed when a problem emerges. Code suggested by a model is not automatically free, open source, secure or maintainable. The phrase open source also needs clear criteria when applied to AI: the OSI's AI definition considers not only whether model weights are available, but also the information and rights needed to study and modify the system. A marketing label or model download does not settle those questions.
The four freedoms suggest a practical design question: can we understand what the system does, adapt it to the real process, keep using it and share changes without losing control? If not, identify the dependency being accepted, the available alternatives and an exit plan.
What to check before adopting software
- Identify the exact licence for the version in use; ‘free’, ‘public’ or ‘open’ alone do not describe the rights granted.
- Check that the source matches the distributed version, and list the components, dependencies and external services needed to run it.
- Verify commercial-use, modification and redistribution rights, including obligations that may apply when distributing derivative versions.
- Review who maintains the project, how updates are released and how vulnerabilities are handled; the licence does not replace these checks.
- For AI-related tools and code, document component provenance, the terms of the models used and tests performed before production.
- Consider data export, formats, documentation, available skills and how to migrate or stop the service.
Free software and open source do not require choosing a team. They help us assess how much control, collaboration and autonomy are built into tools that people and organisations depend on. Keeping the freedoms as a guiding light while using pragmatic routes towards that horizon is a concrete way to make better technology decisions, even when AI makes software faster to build.