A software licence is the legal contract that grants you permission to use software and sets the conditions on how you may run, copy, modify, and redistribute it. Without a licence, default copyright law reserves all rights to the author, meaning you technically cannot legally use the code at all. The licence is what turns "all rights reserved" into a defined set of things you are allowed to do. This guide explains the main categories and why getting them right matters more as your dependency tree grows.
Why software needs a licence at all
Software is protected by copyright the moment it is written. That protection is restrictive by default: the copyright holder controls copying and distribution, and everyone else has no rights unless they are granted some. A software licence is that grant. It converts an implicit "you may not" into an explicit "you may, provided you do these things."
That is true whether the software is a paid enterprise product or a free package on a public registry. Even the most permissive open-source project relies on a licence to give you legal cover; "it's on GitHub" is not permission. A public repository with no licence file is, strictly speaking, all-rights-reserved code you have no right to reuse.
Note the spelling: "licence" (with a c) is the common British and Commonwealth noun, while American English uses "license" for both the noun and the verb. When people search "software license or licence," they are asking about the same thing — the wording is regional, not technical. This guide uses "licence" as the noun throughout.
The three broad families
Almost every licence you will meet falls into one of three buckets.
Permissive open-source licences grant wide freedom with minimal obligations. MIT, BSD, and Apache 2.0 let you use, modify, and embed the code in commercial, closed-source products as long as you preserve attribution. They do not force you to share your own source. These are the least risky for building proprietary products on top of.
Copyleft open-source licences grant the same freedoms but attach a reciprocity condition: if you distribute a derivative work, you must release it under the same licence. The GPL family is the archetype. Strong copyleft (GPLv3) reaches broadly; weak copyleft (LGPL, MPL) limits the obligation to the licensed files or library. Copyleft is not "worse" — it is a deliberate choice to keep derivatives open — but it can conflict with a closed-source business model.
Proprietary licences are the commercial end. The vendor retains ownership and grants you a limited right to use the software under specific terms — seat counts, deployment limits, no redistribution, no reverse engineering. Most paid enterprise software lives here, and the terms vary wildly from one End User License Agreement to the next.
What a licence actually controls
Whatever the family, a software licence typically spells out:
- Usage rights — who can run it, on how many machines, for what purpose (personal, commercial, non-commercial).
- Modification rights — whether you may change the source and under what conditions.
- Distribution rights — whether and how you may share original or modified copies.
- Attribution requirements — notices, copyright statements, or NOTICE files you must preserve.
- Warranty and liability — almost always disclaimed; open-source code is provided "as is."
- Patent terms — whether patent rights travel with the code, as Apache 2.0 grants explicitly.
When people talk about "licence software" obligations, this list is what they mean. The details are where compliance risk hides.
Why the licence of your dependencies is your problem
Here is the part that surprises teams. Your own code might be cleanly licensed, but a modern application pulls in hundreds of third-party packages, and each of those pulls in more. Every one of them carries a licence, and those obligations flow through to whatever you ship.
The classic trap: you build a closed-source product on permissive dependencies, then one package four levels deep in your dependency tree turns out to be GPL-licensed. If that copyleft licence's conditions attach to distribution, you may be obligated to release source you intended to keep private — or to remove the component. Discovering that during an acquisition's due diligence, or after a customer's legal review, is expensive.
License incompatibility is also a real category. Some licences simply cannot be combined; mixing them in one distributed work creates terms that contradict each other. You cannot resolve that by ignoring it.
Managing licences across the whole tree
Manual tracking does not scale past a handful of dependencies. The practical approach is to generate a Software Bill of Materials (SBOM) that lists every component and its licence, then check that inventory against a policy that says which licences are allowed, which need review, and which are banned for your use case.
Automated software composition analysis does this continuously. It reads licence metadata for direct and transitive dependencies, flags copyleft or unknown licences appearing where they should not, and blocks a build before a non-compliant component ships. A platform such as Safeguard's SCA ties that licence inventory to the same SBOM it uses for vulnerability tracking, so compliance and security share one source of truth. For a deeper look at one common permissive licence, our Apache License 2.0 summary walks through a real example. The takeaway is simple: know what licences you depend on before someone with a legal budget asks you to prove it.
FAQ
What is the difference between a software licence and copyright?
Copyright is the automatic legal protection an author gets over their work; it reserves all rights by default. A software licence is the grant the author issues on top of copyright, giving others specific permission to use, modify, or distribute the work. Without a licence, copyright alone means you have no rights to reuse the code.
Is open-source software free to use however I want?
Not entirely. Open-source licences grant broad freedoms but almost always attach conditions — preserving attribution, or, for copyleft licences, releasing derivative works under the same terms. "Open source" means the source is available under a licence, not that there are no obligations. Read the licence before assuming you can embed it in a commercial product.
Software license or licence — which spelling is correct?
Both are correct; the difference is regional. British and Commonwealth English use "licence" as the noun and "license" as the verb, while American English uses "license" for both. They refer to the identical legal concept, so search intent is the same regardless of spelling.
How do I know which licences my project depends on?
Generate a Software Bill of Materials that enumerates every direct and transitive dependency with its declared licence, then review it against a policy. Software composition analysis tools automate this and can alert you when an incompatible or unexpected licence enters the dependency tree, which is far more reliable than manual inspection.