Open Source Licenses Explained: MIT vs Apache vs GPL ​

Written in September 2026. License terms change between versions, so everything below reflects the situation at that time. Always check the project's current LICENSE text before making a commercial decision.

Every AI app you install from LM Downloader ships with a LICENSE file. Most of the time you never need to read it. But the moment you want to modify some code, pull a feature into your own product, or run something as a paid service, that file becomes very important indeed.

Let's clear up three common misconceptions first:

• "Open source means free to use however I like" — no. Open source means the source is public. Most open source licenses come with conditions; they only differ in how heavy those conditions are.
• "Open source means I can sell it closed-source" — depends entirely on which license. MIT yes; GPL requires you to hand over source code when you distribute.
• "Nobody enforces code on GitHub" — this one is wrongest of all. A repository with no LICENSE file defaults to all rights reserved. Copying even one line of its code is infringement. No license ≠ no copyright. It's the opposite.

1. Locate any license with five questions ​

There are far too many licenses to memorize, but they all really just answer a handful of questions. Take any license and ask these five:

The answers to questions 2 and 3 split open source licenses into two camps:

• Permissive — MIT, BSD, Apache-2.0, ISC. These barely ask questions 2 and 3: modify however you like, stay closed-source, sell it, as long as you keep the original copyright notice in place.
• Copyleft — GPL, AGPL, LGPL, MPL. Their whole point is one idea: you received freedom, so you must pass the same freedom on. Once you distribute, the parts involved must be open source under the same license.

How does "viral" actually trigger? The key word is distribute. Copyleft obligations fire when you give the program to someone else — distribution, publication, shipping it in a product. Running it only on your own machine, using it only inside your company, even deploying it as a network service you operate yourself (note: GPL, not AGPL) is not distribution, so nothing triggers. This is the single most commonly unknown rule.

2. Permissive licenses: lowest risk, prefer these ​

MIT ​

Under 200 words long. You may freely use, copy, modify, merge, publish, distribute, sublicense, and sell copies — the only obligation is to keep the original copyright notice and this permission text in all copies or substantial portions of the software.

• Caveat: MIT contains no explicit patent grant. If the author or a contributor holds a patent on the technique inside, a claim is theoretically still possible. Irrelevant for casual users; worth knowing if you're building a product.

BSD-2-Clause / BSD-3-Clause ​

BSD-2 is essentially equivalent to MIT. BSD-3 adds an anti-endorsement clause: without prior written permission, you may not use the names of the original authors or their institution to promote or imply endorsement of your derived product.

• Practical impact: you can't put "powered by the XXX team" on your product page to borrow credibility, unless you have permission.

Apache-2.0 ​

Extremely common in local AI projects (including audio.cpp). On top of what MIT gives you, it does two extra things right — which is exactly why it's the better choice:

1. An explicit patent grant. Every contributor automatically grants you the relevant patent licenses, and there's a defensive clause: if you file a patent claim about this work against anyone, your patent license terminates. This makes Apache-2.0 considerably safer than MIT for large, patent-heavy projects.
2. The NOTICE file obligation. If the original project ships a NOTICE file, you must preserve the attribution statements it contains when you distribute. This is not optional; dropping it is one of the most common compliance failures.

Apache-2.0 also explicitly requires you to mark the changes you made.

Compatibility landmine: GPL-2.0 (except "or later") is incompatible with Apache-2.0. You cannot merge Apache-2.0 code into a GPLv2 project and distribute the result. GPLv3 has no such problem.

ISC / CC0 / The Unlicense ​

• ISC: functionally equivalent to MIT, more tersely worded, common in European projects.
• CC0 / Unlicense: copyright is waived outright, the work enters the public domain, not even attribution is required.
• But note: waiving copyright does not waive patent rights, and it doesn't affect models, datasets, or trademarks bundled in the repo. "CC0 code" can still carry restrictions through its dependencies or bundled resources.

3. Copyleft: where the boundaries actually are (the highest-risk section) ​

This is the most technical part of the article, and also where closed-source integration accidents cluster.

GPL-2.0 / GPL-3.0 ​

The rule: if you distribute this program, or anything derived from it (even just one executable), you must provide complete corresponding source code to recipients and license the whole work under GPL. You may charge money. You may not stay closed.

Where GPLv2 and GPLv3 actually differ for you — three points:

• GPLv3 has an explicit patent grant; v2 doesn't.
• GPLv3 has anti-Tivoization clauses: embedded in consumer hardware, you must let users reflash modified firmware (TiVo used this to block Android back then). Ignore this for pure software.
• Compatibility: as noted, v2 is incompatible with Apache-2.0; v3 is compatible.

Example: you link a GPL-3.0 library into your desktop audio tool and let users download the tool. Now your entire program falls under GPL-3.0, and you must publish complete, compilable source. But if you only run it on your own machine, or deploy it on your company intranet for colleagues — no distribution, no obligation.

AGPL-3.0: closing the "network service" loophole ​

GPL's obligations hinge on distribution, so someone found the perfect workaround: I don't distribute anything, I just run it on a server and expose it as a service. AGPL exists specifically to close that road.

AGPL section 13: when users interact with the program over a network, that counts as fulfilling your source obligation — you must give them a prominent way to obtain the corresponding source.

Strictly speaking this applies to your modified version, so running a stock AGPL program may not trigger it on a literal reading. But in practice you will almost certainly trigger it: as soon as you link or integrate AGPL code into your project, your project is the "modified program," and once it faces users over a network you must hand over the project's entire corresponding source.

Example: an AI project's WebUI is AGPL-3.0. You adapt it into your own paid online dubbing platform. You distribute zero binaries. Under GPL this is safe. Under AGPL you must offer every user the complete source of your modified version.

So: if you're running a public service and you see AGPL, stop and read it.

LGPL: the "middle state" you'll actually meet in local AI tooling ​

LGPL exists precisely so that proprietary software can use a library. Everything depends on how you use it:

• Dynamic linking (.dll / .so, loaded at runtime) → your main program may stay closed-source, provided you: ship the LGPL text, state that you use the library, guarantee users can replace the library (so you cannot statically bundle it), and open-source the library itself if you modified it.
• Static linking (compiled into your executable), or copying its source files into your project → your program becomes a derivative work, and you must provide complete, compilable source. The LGPL's protection disappears.

Example: you ship a closed-source TTS desktop app that loads an LGPL audio decoding library at runtime → legitimate, closed source is fine, as long as you didn't modify the library and a user could drop in their own rebuilt .dll of the same version and your app still works. But if you copy that library's .c files into your project because it's convenient → sorry, the whole program now needs LGPL source.

This is why dynamic vs static linking deserves its own paragraph: it is the direct cause of many closed-source product mistakes.

MPL 2.0: file-level weak copyleft ​

MPL is a compromise between GPL and permissive, and considerably friendlier to commercial use:

• It only spreads to the specific files you modified, and only under MPL — not to the whole work the way GPL does.
• New, separate files may stay closed-source, and MPL files may exist as components of a larger work.
• The obligation is simply: tell people where to get the source of those MPL files.

One-line rule of thumb: GPL says "touch me, open everything". MPL says "open the files you changed, nothing else".

4. These look open source but aren't (the section most relevant to this project) ​

A large share of AI projects don't use standard open source licenses at all. This is where the blind spots concentrate.

Community Licenses ​

Stability AI, bilibili, FunASR, MiniMax and others each have their own. Typical clause combination:

• Free commercial use allowed, but with an annual revenue cap (US$1M is a common threshold) — above it you must buy a commercial license;
• Registration on the official site is required for the license to be valid;
• Attribution or notice requirements;
• Reselling or redistributing the model weights themselves is prohibited;
• You may not use them to train competing foundation models.

These must be read line by line by a human. You cannot infer them from an SPDX tag — which is exactly why the model-licensing document puts every one of them under "⚠️ Conditional commercial use" rather than "✅".

Research / Non-Commercial Licenses ​

The CC BY-NC family and each vendor's *-research-license. Use is restricted to research and non-commercial purposes; commercial use is flatly prohibited. There is no revenue cap to negotiate.

Dual Licensing ​

The same code under two licenses: a GPL version (free, but forces you open) plus a commercial version (paid, may stay closed). Qt, MySQL and iText are the archetypes.

• How to spot it: if the project says "licensed under GPL, contact XX for commercial licensing", then staying closed-source costs money. There is no third path.

Source-available: not open source ​

BSL (Business Source License), Elastic License, SSPL. They publish source, but OSI explicitly does not recognize them as open source licenses.

• BSL: restricts commercial use, and typically converts automatically to MPL or another open source license after several years (Terraform: 4 years). Check the restrictions on your current version and the change date before buying.
• SSPL (introduced by MongoDB): if you provide the database as a service, you must open-source the entire service stack — monitoring, orchestration, backup, logging, all of it. Commercially ruinous, and effectively a deterrent aimed at cloud vendors.

5. In practice: judging a project's license in 30 seconds ​

1. Look in this order: root LICENSE / COPYING / LICENSE.txt → the License section of the README → header comments in source files → the license field in pyproject.toml / package.json.
2. When they conflict, the LICENSE file body wins. The License badge in GitHub's sidebar is only automatic detection and gets things wrong. Real example: the LICENSE bodies of audio.cpp and audio.cpp-webui are both complete, standard Apache-2.0, yet GitHub reports them as NOASSERTION ("other/unrecognized"). Don't panic at NOASSERTION — read the file itself.
3. Trust SPDX identifiers, not names. Write Apache-2.0, GPL-3.0-only, MIT, not "the Apache license", to avoid version ambiguity.
4. The stacking principle: the strictest one governs. The compliance boundary of a distributable product is set by the strictest license in its dependency tree — not by the main project's license. Application code, dependency libraries, model weights, training data, fonts, icons each have their own license and each must be checked.
5. Three things people miss:
   • Translations have no legal force. A Chinese translation is for reference only; the English original governs (most licenses say so explicitly).
   • Trademarks are not part of the grant. An open source license gives you code. It does not give you the right to use the project's name or logo. You cannot publish your modified version under the original name.
   • Versions change. Projects switching licenses between versions is routine (both Redis and Elastic have done it). Use the version you actually depend on as your reference.

6. Conclusions by role ​

7. Don't forget: software license ≠ model license ​

This distinction is the single thing you should take away from the article, and it's the premise of the audio.cpp document:

• The software you installed is Apache-2.0, meaning the code is yours to modify and commercialize freely.
• But the model weights the software loads follow their own licenses, which may say "commercial use prohibited".
• The two layers stack and you take the intersection — your use is permitted only if both sides allow it.
• And quantization, format conversion, LoRA, and fine-tuning all produce derivative works, so the original model license keeps applying. "I'm not using the official original" is not a way around the license.

Model-by-model classification is here 👉 audio.cpp Model Licenses and Commercial Use

Appendix A: License quick-reference table ​

Appendix B: One-line verdicts ​

Disclaimer: this article is our compilation of publicly available information. It is not legal advice, and we do not guarantee that every description remains accurate under current versions. For any decision with real commercial stakes, consult a qualified professional and always defer to the project's current LICENSE text.