AI & Open-Source Software Licenses Explained: MIT vs Apache vs GPL vs AGPL vs Proprietary

Quick Facts

• MIT is the shortest and most common permissive license — roughly 170 words, no patent clause.
• Apache-2.0 adds an explicit patent grant that MIT does not have, which is why many companies prefer it for corporate-authored projects.
• GPL requires source disclosure only when you distribute the software; AGPL-3.0 extends that requirement to running it as a network service.
• OSI-approved "open source" is a specific certification from the Open Source Initiative; "source-available" and "fair-code" are marketing terms for licenses that do not meet that definition.
• AI model licenses are a separate category from code licenses. A tool's code can be Apache-2.0 while the model weights it downloads carry entirely different, more restrictive terms.

What Are Permissive Licenses? MIT, Apache-2.0, and BSD

• MIT License originated at the Massachusetts Institute of Technology as a way to release university-authored software with minimal restriction. It is roughly 170 words, grants near-unlimited rights, and asks only that the original copyright and license text stay attached to any copy or substantial portion you redistribute.
• Apache License 2.0 comes from the Apache Software Foundation, formed to give corporate and community contributors a shared legal framework for large collaborative projects. Unlike MIT, it includes an explicit patent grant — contributors license their patent claims covering the code to users — which is why many companies with patent portfolios prefer it.
• BSD licenses (2-clause and 3-clause) originated at the University of California, Berkeley, for the Berkeley Software Distribution operating system. The 3-clause variant adds a non-endorsement clause preventing you from using the original authors' names to promote a derived product without permission.
• Practical effect for adopters: you can fork, modify, embed, and sell a permissively licensed tool as part of a closed product and never release your own source code — the only real risk is dropping the required copyright/license notice from your distribution.
• Real examples from this site's reviews: Ollama and llama.cpp both ship under MIT; vLLM ships under Apache-2.0 — all three can be embedded in a commercial product without triggering any source-disclosure obligation.

What Is Copyleft? The GPL and LGPL Family

• The GNU General Public License (GPL) was written by Richard Stallman and the Free Software Foundation as the license for the GNU Project, built on the idea that software freedom should be preserved forward — anyone who receives a modified copy should have the same rights the original author had.
• GPL v2 and GPL v3 differ mainly in patent language and compatibility provisions; v3 added explicit patent-retaliation and anti-tivoization clauses (preventing hardware that blocks you from running modified software you are legally entitled to run).
• The GNU Lesser General Public License (LGPL) relaxes GPL for libraries specifically — you can link an LGPL library into a proprietary application without open-sourcing the application itself, as long as the library component stays swappable and its own source stays available.
• What actually triggers the obligation: distributing a modified copy of the GPL-covered code. Merely using unmodified GPL software internally, or running proprietary software on a GPL-licensed operating system, does not by itself pull your own code under GPL.
• Who should be cautious: a startup planning to fork and modify a GPL tool as the core of a commercial product needs a plan for either open-sourcing those modifications or avoiding the fork; a company merely running an unmodified GPL tool internally faces no such obligation.

How AGPL-3.0 Closes the SaaS Loophole

• The gap it closes: under plain GPL, running a modified version of the software as a hosted web service is not "distribution" in the legal sense the license triggers — a company could take GPL code, modify it, offer it only as a SaaS product, and never have to release the modifications. This became known informally as the "ASP loophole" (application service provider) or "SaaS loophole."
• AGPL-3.0 was written specifically to close that gap by adding a network-interaction clause: offering the modified software's functionality to users over a network counts as triggering the same source-availability obligation that distributing a physical copy would.
• Why it matters for hosting and reselling: an agency or hosting provider that takes an AGPL-licensed tool, modifies it, and offers it to clients as a hosted service must make the modified source available to those users — running it unmodified carries no such obligation.
• Real examples from this site's reviews: Jan, KoboldCpp, SillyTavern, and text-generation-webui ship under AGPL-3.0 — fine to self-host unmodified for personal or internal use; a materially different question the moment you modify one and resell hosted access to it.
• This is general information about how the license mechanism works, not legal advice — whether a specific deployment counts as "offering it over a network" under AGPL-3.0's exact wording is a question for counsel reviewing your specific architecture.

What Are Source-Available and "Fair-Code" Licenses?

• The Business Source License (BSL, also called BUSL) grants source access and broad usage rights up front, with a defined future date at which the license converts to a genuinely open-source license (often Apache-2.0 or a similar permissive license) — until that conversion, a stated commercial-use restriction applies, typically aimed at preventing a competing hosted offering.
• The Server Side Public License (SSPL), created by MongoDB, requires that anyone offering the software as a service must also open-source the entire service stack they built around it — a far broader obligation than AGPL-3.0's, deliberately written to make commercial hosting impractical for a rival cloud provider.
• The Commons Clause is an add-on restriction layered on top of an otherwise permissive or copyleft base license, specifically prohibiting selling the software or offering it as a paid hosted service, while still allowing free use and modification.
• Why projects move to these licenses: a project that starts under a fully open license and later adopts a source-available one is typically responding to a large cloud provider offering the project as a hosted service without contributing back — moving to a source-available license lets the maintainer keep most of the openness while blocking that specific competing use.
• Practical effect for adopters: you can usually read, self-host, and modify source-available software for internal use without issue; the restriction bites when you try to resell it as a hosted product competing with the license holder's own offering — read the specific commercial-use clause, since wording varies significantly between projects.

What Do Proprietary and Freemium "Free" Licenses Mean?

• "Free (closed)" on a comparison table means no-cost proprietary software. You may use the compiled application under the vendor's terms of service, but you have no access to the source code and no right to modify, audit, or fork it.
• The core trade-off versus open-source alternatives: a proprietary free app is often more polished and easier to install, since a single vendor controls the whole user experience — but you depend entirely on that vendor's continued willingness to keep it free, secure, and maintained.
• Vendor lock-in risk: without source access, you cannot self-host a modified version, audit exactly what the application does with your data, or continue development if the vendor stops maintaining it, changes the pricing model, or shuts down.
• Who should care most: anyone building a workflow or business process around a proprietary free tool should have a documented fallback plan — the same due diligence you would apply to any vendor dependency, since "free" does not mean "permanent" or "guaranteed."
• Not the same as source-available: source-available licenses (BSL, SSPL) at least let you read and audit the code even if commercial use is restricted; a fully proprietary tool gives you neither the code nor those assurances.

How Do AI Model Licenses Work? Open Weights, RAIL, and Acceptable-Use Restrictions

• Fully permissive weights: some model families release weights under a standard permissive software license (commonly Apache-2.0), granting the same broad usage rights that license gives to code, including commercial use with no field-of-use restriction.
• RAIL and OpenRAIL licenses (Responsible AI License) originated with BigScience's release of the BLOOM model and were designed jointly with legal researchers to pair open access with a specific list of prohibited uses — commonly barring uses like generating disinformation, discriminatory decision-making, or content that violates law, while otherwise permitting broad commercial use.
• Custom "community" or "open-weight" licenses: several major model providers release weights under a bespoke license that reads like an open license but adds field-of-use conditions. The most widely cited example is the community license Meta attaches to its openly released model weights, which grants broad free use but adds a usage-scale threshold above which a separate commercial agreement is required, along with acceptable-use restrictions.
• What to check specifically: whether commercial use is permitted at all, whether there is a usage-scale or revenue threshold that changes the terms, what the acceptable-use policy prohibits, and whether the license restricts using the model's outputs to train a competing model — a restriction that has appeared in several model-specific licenses and has no equivalent in standard software licenses.
• This is not legal advice — model license terms change between releases from the same provider, so verify the exact license text attached to the specific model weights you plan to deploy rather than assuming continuity with an earlier release from the same organization.

Who Should Care About Which License?

Pre-Adoption License Checklist: 7 Things to Verify Before You Deploy a Tool

1. 1
   Read the actual LICENSE file in the repository
   Why it matters: A landing page's "open source" claim can be marketing, not a legal fact — the LICENSE (or NOTICE/COPYING) file in the source repository is the authoritative document, not a badge or pricing page.
2. 2
   Check whether the license has changed since the project started
   Why it matters: Some projects relicense from a permissive or copyleft license to a source-available one after gaining commercial traction — this pattern has recurred across the software industry as cloud providers began hosting popular open-source projects without contributing back. Check the repository's license history, not just the license file as it reads today.
3. 3
   Verify the license is actually OSI-approved if that matters to you
   Why it matters: Source-available licenses like BSL and SSPL are commonly marketed as open source but are not on the Open Source Initiative's approved list — if OSI approval is a requirement for your use case, check the list directly rather than trusting a project's own description.
4. 4
   Read the commercial-use and field-of-use clauses for AI models specifically
   Why it matters: A model's license can permit commercial use broadly, restrict it above a usage-scale threshold, or prohibit specific applications outright — these clauses sit outside standard software-license language and are easy to miss if you only check the code license.
5. 5
   Determine whether self-hosting vs SaaS-hosting changes your obligations
   Why it matters: Under AGPL-3.0, offering modified software over a network triggers the same disclosure obligation that distributing a copy does under GPL — confirm which category your planned deployment falls into before you modify the code.
6. 6
   Check for a contributor license agreement (CLA) if you plan to contribute back
   Why it matters: A CLA can grant the project maintainer broader rights over your contribution than the project's own license grants to users — relevant mainly if you intend to submit code back to the project, not if you are only consuming it.
7. 7
   Check trademark restrictions separately from the code license
   Why it matters: A permissive or copyleft code license does not automatically grant rights to the project's name or logo — forking and rebranding a tool can be blocked by trademark law even when the code license would otherwise allow the fork.

Common Mistakes

• Trusting a marketing page's "open source" claim instead of reading the actual LICENSE file in the repository.
• Assuming AGPL-3.0 only matters if you distribute a copy of the software — it also applies to offering modified code as a hosted service.
• Treating a model's code license and its weights license as the same document — they frequently are not.
• Forking and rebranding a tool without checking trademark restrictions separate from the code license.
• Assuming a license that was permissive when a project started still applies after a later relicensing — check the license actually shown in the repository, not the one you remember.
• Skipping legal review for a copyleft or source-available tool because "it is free" — free-to-use and free-of-obligation are not the same thing.

Sources

• Open Source Initiative — The Open Source Definition — the formal definition a license must meet to be certified OSI-approved open source.
• GNU Project — Free Software Licenses — the Free Software Foundation's own explanations of GPL, LGPL, and AGPL.
• Apache Software Foundation — Apache License 2.0 — full license text.
• MIT License text (Open Source Initiative) — full license text.
• MongoDB — Server Side Public License — SSPL's own terms and rationale.
• Business Source License FAQ — an explanation of how BSL/BUSL conversion works from a widely cited adopter of the license.

Frequently Asked Questions

Related Reading

• The Complete Local LLM Software Directory — 160+ local LLM tools with the license listed for each entry.
• Dify AI Workflow Builder Review — a platform review that names its license; use this guide to understand what that license means for your deployment.
• AI-Generated Content and IP Risk — the intellectual-property questions that sit alongside licensing when you deploy AI-generated output commercially.
• Agentic AI Security: Identity & Access — security and governance considerations for self-hosted AI deployments, a companion concern to license compliance.
• GDPR-Compliant Local RAG for Sensitive Documents — license risk and data-residency/compliance risk are separate checklists; this guide covers the compliance side.