Posso collegarmi a una libreria GPL da un'applicazione closed source?

24

Ok, prima che tutti gridino su domande doppie, sì, ho già visto diverse domande come questa qui. Ma nessuno risponde alla domanda.

Se collego a una libreria GPL-edita senza modificare quella libreria, devo rilasciare il mio codice sorgente?

Secondo questa domanda , la risposta è si!

Ma questa risposta non è soddisfacente per me. La risposta dice fondamentalmente che non posso usare il codice GPL in alcun modo senza rendere il mio codice open source.

Ma se il precedente è vero, ciò indicherebbe che nessuna persona o organizzazione potrebbe mai rilasciare alcun software proprietario su Linux. Quale deve essere sbagliato. Semplicemente perché ogni applicazione possa fare qualcosa di utile, aprire file, scrivere sulla console, creare connessioni TCP, l'applicazione deve essere collegata a libc che è GPL-ed.

Quindi la mia domanda è questa: se la GPL afferma, come tutte le risposte precedenti sul sito dicono, che un programma che si collega ad un altro programma GPL deve essere GPL stesso, come è possibile creare / rilasciare / vendere qualsiasi applicazione proprietaria su Linux? Dal momento che ho descritto sopra, l'applicazione deve essere piaciuta al codice GPL solo per funzionare su Linux.

Un esempio più pratico dice che collego ad una libreria condivisa che è GPL-ed in un'applicazione non GPL, che costringerebbe l'applicazione non GPL a diventare GPL-ed? Più specificatamente se uso una libreria GPL senza modificarla e poi la distribuisco come .so o .dll , sarebbe necessario che la mia applicazione sia open source?

    
posta john-charles 30.07.2012 - 23:52
fonte

3 risposte

30

Se ti colleghi a una GPL lib, hai creato un'opera derivata e il tuo codice deve essere GPL - questo è diverso dal codice L GPL che consente specificamente il collegamento dinamico di codice con licenza diversa Le librerie di sistema incluso libc, sono tutte LGPL.

Esiste anche un'esenzione speciale per le intestazioni del kernel di Linux e libgcc (la libreria implicitamente chiamata dal compilatore).

    
risposta data 31.07.2012 - 00:22
fonte
6

Nel caso generale, hai ragione nel senso che non puoi collegarti a una libreria GPL, distribuire il tuo codice e quindi non rilasciare il tuo codice come GPL.

Tuttavia, vi è l' Ecologia delle librerie di sistema che spiega come le persone si collegano alle librerie e alle librerie Linux rilasciare il loro prodotto con licenze non GPL.

Un'altra eccezione è quando le due licenze sono compatibili l'una con l'altra. Controlla la pagina di licenza compatibile della FSF per ulteriori letture.

Infine, gli autori della GPL'd lib possono creare eccezioni specifiche, ad esempio per uso non commerciale o hobbista.

Sfortunatamente, ci sono troppe potenzialità per avere una regola dura e veloce. Senza ulteriori dettagli nella tua domanda, la tua risposta è "probabilmente non puoi, ma forse puoi".

    
risposta data 31.07.2012 - 02:51
fonte
0

La risposta breve è che nessuno lo sa davvero. (Questa discussione riguarda GPL non LGPL.)

La GPL ha un linguaggio vago su "Opere derivate", che diverse persone interpretano in modi diversi. Il consenso sembra essere che il collegamento statico vìola, ma la chiamata tramite interrupt di sistema (ad esempio al Kernel Linux) non lo fa. Quest'ultimo si basa principalmente sul fatto che aziende come Oracle vengono fornite su Linux e non sono state citate in giudizio - non è chiaro nella licenza.

Il collegamento dinamico non è chiaro, probabilmente 70/30 dicono che viola. Chiamando un programma usando pipe o chiamate di procedure remote, probabilmente 30/70 non viola, anche se questo essenzialmente è la stessa cosa. La chiamata tramite COM o l'uso di Java Jar non è completamente chiara.

In sostanza, se c'è qualche dubbio, e non ti piacciono gli avvocati, allora stai lontano dalla GPL.

    
risposta data 15.08.2016 - 08:30
fonte

Leggi altre domande sui tag