Read four documents, not one label
A model page can contain at least four different objects: source code, trained weights, training data information and an interface or demo. They can have different permissions and limitations. A badge that says ‘open’ does not answer whether the weights allow commercial use, whether the data description is complete, or whether an output can be cleared for a particular release. Treat each object as a separate row in your audit.
MusicGen makes the distinction concrete. Its published model card says the code is under MIT while the model weights are under CC BY-NC 4.0. That is not a contradiction; it is a reminder that copying a repository and running the trained model are different acts. The model card also identifies the model family and links to the underlying paper. Record the exact page and retrieval date because hosted repositories can change.
Ask what the card actually discloses
Look for developer, version, intended task, architecture, data sources or datasets, evaluation, known limitations and licence. Missing information is itself a result: write ‘not disclosed on the reviewed page,’ rather than inventing an explanation. A card may describe a dataset's licence without proving that every downstream use is suitable for your project. It is evidence about the developer's documentation, not a universal rights warranty.
For MusicGen, distinguish the card's training description from the rights of anything you upload as a melody prompt, reference or source recording. A model card usually cannot grant permission for your use of somebody else's audio. Keep a separate row for project inputs and the consent or licence that allows you to process them.
Translate licences into a decision
Make a short matrix: code licence, weight licence, dataset description, hosted-service terms, your input rights and intended output use. Mark each ‘confirmed,’ ‘conditional,’ ‘not found’ or ‘needs specialist advice.’ A non-commercial weight licence, for example, may rule out a paid client deliverable even where the repository itself permits broad code reuse. Do not cure that mismatch with vague language such as ‘experimental.’
The exercise is not legal advice and it does not determine whether copyright exists in an output. It does prevent a common category error: treating a permissive code licence as permission for every model artefact, input and release use around it.
Keep an audit note with the project
Save a one-page note beside the session: exact model identifier, revision if available, links, licences, date checked, planned use, inputs supplied and open questions. When a collaborator asks why the model was selected, the team can point to a dated record instead of memory. Revisit it when moving from a private sketch to a public release or client delivery.
A good audit ends with a modest conclusion: ‘Suitable for this non-commercial local experiment under the reviewed materials,’ or ‘not cleared for this commercial use on the information found.’ The clarity is more valuable than a broad claim that a model is safe or unsafe for everyone.
Continue in Tool decisions, or Meta open-sourced MusicGen with a licensed dataset and an NC licence.
Evidence & further reading
Go to the source.
Primary references checked 19 September 2026. Practical exercises are editorial guidance, not reported product tests.
- MusicGen Model Card ↗
Primary documentation identifies MusicGen details and distinguishes the code's MIT licence from the weights' CC BY-NC 4.0 licence.
Meta AI · Accessed 2026-09-19 - facebook/musicgen-small ↗
Model repository identifies the small checkpoint and its CC BY-NC 4.0 licence.
Meta AI · Accessed 2026-09-19 - Simple and Controllable Music Generation ↗
Primary research paper linked by the model documentation describes the MusicGen research work.
arXiv · Source date 2023-06-08 · Accessed 2026-09-19