What this page is, and what it is not
It is a table with a filter on it. It sets out what a small number of widely used open source licenses are generally understood to permit and require, and it ranks them against four questions about what you want. That is genuinely useful for narrowing a field of a dozen down to three worth reading.
It is not legal advice, and the distinction is not a formality. Legal advice takes account of who owns the code, what your employment agreement says, what patents exist in the area, which jurisdictions matter, what your dependencies already oblige you to do, and what you actually intend to do with the project commercially. None of that is knowable from four dropdowns. If any of it applies — and for anything commercial, employer-related, or patent-adjacent, it does — the shortlist here is a starting point for a conversation with a lawyer, not a substitute for one.
The axis that matters most: how far the obligation reaches
Every open source license permits use, modification and redistribution. What separates them is what a person who distributes a modified version has to give back, and how much of their work that obligation touches. It is a spectrum, not a binary:
| Reach | What a distributor generally has to do |
|---|---|
| None | Keep the notice. Changes may stay closed |
| Per file | Publish changes to the licensed files; the rest of the program is unaffected |
| Per component | Publish changes to the component, and let users substitute their own build of it |
| Whole program | Publish the corresponding source of the program being distributed |
| Whole program, network included | The same, extended to users who only interact with it over a network |
Read that column downwards and you can see what each step is buying. The middle two exist because the ends were too blunt: a per-file obligation keeps contributions to a library open without touching the application around it, and a per-component obligation adds the user right to swap in their own build. The last row exists because ordinary copyleft never triggers for hosted software — nothing is distributed, so nothing is owed — which is a gap some authors want closed and many companies decline to accept.
The axis people notice too late: patents
Copyright and patents are separate rights, and a license that grants one does not automatically grant the other in any express way. The shortest permissive licenses were written before this was a live concern and say nothing about patents at all. Later licenses added an express grant from contributors, usually paired with a termination clause: sue a contributor over patents in the software and your own grant ends.
Whether that matters depends entirely on the field you are in and on who your users are. In some areas it is the first thing a reviewer looks for; in others it never comes up. What is worth knowing is that it is a real difference between two licenses that otherwise look interchangeable, and that it is the reason a corporate legal review will sometimes ask for one permissive license rather than another that appears equivalent.
Combining licenses is where it gets complicated
A project is rarely one license. It has dependencies, it has contributed patches, it may have code copied from somewhere with terms nobody recorded. Those terms travel with the code and interact with whatever you choose. Some combinations are routine, some are contested, some are widely understood to be problems — and which is which depends on how the pieces are combined, in what jurisdiction, and for what kind of distribution.
This page deliberately does not draw that conclusion, and no table should. What it can usefully tell you is that the question exists, that it is worth asking before the code ships rather than after, and that the answer depends on facts about your project rather than on the license names alone.
Applying whatever you pick
Three mechanical things go wrong often enough to be worth stating. The text goes in a LICENSE file at the repository root, unmodified — editing a license produces a license nobody recognises and everyone has to read in full. The choice is declared in the project metadata as well, because that is what dependency tooling reads. And the header convention, if the license suggests one, is applied consistently rather than to the three files someone remembered. While you are setting the repository up, the gitignore builder covers what should not be committed, the table of contents generator handles a long README, and the changelog formatter and semantic version comparator cover the release side.
Questions people ask
Can this tell me whether two licenses are compatible?
No, and it deliberately does not try. Compatibility is a legal conclusion about specific facts — how the code is combined, what is distributed to whom, which jurisdiction applies, what the exact versions of each license say. A tool that returns yes or no to that question is giving you a guess dressed as an answer. What this page does is show you where the obligations differ, which is the information you need in order to ask the question properly.
Which license is the safest choice?
That framing does not have an answer, because the risks run in different directions. A permissive license makes adoption easy and gives you no claim on what others do with it. A strong copyleft license keeps derivatives open and rules your project out for a large set of potential users. Neither is a risk-free position; they are different tradeoffs. The productive question is what you want to happen when someone builds on this, and the table above is organised around that.
What about hosted software that is never distributed?
That is precisely the gap the network-copyleft option addresses. Traditional copyleft obligations are triggered by distributing a copy, and a service running on servers you do not control distributes nothing, so a modified version can stay private indefinitely. The network variant extends the obligation to users interacting over a network. It is the right tool for that specific concern, and it is also the license family most often refused by corporate policy, so the choice has a cost on the adoption side.
Does adding a license file protect me from liability?
Standard open source licenses include warranty disclaimers and limitation-of-liability language, and that is one of the reasons publishing code without any license is a poor idea. Whether those clauses are effective, and against what, is a question about contract and consumer law in a particular place. It is exactly the kind of question to put to a lawyer rather than to a table. Nothing here should be read as a statement about your exposure.
Why is the license text not shown?
Because a license only functions as the exact text published by the steward, and reproducing it here would invite someone to copy a version that had been reflowed, truncated or subtly altered. Pick from the comparison, then take the canonical text from the organisation that publishes it and put it in your repository unmodified. That is also the version any reviewer will compare yours against.
Are my answers recorded?
No. The comparison table is a constant inside the page and the ranking runs in JavaScript in this tab. Nothing is sent anywhere and nothing is stored, so the questions you answered about an unannounced project stay on your machine.