Open-Source Licenses Explained: MIT vs GPL vs Apache

Almost every app your business builds or buys is mostly open source code. A typical web or mobile project pulls in hundreds of packages, and each one comes with a license. Most of those licenses are easy to live with. A few can force you to publish your own source code if you handle them carelessly.

The good news: you don’t need to be a lawyer to avoid the common mistakes. You need to know which family each license belongs to, what triggers its obligations, and how to keep a simple record. This guide explains MIT, Apache 2.0 and the GPL family in plain English, then gives you a checklist your team can use this week.

What an open source license actually does

Code is protected by copyright the moment someone writes it. Without a license, you have no right to copy, change or ship it, even if it sits in a public GitHub repository. An open source license is the author’s written permission to do those things, with conditions attached.

Those conditions fall into 2 broad families:

• Permissive licenses (MIT, BSD, Apache 2.0) let you use the code almost any way you like, including inside closed, paid products. You mainly have to keep the copyright and license notices.
• Copyleft licenses (GPL, LGPL, AGPL, MPL) also let you use and change the code, but if you distribute it, you must share the source under the same license. How far that “share alike” rule reaches depends on the license.

The licenses that the Open Source Initiative (OSI) has reviewed and approved are the ones most companies treat as “real” open source. Some projects use source-available licenses instead, such as the Business Source License or the Server Side Public License. You can read their code, but they restrict certain commercial uses and are not OSI-approved. Treat them as commercial licenses and read the terms.

MIT vs Apache 2.0 vs GPL at a glance

Key takeaway: Permissive licenses ask you to give credit. Copyleft licenses ask you to share your source when you distribute. Most compliance problems come from treating a copyleft package as if it were permissive.

The MIT license: credit and no warranty

MIT is the shortest common license and the most popular for small libraries. It has 1 condition: the copyright notice and the permission notice must be included in all copies or substantial portions of the software. It also says the software comes “as is”, with no warranty, and the authors aren’t liable for damages.

In practice that means:

• You can use MIT code in a closed-source product, change it, and sell the product.
• You must ship the MIT license text and copyright line somewhere users can find it, such as an “open source notices” screen in a mobile app or a THIRD_PARTY_NOTICES file in a download.
• You get no promise that the code works or is secure. That risk is yours.

The BSD 2-clause and 3-clause licenses work in much the same way. BSD 3-clause adds a rule that you can’t use the authors’ names to endorse your product without permission.

Apache 2.0: permissive with patents and paperwork

Apache 2.0 is also permissive, but it is longer and more precise, which is why many companies prefer it. When you redistribute Apache code, in source or compiled form, Section 4 of the license asks you to:

1. Give recipients a copy of the Apache 2.0 license.
2. Make any files you changed carry prominent notices saying you changed them.
3. Keep the existing copyright, patent, trademark and attribution notices.
4. If the project includes a NOTICE file, pass on its attribution notices in your documentation, source or display.

Section 3 is the big difference from MIT. Each contributor grants you a patent license for their contributions. That license ends if you file a lawsuit claiming the work infringes a patent. Section 6 adds that the license does not let you use the project’s trademarks, beyond describing where the code came from.

For a business, Apache 2.0 is usually the lowest-risk license to depend on. The patent grant protects you, and the obligations are clear.

The GPL family: share the source when you distribute

The GNU General Public License is the best-known copyleft license. Its core rule: if you distribute a program that contains GPL code, including a modified or combined version, you must make the complete corresponding source available under the GPL. You can still charge money for the software. You just can’t stop recipients from getting the source and sharing it.

What counts as distribution matters a lot. The Free Software Foundation’s GPL FAQ explains that using a modified GPL program inside your own organization is not distribution, so you don’t have to release your changes. Shipping an app, an installer, firmware on a device, or giving copies to an outside contractor is distribution.

GPL v2 vs GPL v3. GPL v3 adds an explicit patent license, rules against locking users out of modified software on consumer devices, and better compatibility with other licenses. Watch for “v2 only” vs “or any later version” wording, because it changes what you can combine.

LGPL. The Lesser GPL is built for libraries. You can link a closed application to an LGPL library, as long as users can swap in a modified version of the library. Dynamic linking is the usual way to meet this. Static linking brings extra obligations, such as providing your app in a form that can be relinked.

AGPL. The ordinary GPL is only triggered by distribution, so running modified GPL code on your own servers as a web service doesn’t require releasing it. The Affero GPL closes that gap. If users interact with a modified AGPL program over a network, you must offer them its source. Many companies ban AGPL dependencies in their SaaS products unless legal has approved them.

MPL 2.0 and other licenses in between

The Mozilla Public License 2.0 is a “file-level” copyleft. If you change an MPL file, those file changes must stay under the MPL and be available to recipients. New files you write that contain no MPL code can stay under your own license, even in the same product. That makes MPL easier to use in commercial software than the GPL.

Compatibility is the other thing to check when you combine code. According to the Free Software Foundation’s license list:

• MIT (which the FSF calls the Expat license) is compatible with the GPL.
• Apache 2.0 is compatible with GPL v3 but not with GPL v2, because of its patent termination and indemnification terms.
• MPL 2.0 lets you combine MPL files with GNU-licensed code in a larger work.

If you see an unfamiliar license, look it up on the SPDX License List to get its standard name and full text before anyone merges it.

Common ways businesses violate licenses by accident

Most violations aren’t deliberate. They come from busy teams who never looked at the license file. Watch for these:

• Missing attribution. Shipping an app or device with MIT, BSD or Apache code but no notices screen or file.
• Copying GPL snippets into proprietary code. A function pasted from a GPL project carries the GPL with it.
• AGPL in a SaaS backend. Fine for internal tools, risky for a customer-facing service you’ve modified.
• Assuming “on GitHub” means “free to use”. No license file means no permission.
• Ignoring transitive dependencies. The package you chose may be MIT, while something it pulls in is GPL.
• Outsourced code with unknown origins. Ask any agency you hire to disclose third-party components. Our guide on how to hire a mobile app developer covers contract questions worth adding.
• AI-generated code. Coding assistants can sometimes reproduce code that matches open source projects. Some tools offer filters or reference checks; turn them on. See AI coding assistants and software teams for team policies.

Where to start: a 6-step license checklist

You can set up basic open source compliance in a week or two, even on a small team.

1. Write a 1-page policy. List licenses that are pre-approved (for example MIT, BSD, Apache 2.0), licenses that need review (LGPL, MPL), and licenses that need legal sign-off (GPL, AGPL, anything source-available or unknown).
2. Generate an inventory. Use a software composition analysis (SCA) tool or your package manager’s license report to list every direct and transitive dependency with its license. The same tools help with security, which ties into software supply chain attacks.
3. Produce an SBOM. A software bill of materials in a standard format such as SPDX or CycloneDX records what you ship. Enterprise and government customers increasingly ask for one.
4. Add a check to your pipeline. Fail the build or flag a review when a new dependency uses a license outside your policy. Our guide to securing a CI/CD pipeline shows where these checks fit.
5. Ship your notices. Generate a third-party notices file automatically and include it in every release, app and device.
6. Review before big moments. Fundraising, acquisitions and large enterprise deals often include open source due diligence. Clean up before you’re asked.

For your own projects, choose a license on purpose. MIT or Apache 2.0 suits code you want widely adopted. GPL or AGPL suits code where you want improvements shared back.

Conclusion

Open source licenses are less scary than they look. MIT and Apache 2.0 mostly ask for credit, and Apache adds useful patent protection. The GPL family asks you to share source when you distribute, and AGPL extends that to network services. Know which family each dependency belongs to, keep an inventory, automate the checks, and get legal advice for anything copyleft that touches a product you ship. For more definitions, browse our tech glossary.

This is not legal advice. License terms and how courts read them can vary, so talk to a qualified attorney about your specific products.

Sources

• Open Source Initiative: The MIT License — the MIT condition and warranty disclaimer
• Apache Software Foundation: Apache License, Version 2.0 — redistribution conditions, patent grant and trademark terms
• GNU Project: Frequently Asked Questions about the GNU Licenses — internal use, charging for GPL software, AGPL and LGPL linking
• GNU Project: Various Licenses and Comments about Them — GPL compatibility of MIT, Apache 2.0 and MPL 2.0
• Mozilla: MPL 2.0 FAQ — file-level copyleft and combining with proprietary code
• SPDX License List — standard license identifiers