Picking a license for your project? The gpl vs mit license choice comes down to one question: must others share their changes? MIT lets people do almost anything; GPL requires derived works to stay open.
This page belongs to the wider guide toopen source software.
| Item | Value |
|---|---|
| MIT SPDX short identifier | MIT |
| MIT warranty | Provided “AS IS”, without warranty of any kind |
| GPL version covered here | Version 3, dated 29 June 2007 |
| GPL license type | Free, copyleft license |
| GPL rule for conveyed derivatives | Entire work licensed as a whole under the GPL |
| GPL rule for aggregates | Inclusion in an aggregate does not extend the license to other parts |
These figures come from the Open Source Initiative’s MIT page and the GNU Project’s GPL text. Licence texts and pages can change, so check the source before you rely on them.
The short version: permissive versus copyleft
The MIT License is a permissive license. It grants permission, in its own words, “free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction”. Anyone can use, copy and modify the code, including inside closed-source products.
The GNU General Public License describes itself as “a free, copyleft license for software and other kinds of works”. Copyleft means the rights you get come with a condition: what you pass on must keep the same freedoms.
In practice:
- MIT asks very little of people who reuse your code.
- GPL asks reusers to share source when they distribute a derived program.
- Both let users run the software for any purpose.
What the MIT License actually requires
MIT is short. The text carries a copyright line, a permission grant and a disclaimer. The OSI lists its SPDX short identifier as MIT, which is the tag you will see in package metadata.
The disclaimer states that the software is provided “AS IS”, without warranty of any kind. It also says the authors are not liable for claims or damages arising from the software. That protects the author, and it also tells users that nobody is promising the code works.
A company can take MIT code, modify it, and sell the result without publishing its changes. That is the main attraction for developers who want the widest adoption. It is also the main drawback if you want improvements to flow back to you.
What the GPL requires when you share code
The GPL has strong conditions once you convey a work. Version 3 of the license says that a modified work must carry prominent notices stating that you modified it, and that the work must be released under the license.
The central rule is that “You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy.” If you build a derivative and distribute it, recipients get the GPL too.
Distributors must also supply the “Corresponding Source”: all the source code needed to generate, install, and run the object code and to modify the work. That includes build scripts and, in some cases, specially required shared libraries.
The GPL also addresses patents. The license states that it “assures that patents cannot be used to render the program non-free.”
How the two licenses differ side by side
| Question | MIT | GPL v3 |
|---|---|---|
| Can it go into a closed-source product? | Yes | Not if the product is a derivative you distribute |
| Must you share your changes? | No | Yes, when you convey the work |
| Source code with binaries? | Not required by the license | Corresponding Source required |
| Length and complexity | Very short | Long, detailed |
| Patent language | None in the text | Explicit patent provisions |
The comparison draws on the MIT text at the OSI and the GPL text from the GNU Project; licence pages can change, so check the source before you rely on it.
The table reduces a long legal text to a few lines, so treat it as a map and not as the license itself. Read the full text of whichever license you adopt, because small details such as notice wording and distribution duties matter in real projects.
A related point is what counts as “derived”. The GPL says including a covered work in an aggregate “does not cause this License to apply to the other parts of the aggregate.” An aggregate means separate, independent works shipped together, not parts combined into one larger program.
Where the line sits for a given piece of software can be a legal question. If your product depends on it, ask a qualified lawyer rather than rely on a summary.
Which license should you choose?
Match the license to your goal. Neither is better in general.
- Choose MIT if you want maximum reuse, a library that companies will adopt freely, or simple terms with few questions.
- Choose GPL if you want every public derivative to stay open, so a competitor cannot close your work.
- Consider a third option if you want permissive terms plus explicit patent wording; the apache 2.0 license explained page covers that route.
If you are using code instead of publishing it, read the license that comes with each dependency. A broader comparison is in our overview of open source software licenses.
Common situations and how each license plays out
Think about who will touch your code. A small utility library that you hope every team will adopt tends to suit MIT, because nobody has to ask a legal department whether they can pull it in.
An application that you want to stay community-owned tends to suit the GPL. If a company ships a modified build, the license requires it to hand the same freedoms and the source to its own users.
Contributors matter too. People who contribute to a GPL project know their work will not be locked away in a proprietary fork that distributes without source. People who contribute to an MIT project accept that others may do exactly that.
If you only run the software internally and never convey copies to anyone, the GPL’s sharing duties are generally triggered by distribution, not by private use. The GPL text frames its conditions around conveying a work, so the distinction between using and distributing is worth keeping in mind.
Finally, remember that you can only license what you own. If your project already includes code from others, their licenses constrain what you can choose for the combined work.
Practical tips before you commit
- Put the full license text in a LICENSE file at the root of your repository.
- Add the copyright holder and year to the notice line.
- Record the SPDX identifier in your package metadata.
- List the licenses of your dependencies and check they are compatible.
- Do not edit the GPL text itself; the license says changing it is not allowed.
Frequently asked questions
Can I use MIT code in a commercial product?
Yes. The MIT License grants permission to deal in the software without restriction, so commercial use is allowed. Keep the license notice and accept that there is no warranty.
Does the GPL forbid selling software?
No. The GPL is about the freedoms and source you pass on, not about price. If you distribute a derived work, you must license it as a whole under the GPL and provide the Corresponding Source.
Can GPL software sit alongside other programs?
Yes, as an aggregate of separate, independent works. The GPL says this does not cause the license to apply to the other parts.
Can I change the GPL text to suit my project?
No. The GNU text says everyone may copy and distribute verbatim copies of the license document, but changing it is not allowed.
