A license counts as open source when its terms meet the ten criteria in the Open Source Definition published by the Open Source Initiative. Access to the code is not enough. The license must also allow free redistribution, modification, and use in any field, with no extra terms for others.
Definition
The Open Source Definition (OSD) opens by saying that open source does not just mean access to the source code. Distribution terms must comply with ten criteria. A license that fails any of them is not open source by this definition, even if you can read the code.
The ten criteria, translated
| Criterion | Plain meaning |
|---|---|
| 1. Free redistribution | You can sell or give the software away as part of a bundle, with no royalty |
| 2. Source code | Source must be included or easy to get, in the form a programmer would edit; obfuscated source is not allowed |
| 3. Derived works | Modifications are allowed and can be shared under the same terms |
| 4. Integrity of the author's source | A license may require patches or a renamed version, but must allow shipping modified builds |
| 5. No discrimination against persons or groups | Nobody can be excluded |
| 6. No discrimination against fields of endeavor | No ban on business use or any other field |
| 7. Distribution of license | Rights pass to everyone who gets the software, without extra agreements |
| 8. Not specific to a product | Rights do not depend on being part of one distribution |
| 9. Must not restrict other software | The license cannot demand that neighbouring programs be open |
| 10. Technology neutral | No provision tied to one technology or interface style |
Why criteria 6 and 9 matter in practice
Criterion 6 is the one product teams run into. The OSD says a license may not restrict use in a specific field of endeavor, and gives the example that it may not restrict use in a business. So a license that allows everything except commercial use, or except competing with the author, does not meet the definition. That is why non commercial and source available terms need separate handling in your policy.
Criterion 9 is often misread. It says the license must not place restrictions on other software distributed along with it. A copyleft license requires derived works to carry the same terms, but it does not demand that unrelated programs on the same disk be open. That is criterion 3 and criterion 9 working together.
How to use this in a license policy
- Treat "open source" as a claim to verify, not a label to trust. Check the license text or the SPDX identifier.
- Put licenses that fail criterion 6 in a separate review tier.
- Record the license for every dependency, including transitive ones.
- For anything custom or nonstandard, route it to counsel before it ships.
- Keep the decision with the component record so the next audit can follow it.
Try it yourself
In the demo below, open a package in the inventory and read its license field. Note how many are standard identifiers and whether any look nonstandard, since those are your review queue.
Click through it at your own pace, or open it full screen.
Safeguard's dependency scanning and SBOM generation list the components in your build so the license review starts from a real inventory. A free scan is available at gold.safeguard.sh/scan.
Quick check
Is code on a public repository automatically open source?
No. Visible code with no license, or a license that fails the OSD, is not open source under the definition.
Can an open source license ban commercial use?
No. Criterion 6 says the license may not restrict use in a business or any other field of endeavor.
Does copyleft violate criterion 9?
No. Copyleft sets terms for derived works. It does not restrict separate software distributed alongside.
Sources
Last reviewed: 19 October 2026.
