Open source describes software whose source code is publicly available under a license that grants everyone the rights to use, study, modify and redistribute it, including for commercial purposes. In software licensing, the term has a precise meaning: a license qualifies as open source only if it meets the Open Source Definition, a set of ten criteria maintained by the Open Source Initiative (OSI) since 1998.
Publishing code on a public repository does not make it open source. Without a license, copyright law reserves all rights to the author, so the code is merely visible, not reusable. The license is what turns access into legal permission, and its specific terms decide what obligations come with that permission.
What the Open Source Definition requires
The Open Source Definition sets the test that a license must pass, and it concerns rights granted to recipients, not the development model. It was adapted from the Debian Free Software Guidelines, and its ten criteria fall into a few practical groups.
| Group | Criteria | Practical consequence |
|---|---|---|
| Redistribution and source | Free redistribution; source code must be available | Anyone may share copies, and the preferred form for modification must be accessible |
| Modification | Derived works allowed; integrity of the author’s source may be protected | Changes are permitted, though a license may require them to ship as patches or under a new name |
| Non-discrimination | No discrimination against persons, groups or fields of endeavor | A license cannot ban commercial, military or any other use |
| License mechanics | License travels with the code; not specific to a product | Rights apply automatically to every recipient without extra agreements |
| Neutrality | Must not restrict other software; must be technology-neutral | No conditions on accompanying programs or on a particular interface |
The non-discrimination criteria are where many self-described open licenses fail. A license that forbids use by competitors, cloud providers or companies above a revenue threshold is source-available, not open source, even when the code is fully public.
Permissive and copyleft license families
Open source licenses differ mainly in what they require when you redistribute the code. Permissive licenses such as the MIT License, BSD licenses and the Apache License ask only for attribution and notice preservation. Copyleft licenses such as the GPL require that distributed derivative works carry the same license, so that the freedoms are preserved downstream.
| Family | Typical licenses | Key obligation on distribution | Common use |
|---|---|---|---|
| Permissive | MIT, BSD-2-Clause, BSD-3-Clause | Keep copyright and license notice | Libraries meant for the widest adoption |
| Permissive with patent grant | Apache-2.0 | Keep notices, state changes, explicit patent license | Corporate-backed projects and infrastructure |
| Weak copyleft | LGPL, MPL-2.0, EPL-2.0 | Share changes to the licensed files or library only | Libraries usable in proprietary products |
| Strong copyleft | GPL-2.0, GPL-3.0 | Release the whole derived work under the GPL | Operating system components, applications |
| Network copyleft | AGPL-3.0 | Offer source also to users who interact over a network | Server software that wants to bind SaaS providers |
License compatibility determines whether code under two licenses can be combined. For example, Apache-2.0 code can be included in a GPL-3.0 project, but not in a GPL-2.0-only project, because of conflicting patent and termination terms. Compatibility problems are the most frequent legal obstacle in mixing dependencies.
Open source compared with related terms
Open source overlaps heavily with free software, but the two terms come from different philosophies. Free software, as promoted by the Free Software Foundation, frames the four freedoms as an ethical requirement; open source frames the same practical rights as a better way to develop and distribute software. Almost every license approved under one definition is accepted under the other.
| Term | Source available | Modification and redistribution allowed | Main distinction |
|---|---|---|---|
| Open source | Yes | Yes, for any purpose | Meets the Open Source Definition |
| Free software | Yes | Yes, for any purpose | Same rights, framed as user freedom |
| Source-available | Yes | Restricted or forbidden | Visibility without full open source rights |
| Freeware | Usually no | Usually no | Free of charge only, not free to modify |
| Public domain | Varies | Yes, without conditions | No copyright claimed, so no license terms |
Price and openness are independent. Open source software may be sold, and freeware is often closed. The word free in free software refers to liberty, not cost.
How organizations use and comply with open source
Open source components make up the majority of the code in most modern applications, so licensing compliance is an ordinary engineering task rather than an exception. Compliance means knowing which components are present, under which licenses, and fulfilling the obligations that distribution triggers.
- Maintain an inventory, ideally a software bill of materials (SBOM) that lists every direct and transitive dependency with its version and license.
- Use SPDX license identifiers such as
MITorGPL-3.0-onlyso tools can classify licenses automatically and unambiguously. - Preserve notices: ship license texts and copyright statements with the product, typically in an about screen or a notices file.
- Distinguish internal use from distribution: most obligations are triggered only when software is conveyed to others, with the AGPL’s network clause as the notable exception.
- Set a policy that lists pre-approved licenses, licenses that need review and licenses that are not allowed in a given product.
Companies also earn revenue from open source through support contracts, hosted services, dual licensing and open core models, in which a free core is surrounded by proprietary extensions.
Common misconceptions about open source
Misreading open source terms leads to real legal and security exposure, especially in commercial products. The points below correct the most frequent errors.
- Public code is not automatically open source: without a license, no reuse rights exist.
- Open source does not mean unsupported: many projects have paid maintainers and commercial support.
- Copyleft does not apply to internal use: obligations generally start when you distribute the software.
- Open source is not inherently more or less secure: security depends on maintenance activity, review and patch speed, not on visibility alone.
- A license change affects only new versions: code already released under an open source license remains available under those terms.
Explained without jargon
Open source software is like a recipe that comes with permission to share it. You get not only the finished dish but also the full list of ingredients and steps, and you are allowed to cook it, change it and pass it on.
The license is the note attached to the recipe that spells out the rules. Some notes only ask you to keep the original author’s name. Others ask that anyone who passes on an improved version must share it under the same rules.
A typical use case
A software company preparing to ship a desktop product runs a dependency scan before release. The scan finds 412 open source packages: 298 under MIT, 61 under Apache-2.0, 37 under BSD licenses, 12 under the LGPL, 3 under GPL-3.0 and 1 with no license at all.
The 396 permissive packages, about 96 percent of the total, need only their notices collected into a third-party license file. The 12 LGPL libraries are kept as dynamically linked, replaceable components, which satisfies their terms. The 3 GPL-3.0 packages would require releasing the whole product under the GPL, so the team replaces them with permissively licensed alternatives, and it removes the unlicensed package because it grants no usage rights. The product ships on schedule with a complete SBOM and notices file.