AI Music Model Licenses: Code, Weights, Outputs, and Service Terms

A downloadable checkpoint is not necessarily cleared for commercial use. Start by identifying which license covers the code, which covers the weights, and what each permits. When someone asks whether they can ship a product on an AI music model—or sell a song made with one—they are usually stacking four different questions into one word. A team may have permission to run the inference code without permission to use its checkpoint commercially. A creator may have contractual permission to sell an output without a guarantee that it qualifies for copyright protection.

“Open source,” in the Open Source Definition sense, also means the license cannot restrict fields of endeavor such as business use. Many AI music releases use other labels—research-only, non-commercial weights, custom community terms—while still publishing source. Treat the badge as a pointer to documents, not as clearance.

This note is general information for engineers and musicians who need a clearer map. It is not legal advice. Licenses change between versions; read the text that ships with the model or service you actually use, and talk to a lawyer about your situation.

Four questions people collapse into “the license”

Keep these separate.

Model license (code and weights). Who may run, modify, redistribute, and commercially deploy the software and the trained parameters—and under what notice, patent, non-commercial, revenue-cap, or registration rules.
Rights in the generated audio. Whether a particular output is protected by copyright, and who holds those rights, depends on the law where you live and on the terms of the tool you used. A permissive model license does not, by itself, mint you a clean publishing chain.
Training data. What the model learned from. A MIT or Apache badge on the repo does not prove the training corpus was licensed for your use case. Developer statements about data are their claims; verify when the risk matters.
Service terms (SaaS / app ToS). If you generate through a website or app instead of self-hosting, that product’s terms—not the underlying model card—usually decide what you may do with the files you download.

For self-hosting, review code and weight permissions alongside training-data disclosures and output terms. For a hosted service, start with the service agreement; it does not resolve every question about output rights or third-party material.

Why a green “MIT” badge is not enough

GitHub and Hugging Face badges often describe the repository, not every artifact inside it. The common trap looks like this:

Code under MIT or Apache 2.0 (permissive).
Weights under CC BY-NC, a custom community license, or “research only.”
Inference scripts that quietly pull a third checkpoint with its own file.

If you only skim the README hero badge, you can build a commercial pipeline on weights you were never allowed to use that way. Always open the weight license file, the model card’s license field, and any NOTICE or extra PDF the authors attach. If the documents conflict, pause the affected deployment. Ask the publisher which terms apply to the exact checkpoint and version, and archive the clarification. Do not assume that a badge, model-card field, or stricter document automatically takes precedence.

License families you will actually meet

MIT

Short and permissive. You may use, modify, redistribute, and sell the software, including commercially, if you keep the copyright notice and license text. It ships “as is,” with no warranty, and says little about patents. Fine for many internal tools—still check whether the weights use the same text. Primary text: MIT License.

Apache 2.0

Also commercial-friendly. Compared with MIT it usually adds an explicit patent grant (which terminates if you sue claiming the software infringes), stricter notice rules (keep LICENSE/NOTICE, mark modified files), and a reminder that you do not get trademark rights to the project’s name or logo. The patent grant covers specified contributor patent claims; it is not a general assurance against infringement. Redistribution obligations are set out in section 4. Neither provision establishes clearance for training data or generated audio. Primary text: Apache License 2.0.

Creative Commons on weights (BY, NC, SA)

Creative Commons was written for creative works, not software, but weight files often wear it anyway. The letters stack:

BY — credit, link the license, note changes.
NC — non-commercial: purposes not primarily aimed at commercial advantage or monetary compensation.
SA — sharing adapted material can require an applicable ShareAlike license. Separately check whether the weight license addresses generated audio; do not assume that a song inherits the weights’ license.

See, for example, the CC BY-NC-SA 4.0 summary, which notes that its permissions may not cover every right needed for your use.

The classic split is open code + NC weights. That pattern is easy to miss because the repo still feels “open.” If your plan includes paid products, ads funded by the model, or client work that depends on those weights, NC is usually a hard stop unless you negotiate a separate grant.

Custom community licenses

Some labs write their own terms: research free, commercial allowed only after registration, revenue caps (for example, a ceiling on total annual revenue, not only revenue from the model), mandatory attribution lines such as “Powered by…”, and enterprise upgrades above the cap. These texts change between versions. Pin the exact license hash or file that came with the checkpoint you ship, not a blog summary from last quarter.

Research-only and “license: unknown”

No clear license is not an invitation. In most places, default copyright still attaches to someone else’s code; the status of weights is less settled but “unknown” is not clearance. Treat research-only and unlabeled releases as not cleared for commercial deployment until the publisher says otherwise in a license you can archive.

A practical checklist before you build

Use this when evaluating a checkpoint for a product, a plugin, or a personal pipeline you might later commercialize.

Identify every artifact. Training code, inference code, tokenizer, config, and each weight file. Licenses can differ per file.
Read the weight license first. Then the code license. Then any community addendum.
Record what triggers each obligation. Note which requirements apply to internal use, hosted inference, redistribution, or sharing modifications, and when registration or revenue thresholds must be checked.
Write down what is not granted. Patents (if silent), trademarks, training-data warranties, output ownership, indemnity.
Decide host vs SaaS. If you will not run the model yourself, skip straight to the host’s terms and still understand what they claim about the models underneath.
Archive the evidence. Commit the LICENSE files, model card snapshot, and download date into your repo or ticket. Future you will need them during due diligence.

What creators should check when they are not self-hosting

If you make songs in a browser tool, your first documents are that product’s terms and pricing pages—not a random model card on Hugging Face.

Ask, in plain language:

After I pay (or while I am on the free tier), who holds rights in the files I download?
Is free use limited to personal purposes?
Which paid plans include commercial licensing, and what does that license actually cover (ads, client work, streaming, sync)?
Does the service assign rights only after payment, and do those rights cover the specific plan I bought?
Does the contract promise exclusive rights, unique outputs, or neither? Check these separately; an assignment clause does not itself guarantee that another user will never receive similar audio.

On EasyMusic, the public pages draw that line carefully: free use is for personal purposes; commercial licensing is described on paid plans (see the current pricing page rather than assuming every paid tier is identical); and the terms say EasyMusic assigns any rights it may hold in a paid-plan output upon receipt of the applicable payment, subject to its terms and the plan shown at purchase, and to the extent legally permitted. EasyMusic uses an in-house model and offers Google Lyria as an option; it does not distribute downloadable model weights. Always re-read the live pages; wording can change.

None of that replaces advice about whether your jurisdiction treats AI-assisted songs as copyrightable, or whether a label, platform, or client will accept them. Those are separate conversations from the model license.

Builders: SaaS terms do not replace the model license

If you wrap someone else’s weights in your own paid API, you still need a license path for those weights. Hosting does not remove NC or research-only restrictions. Likewise, giving users a “commercial use” button in your UI does not create rights you never received upstream.

Conversely, if you only call a third-party music API and never redistribute weights, your contract with that API provider is the primary document—plus whatever you promise users in your terms. Be consistent: do not grant users broader rights than your upstream agreements allow.

Training data: treat marketing claims as claims

Model cards sometimes say “licensed,” “royalty-free,” “public domain,” or “synthetic.” Those statements help, but they are not a substitute for your own risk assessment when you:

train further on the checkpoint,
ship the model to enterprise customers with indemnity expectations,
or operate in a market where training-data litigation is active.

Permissive code licenses almost never warranty the training corpus. If your business needs a warranty, get it in a signed agreement—not from a LICENSE snippet.

A short decision tree

I want to sell songs I made in an app.
→ Read that app’s terms and pricing. Confirm personal vs commercial tiers. Ignore the underlying model badge until the app points you at it.

I want to fine-tune and ship a product on downloaded weights.
→ Weight license first. Reject NC / research-only / unknown for commercial shipping unless you have a separate grant. Budget for notices and any revenue-cap registration.

I want to study the architecture and publish a paper.
→ Research terms may be enough; still keep attribution rules and do not quietly move the same checkpoint into a paid demo.

I am unsure.
→ Do not ship. Ask the authors, get counsel, or pick a stack with clearer paperwork.

Keep a release record

Hypothetical example: inference code is MIT-licensed, but the downloaded checkpoint carries an NC restriction. For a planned paid generation API, record the checkpoint as unresolved for commercial deployment. The code license does not supply the missing weight permission. Obtain a separate grant covering the intended service or select another checkpoint and review its terms.

For a song made through a hosted service, keep the output identifier, generation date, plan receipt, applicable terms, and permissions for uploaded lyrics, recordings, or voices. Before a client delivery, also check whether the agreement addresses use after cancellation, earlier free-tier generations, and any exclusivity the client expects.

Licenses stay cheap to check and expensive to ignore. Separating code, weights, outputs, training-data claims, and service terms is the diligence most music-AI projects postpone—and the step that most often decides whether a release can stay up.