Prendere in considerazione le licenze open source

E così avete un progetto che volete creare con degli strumenti open source. Beh, mi tolgo il cappello davanti a voi developer. Ma sapete a che domande dovete rispondere prima di iniziare?

In quale fase di sviluppo si trova il vostro progetto in questo momento? Avete finito la fase di pianificazione? State lavorando con un team? Il progetto sarà suddiviso in diversi moduli? E così via.

Il principio DRY (Don’t Repeat Yourself) è diventato una regola non scritta per gli sviluppatori. Invece di partire da zero su ogni nuovo progetto, trovate modi per costruire basandovi sul lavoro precedente. Questo vi consente di risparmiare tempo e altre risorse. In altre parole, non re-inventate la ruota: sfruttate il grande lavoro che gli altri hanno perfezionato e vi hanno messo a disposizione “gratuitamente” come base da cui partire.

Tale principio DRY può essere applicato anche ai lavori open source. Quando si avvia un nuovo progetto, la maggior parte degli sviluppatori innanzitutto cerca attentamente i framework, le librerie e i pacchetti su cui possono costruire o che possono modificare per soddisfare le loro esigenze.

Soprattutto, potete scegliere tra le migliaia e migliaia di progetti open source (OS, framework, IDE, librerie, sistemi di gestione di database e così via) disponibili.

Ma aspettate un minuto!

Immaginate che il vostro progetto diventi un enorme successo, solo per essere poi abbattuto da questioni di licenze richieste dai lavori su cui vi siete basati per realizzarlo. Capite veramente che cosa significa usare il lavoro open source nel vostro progetto?

Man mano che aumenta l’adozione di open source, aumenta anche il rischio di non conformità con i termini di licenza che, a sua volta, porta ad un aumento del numero delle controversie che coinvolgono le opere open source.

Uno degli esempi più recenti coinvolge Hancom e Artifex, lo sviluppatore di Ghostscript . Il caso è in corso, ma da quanto segue, la direzione sembra essere chiara:

Oppure, Hancom deve pagare un diritto di concessione ad Artifex.

Adesso cominciate a farvi un’idea della situazione, vero?

Nota: nulla di ciò che dico in questo articolo è consulenza legale. Se non vi sono chiare le spiegazioni o i termini che trovate in una licenza, è una buona idea ottenere una consulenza legale qualificata. Queste sono solo alcune cose in cui mi sono imbattuto e voglio metterle in evidenza per i miei colleghi sviluppatori.

Valutare le opzioni open source#section1

Prima di decidere per un progetto open source da utilizzare o da includere nel vostro progetto, tornate alla vostra grande idea (cioè, il progetto che state sviluppando) e rispondete alle seguenti domande.

1. Qual è la visione del progetto? In particolare, state sviluppando un altro progetto open source o venderete il vostro progetto per trarne profitto?
2. Come metterete a disposizione degli altri il vostro progetto? Saranno in grado di leggere il codice sorgente o lo renderete off limit?
3. Quali diritti di ridistribuzione permetterete? Gli altri saranno autorizzati a re-impacchettare il vostro lavoro e a venderlo a scopo di lucro, oppure saranno in grado di ridistribuirlo gratuitamente?
4. Come dovreste gestire l’embedding? Gli altri potranno incorporare il vostro lavoro nel loro, per poi venderlo o distribuirlo per profitto o incorporare il vostro lavoro, ma impedire l’accesso al sorgente in modo che non sia disponibile ad altri?
5. Come gestirete l’attribuzione? Cosa farete per dare credito ai creatori originali dei tool inclusi?

Una volta che avrete risposto alle domande precedenti, cosa succede? È giunto il momento di rispondere ad un’altra domanda.

Cosa significa open source?#section2

Cosa vi viene in mente quando vi imbattete in un lavoro classificato come open source? Libero da utilizzare come lo ritenete appropriato? Scoprite cosa significa realmente in questo caso dalla Open Source Initiative.

Dopo averlo letto, volete ancora includere del lavoro open source nel vostro progetto? Farà deragliare il vostro scopo e il vostro obiettivo?

Perché i progetti open source hanno una licenza?#section3

Una ragione per cui i progetti sono concessi in licenza con una licenza open source è per convenienza.

Le licenze open source dicono agli sviluppatori come utilizzare il vostro lavoro e quali limitazioni e restrizioni devono rispettare. Non vorreste un flusso costante di messaggi di posta elettronica da parte di tutti quelli che sono interessati a utilizzare il vostro lavoro: potrebbero essere migliaia di persone.

Allo stesso tempo, le licenze open source rendono facile per altri contribuire a un progetto, al contrario di un sistema chiuso. Immaginate i talenti che potranno contribuire a un progetto open source rispetto a un progetto interno. Sarete in grado di attirare risorse di gran lunga maggiori per raggiungere l’obiettivo del vostro progetto: sì, sarete d’accordo sul fatto che si può ottenere molto di più in questo modo.

La licenza serve come protezione per il creatore di un lavoro o di un insieme di lavori: nessun altro potrà affermare che il vostro lavoro sia loro. Assicuratevi di ottenere i credit che meritate come autori di un progetto.

Leggete ogni licenza, ogni volta#section4#section4

Non tutte le licenze open source sono uguali. Date un’occhiata alla tabella nella Fig. 1 per vedere che tipi di differenze potreste incontrare.

Introduzione alle licenze più popolari#section5

Di seguito sono riportate alcune delle licenze open source più diffuse, con i dettagli su quali poteri o limitazioni vengono imposti per quanto riguarda l’utilizzo e la ridistribuzione.

MIT License#section6

Un progetto con questa licenza open source consente di utilizzare, copiare, modificare, unire, pubblicare, distribuire, sub-licenziare e/o vendere copie del Software e permettere di fare lo stesso alle persone a cui è fornito il software”. Ciò significa che potete utilizzare questo lavoro per il vostro progetto come lo ritenete appropriato (anche vendere opere derivate) con le uniche condizioni che voi 1) lasciate intatta la licenza MIT e 2) includiate un avviso di copyright.

Ciò significa che è necessario includere una nota simile a questa nel file di licenza del vostro lavoro:

Un’altra cosa da notare prima di utilizzare un lavoro con questa licenza è che “Il software MIT concesso in licenza può essere integrato nel software GPL, ma non il viceversa“. Pensate a una situazione in cui dovrete includere dei lavori con le licenze MIT e GPL nel vostro progetto. Alla fine, questa combinazione porterà la licenza GPL, escludendo la licenza MIT. (Potete leggere della licenza GPL qui sotto.)

Apache License#section7

Questa licenza è in qualche modo simile alla licenza MIT. Potete utilizzare i lavori con questa licenza nel vostro progetto a condizione che prendiate nota del fatto che “richiede la conservazione dellacopyright notice e del disclaimer“.

I termini della Apache Licence sono molto rigorosi circa le modifiche. È necessario dichiarare esplicitamente che l’opera originale è stata modificata e includere quanto segue nel vostro avviso di licenza:

GNU General Public License (GPL) 3#section8

Questa licenza non è particolarmente permissiva se confrontata con, ad esempio, la licenza MIT. Tuttavia, promuove notevolmente lo sforzo comunitario ed è una delle licenze open source più popolari là fuori.

Quando utilizzate un lavoro con GPL che rilascerete al pubblico (o ridistribuirete), questa licenza richiede che rendiate disponibili le modifiche (inclusa la documentazione per l’installazione e la creazione) sotto la licenza GPL.

BSD 3-Clause License#section9

Anche questa è molto simile alla licenza MIT: vi permette l’utilizzo per progetti commerciali, la ridistribuzione e la modifica, ma devono essere incluse la nota sul copyright e la licenza BSD stessa.

La scelta tra MIT e BSD dipende ora da ciò che è adatto al vostro progetto. Le licenze MIT e BSD differiscono in termini di compatibilità con altre licenze open source, mentre il lavoro licenziato MIT vi permetterà di includere altri lavori con termini di licenza diversi, il lavoro con licenza BSD non lo permetterà. Di più su questa compatibilità di licenza sotto.

Ci sono diverse altre licenze open source che non sono incluse qui. Richiedono un’attenta lettura e comprensione prima di lanciarsi nell’utilizzo di opere con questo tipo di licenze.

Ignorare i termini di una licenza open source#section10

Valutare quali licenze open source sono adatte si riduce ad evitare future cause legali. I problemi previsti sono problemi mezzo-risolti. Ma cosa succede se ignorate i termini di una licenza?

Sarete perseguiti quando lo si scoprirà? La Free Software Foundation è un’organizzazione che offre come volontarie le proprie risorse per garantire la conformità delle licenze open source: una specie di polizia delle licenze open source. Di seguito è riportata una frase tratto dalla loro pagina di conformità:

Compatibilità delle licenze#section11

E per quel che riguarda l’utilizzo di lavori con licenze open source diverse? Ci saranno delle implicazioni? In altre parole, se state pensando di “mescolare” il lavoro di vari termini di licenza in un progetto, è qui che dovete iniziare a pensare alla compatibilità.

Se delle componenti di codice che sono state concesse sotto condizioni di licenza diverse vengono compilate per formare un nuovo lavoro, si pone una domanda: l’uso comune del codice è consentito in base alla licenza? Se per esempio il codice A sotto licenza X è collegato al codice B sotto licenza Y per formare un nuovo programma, le licenze X e Y devono permetterlo. Se questo è il caso, esiste la compatibilità della licenza.

ifrOSS (The Institute for Legal Questions on Free and Open Source Software)

Magari avete trovato un lavoro open source che si adatta perfettamente al vostro progetto… Ma. La. Licenza. Non. È. Compatibile! Cosa puoi fare per questo?

Innanzitutto, considerate la licenza del lavoro open source che intendete utilizzare nel vostro progetto.

Ovviamente, i problemi di licenza saranno più facili da gestire quando userete lavori open source con la stessa licenza e un modo per evitare l’incompatibilità della licenza consiste nel leggere oltre l’elenco delle feature, dopo aver letto la sezione delle funzionalità, assicuratevi di leggere rapidamente la sezione requisiti.

Quando indagate gli strumenti open source da utilizzare nel vostro progetto, fate della “compatibilità” la vostra compagna. Tenetela vicina.

In termini di compatibilità, la licenza MIT è abbastanza generosa: a partire dal momento in cui questo articolo è stato scritto, questa licenza impedisce solo di citare l’autore del lavoro. Quindi, in generale, un lavoro sotto licenza MIT è ottimo per la maggior parte degli obiettivi. (Ricordatevi che questo non è un consiglio legale).