Open-source licenses explained in one sentence: MIT, Apache 2.0 and GPLv3 all let you use, modify and distribute code, including in commercial products, but they ask for different things when that product leaves your organization.
This guide covers the license texts, not every legal issue around a project. A repository can contain multiple licenses, trademarks and third-party assets. For a consequential release, ask qualified counsel to review the actual dependency set.
Start with the act that triggers obligations
Reading, running and modifying code privately is different from distributing a copy. License conditions become most visible when you ship binaries, publish a modified library, bundle dependencies in an app or give an appliance to customers.
That distinction prevents a common mistake: assuming that open source always requires publishing every private change. The MIT and Apache licenses do not impose that requirement. GPLv3 generally requires corresponding source when covered object code is conveyed, but it does not require publication merely because code is used or modified inside one organization.
Software offered only over a network raises a separate question. GPLv3 does not use remote interaction by itself as its main source-release trigger. The GNU Affero GPL was written to add a network-use condition. Check the exact license name rather than treating “GPL” as one interchangeable label.
MIT: broad permission, short conditions
The MIT License text grants broad rights to use, copy, modify, merge, publish, distribute, sublicense and sell copies of the software.
Its central condition is small but real: copies or substantial portions must include the copyright notice and permission notice. The license also includes an “as is” warranty disclaimer.
In practice, a product team should:
- keep the license text and copyright notice in the source distribution;
- include them in the notices supplied with a binary or packaged app;
- preserve notices when copying a substantial portion into another repository.
MIT does not provide an express patent license in the way Apache 2.0 does. That difference can matter in organizations with a formal patent-risk review.
Apache 2.0: notices plus an express patent grant
Apache License 2.0 grants copyright permissions and an express patent license from each contributor for patent claims necessarily infringed by that contributor’s contribution.
The patent grant has a termination clause. If you bring patent litigation alleging that the work or a contribution infringes a patent, the patent licenses granted to you for that work end as the license describes.
Distribution also carries a longer checklist than MIT:
- give recipients a copy of the license;
- mark files you changed with prominent notices;
- retain relevant copyright, patent, trademark and attribution notices from the source;
- if the work includes a NOTICE file, include its applicable attribution notices in one of the allowed places.
The NOTICE file is not a substitute for the license. It is a place for informational notices. Apache 2.0 also says it does not grant permission to use the licensor’s trade names, trademarks or product names except for reasonable descriptive use.
For teams shipping SDKs or infrastructure components, the explicit patent language and clear notice procedure are two reasons Apache 2.0 appears frequently.
GPLv3: recipients keep the same freedoms
The GNU GPL version 3 is a copyleft license. You may run, study, modify and distribute covered software. When you convey a modified covered work, the license requires the work as a whole to be licensed under GPLv3 to everyone who receives a copy, subject to the text’s terms.
For object code, the distributor must provide the corresponding source through one of the methods the license permits. That can mean accompanying the object code with source on a durable medium, providing a written offer in qualifying cases, or offering equivalent access to source from the same place.
Corresponding source is more than the files a developer happened to edit. GPLv3 defines it as the source needed to generate, install and run the object code and to modify the work, excluding listed system libraries and general-purpose tools that are not part of the work.
The license also addresses installation information for certain user products, anti-circumvention rules, patent terms and additional permissions. Those details are why a release checklist should link to the exact version rather than compress the obligations into “share your changes.”
A practical comparison
| Question | MIT | Apache 2.0 | GPLv3 |
|---|---|---|---|
| Commercial use allowed? | Yes | Yes | Yes |
| Keep license and notices? | Yes | Yes, with change and NOTICE handling | Yes |
| Express patent grant? | No comparable express grant | Yes | Yes, with GPLv3 terms |
| Must modified distributed work stay under the same license? | No | No | Generally yes for the covered work |
| Source duty when covered object code is conveyed? | No general source duty | No general source duty | Corresponding source must be provided by a permitted method |
| Private modification alone forces publication? | No | No | No |
The table is a starting map. It does not decide whether two licenses are compatible, whether a plugin forms one combined work or whether a particular distribution channel satisfies the source offer.
What “using a library” can mean
A developer can interact with the same library in several ways:
- call it as a separately installed dependency;
- bundle it into one executable;
- modify its source and ship the fork;
- copy a few files into an application;
- expose a service that runs it on a server.
Those facts can change the analysis, especially for copyleft. Package-manager labels are not enough. Read the license file at the version you actually install, then inspect subdirectories, generated artifacts and bundled assets for additional terms.
A lockfile helps preserve the reviewed version. The semantic versioning guide explains why a range can install something different from the version you inspected. For an inventory that survives a security or license review, record package name, version, source URL, license identifier and the copy of the notice shipped with the product.
A release checklist
- Generate a dependency inventory from the built artifact, not only the top-level manifest.
- Confirm each exact version’s license and copyright notices.
- Flag unknown, custom and copyleft licenses for review.
- Preserve MIT notices and the Apache license, change notices and applicable NOTICE content.
- For GPL-covered object code, prepare the corresponding source and a delivery method that matches the license.
- Keep third-party notices accessible in the product or accompanying materials.
- Re-run the review after dependency updates.
Do not remove a license because a scanner reports two possibilities. Inspect the package. False positives happen, and a dual-licensed project may let you choose one license only if you meet its terms.
Source check: the OSI MIT page, Apache License 2.0 text and GNU GPLv3 text were reviewed on October 18, 2026. GPLv3 is dated June 29, 2007; Apache 2.0 is dated January 2004.
