What is Open Source?
Definition
Open source software is software released under a licence that lets anyone inspect, use, modify and redistribute its source code. What makes it open source is not that the code is visible online, but that the licence explicitly grants those rights. Licences that meet the Open Source Initiative's Open Source Definition qualify; MIT, Apache 2.0 and the GPL are the best known. Linux, PostgreSQL and React are open source projects.
Also known as: open-source software, OSS, FOSS, free and open source software
Visible code is not the same as open source
A public GitHub repository is not automatically open source. Code published without a licence is, by default, all rights reserved: you may read it, but you have no permission to copy, modify or redistribute it. Software becomes open source when it is released under a licence that grants those rights explicitly.
The common reference for which licences count is the Open Source Definition maintained by the Open Source Initiative. It has ten criteria, led by free redistribution, access to source code and permission to create derived works. A less famous criterion matters a lot in practice: the licence must not restrict use in any field of endeavour. A licence that says “read the code, but no commercial use” is therefore source-available, not open source. Several database and infrastructure projects have moved to such licences in recent years, which is why the label deserves a careful read.
The free software movement draws a related line. Its “free” means freedom, not price, and the acronym FOSS covers both traditions.
Permissive versus copyleft licences
Open source licences split mainly by what they require of derived works. The table is a conceptual summary, not legal advice; for a specific product and distribution model, read the licence text and involve a lawyer where it matters.
| Family | Examples | Core obligation |
|---|---|---|
| Permissive | MIT, BSD, Apache 2.0 | Keep the copyright and licence notices. The code may be used inside a closed-source product. Apache 2.0 adds an explicit patent grant. |
| Weak copyleft | LGPL, MPL 2.0 | Changes to the library itself are shared under the same licence; the application using it generally is not covered. |
| Strong copyleft | GPL | If you distribute a derived work, the whole of it must be offered under the same licence, with source code. |
| Network copyleft | AGPL | As the GPL, plus source must be offered when modified software is provided to users over a network. |
GPL obligations are triggered by distribution. A SaaS product that runs on your own servers and reaches users only as a web interface may therefore fall outside the GPL's classic scope; the AGPL was written to close exactly that gap. Mobile apps and installable desktop software are a different story, because the software itself is handed to users.
Free of charge is not free of cost
Open source usually carries no licence fee, but the total cost is never zero. Someone has to track releases, apply security patches, fix what breaks on major upgrades and find support when things go wrong. That is why many projects sit alongside a commercial model: paid support, a managed hosted version, or “open core”, where the base is open and enterprise features are paid.
Open source is also the foundation of nearly every piece of custom software. A typical web application runs on an open source operating system, database, language runtime and framework, and the team writes only the business-specific layer. Access to the source is also insurance against a vendor abandoning a product or changing its pricing.
Before you add an open source dependency
- Licence fit: does the licence suit how you ship your product? Transitive dependencies count too.
- Maintenance: when was the last release, are issues answered, does the project rest on one volunteer?
- Security: is it scanned for known vulnerabilities, and are fixes released promptly?
- Actual need: pulling in a new dependency for something a few lines could do grows both the attack surface and the maintenance load.
Keeping an inventory of components and their licences (an SBOM, or software bill of materials) helps with licence audits, and it turns “are we affected?” into a minutes-long question when a new vulnerability is announced.