OSS License Basics: Understanding the Differences Between MIT, GPL, and Apache

A web development company integrated an open-source shopping cart system into an e-commerce site they were building for a client. The person in charge concluded that since the code was published on GitHub, it was free to use, and skipped reviewing the license. The system ran without issue — until six months later, when the original developer sent a notice. The system had been released under GPL v2, and by embedding it in the deliverable handed to the client, the company had incurred an obligation to disclose its source code.

This case illustrates the danger of assuming "publicly available equals freely usable." Open source software is software where the copyright holder has granted permission to use it under specific conditions — and those conditions are defined by the license. Using OSS without checking the license can unknowingly place you in a state of copyright infringement.

There are hundreds of OSS licenses in existence, but the three you are most likely to encounter in practice are the MIT License, the GNU General Public License (GPL), and Apache License 2.0. Understanding the differences between these three is the essential first step in using OSS responsibly.

To understand OSS licenses, it helps to first grasp their relationship to copyright law. Software is a copyrighted work, and copyright is automatically granted to its creator. Copying, modifying, or distributing software without the copyright holder's permission constitutes copyright infringement.

An OSS license is a permission document in which the copyright holder declares: "As long as you follow certain conditions, anyone may use, modify, and distribute this software." Those "certain conditions" differ significantly depending on the license. When the conditions are met, the use is lawful; if violated, the permission lapses and infringement can occur.

OSS licenses fall into two broad categories.

Copyleft licenses require that derivative works — software that incorporates or builds upon the OSS — be distributed under the same license. GPL is the prime example. This type of license is sometimes described as "viral" or "infectious." Its purpose is to ensure that the freedoms granted by the software are preserved in perpetuity.

Permissive licenses do not restrict the license under which derivative works are distributed. The MIT License and Apache License 2.0 fall into this category. Distributing modified code under a proprietary license is permitted.

With this classification in mind, we can look at the specific terms of each license.

The MIT License

The MIT License is one of the least restrictive open source licenses. Its requirements reduce to essentially one: retain the copyright notice and license text. That is all.

Commercial use, modification, redistribution, and sublicensing are all permitted. There is no obligation to disclose source code. Embedding MIT-licensed code in a closed-source product and distributing only the binary is perfectly legal.

The license does include a disclaimer of warranty — the copyright holder accepts no liability for damages arising from use of the software. This is common to most OSS licenses, but the MIT License is notably concise, which makes it easy to handle from a legal risk perspective.

One practical note: you must include the copyright notice from any MIT-licensed dependency in your own distribution, whether in a LICENSE file or in your documentation.

GNU GPL (General Public License)

GPL is the flagship copyleft license. GPL v2 (GPL-2.0) and GPL v3 (GPL-3.0) are the most widely used versions. The Linux kernel (GPL-2.0) and WordPress core (GPL-2.0 or later) are prominent adopters.

Its defining feature is the copyleft clause: if you incorporate GPL-licensed code into a derivative work and distribute it to third parties, that derivative work must also be distributed under GPL, with source code made available.

The definition of "distribution" is critical here. Using GPL-licensed code internally — without distributing it externally — does not trigger source disclosure obligations. The issue arises when GPL code is embedded in software delivered to clients or end users.

The difference between GPL-2.0 and GPL-3.0 also matters in practice. GPL-3.0 added a patent retaliation clause: if you initiate patent litigation against users of GPL-licensed software, your license automatically terminates. It also addressed "tivoization" — the restriction of user freedoms through hardware locks — by adding a requirement to provide installation instructions.

Note that GPL exceptions exist. Copyright holders can explicitly carve out exceptions that relax GPL conditions for specific uses. The OpenSSL exception and the GCC Runtime Library exception are well-known examples.

Apache License 2.0

Apache License 2.0 is a permissive license that is more detailed in its terms than MIT. Developed by the Apache Software Foundation, it is used by Apache HTTP Server, Android, Kubernetes, TensorFlow, and many other major projects.

Two features distinguish it from MIT.

First, explicit patent grants: contributors to Apache-licensed code grant a license under any patents they hold to the extent necessary for using that code. MIT contains no explicit patent provisions, so Apache License 2.0 is generally considered safer from a patent risk perspective.

Second, attribution and change notification obligations: redistributions must include attribution information in a NOTICE file, and if modifications have been made, that fact must be stated.

Because Apache License 2.0 has no copyleft clause — allowing integration into proprietary software — and explicitly addresses patent risk, it is widely recognized as particularly well-suited to enterprise use.

GPL's copyleft clause demands particular care in commercial software development. Here are the key risk scenarios.

Scenario 1: Delivering to clients

If a GPL v2-licensed library is embedded in a web system built for a client, copyleft obligations are triggered at the point of delivery (distribution). The client may have the right to request source code disclosure. If the client subsequently distributes the system to third parties, the same obligations cascade.

Scenario 2: SaaS and cloud services

In a SaaS model, the software itself is not distributed to users, so GPL copyleft obligations generally do not apply. However, AGPL (Affero GPL) was specifically designed to close this "SaaS loophole": it imposes source disclosure obligations even when software is provided as a network service. If AGPL-licensed software runs on your servers, special care is required.

Scenario 3: GPL-2.0 and GPL-3.0 incompatibility

Combining GPL-2.0-only code with GPL-3.0 code is generally not permitted due to license incompatibility. This is why the Linux kernel adopted "GPL-2.0 only." When using GPL-licensed code in a project, verify that the version is consistent, or that applicable exception clauses exist.

One practical approach to managing copyleft risk is to use LGPL (Lesser GPL). LGPL is a weakened form of GPL: dynamically linking an LGPL library into an application does not cause the GPL conditions to flow to the application. However, if the LGPL library itself is modified, the modifications must be released under LGPL.

When selecting the right OSS license for your own project or product, consider the following dimensions.

Dimension 1: Intent to share code

If your goal is broad adoption with no restrictions on how the code is used, MIT or Apache License 2.0 is appropriate. If you value community contribution and want to ensure derivative works remain open, GPL is the right choice. GPL can also be used strategically to prevent proprietary commercial use.

Dimension 2: Concern about patent risk

For code used in industries where patent disputes are a real concern, Apache License 2.0 is recommended because of its explicit patent grant clause. MIT is silent on patents, meaning patent litigation risk is not entirely eliminated.

Dimension 3: Ease of corporate adoption

Most corporate legal departments approve MIT and Apache License 2.0 relatively easily. GPL often requires lengthier legal review, and some organizations maintain policies against incorporating GPL code. When time-to-decision matters, MIT or Apache License 2.0 is the path of least resistance.

Decision framework for users of OSS

From the perspective of someone integrating existing OSS, the following questions structure the decision:

1. Will you be modifying and distributing the OSS, or using it as-is?
2. Is distribution internal only, or does it include clients or end users?
3. Will the code be embedded directly, or referenced as an external library?

If the answers are "use as-is," "internal only," and "external reference only," most licenses create no issues. When the combination includes "modify and distribute," "deliver to clients," or "embed source code directly," you need to verify copyleft clause implications.

The minimum checks required when using OSS in a business context are as follows.

At project start

• Audit the licenses of all OSS libraries used, via package.json, requirements.txt, and similar dependency files
• If copyleft licenses (GPL, AGPL, LGPL, etc.) are present, cross-reference with your distribution model to determine whether copyleft obligations apply
• Put any code with unclear or unknown licenses on hold and escalate to legal counsel

During development and at delivery

• Include copyright notices for MIT and Apache License 2.0 dependencies in a NOTICE file or documentation
• Attach a list of OSS components and their licenses to the client's delivery specification
• If the client may further distribute or modify the system after delivery, spell out those conditions explicitly in the contract

Ongoing management

• When updating dependencies, check whether license terms have changed (license changes are not uncommon)
• Use tools such as license-checker (Node.js) or pip-licenses (Python) to periodically audit your dependency licenses

OSS license issues often surface only after a significant amount of code has already been written. Early verification at the project outset and the establishment of internal OSS license policies are the most effective preventive measures. "I didn't know" is not an acceptable defense in this domain — raising OSS license literacy across the development team is a worthwhile investment.

---

References

• Open Source Initiative. "Licenses & Standards." https://opensource.org/licenses
• GNU Project. "GNU General Public License, version 2." https://www.gnu.org/licenses/old-licenses/gpl-2.0.html
• Apache Software Foundation. "Apache License, Version 2.0." https://www.apache.org/licenses/LICENSE-2.0
• Software Freedom Law Center. "A Practical Guide to GPL Compliance." https://softwarefreedom.org/resources/2008/compliance-guide.html