Open Source

Cosa significa open source per gli strumenti AI

Il software open source pubblica il codice sorgente sotto una licenza che consente ispezione, modifica e (di solito) ridistribuzione. Per gli strumenti AI potete leggere come vengono gestiti prompt, log e credenziali, adattare il prodotto al vostro stack ed eseguirlo senza attendere la regione cloud del fornitore.

Open source non è gratis come birra gratis, né uguale al self-hosted. Un progetto Apache può spingervi verso un control plane ospitato a pagamento. Un appliance proprietario può essere self-hosted con chiave di licenza. Leggete il file di licenza e il percorso telemetria predefinito, non la parola marketing "open".

Perché interessa ai team AI

Auditabilità. Gli ingegneri vedono il codice che tocca le conversazioni dei clienti — importante in sanità, finanza e legale.

Personalizzazione. I prodotti chiusi limitano le patch. Gli tool aperti permettono auth, retention, routing modelli e integrazioni sul vostro calendario.

Nessun kill switch monofornitore. Le API proprietarie vengono deprecate. Potete fissare un tag git, fare fork o continuare una release vecchia.

Velocità della community. Progetti attivi spesso ricevono fix di sicurezza e adapter (LangChain, chart Kubernetes) più in fretta di quanto una roadmap chiusa ammetta in pubblico.

Licenze che incontrerete davvero

• MIT — Molto permissiva. Tenete l’avviso copyright. Uso commerciale normale.
• Apache 2.0 — Permissiva più grant brevetti esplicito. Comune in infra AI enterprise.
• GPL v3 — Copyleft: distribuire un binario modificato implica in genere condividere sorgente sotto GPL.
• AGPL v3 — Copyleft che raggiunge molti deployment rete/SaaS. Revisione legale prima di prodottizzare.
• Source-available / BSL / open core — Codice leggibile; diritti forse non quelli che pensate. Non OSI-open finché legal non accorda.

Come valutare uno strumento AI open source

1. Compatibilità licenza con come consegnate (interno, SaaS, on-prem).
2. Chi fa merge: azienda, fondazione o un maintainer senza backup.
3. Cadenza release, artefatti firmati, contatto sicurezza.
4. Doc produzione: Compose/Helm, backup, upgrade, cosa telefona a casa.
5. Se "open" include dati di training, eval set, runtime agent o solo un client sottile.
6. Dual licensing: quali feature dietro SKU commerciale.

Rischi

Repo non mantenuti marciscono. AGPL in un servizio productizzato può forzare disclosure sorgente non budgetata. "Open weights" non è la stessa app aperta. Crash report e check licenza possono esfiltrare trace. Fork senza piano maintainer diventano il vostro on-call.

Domande frequenti

Se è su GitHub, è open source?

Solo con licenza open source riconosciuta e uso dei file licenziati. "All rights reserved" non è open source.

Codice Apache 2.0 in prodotto commerciale?

Di solito sì, anche closed source, rispettando notice e NOTICE. Confermate brevetti/marchi con legal.

Dobbiamo pubblicare le modifiche?

Non sotto MIT/Apache 2.0 per uso interno o SaaS tipico. GPL/AGPL diverse. Leggete la licenza prima di redistribuire o offrire servizio di rete.

Open source è automaticamente più sicuro?

No. La visibilità aiuta se qualcuno legge e patcha. Un repo pubblico abbandonato può essere peggio di un vendor con SLA sicurezza.

Rapporto con self-hosted?

Open source rende possibile il self-hosting. Non opera il cluster per voi. Vedi tag Self-Hosted.