A letto con il GPL
Posted on 10 febbraio, 2008
Archiviato in Legal , Open Source , Web 2.0 | 2 Commenti
Oggi ci sono un sacco di equivoci e confusione su quello che usi di software GPL può costringere una società a loro software open source. Dopo aver eseguito in questo problema alla Disney, Sony e start-up diversi, questo articolo ha lo scopo di chiarire la mia comprensione e spero aiutare pochi altri a prendere decisioni informate. Si prega di notare che io non sono un avvocato e questo articolo non devono essere considerate come un sostituto per la lettura del GPL e di ottenere consulenza legale specifica da un avvocato di licenza.
Mentre ci sono molte licenze meno restrittive ( MIT, BSD, MPL, ecc ) il GPL è forse il meno compreso e più temuta da parte delle imprese. In una certa misura questa confusione non deve essere una sorpresa. L'(Software Libero e Open Source) FOSS movimento è costituito da una serie di attivisti che hanno ideali leggermente diverse. Dal momento che una legge si basa fortemente su misura intento e trattamento coerente, le incongruenze in questo approccio le acque fangose. Quando nel corso del tempo il leader del movimento fanno dichiarazioni contraddittorie riguardanti lo scopo e l'intento alla GPL, questo inietta Paura L'incertezza e dubbio (FUD).
A rendere le cose ancora più confuse, la legge sul copyright è anche in forma triste in relazione agli inquilini di base che il GPL si basa. Per il software, ciò che costituisce fair use e le opere derivate sono in contrasto in giurisprudenza. Da un estremo, la giurisprudenza ne deduce che un prodotto è derivato anche se è stato copiato nessun codice dal sistema con cui interagisce. Dall'altro, deduce contrastanti della giurisprudenza che si tratta di Fair Use per reverse engineering un sistema per utilizzarlo senza preoccuparsi di essere considerati derivati.
Quale di questi precedenti si pensa andrà a finire è potenzialmente casuale e dipende molto dal modo in cui usiamo il codice. Senza esclusioni esplicite stabilite dagli sviluppatori dobbiamo tornare l'intento degli autori della licenza stessa. In questo caso la Free Software Foundation incantesimi specificamente le sue credenze. Nella loro interpretazione della GPL il programma è derivato, se si includono codice GPL o linkare a GPL il codice in alcun modo (dinamico o statico).
Ci sono diverse eccezioni a questa regola riconosciuta tale che il programma non può essere considerato un lavoro derivato.
- Si può collegare dinamicamente contro una interfaccia standard dove altre librerie esistenti può essere sostituito.
- Si può eseguire un programma GPL tramite fork () o execute ().
- Si può comunicare con un programma tramite rete standard e meccanismi di IPC. *
- Si può distribuire il programma e un programma GPL in forma aggregata (sullo stesso supporto) a condizione che siano ancora rappresentano programmi separati ed i termini della GPL sono stati osservati.
Queste eccezioni ci danno abbastanza corda per utilizzare programmi GPL e biblioteche in collaborazione all'interno di un più ampi sistemi closed source. In cima a questi alcuni sviluppatori possono aggiungere ulteriori eccezioni esplicite come permettere dinamico ( LGPL linkage) o statici. In alcuni casi può anche essere possibile contattare gli sviluppatori e negoziare una licenza closed source che rimuove i limiti della GPL tutti insieme.
C'è una scappatoia altro notevole. La GPL calci solo quando si distribuisce il programma derivato. Se non si distribuisce un programma derivato da persone al di fuori della vostra azienda non dovete distribuire il closed source. Potete anche usare software derivato GPL come un servizio e caricare i soldi per esso senza rilasciare alcun codice.
In pratica questa scappatoia ha un paio di grattacapi. Il primo è che non si può vendere o dare il programma derivato ad un'altra società o persona. La seconda che molti non considerano è che durante alcune di M & A operazioni che la società sta vendendo il patrimonio piuttosto che la fusione delle società e vendere le attività che può anche essere considerata una distribuzione.
Ovviamente come per ogni licenza software (FOSS o commerciale) si dovrebbe essere consapevoli delle questioni relative ai brevetti, l'indennizzo, restrizioni di licenza aggiuntiva (ad esempio GPL3 limita DRM) e il costo totale di proprietà relativi alla manutenzione e supporto. Come con qualsiasi cosa che facciamo come le società vi è di più per la linea di fondo rispetto al cartellino del prezzo in arrivo dalla porta.
L'altra cosa da considerare è la percezione del pubblico e il movimento FOSS. Si utilizza un software FOSS e il contratto implicito è che parteciperà alla comunità e contribuire con miglioramenti. Non è sufficiente utilizzare FOSS, si dovrebbe adottare una politica che stabilisce come si utilizzano FOSS e come lo supportano. Lavorare con gli sviluppatori FOSS ed essere un buon cittadino va un lungo cammino.
Riferimenti:
http://www.gnu.org/copyleft/gpl.html
http://www.gnu.org/licenses/old-licenses/gpl-2.0.html
http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html
http://www.fsf.org/licensing/licenses/gpl-faq.html
http://www.bu.edu/law/lawreview/v85n5/Stoltz.pdf
http://www.linuxinsider.com/story/38089.html?welcome=1202601329&welcome=1202602307
http://en.wikipedia.org/wiki/Free_software_licenses
http://en.wikibooks.org/wiki/FOSS_Licensing/Scenarios
Scridb filtro
Commenti
Come qualcuno ha recentemente ricordato in una mailing list, il GPL sembra molto arbitraria nel senso che non c'è bisogno di distribuire i sorgenti se fornisci un servizio, ma si fa se si fornisce un prodotto. In altre parole, la GPL promuove il software-come-servizi su software-as-prodotti.
Perché qualcuno dovrebbe creazione di software con una interfaccia XML-RPC arriva a mantenere le loro mods privati mentre qualcuno distribuisce una biblioteca essere costretto a rivelare la loro mods?
Ricerca
Archivio
Blogroll
Admin
 |  |  |  |  |  |  |  |  |  | ||||||||||||||||||||||||||||||||||||||
Ciao Chuck,
Guardare ad esso come un outsider Penso che ci siano una serie di fattori.
1) La GPL cuciture a essere progettato per ridefinire i ruoli di programmatori da parte dei produttori IP in fornitori di servizi. Con il software client del servizio è semplicemente un diverso modello (consulenza, personalizzazione, ecc).
2) E 'più difficile da applicare sul server. Sarebbe semplice per nascondere l'uso di software GPL.
3) Non consentendo così al software di essere monetizzato come servizio limita l'adozione dei prodotti.
In poche parole la limitazione software GPL utilizzare come servizio limiterebbe la sua adozione, l'utilità e l'applicabilità. Anche ricordare che il proprietario del software GPL può doppia licenza del prodotto e salse non è vincolato da licenza GPL.
Mentre faccio utilizzare alcuni software GPL, io preferisco le licenze molto meno restrittiva e virali, anche come servizio. Ogni uso di software, commerciale o FOSS, richiede un po 'di due diligence per determinare l'idoneità fisica e il costo totale di proprietà.
Ci sono molti fattori che portano al successo o il fallimento di un progetto FOSS, la licenza è uno degli elementi che possono aggiungere attrito per l'adozione. Stiamo già vedendo una divisione e duplicazione degli sforzi a causa di requisiti di licenza. Sarà interessante vedere come ogni licenza compete.
-Marty
- lo spam
- offensiva
- dissentire
- off topic
Come