The software is free to download. Someone concludes that the licence can wait until procurement.
That is how an architectural choice becomes an unexpectedly lively legal meeting.
The short answer: MIT and Apache 2.0 are permissive licences; GPLv3 and AGPLv3 use copyleft conditions. All four permit commercial use, but their obligations differ. Read the licence of the exact release and match it to what you intend to do.
This is an orientation for a technical buying decision, not a legal opinion on your particular distribution or integration. Where the boundary matters, have the proposed arrangement reviewed.
Compare the four licences
| Licence | Broad approach | Key issue to inspect |
|---|---|---|
| MIT | Permissive | Preserve the copyright and permission notice in copies or substantial portions |
| Apache 2.0 | Permissive, with an express patent grant | Licence and notice obligations, modified-file notices and patent terms |
| GPLv3 | Copyleft | Conditions for conveying covered work, including corresponding source |
| AGPLv3 | Copyleft with an additional network provision | Modified versions used over a network and the corresponding-source offer |
The table deliberately names GPLv3 and AGPLv3. “GPL” without a version is not precise enough for a licence review. Check whether the grant specifies that version only or allows later versions.
MIT: short does not mean no conditions
The MIT licence grants broad permissions, including modification and sale, subject to preserving its copyright and permission notice. It includes a warranty disclaimer.
For a team adopting an MIT component, record the notice and make sure the release process preserves it where required. Do not assume that the main repository’s MIT licence covers every bundled dependency, image or dataset.
An MIT application can still rely on services with separate commercial terms. The software licence and the hosted service agreement answer different questions.
Apache 2.0: read the patent and notice provisions
Apache 2.0 includes an express contributor patent licence with conditions, alongside copyright permissions. Its redistribution requirements include providing the licence, identifying modified files and handling relevant notices, including NOTICE content where applicable.
It does not grant general trademark rights. A right to modify and redistribute software is not automatically a right to present your version as the original project’s official product.
Keep the licence and notice process in the build and release workflow. Treating attribution as a manual task someone remembers on launch day is unnecessarily fragile.
GPLv3: distribution changes the question
The GPLv3 text sets conditions for conveying covered software, including requirements concerning corresponding source. It does not mean that every internal use requires publishing your organisation’s entire codebase.
The difficult questions are often about what constitutes the covered or combined work and how it is conveyed. Linking, packaging and distribution arrangements need analysis in context. A diagram of the actual integration is more useful to a reviewer than “we use a GPL library somewhere”.
Do not rely on the simplistic claim that a separate process always removes obligations. Describe the arrangement and obtain a reasoned assessment.
AGPLv3: include the network use case
AGPLv3 adds a provision addressing users interacting remotely with a modified version over a network. Section 13 is the place to start when assessing that arrangement.
This matters when evaluating a hosted service built around modified AGPL software. It is not a blanket statement that every unrelated service in the organisation must become open source. The scope of the covered work still matters.
If a supplier offers a commercial licence as an alternative, compare the exact rights and conditions. Paying a fee is not automatically necessary, nor is it automatically the wrong choice.
Build a small licence record
For each component, record its name, version, source, exact licence identifier, notices, modifications, intended use and whether it is distributed or offered over a network. Include transitive dependencies and non-code assets in the review where relevant.
Ask the technical team to describe the architecture and release process. Ask the legal reviewer to resolve the uncertain obligations. Then assign someone to implement the answer in packaging and operations.
The point is to preserve the rights you need while meeting the conditions you accepted. A licence label is the start of that work, not its conclusion.
Sources and scope
Reviewed 1 November 2026. The examples and worksheets are my suggested working methods, not measured client results or official standards.
