Guida per sviluppatori alle licenze Open Source

Non tutte le licenze open source sono uguali. Alcuni di essi obbligano il fornitore del software a concedere licenze di brevetto agli utenti e agli sviluppatori del software. Altre licenze obbligano lo sviluppatore che utilizza il prodotto o la libreria concessi in licenza a offrire il codice sorgente di questo prodotto o libreria alle stesse condizioni. Altri semplicemente danno via il codice, senza garanzie di alcun tipo o preoccupazioni. In questo articolo cercherò di evidenziare le principali differenze tra le licenze open source più utilizzate dal punto di vista di un utente di software e di uno sviluppatore di software.

Quando nel 1984 Richard Stallman iniziò il progetto GNU per la creazione di un sistema operativo libero, recuperò l'idea che il software dovesse essere condiviso tra sviluppatori, ingegneri e utenti; e dovrebbero essere in grado di migliorarlo in modo collaborativo nello stesso modo in cui di solito si fa la scienza.

Questa opzione contrastava con il solito concetto di software con licenza scelto dalla maggior parte delle società di software e degli sviluppatori per la distribuzione e la vendita dei propri programmi. Oggi, a più di trent'anni di distanza, il software open source continua lentamente a conquistare ampi settori della nostra industria: Linux, Android, Apache e Git sono esempi di prodotti open source leader nelle loro categorie.

Software open source o gratuito?

In questo articolo utilizzerò i termini “open-source” e “gratuito” come sinonimi per riferirmi a software o licenze. A mio parere, entrambi i termini esprimono la stessa idea. “Open-source” lo esprime in modo pratico e tecnico, e l'utilizzo di “Free” pone l'accento sul significato filosofico e politico del concetto.

Purtroppo la parola “libero” in inglese, oltre ad essere l'aggettivo associato a “libertà”, significa anche “senza costo”. Questo è il motivo per cui di solito preferisco dire “open-source”.

Proprietà comuni del software open source

Suppongo che tu abbia già un'idea approssimativa di cosa sia il software open source. Ma mentre parleremo dei dettagli delle diverse licenze, dobbiamo prima parlare delle proprietà specifiche che definiscono il software open source.

Innanzitutto: non sono un avvocato e questa non è una consulenza legale. In caso di dubbio, si prega di fare riferimento al testo effettivo delle licenze di cui parlo e al proprio consulente legale.

Tutto il software open-source, secondo l'Open Source Initiative, è distribuito sotto una licenza che conferisce ai suoi utenti e sviluppatori (i licenziatari) alcuni diritti. L'elenco completo può essere consultato nella Open Source Definition, ma ecco un riassunto di base:

1. Ridistribuzione gratuita del software: il software può essere venduto o regalato come prodotto o incluso in un pacchetto software. Questo può essere fatto senza pagare alcuna royalty.
2. Il codice sorgente del software concesso in licenza è incluso nella distribuzione, o almeno ci sono mezzi ben pubblicizzati per ottenere il codice sorgente. Questo codice sorgente è utilizzabile per lo sviluppo di versioni modificate del software.
3. È consentita la creazione di opere derivate e la licenza consente la loro distribuzione con gli stessi termini e licenza del software originale. A seconda della licenza del software originale, in alcuni casi queste opere derivate devono essere differenziate dal software originale modificandone il nome o il numero di versione, oppure possono essere distribuite solo sotto forma di patch del codice sorgente.
4. Il software può essere utilizzato da qualsiasi persona o gruppo di persone e in qualsiasi campo di attività, senza limitazioni.

Ma devi tenere a mente che le licenze software parlano solo dell'uso o della distribuzione delle autorizzazioni concesse dai detentori del copyright. Le licenze open source possono consentire all'utente di ridistribuire il software o le opere derivate liberamente, ma tale indennità potrebbe anche essere limitata in alcuni paesi in cui l'esportazione di software crittografico è vietata. In modo simile, le licenze open source ti consentono di utilizzare il software per qualsiasi scopo, ma ciò non significa che ti consentano di hackerare una banca utilizzando software con licenza open source. I brevetti software ne sono un altro esempio: alcune licenze open source concedono i permessi per utilizzare i brevetti liberamente, ma non tutti.

Quindi, possiamo utilizzare un software open source nello sviluppo di un prodotto o progetto? Fondamentalmente, dipende dalla licenza del software utilizzato e dalla licenza prevista per il prodotto finale. Le diverse licenze contano anche quando vuoi pubblicare il tuo codice come open-source e stai decidendo quale licenza dovresti usare.

Copyleft

Un concetto piuttosto interessante sulle licenze open source è quello che di solito viene chiamato copyleft, l'opposto del copyright. Laddove il copyright viene utilizzato per proteggere la proprietà intellettuale (incluso il software) dalla copia o dalla distribuzione, il copyleft viene utilizzato per garantire che la proprietà intellettuale e il software open source possano essere copiati o distribuiti come open source.

In base alla sua forza, ci sono due tipi di copyleft:

• Copyleft forte: quando le opere derivate da altre opere con licenza copyleft forte, o collegate a queste opere, devono continuare ad avere licenze copyleft forte, o anche esattamente la stessa licenza. Cioè, quei lavori open source non possono essere chiusi in futuro.
• Copyleft debole: quando opere che utilizzano opere con licenza copyleft debole, o ad esse collegate, possono essere concesse in licenza con altre licenze, anche licenze closed-source. In questo caso, il copyleft interessa solo il lavoro con licenza copyleft debole originale.

Esistono anche licenze open source senza copyleft: semplicemente non si preoccupano dell'apertura futura del software derivato.

Permissività

In base alla loro permissività, le licenze possono essere classificate anche in:

• Licenze rigide: quando non è possibile combinare software con licenza forte con software closed-source o anche con software con licenza più permissiva.
• Licenze permissive: quando i prodotti di solito possono essere combinati con software closed-source, o software con una licenza totalmente open-source.

Di solito, anche le licenze copyleft forti sono rigide e le licenze copyleft deboli sono più permissive, ma non deve essere così.

Differenze tra le licenze open source

Esistono molte licenze open source. L'Open Source Initiative ne ha già approvati più di 80. Alcuni sono ridondanti e potrebbero essere considerati equivalenti ad altri. Altri sono specifici per gli interessi dell'editore del software (come la licenza NASA) o per un determinato ambiente o scopo (come la Educational Community License o la Open Font License).

Questa proliferazione di licenze si basa in termini specifici nella licenza che, sommata alle proprietà open source di base, consente o non consente altri usi. Esempi di queste condizioni aggiuntive possono includere:

• Tipo di copyleft: debole o forte o inesistente.
• Tipo di permissività: permissiva o rigorosa.
• L'obbligo di aggiungere un avviso di copyright nel codice sorgente o nell'interfaccia utente.
• Concessione automatica del brevetto ai licenziatari.
• Considerando come licenziatari non solo i soggetti a cui viene distribuito il software, ma anche gli utenti del software (in modo che le persone che utilizzano un servizio nel cloud che utilizza questo tipo di software open source dovrebbero avere la possibilità di scaricare il codice sorgente di il software)

Problema di missaggio del codice con diverse licenze

Secondo quanto già detto in precedenza, alcune licenze sono permissive, consentendo agli utenti di combinare il codice con codice sorgente con licenza diversa (magari con condizioni aggiuntive). Questo caso consentirebbe di mescolare questo tipo di software con licenza open source con software closed-source. Un esempio di questo tipo di licenza è MIT License.

Altri sono più restrittivi, quindi il codice sorgente può essere combinato solo con codice concesso in licenza in modo simile e il risultato finale deve essere concesso in licenza con la stessa licenza originale. Un esempio di questo tipo di licenza è la General Public License (GPL).

Forse vuoi combinare il codice concesso in licenza con due diverse licenze open source restrittive. Usando la libertà dell'open source di usare il software come vuoi, puoi farlo. Ma il programma finale non può essere ridistribuito, in quanto dovrebbe essere distribuito con due licenze non compatibili tra loro.

Un esempio di questa situazione è stato ZFS. ZFS è un filesystem molto avanzato e innovativo che è stato incluso in OpenSolaris nel 2005. È un software open source concesso in licenza secondo i termini della Common Development and Distribution License (CDDL). Sebbene sia codice open source, non può essere integrato nel kernel Linux perché il codice sorgente di Linux è distribuito secondo i termini della General Public License, un'altra licenza open source restrittiva. I binari del kernel Linux compilati con il supporto ZFS non possono essere distribuiti a causa del conflitto di licenza.

Questi tipi di conflitti possono essere risolti solo se tutti i proprietari di uno dei programmi open source accettano di modificare la licenza o di aggiungere termini di eccezione nella licenza del software. Ad esempio: molti programmi su licenza GPL sono collegati alla libreria OpenSSL. La distribuzione della libreria OpenSSL è concessa in licenza che richiede che una frase appaia nel materiale pubblicitario e in qualsiasi ridistribuzione. Queste condizioni extra non sono compatibili con la GPL e per questo gli sviluppatori di prodotti GPL che utilizzano OpenSSL hanno incluso un'eccezione nella loro licenza che consente specificamente il collegamento con OpenSSL.

Caratteristiche differenziali delle licenze Open Source

Ora cercherò di analizzare le licenze open source più popolari, rimarcandone le caratteristiche differenziali, con una piccola guida su quando usarle o meno. Li ho ordinati dal più al meno utilizzato, secondo la Black Duck Knowledgebase.

Licenza pubblica generale GNU (GPL)

La GPL è la licenza open source più popolare. È stato creato dalla FSF come licenza per il progetto GNU, ed è anche la licenza del kernel Linux.

Le sue caratteristiche differenziali:

• Copyleft forte.
• Licenza molto rigida.
• Di solito è chiamata licenza 'virale': se colleghi il tuo codice a un altro pezzo di codice concesso in licenza sotto GPL e desideri distribuire i risultati, l'intero prodotto deve avere la licenza GPL.
• È anche una licenza "abbracciante": se stai sviluppando un software e vuoi concederlo in licenza sotto GPL, puoi collegarlo o includere altro software open source purché questo software abbia una licenza compatibile con GPL. Non richiede alcun obbligo non previsto dalla GPL.

Di solito, il testo della licenza utilizzato include il testo che dice che il software è distribuito secondo i termini della versione GPL N (o qualsiasi versione successiva).

Attualmente esistono due versioni di licenza GPL in uso: v2 e v3. La versione 3 è stata rilasciata nel 2007 per risolvere alcuni problemi che erano comparsi dal rilascio della versione 2 nel 1991.

La GPL v3 include alcune clausole e termini aggiuntivi, che riguardano i regolamenti di compatibilità con altre licenze open source, l'obbligo di licenza di brevetto, la definizione delle condizioni per l'utilizzo del software con licenza GPL come firmware nelle apparecchiature e la presa in considerazione di concetti come la gestione dei diritti digitali.

Licenza MIT

La licenza open source solitamente nota come MIT License, nota anche come licenza X11, è una licenza non copyleft molto permissiva che consente a tutti di utilizzare fondamentalmente il codice con tale licenza per qualsiasi cosa tu voglia, purché mantieni il messaggio di copyright e sappi che il software viene fornito senza garanzie di alcun tipo.

Questa licenza è molto popolare ed è utilizzata da diversi progetti come X Window System, Ruby on Rails, jQuery o Node.js.

È compatibile con la GPL, quindi puoi combinare il codice con licenza MIT nel software GPL.

Licenza Apache 2.0

La licenza Apache è stata creata dalla Apache Software Foundation (ASF) come licenza per il suo server HTTP Apache.

Proprio come la licenza MIT, è una licenza molto permissiva senza copyleft che consente di utilizzare il software per qualsiasi scopo, distribuirlo, modificarlo e distribuire opere derivate da esso senza preoccupazioni per i diritti d'autore. Le sue principali differenze rispetto alla licenza MIT sono:

• Utilizzando la licenza Apache, gli autori del software concedono licenze di brevetto a qualsiasi utente o distributore del codice. Queste licenze di brevetto si applicano a qualsiasi brevetto che, essendo concesso in licenza da uno qualsiasi degli autori del software, sarebbe violato dal pezzo di codice che hanno creato.
• La Licenza Apache richiedeva che le parti non modificate nelle opere derivate mantenessero la Licenza.
• In ogni file concesso in licenza deve essere preservato qualsiasi avviso di copyright, brevetto, marchio o attribuzione originale.
• In ogni modifica del file con licenza, deve essere presente una notifica che indichi che sono state apportate modifiche al file.
• Se il software con licenza Apache include un file NOTICE, questo file e il suo contenuto devono essere conservati in tutte le opere derivate.
• Se qualcuno invia intenzionalmente un contributo per un software con licenza Apache ai suoi autori, questo contributo può essere utilizzato automaticamente con la licenza Apache.

Questa licenza è interessante per la licenza di brevetto automatica e per la clausola sulla presentazione del contributo.

È compatibile con la GPL, quindi puoi combinare il codice con licenza Apache nel software GPL.

Licenza BSD

Ci sono 3 diverse licenze BSD. Sono tutte licenze molto permissive senza copyleft.

La licenza BSD a 2 clausole (o Licenza BSD semplificata) è totalmente equivalente alla licenza MIT che è stata spiegata in precedenza.

La Licenza BSD a 3 clausole (o Nuova Licenza BSD) aggiunge una clausola, specificando che né il nome del titolare del copyright né i nomi dei suoi contributori possono essere utilizzati per avallare o promuovere prodotti derivati ​​dal software senza una specifica autorizzazione scritta. Questa versione è compatibile con la GPL e consente di combinare codice con licenza BSD a 3 clausole nel software GPL.

La Licenza BSD a 4 clausole (o Licenza BSD Originale) aggiunge un'altra clausola, specificando che tutto il materiale pubblicitario che menziona le caratteristiche o l'uso del software deve mostrare un riconoscimento in cui si afferma che il prodotto include software sviluppato dal titolare del copyright. Questa licenza BSD a 4 clausole non è compatibile con la GPL. Il codice con questa licenza non può essere rilicenziato secondo i termini della GPL, poiché la quarta clausola aggiunge un requisito non richiesto nella GPL.

GNU Lesser General Public License (LGPL)

La LGPL è stata creata dalla FSF come una modifica della GPL con un copyleft più debole, consentendo il collegamento del software con licenza LGPL con qualsiasi altro software. Nelle sue origini LGPL stava per "Library General Public License", ma in seguito ha preso il nome attuale "Lesser General Public License" per indicare l'opinione della FSF secondo cui tutto il software dovrebbe essere gratuito, e per questo motivo la LGPL non dovrebbe essere generalmente usato.

È possibile collegare il codice closed-source a una libreria o a un software LGPL e distribuire i risultati finali purché:

• Fornisci il codice sorgente della parte LGPLed, con tutte le modifiche che hai apportato ad essa.
• Qualsiasi utente con sufficiente conoscenza è in grado di sostituire la parte LGPL del programma con una versione modificata. Questo può essere fatto distribuendo la parte del programma con LGPL come una libreria dinamica (DLL in Windows, .so in Linux/Unix) o fornendo il codice oggetto della parte non LGPL del programma.

LGPL v3 è compatibile con GPLv3, quindi puoi inserire il codice LGPLv3 nel software GPL.

Licenza artistica

La licenza artistica, nella sua attuale versione 2.0, è una licenza open source permissiva senza copyleft simile alla licenza MIT.

La principale differenza tra la licenza MIT e la licenza Artistica è che quest'ultima richiede che qualsiasi modifica apportata al codice debba essere chiaramente indicata.

Questa licenza è usata quasi esclusivamente nella comunità Perl.

L'attuale Artistic License 2.0 è compatibile con GPL: puoi mescolare codice Artistic-Licensed nel software GPL.

Licenza pubblica Microsoft (MS-PL)

La Microsoft Public License è stata creata nel 2008 da questa società come una delle licenze open source create dalla loro Shared Source Initiative.

È una licenza copyleft rigorosa e debole: consente la creazione e la distribuzione di programmi closed-source con codice MS-PLed, ma obbliga ad utilizzare l'MS-PL come licenza di opere derivate se queste sono distribuite in codice sorgente.

Personalmente ritengo che questa licenza sia un po' perversa e contraria allo spirito dell'open-source, consentendo la chiusura del codice in modo che in un certo senso al detentore del copyright non importi cosa puoi fare con il software, ma non puoi condividi il codice per essere mescolato con altro codice sorgente copyleft. Quindi, in un altro modo, al detentore del copyright interessa davvero quello che puoi fare e non vuole che tu usi il codice per ragioni come il miglioramento di Linux.

L'MS-PL non è compatibile con la GPL.

Licenza pubblica Eclipse (EPL)

La Eclipse Public License è la licenza creata dalla Eclipse Foundation per il proprio ambiente di sviluppo integrato. È una licenza restrittiva e con copyleft debole, simile per molti versi a LGPL. Include anche clausole per la concessione automatica della licenza di brevetto.

L'EPL è incompatibile con la GPL.

Licenza pubblica Mozilla (MPL)

La Mozilla Public License versione 2.0 è una licenza permissiva con copyleft debole creata dalla Mozilla Foundation per i suoi prodotti.

Potremmo considerare questa licenza come simile a LGPL, ma con la differenza principale che MPL consente anche il collegamento statico delle parti di codice MPL in software closed-source.

La MPL, nella sua attuale versione 2.0, è compatibile con la GPL. Questo non è vero per le versioni precedenti di MPL.

Licenza di sviluppo e distribuzione comune (CDDL)

Il CDDL è una licenza permissiva con copyleft debole creata da Sun (ora Oracle) basata su MPL versione 1.1. Fondamentalmente, ha le stesse proprietà dell'MPL. I suoi termini sono stati chiariti, ma non sostanzialmente modificati.

Il CDDL è la licenza open source scelta da Sun (ora Oracle) per molti dei suoi prodotti, come OpenSolaris o NetBeans, tra gli altri.

Poiché questa licenza era basata su MPLv1.1, questa licenza non è compatibile con GPL, quindi non è possibile combinare sorgenti con licenza CDDL in un software con licenza GPL. Molte persone dicono che questo è stato intenzionale, quindi il codice sorgente di OpenSolaris non può essere introdotto nel kernel Linux.

Licenza pubblica generale GNU Affero (AGPL)

L'AGPL è una versione della GPL con copyleft ancora più forte e restrittivo. Obbliga a fornire il codice sorgente dell'applicazione non solo alle persone che ricevono una copia del software, ma anche alle persone che utilizzano questo software attraverso una rete di computer.

Questa licenza è stata creata dalla FSF per fornire agli sviluppatori i mezzi per evitare la chiusura pratica del software open source quando viene eseguito nei server di rete o nel cloud, poiché la GPL non può costringere i fornitori di servizi a fornire codice sorgente agli utenti . In questo caso il software non viene distribuito.

L'AGPLv3 è compatibile con la GPL3. È possibile inserire il codice AGPLv3 nel codice GPLv3, purché il risultato finale sia concesso in licenza in base all'AGPLv3.

Licenza ISC

La licenza ISC è una licenza software libera permissiva scritta dall'Internet Software Consortium (ISC). È funzionalmente equivalente alle licenze BSD e MIT a 2 clausole, dopo aver rimosso alcune lingue ritenute non necessarie.

Inizialmente utilizzata per le versioni software di ISC, da allora è diventata la licenza preferita di OpenBSD (a partire da giugno 2003), tra gli altri progetti.

È compatibile con la GPL: puoi combinare il codice con licenza ISC nel software GPL.

Licenza reciproca Microsoft (MS-RL)

La Microsoft Reciprocal License è stata creata nel 2008 da questa azienda come una delle licenze open source create dalla loro Shared Source Initiative.

È simile all'MS-PL spiegato prima, ma ha un copyleft un po' più forte, simile alle condizioni di LGPL, CDDL ed EPL. Richiede che se si combina il codice con il codice sorgente con licenza MS-RL e si desidera distribuire i risultati finali, almeno la parte originale con licenza MS-RL deve continuare a essere concessa in licenza con questa licenza.

Non è compatibile con la GPL.

Dominio pubblico (CC0)

Secondo Wikipedia, "le opere di pubblico dominio sono quelle i cui diritti di proprietà intellettuale sono scaduti, sono stati persi o sono inapplicabili". Dedicando un'opera al pubblico dominio, l'autore rinuncia a tutti i suoi diritti su di essa ai sensi della legge sul diritto d'autore.

Esistono diversi progetti software in Public Domain, ad esempio SQLite, la libreria che implementa un semplice motore di database SQL incorporabile che è incluso in molti altri progetti, come i progetti Mozilla, Android, ecc.

Esistono molti modi per dedicare un software al pubblico dominio. Creative Commons ha creato CC0 Public Domain Dedication, un modo universale per regalare un'opera di pubblico dominio. La FSF raccomanda di utilizzare questo testo per dedicare il software al pubblico dominio.

Le opere di pubblico dominio sono compatibili con qualsiasi licenza open o closed source e possono essere combinate in qualsiasi altro software.

Licenze multiple

C'è del software open source con licenza doppia o addirittura tripla. Ciò significa che una persona che riceve questo software con più licenze può scegliere con quale licenza desidera distribuirlo. Poiché ogni licenza concede autorizzazioni diverse e impone obblighi diversi, è necessario effettuare una selezione per scegliere la licenza che meglio soddisfa le esigenze.

Questo è un caso normale per alcune biblioteche. Ad esempio, NSS è una libreria realizzata da Mozilla che implementa il supporto SSL/TLS, tra le altre funzionalità relative alla sicurezza. Ha una licenza tripla con licenze MPL, GPL e LGPL.

Per favore, scegli una licenza

Molte persone pubblicano codice in piattaforme come GitHub senza alcuna licenza scritta. Nessuno dovrebbe usare quel codice. Non abbiamo idea di quali autorizzazioni abbiamo per usarlo. Se lo usi, potresti essere citato in giudizio per questo. È come se queste persone ci prendessero in giro dicendo “Ehi, guarda cosa ho fatto! Fantastico, vero? Ma non puoi usarlo, volevo solo mostrartelo!”.

Per favore, non essere uno di loro. Se carichi il tuo codice su GitHub o siti pubblici simili, consenti ad altri di usarlo e migliorarlo. Se non vuoi pensare molto, questi sono i miei consigli:

• Se vuoi mantenerlo semplice e permissivo, consentendo a tutti di fare ciò che vogliono con il tuo codice purché ti forniscano l'attribuzione e non ti ritengano responsabile, usa la licenza MIT.
• Se vuoi mantenerlo permissivo, consentendo a tutti di fare ciò che vogliono con il tuo codice ma enumerando saggiamente i diritti ai sensi della legge sul copyright e concedendo tali diritti, oltre a fornire un'esplicita concessione di diritti di brevetto dai contributori agli utenti, usa la licenza Apache 2.0 .

• Se ti interessa condividere le modifiche e non vuoi che il tuo codice venga utilizzato in sviluppi chiusi (né in prodotti software chiusi né in dispositivi hardware chiusi), usa GPL v3.

  • Se non ti interessa la possibilità che il tuo software venga utilizzato in un'appliance chiusa, usa GPL v2. Ma per favore con la frase "o qualsiasi versione successiva", così il tuo codice può essere utilizzato anche nei progetti GPLv3.
  • Se non ti interessa la possibilità che il tuo software venga utilizzato in un software chiuso, purché il tuo software o la parte che lo utilizza continui a essere open source alle stesse condizioni, usa LGPL v3.
  • Se vuoi che tutti coloro che utilizzano il tuo software attraverso una rete abbiano il diritto di ottenere il suo codice sorgente, usa AGPL v3.

Dopo tutto questo, potresti essere esausto di tutte queste sciocchezze quasi legali senza senso. Ma sai una cosa? È necessario. Perché senza una licenza, non hai i diritti per l'utilizzo o la distribuzione di alcun codice.