🧙 Maestro Yoda Cap. 21 · Open source e HuggingFace

Puntata 232

Puntata 232 — License pitfall: Apache, MIT, OpenRAIL, Llama Community

Livello: 🧙 Maestro Yoda · Capitolo 21 · Open source e HuggingFace

Il modello è figo, i benchmark sono ottimi, hai costruito il prodotto, e poi un avvocato che legge la license ti spegne tutto. Le license dei modelli AI sono diverse da quelle del software: a volte permissive identiche, a volte un labirinto di clausole. Capirle ti risparmia un rollback in produzione.

un labirinto di siepi vista dall’alto. Sopra ogni biforcazione un cartello: “Apache 2.0 ←”, “MIT →”, “Llama Community ↓”, “OpenRAIL ↑”, “Research only ⊗”. In mezzo un avvocato con la lente. Sotto: “scegli con calma, costa meno che uscire”

Le 5 famiglie principali

LicenseTipoCommerciale?Modifiche?OSI?Restrizioni use case
Apache 2.0PermissiveSìSìSìNessuna
MITPermissiveSìSìSìNessuna
OpenRAIL-MResponsibleSìSìNoSì (use case prohibiti)
Llama CommunityCustom permissiveSì + caveatSìNoSì (>700M MAU, AUP)
Gemma LicenseCustom permissiveSì + caveatSìNoSì (AUP)
Mistral ResearchResearch-onlyNoSolo ricercaNoSì
Custom proprietaryClosedA discrezioneVariabileNoVariabile

Dettaglio puntuale di ognuna.

Apache 2.0

License classica del software open source moderno. Adottata da: Mistral 7B, Qwen ≤14B, Phi 3, OLMo, BLOOM (alcuni), molti modelli embeddings.

Cosa ti permette:

  • Uso commerciale ✅
  • Modifica ✅
  • Distribuzione ✅
  • Sublicensing ✅
  • Uso in prodotti chiusi ✅
  • Patent grant esplicito ✅

Cosa richiede:

  • Mantenere note copyright + license.
  • Indicare le modifiche significative.
  • (Implicito) attribuzione.

È la license che vuoi se possibile. OSI-approved, FSF-approved, nessuna trappola.

MIT

Ancora più semplice di Apache. Adottata da: DeepSeek-V3, DeepSeek-R1 (in larga parte), Falcon, alcuni Qwen, Kimi-K2 (modified MIT), molti modelli accademici.

  • Uso commerciale ✅
  • Modifica ✅
  • Distribuzione ✅
  • Sublicensing ✅
  • Praticamente identica ad Apache, ma senza patent grant esplicito.

Senza patent grant = rischio teorico che il licensor ti faccia causa per brevetti propri. In pratica raro, ma se sei una big enterprise i legali preferiscono Apache 2.0 per questo.

OpenRAIL (Responsible AI License)

Famiglia introdotta da BigScience/HuggingFace nel 2022. Versione “-M” per modelli, “-D” per dataset, “-A” per app.

Adottata da: Stable Diffusion, BLOOM (in parte), molti modelli generativi visivi.

Concedi: uso commerciale, modifica, distribuzione.

Imponi restrizioni d’uso (Use Restrictions):

  • No deepfake non consensuali.
  • No discriminazione su base protetta.
  • No diffusione di disinformazione intenzionale.
  • No generazione di CSAM.
  • No surveillance illegale.
  • Decision support medico/legale solo con human in the loop.
  • Eccetera (lista nell’allegato Use Restrictions della license).

Caveat: queste restrizioni d’uso sono contrattuali, non basate sul copyright. Difficile farle rispettare contro un attore malevolo, ma sono utili per:

  • Posizionamento etico del lab che pubblica.
  • Base legale per ban da HF Hub di chi le viola.
  • Difesa reputazionale.

Non OSI-approved proprio perché viola “no discrimination against fields of endeavor”. Per molti puristi non è “open source”. Per chi pubblica modelli generativi è un trade-off accettato.

Llama Community License

Specifica Meta per la famiglia Llama (Llama 2, Llama 3.x, Llama 4).

Concedi:

  • Uso commerciale ✅
  • Modifica ✅
  • Distribuzione ✅ (con caveat)

Imponi:

  1. Threshold 700M MAU: se la tua azienda o un suo affiliato ha più di 700 milioni di utenti attivi mensili, devi chiedere una license commerciale a parte. Targetizza Apple/Google/Microsoft/Amazon/TikTok/Meta-stessa.
  2. “Built with Llama”: devi indicare nel prodotto che usa Llama.
  3. Naming: se distribuisci un modello derivato, il nome deve iniziare con “Llama” (per Llama 3+).
  4. Acceptable Use Policy (AUP): no use case prohibiti (military, CSAM, fraud, ecc.).
  5. License redistribution: se redistribuisci pesi o derivati, devi includere la license originale.

Non OSI-approved perché:

  • Discrimina contro grandi aziende (≥700M MAU).
  • Impone restrizioni di campo d’uso (AUP).

Per il 99.99% degli sviluppatori la threshold non si tocca mai. La AUP è ragionevole. Ma legalmente non è open source per puristi.

Gemma License (Google)

Simile in spirito a Llama Community.

  • Uso commerciale ✅
  • Modifica ✅
  • Distribuzione ✅
  • AUP da rispettare (no CSAM, weapons, disinformation, ecc.).
  • Diritto di Google di revocare in caso di violazione AUP.
  • Indemnity reciproca.

Niente threshold di MAU come Llama. Più libera in quel senso.

Mistral License (varie)

Mistral è diventata complicata nel 2024.

  • Apache 2.0 sui modelli “Small” e “open” (Mistral 7B, Mixtral 8x7B, Mixtral 8x22B, Codestral mamba, ecc.).
  • Mistral Research License (MRL) sui modelli “Large” e “flagship” (Mistral Large 2, Codestral 22B prima del 2024-09): research-only, no use commerciale senza accordo separato.
  • Mistral Commercial License: accordo a pagamento per uso commerciale dei modelli MRL.

Conseguenza: se costruisci su Mistral, devi sapere precisamente quale modello stai usando. Stesso brand, license molto diverse.

Pitfall comuni (e come evitarli)

a) Derivazione di license

Se fai un fine-tune di Llama-3 e lo pubblichi con license “Apache 2.0”, è probabilmente sbagliato: i pesi base sono Llama Community, ne erediti i vincoli. L’adapter LoRA tuo può essere Apache, ma il modello “merged” eredita.

Pattern corretto:

  • LoRA adapter solo: Apache 2.0 sull’adapter, “use con Llama base” → utente deve accettare Llama license.
  • Merged model: Llama Community sull’intero modello + tua attribution.

b) Training data che contamina la license

Se hai addestrato su un dataset license CC-BY-SA-NC, il tuo output può ereditare:

  • Restrizioni non-commerciali.
  • Obblighi di share-alike.

In pratica le license dei dataset si applicano spesso solo ai dati, non ai modelli che ne derivano. Ma è materia legalmente grigia (es. cause NYT vs OpenAI). Conservativo: non addestrare su dataset NC se vuoi vendere il modello.

c) Output di modelli commerciali nel training

Usi GPT-5 per generare dataset sintetico (vedi puntata 220), poi ci addestri un modello e lo pubblichi. I TOS di OpenAI vietano esplicitamente di usare i loro output per addestrare modelli concorrenti. Stesso per Anthropic.

Pratica diffusa (DeepSeek-V3, vari modelli cinesi, molti fine-tune occidentali) ma legalmente esposta. Per uso commerciale serio: usa solo modelli con TOS permissivi (Llama, Mistral, Qwen, Gemma).

d) Naming derivati

Se fai un fine-tune di Llama-3 e lo chiami “MioBrand-Chat-v1”, violi la convenzione naming Llama 3+ (“deve iniziare con Llama”). Per essere compliant: Llama-3-Italian-Legal-v1.

e) Gated model in produzione

Se servi un modello gated (Llama, Gemma) tramite la tua API, ogni utente finale tecnicamente dovrebbe accettare la license? La risposta legale comune: tu accetti la license per conto del tuo prodotto. Ma:

  • Se distribuisci i pesi (es. mobile app con on-device), gli utenti finali devono accettare.
  • Best practice: avere ToS che incorporano per riferimento le license dei modelli base.

f) Diritto d’autore sull’output

Domanda aperta nel 2026: l’output generato dal modello è coperto da copyright? E di chi?

  • USA Copyright Office: opere “puramente AI-generated” non sono coperte. Serve contributo umano “creativo” sostanziale.
  • UE: varia per paese. Italia: opera AI-assistita può essere protetta se il contributo umano è creativo (art. 1 LDA).
  • License dei modelli (Apache, Llama, ecc.) non rivendicano copyright sull’output → tu sei libero di usarlo come vuoi. Ma il copyright stesso è un’altra questione.
  1. Identifica ogni modello, dataset, codice di terze parti usato.
  2. Recupera la license di ciascuno (file LICENSE, model card, README).
  3. Verifica compatibilità con il tuo use case (commerciale, redistribution, modifica).
  4. Controlla AUP specifiche (no medical, no military, no surveillance, ecc.).
  5. Annota obblighi (attribution, naming, redistribuzione license).
  6. Documenta nel tuo prodotto (“Powered by…” pages, license bundle).
  7. Per casi dubbi: chiedi a un avvocato specializzato AI (sì, esistono).

Per progetti enterprise: tieni un SBOM modelli (Software/Model Bill of Materials) aggiornato. È pratica che entra nei requisiti AI Act high-risk.

Tool utili

  • huggingface_hub.list_models(license=...) — filtra per license.
  • TLDR Legal / Choose A License / OSI Approved Licenses — riferimenti rapidi.
  • EU AI Act compliance checklists (ad es. dalle DPA nazionali).
  • OpenRAIL site (rail-license.com) per esempi e templates.

Glossario lampo

  • AUP (Acceptable Use Policy) — lista di use case prohibiti che accompagna la license (Llama, Gemma, OpenRAIL).
  • OSI-approved — license che soddisfa la Open Source Definition; status assegnato dall’Open Source Initiative.
  • Patent grant — clausola che il licensor concede una license sui brevetti relativi al codice rilasciato. Presente in Apache 2.0, assente in MIT.
  • Derivative work — opera che incorpora/modifica un’opera esistente. Eredita normalmente la license originale, con varianti.
  • SBOM — Software/Model Bill of Materials. Lista strutturata di componenti di terze parti con versione e license. Requisito per molte normative.

Take-away

Le license AI sono diventate un campo minato in cui la stessa parola (“open”) significa cose molto diverse. Apache 2.0 e MIT restano lo standard pulito. Llama Community e Gemma sono “molto liberali con caveat” — per il 99% degli usi commerciali vanno bene, ma vanno lette. OpenRAIL ha l’intento giusto ma non è OSI. Mistral è confuso (varia per modello). La regola d’oro: prima di costruire, leggi tu — non fidarti del marketing.

➡️ Prossima puntata: la filiera open completa — dal dataset all’app.