This guide is general legal information, not legal advice, and does not create an attorney–client relationship. Rules change and vary by state — verify current requirements with official sources or a licensed attorney.
Every open-source licence is a copyright licence. The author still owns the code; the licence is a conditional permission to use it. Break the condition and you are not merely in breach of contract — you may be using copyrighted software without permission at all. That is why a licence term buried in a dependency three levels deep can matter more to a software company than most of the contracts it actually negotiated.
The practical question is rarely "may we use this library?" Almost always the answer is yes. The real question is what the licence asks in return, and whether the thing you are about to do counts as distribution — because that is the event most obligations attach to.
Key takeaways
- Permissive licences such as MIT, BSD, and Apache 2.0 mainly require that you preserve copyright notices and licence text; they place almost no constraint on what you build.
- Copyleft licences such as the GPL family impose source-disclosure obligations when you distribute software built on the licensed code, and can extend to your own additions.
- Apache 2.0 includes an express patent licence from contributors plus a termination provision if you sue over patents — a meaningful advantage over bare permissive licences that are silent on patents.
- The Open Source Initiative maintains the reference list of approved licences at opensource.org/licenses; "source available" terms that fail the Open Source Definition are not on it.
- Compliance is an inventory problem before it is a legal problem: you cannot honour obligations in code you have not catalogued.
What a software licence is actually doing
Copyright attaches to original code automatically the moment it is fixed, without registration — the same rule that covers any other creative work, as our copyright protection guide explains. The author's exclusive rights include copying, distributing, and preparing derivative works. Any use of someone else's code touches at least one of those rights, so permission is required.
An open-source licence grants that permission in advance, to everyone, subject to conditions. Registration with the U.S. Copyright Office is not required for the licence to work, though registration matters if the author ever wants to sue in federal court. The important structural point is that conditions in a copyright licence are enforceable as copyright limits, not just as promises.
Permissive versus copyleft: the dividing line
Licences broadly sort into two families based on what happens to your own code when you combine it with theirs.
| Licence family | Core obligation | Effect on your own code | Express patent grant |
|---|---|---|---|
| MIT / BSD 2- and 3-Clause | Keep the copyright notice and licence text with the code | None — you may keep your additions proprietary | No explicit grant |
| Apache License 2.0 | Notice, licence text, and a NOTICE file; state significant changes | None — additions may stay proprietary | Yes, with a patent-litigation termination clause |
| Mozilla Public License 2.0 | Disclose source for modified MPL-covered files | File-level reciprocity; other files unaffected | Yes |
| LGPL | Source for the library and a way to relink it | Application generally may stay proprietary if dynamically linked | Varies by version |
| GPL v2 / v3 | Provide complete corresponding source under the same licence on distribution | Derivative and combined works must be released under the GPL | Yes in v3; v2 addresses patents indirectly |
| AGPL v3 | Adds a network-use trigger to GPL obligations | Offering the software over a network can require source release | Yes |
Notice how narrow the permissive obligations are. MIT compliance is essentially a documentation exercise: ship the notice. Apache 2.0 asks slightly more — carry the NOTICE file forward and flag files you changed — and gives more back, in the form of the patent licence.
Copyleft is different in kind. The GPL's condition is that when you convey the software, recipients get the complete corresponding source under the same terms, including your modifications. That is not a penalty; it is the bargain the author chose. It becomes a problem only when a company distributes a product built on GPL code and never planned to release anything.
The distribution trigger, and why SaaS changed the question
Most copyleft obligations are triggered by distribution — conveying the software to someone else. Purely internal use generally does not trigger them. A company that runs GPL tooling on its own servers for its own operations typically owes nothing beyond keeping the code and notices intact.
Software-as-a-service complicated this. If users interact with your software over a network but never receive a copy, traditional copyleft licences were not triggered. The AGPL exists precisely to close that gap: it treats network interaction as an event that obliges you to offer source to remote users. Teams that assume "we never ship binaries, so copyleft cannot reach us" should confirm nothing in their dependency tree is AGPL-licensed.
Practical note: "Distribution" is broader than shipping a download. Embedding software in a device you sell, delivering a container image to a customer, providing an on-premises installation, and handing a build to a contractor can all count. Map your delivery channels before you map your licences.
Patents: the risk permissive licences often ignore
Copyright permission is not patent permission. Code can be freely licensed under MIT while the technique it implements is claimed in someone's patent, and the MIT licence says nothing about that. Apache 2.0 addresses the gap directly: each contributor grants a patent licence covering their contributions, and that licence terminates for anyone who initiates patent litigation alleging the work infringes. GPL v3 and MPL 2.0 contain comparable provisions.
For companies with meaningful patent exposure — or patent portfolios of their own — this is a real selection criterion, not a footnote. The obviousness standard that governs whether those patents were validly granted is set out in 35 U.S.C. § 103, and the broader mechanics of patenting software-related inventions are covered in our patent basics guide.
Building a compliance process that survives an audit
Compliance failures are almost never decisions. They are accidents of inventory: a developer adds a dependency, the dependency pulls transitive dependencies, and nobody looks at the licence field. A workable process is lightweight but continuous.
- Maintain an automated inventory — a software bill of materials — generated on every build, listing every component and its declared licence.
- Publish an internal policy that sorts licences into approved, approved-with-conditions, and requires-review categories, so most decisions need no lawyer.
- Scan for licence text inside files, not just package metadata; embedded snippets frequently carry terms the manifest never mentions.
- Automate notice generation so the attribution file shipped with each release is produced from the inventory rather than maintained by hand.
- Keep written contribution terms for outside contributors, and confirm employees' work is assigned — see IP assignment and work for hire.
- Re-run the analysis before any release that changes delivery model, such as moving from hosted service to on-premises installation.
Dual licensing and contributor agreements
Owning the copyright in a project lets the owner offer it under two sets of terms: a copyleft licence for the community and a commercial licence for companies that would rather not disclose source. This only works if the project owner actually holds rights in every contribution, which is why serious dual-licensed projects require contributor licence agreements or copyright assignments. A project that accepted years of anonymous patches without paperwork usually cannot relicense later, no matter how much a buyer wants it to.
Proprietary software licensing sits on the same foundation
Commercial software agreements use the same copyright mechanics with different economics. The recurring negotiation points are scope of the licence grant (named users, sites, cores, environments), whether the customer may modify or reverse engineer, source-code escrow for business-continuity risk, indemnities for third-party IP claims, and warranty and liability caps. The general risk-allocation clauses discussed in our guide to business contract clauses apply almost unchanged.
One clause deserves specific attention in software deals: the open-source representation. Buyers and enterprise customers increasingly ask suppliers to warrant that no copyleft-licensed code is combined with the delivered software in a way that would require source disclosure. Signing that representation without an inventory is how compliance problems become contractual liabilities.
Frequently asked questions
Does using a GPL library mean I must open-source my whole product?
Only if you distribute a work that includes or derives from the GPL code, and only for the work that the licence reaches. Internal use generally triggers nothing. Where the boundary of a "combined work" falls depends on how the components interact, and reasonable lawyers disagree — which is exactly why the safe path is to identify GPL components early rather than argue about scope after launch.
Is "free to use" the same as open source?
No. Free-of-charge, source-available, and open-source are three different things. A licence is open source only if it meets the Open Source Definition, and the Open Source Initiative's approved list is the reference point. Several popular "source available" licences restrict commercial or competitive use and are deliberately not on that list. Read the actual terms rather than the marketing label.
What happens if we discover a violation after shipping?
Most enforcement begins with a notice and an opportunity to comply — publishing the source, correcting notices, or removing the component. GPL v3 includes an express reinstatement mechanism for first-time violations cured promptly. Acting quickly and documenting the remediation matters far more than the original mistake, so treat a compliance notice as an engineering ticket with a deadline, not a dispute to be stalled.
Do we need a contributor licence agreement for an internal project?
If contributors are employees creating code within the scope of employment, the employer generally owns it already. Contractors are the gap: absent a written assignment, the contractor typically owns what they wrote. If you plan to relicense, dual-license, or sell the project, get signed assignments or a contributor agreement from every non-employee contributor before the codebase grows.
Should we register copyright in our software?
Registration is optional for protection but is a practical prerequisite to filing an infringement suit for a U.S. work, and timely registration preserves access to statutory damages and attorney's fees. Companies with a core product codebase often register major versions periodically. The Copyright Office publishes procedures for depositing source code with portions redacted to protect trade secrets.
Putting it together
Treat licences as engineering inputs. The decisive facts — what is in the build, how it is combined, and how it reaches users — live with the development team, not the legal team, so the process has to run inside the build pipeline. A generated inventory, a short approval policy, and automated notice files handle the overwhelming majority of cases without anyone opening a licence text.
Save legal analysis for the genuinely hard calls: copyleft components near the core of a distributed product, AGPL dependencies in a hosted service, and any representation you are about to sign in a customer or acquisition agreement. Those last ones surface fast in a transaction, as our guide to IP due diligence describes, and clean records are worth far more at that moment than a well-argued position. For related protection strategies across the rest of your technology stack, see the intellectual property hub.
