MIT, GPL, and Apache 2.0: How the Licenses Differ in Practice

An open-source license does not measure how generous or restrictive an author feels. It answers more concrete questions in advance: who may copy, modify, and distribute the code, which notices must remain, whether recipients must receive source, and how patent rights are handled. Framing MIT and GPL as a philosophical war obscures those mechanics. Both support commercial use and collaborative development, but they attach different conditions to what happens when software is passed on.

This article explains the general structure of four licenses and is not legal advice. A product involving material liability, outside investment, a large dependency graph, or a patent portfolio deserves review by qualified counsel before release.

The GNU GPL unified licenses across GNU programs

On September 27, 1983, Richard Stallman announced the GNU Project, intending to build a free Unix-compatible system. Development began in January 1984, and the Free Software Foundation was founded in October 1985, initially to help fund GNU development. During this period, individual GNU programs used similar but not entirely identical license terms.

By 1989, enough practical experience had accumulated to replace those variants with a common license. GNU GPL version 1, released in February 1989, used copyright not only to grant permissions to the first recipient but also to preserve those permissions downstream. This mechanism became known as copyleft: recipients may run, study, modify, and pass on the program, but conveying a covered modified work requires them to preserve the license and provide the next recipient access to source.

Copyleft does not make code “viral,” nor does it force every local modification onto a public website. GPLv3 obligations mainly arise on conveying, when a copy is made available to another party. Internal use within one organization does not by itself require a public repository, as the GNU GPL FAQ explicitly explains. Ordinary GPLv3 also does not require server code to be released merely because users interact with it over a network; AGPLv3 contains a separate network condition for that scenario.

Later versions addressed new practical problems. GPLv2 followed in 1991, and GPLv3 was published on June 29, 2007 after a public drafting process. Version 3 treats patents and compatibility with some other licenses more explicitly. It also requires Installation Information in certain consumer-device distributions so that a recipient can install a modified build. This provision is commonly discussed under the label tivoization, but it is not a general promise that a vendor must support every user modification.

MIT continues a short permissive tradition

Permissive notices circulated through academic and Unix software before modern license catalogs standardized the identifier MIT. The X Window System, created at MIT in the mid-1980s, provides a well-documented example. X.Org preserves the historical X/MIT copyright texts, which allowed software to be used, modified, distributed, and sold while requiring the copyright and permission notices to remain; a separate paragraph disclaimed warranties.

Today, the SPDX identifier MIT points to the common short text published in the Open Source Initiative catalog. It grants permission to use, copy, modify, merge, publish, distribute, sublicense, and sell copies. Its condition is brief but real: the copyright notice and permission notice must accompany all copies or substantial portions of the software. A final paragraph disclaims warranties and limits liability to the extent applicable law allows.

Unlike copyleft, MIT does not require a larger product to use MIT or require source delivery with a binary. MIT-licensed code can therefore remain a separately attributed component inside a proprietary product as long as its notice condition is honored. That does not eliminate every legal risk. The text has no express patent grant, trademark rights do not automatically follow from a copyright license, and a contributor cannot grant rights they do not own in third-party code.

Apache 2.0 states more of the arrangement explicitly

Apache License 2.0 is sometimes described as a longer or “corporate” MIT license, but that shorthand hides its origin. The Apache Software Foundation spent several years revising its own license to address contributions, documentation, notices, and patent risk more clearly. The ASF board approved version 2.0 on January 21, 2004.

The full Apache 2.0 text grants copyright and patent rights in separate sections. The copyright license permits reproduction, modification, and distribution. The patent grant covers only claims a contributor can license that would necessarily be infringed by the contribution alone or in combination with the work to which it was submitted. It is neither a guarantee against every patent claim nor a transfer of every patent the contributor owns.

Its patent-termination provision is narrower than many summaries suggest. If a recipient initiates patent litigation alleging that the work or an incorporated contribution infringes a patent, the Apache patent licenses granted to that recipient for the work terminate. The text does not say that any patent suit on any subject automatically cancels the copyright license.

An Apache distribution must include the license, mark modified files, and preserve relevant copyright, patent, trademark, and attribution notices. If the original work includes a NOTICE file, its applicable attributions must be reproduced in one of the permitted locations. Apache 2.0 nevertheless remains permissive: distributing a derivative does not by itself require the distributor's own modifications to be published as source.

Unlicense uses a different legal construction

Unlicense attempts to step away from downstream copyright conditions by dedicating a work to the public domain as fully as possible. Its official text combines that intention with broad permission to use the software and a warranty disclaimer. The Unlicense is approved by the Open Source Initiative, which currently classifies it as a special-purpose license.

Public domain status and a license are not the same legal concept. Whether an author can fully waive copyright, and what that waiver accomplishes, varies by jurisdiction, which is why the Unlicense text describes its dedication in terms of jurisdictions that recognize copyright laws. It also lacks the express patent grant found in Apache 2.0. A project seeking an internationally predictable public-domain-style instrument should compare Unlicense with CC0-1.0 and its organization's policy rather than treating the two texts as interchangeable.

Comparing obligations without philosophical labels

This table describes typical cases; it does not decide whether a specific architecture forms one derivative or combined work. Dynamic loading, IPC, plugins, generated code, and components distributed by different parties require analysis of the actual relationship. A slogan such as “any link infects the project” cannot perform that analysis.

Compatibility always has a direction

Two licenses are compatible when code can be combined and conveyed while satisfying both sets of conditions. This does not mean that an original file changes its license, and it does not make compatibility symmetric. MIT code can join a GPLv3 program when its MIT notice remains and the covered combination is distributed under GPLv3. The reverse direction does not permit GPLv3 conditions to be stripped and the resulting code declared MIT.

The version matters too. Apache 2.0 is compatible with GPLv3 in the sense that Apache code can become part of a work conveyed under GPLv3. The FSF separately considers Apache 2.0 incompatible with GPLv2-only because of Apache's additional patent terms. Code marked GPL-2.0-or-later may have a path to GPLv3 that GPL-2.0-only code does not. The GNU compatibility FAQ also points out that installing two independent programs on the same system does not combine them into one larger work.

License selection should therefore begin with the distribution model rather than popularity. A project needs to decide whether recipients of closed builds should receive source, whether the product is only offered as a network service, which licenses already govern dependencies, whether an express patent grant matters, and which notice procedures the release process can reliably maintain. When no standard license seems to fit, inventing a custom one usually creates more compatibility uncertainty than it resolves.

What License Builder actually does

License & Readme Builder combines three independent functions. Its Compatibility Checker compares a source license with a target license across 11 common identifiers and returns Compatible, Conditional, or Incompatible with a short reason. A separate questionnaire maps preferences to one of four licenses for which the tool stores full text: MIT, Apache-2.0, GPLv3, and Unlicense. After a manual selection, the generator substitutes the copyright holder and year where the template provides those fields, then builds a README from a project title, description, installation command, usage example, and license badge.

The recommendation algorithm is intentionally coarse. A copyleft or network-source preference points to GPLv3, while the interface warns that ordinary GPLv3 does not contain the AGPL network clause. A request for an express patent grant points to Apache-2.0, and the remaining cases recommend MIT; Unlicense is available only through manual selection. All four choices permit commercial use, so this set cannot implement a noncommercial restriction, which would not meet the OSI definition of open source anyway. In the current implementation, the commercial-use and liability-protection checkboxes do not alter the recommendation formula; they only describe requested features, another reason not to treat the result as a complete licensing decision.

The Compatibility Checker is a reference aid rather than a legal conclusion. A Conditional result means that the answer depends on a version suffix, linking method, or another fact the short matrix cannot establish. Its combined display label Unlicense / CC0-1.0 is also a shortcut rather than a statement that the instruments are identical. For an actual release, verify the dependency's exact SPDX identifier, its -only or -or-later suffix, the full license text, and every required notice.

All input and generation stay in the browser. LICENSE and README can be copied together or downloaded separately, but the tool does not audit contribution ownership, project dependencies, CLAs, trademarks, or patent portfolios. Those remain part of the licensing process outside the generator.

Related tools

License & Readme BuilderAnswer a short questionnaire to pick an open-source license, then generate the full license text and a README template with a badge — all in the browser.Markdown EditorWrite Markdown with a side-by-side live preview, a formatting toolbar and shortcuts, word count, and export to .md or .html — all in the browser.JSON ToolboxValidate syntax, format or minify payloads, and browse nested API responses and configuration files as a collapsible tree.Key Pair GeneratorGenerate Ed25519 or RSA (2048/4096) key pairs with the Web Crypto API — OpenSSH public key, PEM private key, SHA256 fingerprint, and downloadable files, all client-side.