Short answer
Permissive licenses (MIT, Apache 2.0, BSD) are generally approved by default. Copyleft licenses (GPL, AGPL) require case-by-case analysis before use in distributed products. Refer to the internal approved licenses list and contact the OSPO for any case not covered.
Detailed explanation
The three main OSS license families
1. Permissive licenses ✅ (approved by default)
These licenses offer maximum freedom with minimal obligations and are compatible with proprietary code.
| License | Key obligations | Commercial compatibility |
|---|---|---|
| MIT | Retain the copyright notice | Very broad |
| Apache 2.0 | Retain copyright + NOTICE file; explicit patent grant | Very broad (recommended for enterprise) |
| BSD 2/3-clause | Retain copyright; BSD-3 prohibits use of the author’s name for promotion | Broad |
Apache 2.0 is often the recommended license in enterprise environments: it includes an explicit patent grant that MIT does not provide, reducing legal exposure. Today, 70% of GitHub repositories use permissive licenses, reflecting global commercial preference.
2. Weak copyleft licenses ⚠️ (review required)
These licenses impose reciprocity obligations only on modifications to the component itself, not on the surrounding project.
| License | Copyleft scope |
|---|---|
| LGPL | Modified files of the library only |
| EPL (Eclipse) | Modified files only |
| MPL (Mozilla) | Modified files only |
Using an unmodified library: generally no impact on your proprietary code. Using with modifications: contact the OSPO.
3. Strong copyleft licenses ❌ (explicit approval required)
These licenses require that any derived or combined software be distributed under the same license — which may force you to open-source your proprietary code.
| License | Key characteristic |
|---|---|
| GPL v2 | Strong copyleft on any distributed software incorporating GPL code |
| GPL v3 | Same + anti-tivoization + better Apache 2.0 compatibility |
| AGPL v3 | Like GPL v3 + triggered by network use (SaaS) — particularly restrictive |
Simple rule: if you incorporate GPL code into a product you distribute (including SaaS for AGPL), the entire product must be published under GPL. Contact the OSPO without exception.
Approval process
Is the license on the approved list?
├─ YES → Use is authorized (comply with obligations)
└─ NO → Submit a request to the OSPO
├─ Legal review (within [X] business days)
└─ Decision documented in the registry
Common obligations across all approved licenses
Regardless of which approved license applies, you must:
- Retain copyright notices in your distribution.
- Provide the license text (or a link) in your product.
- For Apache 2.0: include the NOTICE file if present in the original.
- Register the component in our SCA tool for SBOM generation.
Non-OSI licenses: proceed with caution
Some “source-available” licenses (SSPL, BSL, Elastic License, BUSL) are not open source licenses under the OSI definition. They may appear permissive but include commercial restrictions. Consult the OSPO before any use.
Common pitfalls
- Confusing “open source” with “unlicensed” — code without a license is not free to use. Copyright applies by default.
- Using an AGPL library in a cloud service — AGPL can be triggered even without distribution, depending on interpretation. Clarify with the OSPO.
- Mixing GPL v2 and Apache 2.0 — these two licenses are incompatible (Apache 2.0’s patent grant clause is not accepted by GPL v2).
- Forgetting transitive dependency licenses — your SCA tool must analyze the full dependency tree, not just declared dependencies.