Licenze OSS: cartina tornasole
In ambito Open source vi sono innumerevoli licenze disponibili. Quali sono le loro differenze salienti? Come orientarsi? In questo breve articolo diamo una serie di indicazioni e spunti di riflessione.
Le licenze OSS nascono per cautelare in primis l’autore, ed in seconda battuta le terze parti (tipicamente delle aziende) che se ne servano. In America il discorso è particolarmente sentito per un paio di ragioni:
- Senza un “disclaimer” standard, qualsiasi artefatto software reso pubblico dall’autore può essere usato per fargli causa in caso di lesioni gravi. Da cui il famoso disclaimer “WITHOUT WARRANTY OF ANY KIND” che chiunque deve includere nel suo codice.
- Il reato di plagio in America è molto grave, perché ricade nelle leggi di protezione del copyright, che sono piuttosto severe.
Negli anni le licenze OSS sono evolute per consentire forme di collaborazione più o meno aperta (Open Source): ultime per apparizione sono l’insieme di licenze Creative Commons, nate per consentire una diffusione controllata delle opere d’ingegno (letterarie, figurative, ecc) e che possono essere applicate anche al software.
Di seguito elenchiamo le licenze OSS in ordine storico di apparizione, evidenziando comunanze e differenze.
Licenze virali di tipo GNU v2 e v3
La licenza GNU è stata scritta da Richard Stallman mel 1991
Le licenze GNU sono di tipo virale. In buona sostanza impediscono che un lavoro derivato possano essere usate per sviluppare un software “closed source” (cioé un software che privi della libertà di avere accesso al codice sorgente).
L’idea alla base è che se vuoi puoi fare un lavoro derivato ma devi per forza concedere ad altri le stesse libertà a cui hai avuto accesso tu.
La GNU non impedisce né di vendere il software né di effettuare consulenza su di esso.
La GNU v3 rafforza ulteriormente il copyright, soprattutto per contrastare il software DRM installato su hardware chiuso (es TiVo).
Non tutti la condividono e per es Linus Torvalds ha tenuto GNU Linux in GPLv2.
Obblighi: se si fa un valore derivato bisogna rendere disponibili anche i sorgenti modificati. Il lavoro derivato ricade sotto la medesima licenza virale
LGPL , GNU Lesser General Public License
La licenze di tipo LGPL si applicano alle librerie (un esempio tipico è la libc del GCC) e consente di indebolire il vincolo sul lavoro “derivato”. Difatti se la libc non fosse LGPL, non sarebbe possibile tenere closed source un programma C compilato con il GCC, perché la licenza GNU della libc si “attaccherebbe” al programma in C che se ne serve, considerandolo derivato. Questo è abbastanza assurdo/impraticabile e per tale ragione è nata la LGPL.
Vedi wikipedia https://en.wikipedia.org/wiki/GNU_General_Public_License per maggiori informazioni
Obblighi:copyright
Eclipse Public License 1.0
Questa licenza consente di mischiare software open source a software chiuso. Richiede che i sorgenti modificati siano accessibili.
Più debole della GPL, ottima per creare un software open source e poi venderlo con plugin commerciali, storicamente creata da IBM per supportare lo sviluppo di WSAD.
Come effetto collaterale ha creato un mercato di prodotti commerciali derivati (es MyEclipse).
BSD oppure MIT License
Questa licenza richiede solo di riconoscere il copyright. E’ molto commercial friendly. Nessuna diffusione del sorgente è richiesta.
Mozilla Public License 2.0
Mix di BSD e GNU. Permissiva come la BSD ma richiede che il lavoro derivato ricada sempre sotto la medesima licenza. Richiede anche la distribuzione dei sorgenti, cosa che invece la BSD non richiede.
Conclusioni
Intorno al 1997 Eric Raymond ed altri introdussero un nuovo termine, “open source” al fine di creare una tipologia di licenza più appetibile alle esigenze aziendali. Il primo esempio di licenza OSI è quella sotto cui è rilasciato il codice sorgente di Netscape Navigator (Mozilla license).
In generale diffidate di qualsiasi licenza non OSI, poiché andrebbe attentamente valutata. Inoltre licenze non OSI tra loro potrebbero risultare incompatibili, rendendo il vostro codice non distribuibile. Affidarsi solo alle licenze OSI più diffuse. Per uno specchietto riepilogativo: http://choosealicense.com/licenses/
Per un riepilogo delle licenze OSI approvate consultare https://spdx.org/licenses/
Un esempio dei problemi di incompatibilità di licenze fu Squeak Smalltalk: sviluppato con una licenza Apple permissiva (ma non OSI) richiese un lavoro legale non indifferente affinché ogni persona che aveva partecipato al progetto concedesse di re-licenziare il proprio lavoro verso una licenza OSI):
The current release of Squeak is a combination of source code originating from Apple which Apple agreed to license under the Apache License and more recent contributions licensed under the MIT license. The vast majority of the code is under the MIT License.
Vedi http://squeak.org/license/