# Codice GitHub in un prodotto commerciale: licenze e cosa controllare > Licenze permissive MIT, Apache e BSD, copyleft GPL/AGPL, l’assenza di un file LICENSE e la verifica dell’origine del codice aggiunto dall’IA. Source: https://ailoot.ai/blog/it/github-code-commercial-licenses/ Canonical: https://ailoot.ai/blog/it/github-code-commercial-licenses/ Language: it Publisher: Ailoot (https://ailoot.ai/) Translation: guide-177 Revision: sha256-f27a349d898c151ec4aabe80a0499aa1c80e9d313bbcb698157cc96b269b9027 Stai creando un prodotto e trovi su GitHub un componente già pronto: una libreria, un template, un intero progetto che fa esattamente ciò che ti serve. Claude ti suggerisce di integrarlo nel tuo progetto. Poi ti fermi: il codice sembra disponibile al pubblico, ma puoi davvero usarlo, per non parlare di vendere un prodotto che lo include? L’autore potrebbe rivalersi su di te in seguito? Vediamo la questione con ordine: perché il codice aperto su GitHub non costituisce di per sé un’autorizzazione, quali licenze ti permettono di usare il codice e vendere un prodotto, quali condizioni copyleft possono richiedere il sorgente corrispondente di un’opera coperta e come controllare una licenza in un minuto prima di usare il codice. Niente «dipende dalla situazione». [Le informazioni pratiche sull’uso di Ailoot sono disponibili nella documentazione](https://ailoot.ai/docs/).
Attenzione Questo materiale è a scopo informativo; non sono un avvocato. Di seguito descrivo i termini delle licenze più diffuse e le relative regole, con collegamenti alle fonti primarie, ma verifica la tua situazione specifica sulla base del testo della licenza e, se il prodotto è grande e commerciale, con un avvocato. La decisione spetta a te.
## È vero che se il codice è su GitHub puoi usarlo gratis?
Punto chiave No. Il fatto che il codice sia visibile non significa che tu possa usarlo nel tuo lavoro. Per impostazione predefinita, tutto il codice è protetto dal diritto d’autore e non puoi usarlo, a meno che l’autore non abbia concesso un’autorizzazione separata. La pubblicazione su GitHub, da sola, consente agli altri soltanto di visualizzare il repository e crearne una copia all’interno di GitHub. Il diritto di inserire quel codice nel tuo prodotto deriva dalla licenza allegata al repository dall’autore. GitHub non lo concede.
La trappola principale è la parola «aperto». Puoi vedere il codice sorgente e pensi che, siccome non è nascosto, tu possa usarlo. Questo ragionamento è sbagliato. «Aperto alla lettura» e «concesso in licenza per l’uso» sono due cose diverse. Per impostazione predefinita, qualsiasi opera creativa, compreso il codice, è protetta dal diritto d’autore dal momento in cui viene creata. Finché l’autore non concede esplicitamente il permesso, non puoi usarla. È quanto spiega GitHub nella propria pagina di riferimento sulle licenze.

Quando crei un’opera creativa (e anche il codice è un’opera creativa), per impostazione predefinita è protetta da diritti esclusivi d’autore. Se non alleghi una licenza che stabilisca diversamente, nessun altro può copiare, distribuire o modificare la tua opera senza rischiare una rivendicazione o una causa legale.

— choosealicense.com (progetto di riferimento GitHub), https://choosealicense.com/no-permission/
Il secondo livello è GitHub stesso. Si pensa che, avendo accettato le regole di GitHub pubblicando il codice, si possa anche usare il codice altrui disponibile lì. Le regole dicono esattamente il contrario. Rendendo pubblico un repository, l’autore consente agli altri soltanto di visualizzarlo e crearne un fork, cioè farne una copia all’interno di GitHub. Questo non autorizza a usare il codice nel proprio lavoro.

Rendendo pubblico un repository, concedi agli altri utenti una licenza non esclusiva e valida in tutto il mondo per usare, mostrare e riprodurre (tramite fork) i tuoi materiali attraverso il servizio, nell’ambito delle funzionalità di GitHub. Puoi concedere diritti aggiuntivi allegando una licenza.

— Termini di servizio di GitHub, Sezione D, https://docs.github.com/en/site-policy/github-terms/github-terms-of-service
Le parole chiave sono nell’ultima frase: «nell’ambito delle funzionalità di GitHub» e «i diritti aggiuntivi derivano da una licenza». Un fork resta all’interno di GitHub. Non appena vuoi usare il codice nel tuo prodotto, per non parlare di venderlo, ti serve una licenza separata dell’autore. Senza licenza, non hai alcun diritto, anche se il codice è proprio lì, in bella vista. ## Che cosa determina se puoi usare il codice di qualcun altro?
Punto chiave È il file della licenza nel repository, di solito chiamato LICENSE o LICENSE.md. È l’autorizzazione dell’autore e specifica cosa puoi e non puoi fare con il codice. La licenza risponde a tre domande: puoi usare il codice in un prodotto commerciale, puoi modificarlo e puoi mantenere chiuso il tuo codice sorgente? Le diverse licenze danno risposte diverse, quindi la prima cosa da controllare è questo file; solo dopo dovresti aprire il codice stesso.
Tutto si riduce a un file. Un repository mantenuto correttamente contiene un file di licenza, di solito LICENSE, a volte LICENSE.md, oppure un riferimento direttamente nel README. È l’autorizzazione dell’autore, che stabilisce i termini ai quali puoi usare il codice. GitHub di solito mostra il nome della licenza nella barra laterale della pagina del repository, prima ancora che tu apra il file. Per non perderti nel linguaggio giuridico, è utile leggere la licenza ponendoti tre domande sulla tua situazione: 1. **Puoi usare questo codice in un prodotto commerciale** per cui le persone pagano? 2. **Puoi modificare il codice** secondo le tue esigenze? 3. **Dovrai rendere pubblico in seguito il codice sorgente del tuo prodotto** oppure puoi mantenerlo chiuso? Quasi tutte le differenze tra le licenze si riducono a risposte diverse alla terza domanda. Per le prime due, le licenze aperte più diffuse dicono spesso «sì»: usalo, modificalo, vendilo. Ma è sull’obbligo di rendere pubblico il proprio codice che molte persone inciampano. Vediamo ora i principali tipi attraverso queste tre domande. ## Quali licenze ti permettono di usare il codice e vendere un prodotto?
Punto chiave Le più comode per un prodotto commerciale sono le licenze permissive: MIT, Apache 2.0 e BSD. Consentono quasi tutto: usare il codice, modificarlo, vendere il prodotto e mantenere chiuso il proprio codice sorgente. C’è un solo obbligo: conservare il testo della licenza e l’attribuzione. Apache 2.0 protegge anche dalle rivendicazioni sui brevetti e richiede di contrassegnare i file modificati. Se il codice altrui ha una di queste licenze, puoi usarlo tranquillamente in un prodotto commerciale.
Cominciamo con una buona notizia. Per chi crea un prodotto da vendere, l’opzione migliore è un gruppo di licenze chiamate permissive. Ce ne sono diverse, ma le tre più comuni sono MIT, Apache 2.0 e BSD. Tutte e tre rispondono «sì» alle prime due domande e ti consentono di mantenere chiuso il tuo codice sorgente. La più diffusa e semplice è MIT. Il suo testo sta in un solo paragrafo.

Con la presente si concede gratuitamente a chiunque ottenga una copia di questo software il permesso di usarlo senza restrizioni, compresi i diritti di usare, copiare, modificare, unire, pubblicare, distribuire, concedere in sublicenza e vendere copie, a condizione che l’avviso di diritto d’autore e il presente avviso di autorizzazione siano inclusi in tutte le copie.

— Licenza MIT, opensource.org, https://opensource.org/license/mit
In parole più semplici, MIT ti consente di fare quasi tutto con il codice, compreso vendere il prodotto e mantenere chiuso il tuo codice sorgente. L’unico obbligo è includere il testo della licenza e la riga di attribuzione. Babel, .NET e Rails, per esempio, sono distribuiti con licenza MIT, quindi quasi certamente hai già usato codice sotto questa licenza. Apache 2.0 funziona in modo simile, ma aggiunge due punti importanti. Primo, una protezione esplicita dalle rivendicazioni sui brevetti: gli autori del codice promettono di non farti causa per i brevetti relativi a quel codice. Secondo, alcuni requisiti formali aggiuntivi per l’uso.

Puoi riprodurre e distribuire copie dell’opera o opere derivate su qualsiasi supporto, con o senza modifiche, a condizione di fornire ai destinatari una copia di questa licenza, contrassegnare i file modificati, conservare gli avvisi di diritto d’autore e brevetto e includere una copia leggibile del file NOTICE, se presente.

— Licenza Apache 2.0, Sezione 4, https://www.apache.org/licenses/LICENSE-2.0
BSD, nelle versioni a 2 e 3 clausole, è sostanzialmente simile a MIT: puoi usarla, modificarla e vendere il prodotto, conservando l’avviso di diritto d’autore. Ho raccolto tutte e tre in una tabella per mostrare a colpo d’occhio le differenze. | Licenza | Vendere il prodotto | Mantenere chiuso il codice sorgente | Cosa devi fare | Protezione dei brevetti | |----|----|----|----|----| | MIT | sì | sì | conservare l’avviso di diritto d’autore e il testo della licenza | nessuna clausola | | Apache 2.0 | sì | sì | avviso di diritto d’autore, file NOTICE, contrassegnare le modifiche | sì | | BSD (2 e 3 clausole) | sì | sì | conservare l’avviso di diritto d’autore | no | Come applicare queste informazioni al tuo caso: se sul codice di qualcun altro vedi MIT, Apache 2.0 o BSD, puoi stare tranquillo: puoi usarlo in un prodotto commerciale, modificarlo e mantenere chiuso il tuo codice sorgente. Devi solo evitare di rimuovere il file della licenza e l’attribuzione dalla parte che hai preso. ## Come si applicano gli obblighi sui sorgenti di GPL e AGPL?
Punto chiave GPL e AGPL consentono uso commerciale. Gli obblighi GPL sorgono quando si trasferisce un’opera coperta; il normale uso su server senza trasferire una copia non è quel presupposto. AGPLv3 aggiunge l’offerta del sorgente agli utenti che interagiscono da remoto con una versione modificata. Determina l’opera combinata coperta: non tutti i componenti indipendenti ne fanno automaticamente parte.
Il copyleft mantiene l’opera coperta e i derivati sotto la stessa licenza quando ricorrono le condizioni. Con GPLv3, distribuire copie sorgenti o eseguibili di un’opera coperta o derivata combinata richiede conformità alla licenza e agli obblighi sul sorgente corrispondente. Non si estende automaticamente a ogni programma indipendente nello stesso prodotto o server. Nell’esempio web, ospitare una libreria GPL sul proprio server senza fornire copie agli utenti non impone di per sé di pubblicare tutto il servizio. Distribuire ai clienti un’applicazione combinata coperta può attivare obblighi GPL: verifica integrazione e licenza per stabilire quali sorgenti debbano accompagnarla. Un client browser consegnato agli utenti pone una questione distinta di distribuzione. AGPLv3 aggiunge una condizione di rete: se modifichi il programma e gli utenti interagiscono da remoto con quella versione, deve offrire loro chiaramente il proprio sorgente corrispondente. È più preciso che affermare che il solo hosting di qualsiasi componente AGPL apra ogni parte indipendente del servizio. Per un prodotto proprietario esamina opera coperta, combinazione dei componenti, distribuzione di copie e interazione di rete AGPL applicabile. Scegli un’alternativa permissiva compatibile o ottieni un permesso separato se non puoi rispettare gli obblighi. L’uso commerciale è consentito: conta la conformità alla licenza e all’integrazione effettive. ## Cosa dovresti fare se il repository non ha alcun file di licenza?
Punto chiave L’assenza di un file di licenza significa che non puoi usare il codice. Non significa «è gratis»: al contrario, senza una licenza il codice resta soggetto all’intero diritto d’autore dell’autore e non hai il diritto di usarlo, copiarlo o modificarlo. Il permesso di visualizzarlo e crearne un fork all’interno di GitHub non aiuta: non ti dà il diritto di inserire il codice nel tuo prodotto. Se hai davvero bisogno del codice, l’unica strada corretta è scrivere all’autore e chiedere il permesso, oppure aspettare che aggiunga una licenza.
Un errore comune è pensare che, se non c’è una licenza, non ci siano restrizioni e si possa usare liberamente il codice. È vero il contrario. L’assenza di una licenza non è un’autorizzazione; per impostazione predefinita significa che non hai il permesso. Il codice senza licenza resta soggetto all’intero diritto d’autore dell’autore e non puoi toccarlo. Si applica di nuovo la regola da cui siamo partiti: per impostazione predefinita, il codice è protetto dal diritto d’autore e senza un’autorizzazione esplicita non puoi copiarlo, modificarlo o distribuirlo. La possibilità di visualizzarlo e crearne un fork all’interno di GitHub non supera questo ostacolo: non ti concede il diritto di usare il codice nel tuo prodotto. Cosa fare concretamente se il codice non ha una licenza ma ne hai davvero bisogno: 1. **Scrivi all’autore.** Direttamente nella sezione delle discussioni del repository o via email, chiedi se puoi usare il codice e a quali condizioni. A volte l’autore ha semplicemente dimenticato di aggiungere una licenza e lo farà se glielo chiedi. 2. **Cerca un’alternativa.** Per quasi ogni esigenza esistono un secondo, un terzo e un decimo repository simile: tra questi ne troverai uno con una licenza MIT o Apache valida. 3. **Non usarlo.** Se non hai il permesso e non c’è un’alternativa, il codice non è tuo e non puoi inserirlo in un prodotto che intendi vendere. La tentazione di pensare «chi se ne accorgerà?» finisce male proprio quando il prodotto comincia a fare soldi e ad attirare attenzione. ## E se fosse Claude stesso ad aggiungere al progetto il codice di qualcun altro?
Punto chiave È un caso distinto ed è importante non confonderlo con la copia diretta di un repository. Quando prendi personalmente codice da un repository specifico, devi rispettarne la licenza. Quando Claude o un’altra IA genera codice in risposta alla tua richiesta, di solito produce un testo proprio, composto per il compito, anziché copiare il file di qualcun altro, e la questione si sposta sui diritti relativi al codice generato. Ma se l’IA ha chiaramente riprodotto una parte riconoscibile di codice altrui soggetta a licenza, i termini della licenza continuano ad applicarsi. In entrambi i casi conviene verificare la fonte.
C’è un secondo aspetto, che è facile confondere con il primo. Una cosa è visitare un repository e copiarne un file: in quel caso tutto quanto detto sopra sulla licenza è un obbligo diretto. Un’altra è quando Claude scrive codice per te in risposta a una richiesta. Nei casi ordinari, l’IA produce un testo proprio, composto per il tuo compito, invece di copiare il file di qualcun altro. La questione allora si sposta su un altro ambito: a chi appartiene il codice generato e puoi venderlo? È un tema ampio a sé, che ho trattato in un articolo su chi possiede il codice scritto dall’IA. Ma c’è un’eccezione da tenere presente. A volte l’IA produce una parte riconoscibile del codice altrui quasi parola per parola, come un’intera funzione di una libreria nota. In quel caso, la licenza della libreria continua ad applicarsi, indipendentemente da chi abbia materialmente premuto i tasti. Quindi i blocchi già pronti di grandi dimensioni che Claude ha inserito integralmente vanno controllati proprio come se li avessi copiati tu. ## Come controllare una licenza prima di usare il codice: i passaggi
Punto chiave La procedura è questa: apri la pagina del repository e controlla il nome della licenza nella barra laterale, apri il file LICENSE stesso, individua il tipo, permissiva (MIT, Apache, BSD) o copyleft (GPL, AGPL), confrontalo con la tua situazione e decidi se usare il codice o cercare un’alternativa. Se non c’è alcuna licenza, non usare il codice. Il controllo richiede un paio di minuti e va fatto prima che il codice entri nel tuo progetto, non dopo.
Riassumiamo tutto in una breve lista di controllo per verificare qualsiasi codice di terzi prima di inserirlo nel tuo progetto. Procedi dall’alto verso il basso. 1. ### Trova il nome della licenza nella pagina del repository Apri il repository su GitHub. Il nome della licenza di solito è visibile nella colonna a destra o sotto l’elenco dei file, per esempio «MIT License», «Apache-2.0» o «GPL-3.0». Se il campo è vuoto e non c’è un file di licenza, è già un campanello d’allarme; riprendi la questione nell’ultimo passaggio. 2. ### Apri il file della licenza Nell’elenco dei file, cerca LICENSE, LICENSE.md o COPYING e aprilo. Verifica che il nome corrisponda a quello mostrato nella barra laterale e che la licenza si applichi al codice che vuoi usare, non solo a una parte distinta del repository. 3. ### Individua il tipo: permissiva o copyleft MIT, Apache 2.0 e BSD sono permissive: puoi usare il codice in un prodotto commerciale chiuso. GPL e AGPL sono copyleft: controlla opera coperta, distribuzione ed eventuale condizione di rete AGPL prima di determinare gli obblighi. Il solo nome non stabilisce quali componenti indipendenti siano coperti. 4. ### Confrontala con la tua situazione Rispondi a tre domande: venderai il prodotto? Modificherai il codice? Vuoi mantenere chiuso il codice sorgente? MIT, Apache e BSD sono adatte a un prodotto chiuso destinato alla vendita. Per GPL e AGPL determina quale opera coperta o combinata richieda il sorgente corrispondente e quando sorga l’obbligo; valuta se puoi rispettarlo. 5. ### Nessuna licenza significa: non usarlo Se non c’è un file di licenza e il README non dice nulla sul permesso, non puoi usare il codice. Scrivi all’autore e chiedi il permesso, oppure trova un equivalente con una licenza valida. «È disponibile pubblicamente» non equivale a un’autorizzazione. Questo controllo sembra noioso finché il tuo prodotto non cresce, comincia a fare soldi e qualcuno ti chiede del codice di terzi che contiene. Due minuti all’inizio costano meno che dover affrontare una controversia in seguito. Tratto a parte cosa fare con il tuo prodotto dopo, affinché non si blocchi dopo il lancio: [Ho creato un prodotto con l’IA: e adesso?](https://ailoot.ai/blog/it/ai-product-maintenance-after-launch/).
### Domande frequenti Puoi vendere un prodotto che contiene codice di qualcun altro preso da GitHub? Sì, se il codice ha una licenza permissiva, come MIT, Apache 2.0 o BSD. Ti consentono di usare il codice in un prodotto commerciale, venderlo e mantenere chiuso il tuo codice sorgente; devi solo conservare il testo della licenza e l’attribuzione. GPL e AGPL consentono anch’esse uso commerciale, ma gli obblighi dipendono dall’opera coperta e dalla distribuzione o condizione di rete AGPL applicabile. Se non c’è un file di licenza, non puoi usare affatto il codice. Che cosa significa se un repository GitHub non ha una licenza? Significa che non puoi usare il codice. Per impostazione predefinita, l’assenza di una licenza equivale all’assenza di un’autorizzazione; non significa «gratis». Il codice resta soggetto all’intero diritto d’autore dell’autore. La possibilità di visualizzare il repository e crearne un fork all’interno di GitHub non ti dà il diritto di usare il codice nel tuo prodotto. Se ti serve il codice, scrivi all’autore e chiedi il permesso oppure trova un equivalente con una licenza aperta. Qual è la differenza tra MIT e GPL per il mio prodotto? MIT ti consente di usare e modificare il codice, vendere il prodotto e mantenere chiuso il tuo codice sorgente: l’unico obbligo è conservare il testo della licenza. GPL consente uso commerciale, ma trasferire un’opera combinata o derivata coperta richiede il rispetto del sorgente corrispondente e della stessa licenza. Il solo hosting senza trasferire copie è diverso e componenti indipendenti separati non sono automaticamente coperti. Devo fare qualcosa se uso codice con licenza MIT? Sì, una piccola cosa: conserva il testo della licenza MIT e la riga di attribuzione del codice che hai usato nel tuo progetto. Di solito si tratta dello stesso file LICENSE allegato all’originale. MIT non richiede altro: puoi modificare il codice, vendere il prodotto e mantenere chiuso il tuo codice sorgente. E se fosse Claude stesso ad aggiungere il codice di qualcun altro, invece di me? Dovresti comunque controllare la fonte. Di solito l’IA produce un testo proprio per il tuo compito, e allora la questione si sposta sui diritti relativi al codice generato: è un tema distinto. Ma se l’IA ha riprodotto quasi parola per parola una parte riconoscibile del codice altrui, tratta da una libreria nota, la licenza di quella libreria continua ad applicarsi. Controlla i blocchi già pronti di grandi dimensioni inseriti integralmente come faresti con un copia-incolla tuo.
### Fonti - [choosealicense.com - progetto di riferimento GitHub per scegliere una licenza](https://choosealicense.com/) - [choosealicense.com - cosa significa non avere una licenza](https://choosealicense.com/no-permission/) - [Termini di servizio di GitHub, Sezione D (concessione di licenza agli altri utenti)](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service) - [Licenza MIT (opensource.org)](https://opensource.org/license/mit) - [Licenza Apache 2.0 (apache.org)](https://www.apache.org/licenses/LICENSE-2.0) - [GNU General Public License v3.0 (gnu.org)](https://www.gnu.org/licenses/gpl-3.0.en.html) - [GNU Affero General Public License v3.0 (gnu.org)](https://www.gnu.org/licenses/agpl-3.0.en.html)
[Apri Ailoot](https://ailoot.ai/). ## Domande frequenti ### Ospitare una libreria GPL mi obbliga a pubblicare tutto il servizio web? Il solo hosting senza trasferire copie non è il presupposto di distribuzione GPL. Distribuire un’applicazione combinata o derivata coperta può comportare obblighi sui sorgenti di quell’opera; i componenti indipendenti non sono automaticamente coperti. ### Quale condizione aggiuntiva introduce AGPLv3 per un servizio web? Un programma AGPL modificato che supporta interazioni remote deve offrire a quegli utenti il proprio sorgente corrispondente. Controlla programma coperto e integrazione, senza presumere né assenza di obblighi né apertura di ogni servizio indipendente. ## Ailoot · L’azienda e il suo portafoglio di progetti Ailoot si basa su un’esperienza operativa consolidata, un’ampia base di clienti, un servizio stabile e un controllo costante dei KPI. L’azienda e il suo portafoglio di progetti: milioni di clienti; vendite nell’ordine dei miliardi ogni mese. Ailoot mette questa esperienza operativa al servizio dell’accesso API alle funzioni AI nei prodotti dei clienti, negli agenti, nelle applicazioni e nelle automazioni.