Se vi è mai capitato di parlare di informatica con un sostenitore del "software libero", avrete sicuramente sentito, almeno una volta, una frase del genere: "con il software open source ci puoi fare quello che vuoi, perché è tutto libero".
In verità, questa affermazione non è del tutto corretta: anche il mondo del free software, di cui Linux è l'esponente più famoso, ha le proprie licenze d'uso, ed in questi documenti sono tracciati molto chiaramente i limiti di quello che è concesso fare e quanto, invece, non è permesso.
Prima di scatenare una polemica, capiamoci bene: le licenze open source sono estremamente più permissive di quelle che accompagnano i programmi a codice chiuso. Da qui a sostenere però che "è possibile fare quello che si vuole", il passo è tutt'altro che breve.
Tante licenze, tutte "molto complete"
Il primo problema da affrontare riguarda il fatto che, sebbene generalmente si parli di "software open source", in verità non esiste una sola licenza a tutela del software a codice aperto. Ne esistono almeno una cinquantina, ognuna delle quali impone regole differenti, perdendone alcune ed introducendone altre.
Ad aggravare la complessità della situazione, vi è anche il fatto che queste licenze sono state scritte per avere un valore giuridico: come tali, questi testi sono particolarmente dettagliati e finiscono per spiazzare l'utente che è interessato a comprenderne solamente gli aspetti più pratici.
Nel corso di questo articolo, cercherò di presentare le licenze più diffuse in modo quanto più conciso possibile, sottolineando le limitazioni imposte e come queste si traducano nell'utilizzo pratico.
Attenzione, però: non sono un avvocato, e non ho assolutamente la pretesa di tracciare un quadro completo. Raccomando quindi di prendere contatto con un legale qualificato prima di trarre conclusioni basate su quanto esposto nel prosieguo.
Prima di partire
Prima ancora di iniziare la trattazione, vediamo di accomunare le libertà garantite da tutte le licenze che andremo poi ad esaminare in dettaglio:
- È possibile utilizzare il software in modo gratuito sia in ambito personale, sia in quello professionale. In altre parole, potete generalmente installare una distribuzione Linux su tutti i PC dell'ufficio senza dover versare un euro in licenze d'uso
- È possibile prendere, copiare e distribuire software libero senza problemi. Se quindi volete realizzare un CD con Firefox e Thunderbird e darlo a tutti i vostri amici, potete farlo senza problemi.
- È possibile richiedere un corrispettivo per la distribuzione di tali programmi. Siete quindi liberi di vendere il suddetto CD per la cifra che preferite, indipendente dal fatto che questa sia prossima all'euro che serve a pagare il supporto, oppure arbitrariamente maggiore.
- È sempre possibile prendere il listato di un programma rilasciato con una licenza open, modificarlo per i propri scopi e non doverne rendere contro a nessuno
Ma allora... non vi sono limiti? Non esattamente: in caso decideste di condividere con altri il vostro lavoro, oppure il ripubblicare il lavoro di altri, oppure il risultato di una modifica o un miglioramento apportato ad un programma open source, dovrete sottostare a vincoli ben precisi.
GNU General Public License (GPL) è la licenza open source più famosa, probabilmente perché è quella che tutela lo stesso Linux.
Ne sono state realizzate molteplici versioni successive, allo scopo di chiarire alcuni concetti che potessero risultare ambigui o adattare le clausole all'evolversi della tecnologia.
La filosofia alla base di GPL è indubbiamente molto articolata (per un approfondimento, si veda "GNU/Linux: la rivoluzione culturale"), ma in linea di massima è incentrata sul garantire ogni libertà agli individui, a patto che questi siano disposti a garantire lo stesso diritto agli altri.
Ogni programma con il proprio sorgente
In caso uno sviluppatore desiderasse distribuire il risultato delle sue fatiche con licenza GPL, è chiamato a pubblicare sempre il codice sorgente a fianco della consueta versione già compilata.
Sono concesse alcune deroghe circa tempi e modalità (ad esempio, il sorgente può trovarsi su un server distinto), ma, in linea di massima, lo sviluppatore deve sincerarsi che ottenere il sorgente comporti un livello di difficoltà e costi equivalente a quello necessario per ottenere il binario.
Ogni programma deve essere accompagnato una copia della licenza
GPL prevede che tutte le opere da essa tutelate includano anche una copia del testo completo dalla licenza d'uso stessa, nella quale sono illustrate le libertà garantite e gli obblighi da rispettare.
Per preservare la massima chiarezza nel tempo, non è concesso sostituire la licenza con un semplice link: deve essere veicolato il testo completo vero e proprio.
Nessun vincolo, fino a quando non si distribuisce
L'utente è libero di prendere qualsiasi listato rilasciato sotto GPL e modificarlo a proprio piacimento.
Fino a quando il lavoro derivato da questo rimane all'interno di un ambito circoscritto, l'utente non è chiamato a rendere disponibile il codice sorgente dell'applicazione derivata.
Tale diritto si estende anche agli ambienti professionali: è quindi assolutamente lecito prendere, ad esempio, un software gestionale rilasciato sotto GPL, adattarlo alle specifiche esigenze della propria realtà lavorativa, e quindi utilizzare la versione così ottenuta senza essere costretti a pubblicare il codice sorgente della stessa.
Se rendi disponibile al pubblico, serve anche il sorgente
I vincoli di GPL divengono più stringenti in caso si desiderasse rendere disponibile al pubblico (e, quindi, anche "vendere") un programma tutelato da tale licenza oppure un suo derivato.
In tale circostanza, il soggetto è chiamato ad utilizzare la stessa licenza GPL, e non è concesso imporre vincoli più restrittivi.
Il concetto è espresso molto chiaramente da Richard Stallman, ideatore di GNU, nel corso del documento "Copyleft: Pragmatic Idealism":
I programmatori che scrivono miglioramenti per GCC (o Emacs, o Bash, o Linux, o un qualsiasi programma coperto dalla GPL) lavorano spesso per aziende o università. Quando il programmatore vuole offrire questi miglioramenti alla comunità e vedere il suo codice incluso nella versione successiva del programma in questione, il suo capo potrebbe dire: "Fermo lì! Il tuo codice appartiene a noi! Non vogliamo condividerlo con altri; abbiamo deciso di trasformare la tua versione migliorata in un prodotto proprietario". Qui viene in aiuto la GNU GPL. Il programmatore mostrerebbe al capo che un tale prodotto proprietario sarebbe una violazione del diritto d'autore e il capo capirebbe che ci sono soltanto due possibilità: rilasciare il nuovo codice come software libero o non rilasciarlo affatto.
In altre parole, se si desidera rendere disponibile al pubblico un lavoro derivato da un software GPL, è indispensabile che venga rilasciato a propria volta anche il nuovo codice sorgente, e che sia garantito il diritto di modificare anche questo nuovo prodotto secondo le stesse modalità.
Non importa che le modifiche siano sostanziali come una profonda riscrittura di certe funzioni, minime come la variazione di poche stringe di testo o, ancora, che si tratti dello stesso programma "rimarchiato": quello che importa è che, in caso si decidesse di distribuirlo al pubblico, sia reso disponibile anche il sorgente di ogni versione derivata con le stesse modalità previste da GPL.
Finché c'è il sorgente, si può anche vendere
Nulla vieta di vendere un software tutelato da GPL: l'importante è che venga garantita anche la presenza del codice sorgente.
È evidente però che l'acquirente potrà poi scegliere di rendere disponibile a terzi tale lavoro in modo completamente legale.
Non si tratta di una contraddizione: vendendo software tutelato da GPL, il commerciante non è retribuito per il prodotto in sé, ma piuttosto per il servizio erogato, ovvero il "rendere disponibile" il prodotto.
Niente linking da applicazioni closed
Un altro limite che deve essere tenuto bene a mente da chi realizza programmi derivati riguarda l'impiego di librerie coperte da licenza GPL.
Il cosiddetto static linking (ovvero la copia, compiuta in fase di compilazione, di codice contenuto in una libreria esterna all'interno dell'eseguibile principale) è consentito solamente all'interno di programmi che vengano poi rilasciati con la medesima licenza.
In altre parole, non è possibile realizzare un programma closed source utilizzando librerie tutelate da GPL.
Un esempio per capire
Come scenario pratico, si pensi a questa circostanza. Uno sviluppatore ha reso disponibile con licenza GPL una libreria che espone funzioni che consentono la creazione di grafici d'ogni tipo (istogrammi, a torta e via dicendo).
Un'azienda sta sviluppando un software di analisi finanziaria, e vorrebbe quindi utilizzare le funzioni esposte dalla libreria open per mostrare diagrammi al suo interno.
Ai sensi della licenza GPL, tale operazione è permessa solamente a patto che anche l'intero applicativo finanziario sia rilasciato sotto licenza GPL.
Arriva LGPL
Appare evidente che si tratta di un limite piuttosto pericoloso: il programma completo potrebbe essere infatti estremamente ampio, mentre il codice della libreria adibita ai grafici solo poche centinaia di righe.
Si crea quindi una situazione per cui l'utilizzo di un frammento di codice che può costituire una piccola percentuale del totale che costituisce il programma costringe l'azienda a rilasciare il tutto sotto GPL. Una scelta che, all'atto pratico, potrebbe condurre l'azienda a desistere.
Per ovviare a questa situazione, la licenza GPL è disponibile anche in una declinazione specifica, denominata GNU Lesser General Public License (LGPL).
LGPL è pressoché identica alla GPL tradizionale, non fosse per il fatto che il limite relativo all'utilizzo di librerie statiche all'interno di applicazioni non-open è assente: questo significa che è possibile utilizzare librerie LGPL anche all'interno di programmi a codice chiuso.
Starà però al programmatore che ha rilasciato la libreria stessa scegliere di preferire LGPL rispetto alla più restrittiva GPL: questa è però una scelta influenza solamente dagli scopi del singolo sviluppatore.
L'eccezione del "dynamic linking"
Una importante eccezione a quanto appena detto riguarda le librerie studiate per essere linkate dinamicamente (dynamic linking, di cui le .dll di Windows sono l'esempio più famoso).
Poiché il codice di tali componenti viene sì utilizzato, ma mai copiato all'interno del programma vero e proprio (e sarebbe quindi alquanto difficile sostenere che possa trattarsi di un "lavoro derivato), l'impiego di librerie di questo tipo è sempre concesso, anche all'interno di programmi closed source.
Questo è vero indipendentemente dal fatto che la libreria stessa sia rilasciata con licenza GPL o LGPL.
Ogni derivato, con un proprio nome
Per evitare l'enorme confusione che sarebbe generata in caso contrario, GPL impone che l'autore inserisca il proprio nome come parte integrante di ogni versione derivata.
Nessuna variazione al testo della licenza
Il testo della licenza è coperto da copyright, e non ne è consentita la modifica.
In particolar modo, non è generalmente permesso di realizzare licenze derivate che introducano limitazioni aggiuntive rispetto a quelle già presenti.
Fonti e approfondimenti
- Frequently Asked Questions about the GNU Licenses
- A Quick Guide to GPLv3
- How to use GNU licenses for your own software
- GNU General Public License v3.0
Con la dicitura "licenze BSD", si identifica un gruppo di licenze software studiate per favorire la diffusione di software libero.
L'acronimo sta per Berkeley Software Distribution, ovvero un sistema operativo di stampo UNIX realizzato sul finire degli anni 70 presso l'Università di Berkeley in California. Il modello di licenza ha quindi assunto il nome del primo software rilasciato secondo tali modalità.
Le licenze BSD sono più permissive della già tratta GPL: la differenza principale è costituita dal fatto che, mentre GPL impone che ogni lavoro derivato sia rilasciato secondo le stesse modalità, le licenze BSD consentono di modificare e ridistribuire software anche con modalità differenti.
Possibilità di creare opere derivate closed source
Non imporre la necessità di mantenere le stesse modalità di licenza per i software derivati porta ad una conseguenza significativa: è possibile riutilizzare codice tutelato da BSD anche in prodotti proprietari, del quale non si desidera distribuire il codice sorgente.
Nulla vieta, allo stesso modo, di prendere un software completo tutelato da licenza BSD e trasformarlo in un prodotto a pagamento: la versione "libera" rimarrà comunque disponibile, ma con un po' di impegno sul fronte commerciale, un'azienda senza troppi scrupoli potrebbe sicuramente ricavare profitti interessanti, pur rimanendo completamente nella legalità.
Vi sono comunque alcune clausole importanti che devono essere rispettate.
Dare credito all'autore originale
La prima clausola imposta dalle licenze BSD è tesa ad impedire che qualcuno si prenda il merito per il lavoro svolto da altri.
Anche in caso siano effettivamente state apportate migliorie, i termini prevedono che la nota di copyright originale (qualcosa del tipo Copyright (c) 1994-2009 Mario Rossi) venga mantenuta anche in ogni lavoro da essa derivato.
Tale vincolo è slegato dalla necessità di rendere disponibile il codice sorgente: in questo caso, la nota di copyright dovrà però essere inserita "nella documentazione o in altro materiale fornito con la distribuzione".
Rendere accessibili i termini della licenza
Oltre al nome dell'autore, le licenze BSD prevedono che ogni opera derivata consenta di accedere al testo completo della licenza stessa, comprensiva delle clausole e della nota inerente i termini di garanzia (trattati di seguito).
Utilizzare il nome dell'autore solo con il suo consenso
Non è possibile utilizzare il nome dell'autore originale per scopi differenti dal riconoscimento del lavoro svolto nella nota di copyright senza l'autorizzazione scritta dell'interessato.
Questa clausola è stata introdotta per impedire che alcuni malfunzionamenti causati da modifiche apportate da terzi possano danneggiare la reputazione del primo autore.
Nessuna garanzia espressa
L'ultima clausola esclude esplicitamente ogni forma di garanzia: il software è fornito "così com'è", e l'utente che scegliesse di utilizzarlo non ha alcun diritto di rivalsa in caso di problemi o danni causati dal programma.
Possibilità di modificare la licenza
Al contrario di quanto visto con GPL, ogni sviluppatore è libero di prendere a modello una licenza BSD e modificarla secondo le proprie necessità.
Quella a tutela del sistema operativo NetBSD ad esempio, non prevede il vincolo di non impiegare il nome dello sviluppatore originario in progetti derivati: un eventuale clone potrebbe quindi utilizzare come messaggio promozionale "Un NetBSD ancora migliore!" pur rimanendo all'interno dei limiti di utilizzo previsti dalla licenza.
Fonti e approfondimenti
La licenza MIT è una particolare declinazione dalla famiglia BSD.
Tale licenza prende il nome da Massachusetts Institute of Technology, università statunitense nella quale è stata ideata.
Si tratta fondamentalmente di una licenza BSD alla quale è stato rimosso il limite di non impiegare il nome dello sviluppatore originale per la promozione di progetti derivati.
Le uniche due clausole che permangono sono quindi:
- Mantenere il testo completo della licenza nelle opere derivate, comprensivo della clausola di esclusione della garanzia
- Mantenere la nota di copyright relativa all'autore originale
Confrontando l'accodo a tutela del già citato NetBSD con quello di un prodotto distribuito con licenza MIT, emergono differenze minime: si tratta principalmente dei medesimi concetti, espressi con parole differenti.
Ho comunque scelto di citare a parte la licenza MIT poiché è piuttosto diffusa, ed utilizzata anche da software famosi: il progetto Mono impegnato nella realizzazione di strumenti open source compatibili con l'architettura .NET di Microsoft, la libreria Javascript jQuery, l'emulatore di terminale PuTTY, la web application MooTools (utilizzata anche da MegaLab.it) ed il client BitTorrent per Mac Transmission sono solo alcuni dei più noti applicativi che la impiegano.
Fonti e riferimenti
Mozilla Public License (MPL) è la licenza realizzata da Mozilla Foundation per regolare l'uso di Firefox, Thunderbird e tutti gli altri software editi dal gruppo.
[Nota: Mozilla rilascia tutti i propri prodotti con un modello di tri-licenza MPL, GPL, LGPL al fine di superare alcuni problemi di compatibilità che potrebbero venirsi a creare. La trattazione seguente si concentra su un ipotetico software rilasciato con sola licenza MPL.]
MPL è però utilizzabile liberamente per tutelare qualsiasi software open source, non solo quelli realizzati da Mozilla, ed è stata quindi scelta anche per altri progetti indipendenti.
Fondamentalmente, si tratta di una via di mezzo fra i requisti molto rilassati previsti dalla famiglia di licenze BSD e le più stringenti limitazioni inerenti la disponibilità del codice sorgente anche per i progetti derivati imposte da GPL.
Sì anche per progetti closed
I programmi tutelati da MPL possono essere legalmente integrati all'interno di progetti più ampi, anche se poi questi dovessero essere distribuiti solamente nel formato binario.
Come abbiamo visto nelle pagine scorse, tale possibilità è offerta anche dalle licenze BSD, ma espressamente proibita da GPL.
Contrariamente alle BSD però, MPL introduce una precisazione. Si tratta di una clausola incentrata sul concetto di "modifica".
MPL richiede che tutti i file che contengono parti di codice estrapolate da programmi da essa tutelati siano resi disponibili anche nel formato testuale, e secondo gli stessi termini. Tutti i file che compongo il progetto derivato ma sono realizzati ex novo, possono invece rimanere privati.
Un esempio per capire
Un'azienda sta pensando di realizzare un nuovo browser web, del quale non desidera distribuire il codice sorgente.
I programmatori sono intenzionati ad utilizzare Gecko, lo stesso motore di rendering alla base di Firefox, all'interno dell'applicazione.
Poiché tale componente è rilasciato sotto licenza MPL, l'azienda sarà chiamata a rendere disponibile a propria volta il codice sorgente dei file che compongono Gecko, ma potrà scegliere di mantenere privato tutto il resto.
Gli sviluppatori dovranno chiaramente prestare attenzione a non modificare il sorgente del motore stesso: secondo quanto previsto dai termini di MPL infatti, la software house sarebbe altrimenti costretta a rendere disponibili anche tali variazioni.
Fonti e riferimenti
Apache License è una licenza open source realizzata da Apache Software Foundation (ASF), la fondazione incaricata di organizzare le attività di sviluppo di una cinquantina di progetti liberi, fra i quali il celebre Apache HTTP Server è il più famoso.
Anche in questo caso però, la licenza è utilizzabile da qualsiasi sviluppatore interessato, anche in caso non fosse associato ad ASF. Il risultato è che sono più di 5.000 i progetti disponibili su SourceForge distribuiti con le modalità da essa previste.
Attribuzione, innanzitutto
Il vincolo più importante imposto da questa licenza è la necessità di dare credito all'autore originale in ogni progetto derivato.
Restrizione nell'uso dei marchi
Non è concesso di utilizzare il logo o il nome di Apache Software Foundation o dello sviluppatore originale nel proprio progetto (se non per l'indispensabile attribuzione) ed è in particolar modo è proibito sostenere che il programma derivato è stato realizzato con l'approvazione o il supporto degli autori originali.
Accludere un riferimento al testo della licenza
L'autore di progetti derivati è chiamato ad inserire nel proprio lavoro un riferimento al testo della licenza.
È possibile scegliere di copiare integralmente il testo oppure rendere disponibile un URL che consenta di raggiungere il documento via Internet.
Sì anche per la realizzazione di programmi closed
Rispettando tali requisiti, la licenza Apache consente di utilizzare porzioni di codice, oppure realizzare interi progetti derivati, senza la necessità di rendere disponibile il sorgente.
Contrariamente a quanto previsto da MPL (trattata alla pagina precedente), i termini non prevedono nemmeno l'obbligo di rendere disponibili i sorgenti del progetto originale.
Fonti e approfondimenti
Sebbene Microsoft sia considerata la prima avversaria del software libero, anche il monopolista ha predisposto un proprio modello di licenza a tutela del codice open source.
Tale famiglia di licenze, liberamente adottabile dagli sviluppatori interessati a tutelare le proprie realizzazioni, ricade sotto il nome di "Shared source" ("sorgente condiviso").
Come spesso avviene quando è coinvolto il gigante di Redmond, l'offerta è particolarmente ampia: sono infatti in totale cinque le licenze che costituiscono Shared source, sebbene solo due di esse siano state accettate come licenze open source a tutti gli effetti da open source Initiative (OSI).
Tale diversificazione è stata pensata per consentire agli sviluppatori di scegliere il livello di libertà da condere in maniera più granulare: si spazia dalla possibilità di visualizzare il codice senza però modificarlo, fino ad un modello più permissivo.
Microsoft Public License (Ms-PL)
La licenza Microsoft più permissiva è la Ms-PL. Il codice da essa tutelato può essere modificato e ridistribuito in forma binaria a patto di mantenere intatte le note di copyright ed attribuzione presenti.
Un prodotto derivato può anche essere commercializzato, senza l'obbligo di ridistribuire né il sorgente originale, né le modifiche ad esso apportate.
In caso si desiderasse modificare e/o ridistribuire il codice sorgente stesso oltre alla versione compilata però, sarà necessario impiegare la stessa licenza Ms-PL ed includerne una copia nel progetto.
A meno dell'attribuzione, anche questa licenza esclude esplicitamente il permesso di usare il marchio, il logo o il nome dell'autore originale in progetti derivati.
Microsoft Reciprocal License (Ms-RL)
Ms-RL è un tipo di licenza piuttosto simile alla già descritta MPL nella sostanza.
In pratica, sono presenti le stesse clausole di Ms-PL, ma in più è richiesto che l'autore di programmi derivati distribuisca anche il codice sorgente di ogni file dell'applicazione originale che è stato usato, comprensivo di eventuali modifiche.
I sorgenti distribuiti in questo modo dovranno essere obbligatoriamente coperti dalla stessa Ms-RL.
Tutto il lavoro "originale" contenuto in file differenti invece, può anche essere mantenuto privato.
Per un esempio pratico, ci si può riferire a quello del browser web proposto durante la trattazione di MPL.
Le altre licenze
Microsoft propone anche altre tre licenze nella famiglia shared source: Microsoft Reference Source License (Ms-RSL), Microsoft Limited Public License (Ms-LPL) e Microsoft Limited Reciprocal License (Ms-LRL).
Si tratta di documenti non riconosciuti da OSI come licenze open source propriamente dette, poiché dettano limitazioni troppo forti: Ms-RSL consente solamente di visionare il codice sorgente senza però poterlo modificare o riutilizzare in alcun modo, mentre la seconda e la terza sono i corrispettivi delle già citate Ms-PL e Ms-RL con una clausola aggiuntiva: sono valide solamente per gli sviluppatori che scelgano di realizzare programmi per Microsoft Windows.
Fonti e riferimenti
- open source Licenses su Microsoft .com
- Microsoft Reference Source License (Ms-RSL) su Microsoft.com
- Microsoft Limited Public License (Ms-LPL) su Microsoft.com (via Archive.org)
- Microsoft Limited Reciprocal License (Ms-LRL) su Microsoft.com (via Archive.org)
Abbiamo concluso il nostro viaggio nelle pieghe delle più famose ed utilizzate licenze open source. Ne esistono in vero moltissime altre, alcune dedicate ai programmi, altre espressamente studiate per essere applicate a documentazione, articoli ed altro materiale testuale.
Purtroppo però, non mi è possibile prenderle in considerazione tutte: reputo comunque che quelle trattate in questo articolo siano le più significative per il modo del software.
Riassumendo
Abbiamo visto che esistono differenze piuttosto significative fra le varie licenze.
Allo stesso modo, è bene ribadirlo, tutte introducono limitazioni e clausole aggiuntive solamente dal momento in cui uno sviluppatore è interessato a ripubblicare il codice da esse tutelato.
Per quanto riguarda l'utente finale invece, o il programmatore che sceglie di realizzare applicativi derivati senza però rendere disponibile al pubblico il proprio lavoro, la libertà è pressoché assoluta.
GPL è la licenza per i puristi: scegliendola per il proprio lavoro, si dichiara di voler rendere disponibile il codice solamente a chi vorrà utilizzarlo o in un ambito limitato, oppure con la chiara intenzione di condividere a propria volta le modifiche apportate.
La famiglia BSD (comprensiva della licenza MIT) prevede gli accordi più permissivi di tutti quelli analizzati: se siete d'accordo che il vostro lavoro possa essere utilizzato anche i progetti closed source a patto che vi venga dato credito, orientatevi in tale direzione.
Mozilla Public License è una via di mezzo fra le due: è concesso l'utilizzo in programmi closed, ma tutte le modifiche apportate ai vostri sorgenti dovranno comunque essere pubblicate.
Apache License è, in fondo, piuttosto simile ad una BSD, e valgono quindi le stesse considerazioni espresse in precedenza.
La famiglia Shared source di Microsoft propone infine una licenza pubblica piuttosto permissiva ed una sorta di MPL con il marchio del gruppo. Le altre tre licenze non sono invece approvate dall'organizzazione che regola il mondo del free software e, come tali, dovrebbero essere tralasciate da chi ha scelto di distribuire i propri programmi rendendo disponibile anche il codice sorgente.
Una raccomandazione conclusiva
In un'ottica di massima chiarezza, ripeto di nuovo quanto detto in apertura: non sono un avvocato, e non ho assolutamente la pretesa di essere riuscito a tracciare un quadro completo e preciso della situazione. Raccomando vivamente di prendere contatto con un legale qualificato prima di trarre conclusioni basate su quanto esposto, soprattutto in ambito aziendale.
MegaLab.it rispetta la tua privacy. Per esercitare i tuoi diritti scrivi a: privacy@megalab.it .
Copyright 2008 MegaLab.it - Tutti i diritti sono riservati