Open source in your software: licences explained
What the common open source licences require, why the distinction between permissive and copyleft matters for your product, and how to keep an inventory.
The short answer
Modern software is assembled from open source components, and every one arrives with a licence granting rights on conditions. The important distinction is between permissive licences, which allow use, modification and redistribution including inside proprietary products, subject mainly to preserving copyright notices and licence text, and copyleft licences, which require derived works you distribute to be offered under the same terms with source available. Strong copyleft reaches further than weak copyleft, which typically confines the obligation to the component itself, and network copyleft extends the trigger to making software available to users over a network, which is precisely the web application case. For a business hosting a web application built from ordinary permissive dependencies, the practical obligations are light: preserve notices, do not misrepresent authorship, and know what you use. For a business distributing software, or depending on a component under a copyleft licence, the analysis matters and should be done deliberately. In both cases the requirement is the same first step: a generated inventory of components and licences, produced with every release.
The licence families
| Family | Typical conditions | Effect on a hosted web application | Effect on distributed software |
|---|---|---|---|
| Permissive | Preserve copyright and licence notices; no warranty; sometimes no use of names | Minimal: include notices | Minimal: include notices |
| Weak copyleft | Modifications to the component itself shared under the same licence | Usually manageable | Manageable if the component is kept separate |
| Strong copyleft | Derived works distributed must be licensed the same way with source | Hosting is usually not distribution | Significant: your product may be affected |
| Network copyleft | Source availability triggered by providing access over a network | Significant: designed for this case | Significant |
| Public domain dedications | Effectively none | None | None |
| Source-available, not open source | Varies; often restricts commercial or competing use | Read carefully; may prohibit your use | Read carefully |
| Dual licensing | Open licence or a commercial licence at your choice | Choose deliberately and record it | Choose deliberately |
Keeping it manageable
- Generate the inventory from your package manager on every build and store it with the release.
- Define an approved licence list for your situation, and flag anything outside it in the pipeline.
- Know your distribution model: hosted service, downloadable software, client-installed, embedded.
- Read the licence of anything outside the approved list before adopting it.
- Include the notices your dependencies require, typically in a notices file shipped or published.
- Watch for licence changes on upgrade; projects occasionally relicense.
- Check source-available licences carefully; they are not open source and may restrict your use.
- Record commercial licences you hold for dual-licensed components.
- Keep the inventory with each release, because auditors and acquirers ask about a version, not about today.
Security and licences together
The same inventory serves two purposes. It answers the licence question, and it is the basis for knowing whether a newly disclosed vulnerability affects you. Generating it automatically, keeping it with releases and checking it in the pipeline therefore covers supply chain security and licence compliance at once, which is why we treat them as one practice rather than two.
What this means for you
Open source components carry licences with conditions, and the practical distinction is permissive against copyleft, combined with whether you distribute software or host a service. For hosted applications on permissive dependencies the obligations are light. Generate a licence inventory with every release, flag anything outside an approved list, read before adopting, include required notices, and watch for relicensing. This is general information rather than legal advice; a distributed product with copyleft dependencies deserves a qualified review.
Frequently asked questions
Do open source licences create a problem for our web application?
Rarely, if the components carry permissive licences and you host the application rather than distributing it. The conditions in most permissive licences amount to preserving copyright notices and licence text. The cases needing attention are copyleft licences where you distribute software, and network-copyleft licences that treat providing access over a network as triggering the source availability condition. Knowing which you depend on is the whole task.
What is the difference between permissive and copyleft?
Permissive licences let you use, modify and redistribute, including in proprietary products, with conditions limited mainly to attribution and notice preservation. Copyleft licences require that derived works you distribute are licensed on the same terms, with the source made available. Strong copyleft reaches further than weak copyleft, and network copyleft extends the trigger to software made available as a service. The practical question is whether any dependency carries one and whether your distribution model triggers it.
How do we keep track?
Generate the inventory from your build tooling with every release, store it with the release, and add a check to the pipeline that flags licences outside an approved list. That way the question of what you depend on is answered automatically rather than reconstructed. Buyers in an acquisition, enterprise clients and auditors all ask for exactly this, and producing it in minutes is a good look.
Sources
- Open Source Initiative: Licenses (accessed 2026-09-12)
- Linux Foundation: SPDX License List (accessed 2026-09-12)