An “open source” AI model is not automatically free to put in a commercial product. The license on the code, the license on the weights and the terms on the training data can all differ. Some are permissive. Some carry

source-disclosure duties. Some are custom contracts that only look open. Before you build on any model, read each layer separately and write down what you find.

This guide shows how software licenses and AI model terms differ. It lists what MIT, Apache 2.0 and GPL ask of you, which clauses in open-weight licenses cause trouble, and how to review every component in an AI product.

TL;DR

  • “Open source” for AI can mean code, weights, data or all three. Each can carry its own license, so check them one by one.
  • MIT, Apache 2.0, GPL, LGPL, MPL and AGPL all allow commercial use. What differs is what you owe in return: notices, stated changes, source disclosure or same-license distribution.
  • Many models called “open” are really open-weight, released under custom terms with usage limits, attribution rules or bans on training competing models.
  • Training-data and output rights are a separate question from the model license. Review them on their own.
  • Keep a running inventory of every model, dependency and dataset in the product. It turns a legal worry into a routine check.

Table of Contents

What “open source AI license” actually means

In traditional software, the picture is simple. You have source code and a license that says what you may do with it. AI breaks that into several pieces.

The Open Source Initiative published its Open Source AI Definition 1.0. It says an open-source AI system must give users the freedom to use, study, modify and share it for any purpose, without asking permission. It also treats the “preferred form” for making changes as more than code. That form includes information about the data, the complete training and inference code, and the model parameters, such as weights.

Most releases do not meet that bar. The Turing Way notes that developers commonly call a model “open source” when they publish the weights under an open software or content license, even though conventional software licenses may not account for the technical character of a machine learning model. The same source explains that a model license governs use, redistribution and derivatives of the model, while the source code, data and application can each have separate licenses.

The American Bar Association makes the same point from the legal side. Its 2025 article says AI raises separate licensing issues for code, training data and model weights. Software licenses were designed around copyright in code, and they may fit training datasets poorly.

The LF AI & Data Foundation suggests a way to split the work. It recommends OSI-approved software licenses for code, open data licenses for weights and datasets, and Creative Commons licenses for documentation, because weights and datasets are not the same legal artifact as source code.

The practical takeaway: when someone says “it’s open source,” ask which part. The repository, the weights file, the dataset and the documentation may each have a different license.

Four AI model components may have separate licenses

The common software licenses and what they ask of you

Start with the licenses on the code around the model: inference servers, libraries, orchestration frameworks, vector databases. These are usually standard open source licenses, and they are the easiest layer to get right.

Johns Hopkins University’s Open Source Programs Office describes the split well. Permissive licenses such as Apache, BSD and MIT allow significant freedom, including use inside commercial products. Reciprocal licenses such as GPL and AGPL require that modifications be released under the same license.

The ChooseALicense.com summaries give the finer detail. Here is how the main licenses compare for a business building a product.

License Commercial use Main obligations Patent grant
MIT Yes Keep copyright and license notices; no warranty or liability Not expressly granted
Apache 2.0 Yes Keep notices and state changes you made Yes, express
MPL 2.0 Yes Share changes to covered files under the same terms Yes, express
LGPLv3 Yes Narrower reciprocity than GPL; modifications to the library stay open Yes, express
GPLv3 Yes Disclose source and distribute covered derivatives under the same license Yes, express
AGPLv3 Yes Same as GPL, plus source disclosure for modified versions used over a network Yes, express

A few readings of that table matter for AI work.

MIT is the low-friction option. ChooseALicense states that it permits commercial use, distribution, modification and private use as long as you preserve the copyright and license notices. It disclaims liability and warranty, so nobody is promising the code works.

Apache 2.0 adds a patent grant. For companies, that matters. You get express patent rights from contributors, plus a duty to say what you changed.

GPL and AGPL are about what you ship. If you modify GPL code and distribute it, covered derivatives go out under the same license. AGPL goes further: if users reach your modified version over a network, you owe them the source. That is the license to flag early if your product is a hosted service.

The distinction between using a tool and building it into your product is where most mistakes happen. Running an unmodified open source tool inside your own infrastructure is different from linking it into software you sell or host for customers. When in doubt, ask counsel before launch, not after.

Open weights are not the same as open source

This is where AI licensing gets expensive for the unwary. Cooley’s 2026 guide separates the two ideas. Open weights generally means downloadable numerical parameters, while bespoke terms may govern commercial use, IP, redistribution, attribution and downstream deployment.

So you can download the file and still not be free to do what you planned. The same guide lists terms that show up in open-weight licenses:

  • Commercial-use limits
  • Acceptable-use restrictions
  • Volume or user-count thresholds
  • Attribution or branding requirements
  • Bans on using the model, its outputs or its derivatives to train or improve a competing model

Cooley’s view is that the real risk usually sits in these custom contractual conditions, such as thresholds, use rules, attribution and training restrictions, rather than in whether the weights can technically be downloaded.

That last restriction deserves attention if you plan to fine-tune, distill or generate synthetic data from a model’s outputs. Read it before your team starts, because it is hard to unwind afterward.

Cooley also warns that copyleft provisions applied to model derivatives can conflict with a business goal of keeping your application source code proprietary. If your competitive edge is in the application layer, that conflict is worth finding at the design stage.

A purpose-built alternative

The Linux Foundation built the OpenMDW license because conventional code licenses fit model artifacts badly. Its explanation says OpenMDW covers code, parameters, datasets and other included model materials, grants broad royalty-free rights, and requires you to keep notices when you redistribute the model materials. Outputs are free from OpenMDW obligations, including attribution. The license also includes a patent-termination mechanism and supports compatibility and dual licensing.

That makes it a useful reference point. When you read a custom model license, ask whether it is as clear as that about what covers the weights, what covers the data and what covers the outputs.

What to check before you use a model commercially

Skadden’s 2024 legal primer on open generative AI models gives a solid checklist. It advises reviewing the licensing terms for the model, its components and its training data, including restrictions on commercial use or modification and potential incompatibilities. It also advises weighing provenance, output and copyright risk, and whether warranties or indemnities are available.

It also warns that different licenses may govern a model’s code, its pretrained weights, its datasets and a fine-tuned version. That creates incompatibility risk when one component permits commercial use and another does not.

Turn that into a working checklist:

  1. Identify every layer. Code, weights, training data, fine-tuned variants, adapters, documentation. Note the license on each.
  2. Read the commercial terms. Look for revenue caps, user thresholds and field-of-use limits.
  3. Check acceptable-use rules. Does your use case fall inside them today, and will it after your product grows?
  4. Look for copyleft reach. Does any term pull your application code or your fine-tuned model under the same license?
  5. Check the competing-model clause. Does it limit fine-tuning, distillation or training on outputs?
  6. Record attribution duties. Decide where notices will live in your product and docs.
  7. Ask about warranties and indemnity. Open models rarely offer them. Know that going in and plan around it.
  8. Check the data story. Where did the training data come from, and is there a documented license chain?

Training data and outputs: the separate question

A clean model license does not settle every issue. Training data and generated output carry their own rights questions.

On training, Heather Meeker, an open source licensing lawyer, explains that open source licenses permit training on the code they cover, while public code with no open source license may prohibit AI training or grant no rights at all. In the U.S., fair use may be relevant, but courts have not settled the question. Her point on outputs is that substantially similar output can raise license and derivative-work issues even if the training itself is defensible.

Skadden adds two cautions. Open datasets such as Books3 introduce significant copyright risk and have been the subject of infringement suits. And although open-model users often retain ownership of their inputs and outputs under the applicable terms, outputs may still reproduce protected material and need a separate infringement review.

In practice, that means two parallel reviews. One covers what you are allowed to do with the model. The other covers what the model learned from and what it might reproduce. Teams that only run the first review are the ones surprised later.

The same applies to code your own developers produce with AI assistants. If a coding assistant writes something that closely mirrors a licensed project, the license obligations of that project can follow the code into your repository. Code review and scanning catch this far more cheaply before release than after.

Training data and outputs: the separate question

Build an inventory of everything in your AI product

License review only works if you know what is in the product. The fix is an inventory, a bill of materials for your AI stack. For each model, list the name and version, the license, any fine-tuning, adapters or quantization applied, and a link to its model card. For each dataset, list the source, the license, whether it contains personal data and how it was collected. Then track your software dependencies the usual way.

Two habits keep it useful:

  • Update it when something changes. Swapping a model, upgrading a library or adding a dataset is a license event, so treat it like one.
  • Request the full license chain from vendors for training data and third-party components. A vendor that cannot show where its data came from is giving you a risk, not a product.

Our guide on what to include in an SBOM and how to keep it useful covers the software half of this. For the data half, see our framework on data governance for AI, and if your product handles California residents’ information, our piece on CCPA compliance for AI covers what the systems must do.

Why local models change the license conversation

Running a model on your own infrastructure can help with privacy and compliance, since your data stays inside your environment. It does not make license questions go away. Local deployment means you are the one redistributing, packaging and operating the weights, so notices, use limits and any copyleft terms apply to you directly. Pick the model with the license in hand, not after the prototype works.

If you are planning that route, our walkthrough on deploying LLMs on Kubernetes with vLLM covers the engineering side, and our guide to building governed, model-flexible enterprise AI explains why keeping your architecture able to swap models is also a license-risk strategy. If a license changes or a term stops fitting your business, you can move.

Perspective

We see the same pattern again and again. A team finds a model that works in a demo, wires it into an app, and only later asks what the license says. By then the model is in the product, the prompts are tuned to it and the deadline is close.

Our approach is to treat license review as part of engineering, not a legal afterthought. When we audit an AI-built or vibe-coded application, we look at what is in it: the dependencies, the model calls, the code that arrived from an assistant nobody can fully trace. That review sits next to security, maintainability and production readiness, because they are the same discipline. A codebase you cannot explain is a codebase you cannot license with confidence.

We also lean toward architectures that keep options open. Models change, terms change and pricing changes. A system designed so the model can be swapped is easier to defend, cheaper to run and less likely to leave you stuck. Pair that with experienced human engineers reading the code and the terms, and you get software that is simpler, cleaner and ready to ship.

The prototype trap is real: it works on the demo, then stalls at the last mile. License clarity is part of crossing that last mile.

Chad

How Bowtie can help

If you have an AI-built app and are not sure what is inside it, start with a review. Our Vibe Check is $449 one-off, and our ShipDoctor scan is $59 one-off. For a broader read by an experienced engineer, the Senior Developer Review starts from $449 on our pricing page.

Bowtie

We can also take on ongoing work. Our Ship Shape Service starts from $1,850 per month and our Crew Service from $2,950 per month. Both are described on the vibe code review page. For a look at why a professional review matters before launch, read why every AI application needs a code audit. We are not a law firm, so for a legal opinion on a specific license, bring in counsel. What we do is find what is in your stack and make it ready for that conversation.

FAQ

Can I use an open source AI model in a commercial product?

Often yes, but it depends on the license for each layer. MIT and Apache 2.0 permit commercial use with notice requirements, as ChooseALicense.com summarizes. Custom open-weight terms may add thresholds, acceptable-use rules or attribution duties, so read them before building.

What is the difference between open source and open weights?

Open weights usually means you can download the model’s parameters. Open source in the OSI sense also requires the freedom to use, study, modify and share, with access to the preferred form for modification, including data information and training code. Many open-weight releases carry bespoke terms that fall short of that.

Does the GPL apply to my AI app if I use a GPL library?

It can. GPL asks that covered derivatives you distribute use the same license, and AGPL extends source disclosure to modified versions offered over a network. Whether your app counts as a derivative depends on how it uses the library, so have counsel review the architecture before you ship.

Can open source licenses stop AI training on code?

Per Heather Meeker, open source licenses generally permit training on the code they cover. Public code with no open source license may prohibit training or grant no rights. In the U.S., fair use may apply, but courts have not settled the question.

Who owns what a model generates?

Skadden notes that users of open models often keep ownership of inputs and outputs under the applicable terms. Outputs can still reproduce protected material, so review them for infringement separately from the model license.

Sources