Library or SDK you publish
A reversal of perspective: you are no longer the consumer but the supplier. Two constraints answer each other.
What actually happens
| Question | Answer |
|---|---|
| Does a third party receive the software in executable form? | Yes, and usually in source form too |
| Does your licence constrain your users? | Yes — that is the central point |
| Do your dependencies constrain your licence? | Yes |
The rule that governs everything
You cannot publish under a licence more permissive than the most restrictive of your dependencies.
A library embedding a GPL component cannot be published under MIT. The licence you display must be downstream-compatible with everything you include.
Corollary: the composition of your dependencies is a product decision, not a technical one. Adding an LGPL dependency to a permissive SDK transfers an engineering constraint to all your users, usually without their noticing.
The verdict for your dependencies
| Dependency family | Verdict | Effect on what you publish |
|---|---|---|
| Permissive | ● | None. You remain free to choose your licence |
| Weak copyleft, file (MPL) | ◐ | Your files stay free; modified MPL files must be published |
| Weak copyleft, library (LGPL) | ○ | Your users inherit the replacement constraint, often unknowingly |
| Strong copyleft (GPL) | ○ | Your library becomes GPL. A legitimate choice, but it must be deliberate |
| Network copyleft (AGPL) | ○ | Your library becomes AGPL, which makes it unusable by most integrators |
| Source-available | ✕ | You cannot redistribute |
Choosing your own licence
A commercial decision as much as a legal one.
| Your licence | Who can integrate you | What you get |
|---|---|---|
| Apache-2.0 | Everyone | Maximum adoption, plus patent protection for you and for them. The default choice for an SDK meant to be adopted |
| MIT | Everyone | Maximum adoption, no patent protection |
| MPL-2.0 | Everyone, with per-file reciprocity | Improvements to your code come back to you without blocking integration |
| LGPL | Everyone, with a linking constraint | Strong reciprocity, but effectively rules out embedded and mobile |
| GPL / AGPL | Free software projects only | The dual licensing model: free for open source, paid for proprietary |
| BSL / source-available | Depends on the restrictions | Protection against managed-service resale, at the cost of leaving open source |
The dual licensing model — GPL or AGPL on one side, a commercial licence on the other — requires owning all rights in the code. Which leads to the next point.
The CLA, to settle before the first external contribution
Without a contributor licence agreement or, at minimum, a DCO, each contributor keeps their rights in their contribution. Consequences:
- relicensing later is impossible without everyone’s consent;
- offering a commercial licence is impossible over code you do not fully own;
- enforcing the licence against a third party is difficult, since you do not hold all rights.
This must be decided before accepting the first external contribution. Fixing it afterwards means tracking down every contributor, or rewriting their work.
Pitfalls in this scenario
The invisible transitive dependency. Your SDK is Apache-2.0 but pulls in an LGPL dependency. Your users inherit the linking constraint with nothing to warn them. The remedy: publish your own SBOM alongside the SDK, and explicitly document transitive licences carrying obligations.
Nested licences in one repository. A repository announced as MIT with a vendor/
subdirectory under GPL. Your licence declaration becomes inaccurate.
Example code. The snippets you publish in the documentation are reused verbatim by your users. Without an explicit licence their status is uncertain — state that they are under the same licence, or a more permissive one.
Generated files. An SDK generated from an interface specification sometimes inherits the
generator’s licence. Check what the generator says about its output — exceptions of the
Autoconf-exception kind exist for exactly this.
Trademarks. No free software licence grants trademark rights. A user may fork your code; they may not call it by your name.
What the CRA adds
A great deal, and it is often overlooked: a library placed on the market separately is a product with digital elements in its own right (Art. 3, point 1).
It therefore has, for itself: its technical documentation, its SBOM, its support period, its coordinated disclosure policy, its CE marking.
Unless it is made available outside a commercial activity, in which case it falls outside the scope — see Open source. The boundary is commercial character, not licence: publishing an Apache-2.0 SDK alongside a paid offering is still a commercial activity.