Posso collegarmi a una libreria GPL da un'applicazione chiusa?

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

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

Secondo questa domanda , la risposta è sì!

Ma questa risposta non è soddisfacente per me. La risposta sostanzialmente dice 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é qualsiasi applicazione possa fare qualcosa di utile, aprire file, scrivere sulla console, creare connessioni TCP, l'applicazione deve essere collegata a libccui è GPL-ed.

Quindi la mia domanda è questa: se la GPL afferma, come dicono tutte le precedenti risposte sul sito, che un programma che si collega a un altro programma GPL deve essere GPL stesso, come è possibile creare / rilasciare / vendere qualsiasi applicazione proprietaria affatto che funziona su Linux? Da come ho descritto sopra, l'applicazione deve essere apprezzata per il codice GPL solo per essere eseguita su Linux.

Un esempio più pratico dice che collego a una libreria condivisa che è GPL edita in un'applicazione non GPL, ciò costringerebbe l'applicazione non GPL a diventare GPL ed? Più precisamente se uso una libreria GPL senza modificarla e quindi la distribuisco come .soo .dll, richiederebbe che la mia applicazione fosse open source?

gpl linking

— john-charles
fonte

Continui a porre la stessa domanda nella speranza di una risposta diversa. Non è possibile utilizzare GPL in software non compatibile con GPL. Semplicemente morto.

— Andrew T Finnell,

Davvero? Accidenti. La risposta è semplice; perché non ti metti in contatto con gli autori del programma GPL e chiedi loro se le dispiace? Se dicono che va bene è grandioso! Se si oppongono, quindi cercare di armarli con dettagli legali ti renderà molto impopolare, non importa quanto "giusto" ti senti di essere.

— James,

@James: Se hanno scelto GPL, è abbastanza forte dichiarazione che fanno mente. Le persone a cui non importa scelgono MIT o BSD o LGPL in primo luogo. È molto raro vedere una libreria sotto GPL completo. Quando lo fai, puoi essere quasi certo che fosse intenzionale.

— Jan Hudec,

@Jan Forse, dipende dall'app e dall'uso previsto di john-charles. Ma penso solo che sia strano come JC si stia avvicinando a questo. Jc sta solo cercando di ottenere la risposta che vuole? Ci sono molte domande su questo sito che potrebbero essere risolte con un "solo parlare con loro, per gridare ad alta voce". :-)

— James

@JanHudec: sono d'accordo. Ho sostenuto di rilasciare parte dell'IP della nostra azienda sotto forma di libreria GPL, dal momento che sarebbe essenzialmente inutile per i nostri concorrenti e comunque molto utile per la nostra comunità.

— MSalters,

Risposte:

Se si collega a una libreria GPL, è stata creata un'opera derivata e il codice deve essere GPL: questo è diverso dal codice GPL L che consente specificamente il collegamento dinamico di codice con licenza diversa. Le librerie di sistema, incluso libc, sono tutte LGPL.

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

— Martin Beckett
fonte

Nessuna libc è LGPL - puoi collegarti ai programmi LGPL. Esiste anche un'esenzione generale per le chiamate del kernel / sistema, quindi non c'è alcun argomento su cosa sia una chiamata di sistema rispetto a una libreria

— Martin Beckett,

LGPL non è una nuova licenza, è stata rilasciata per la prima volta nel 1991. libc è sempre stata LGPL.

— FigBug

@ john-charles - ecco perché LGPL è stata inventata nel 1991 con gplv2. AsLinux (e altri kernel FOSS) sono diventati popolari - ed è per questo che originariamente era chiamato Library-GPL - c'era il timore che ci sarebbe stata una profusione di libc da parte di tutti i produttori di compilatori se le app commerciali non potessero usare gcc.

— Martin Beckett,

@MartinBeckett Questa è l'opinione di FSF (non puoi collegarti al codice GPLd se non concedi la tua licenza sotto GPL), tuttavia non è indiscusso. Non c'è stata nessuna causa legale (che io sappia, se sbaglio, per favore correggimi) per confermare l'opinione della FSF sul collegamento.

— K.Steff,

@ john-charles - sì, tutta la legge comune viene messa alla prova in tribunale, ma esiste un bel po 'di giurisprudenza sul copyright. Se sostengo che la mia copia non modificata di un DVD di Batman non è un'opera derivata e quindi posso venderne quanti ne voglio, è improbabile che l'MPAA sia d'accordo! Il copyleft GNU usa il copyright per far rispettare un accordo di licenza in un modo abbastanza intelligente - uno dei motivi per cui non è mai stato testato in tribunale è che tutti hanno sempre risolto

— Martin Beckett

In generale, hai ragione a dire che non puoi collegarti a una libreria GPL, distribuire il tuo codice e quindi non rilasciare il tuo codice come GPL.

Tuttavia, c'è l' eccezione della libreria di sistema che è il modo in cui le persone si collegano alle librerie Linux e rilasciano ancora il loro prodotto con licenze non GPL.

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

Infine, gli autori della libreria GPL possono creare eccezioni specifiche, ad esempio per uso non commerciale o hobbistico.

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".

Il SLE risponde anche alla domanda di un programma che è un lavoro derivato del compilatore poiché contiene un parser generato dal compilatore

— Martin Beckett

No, SLE consente lo sviluppo di codice GPL utilizzando toolchain non liberi e runtime standard, ad esempio Visual Studio. Non consente mai di collegare applicazioni non libere con la libreria GPL.

— Jan Hudec,

L'output di un programma GPL non è coperto dalla GPL. Vedi gnu.org/licenses/gpl-faq.html#GPLOutput

— Maximus

-1

La risposta breve è che nessuno lo sa davvero. (Questa discussione riguarda GPL e 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) no. Quest'ultimo si basa principalmente sul fatto che aziende come Oracle spediscono su Linux e non sono state citate in giudizio - non è chiaro nella licenza.

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

Fondamentalmente, se c'è qualche dubbio e non ti piacciono gli avvocati, allora stai alla larga da GPL.

— Tuntable
fonte

GPL non è poi così vago, e c'è una giurisprudenza ben discussa sulla questione di cosa sia e non sia un'opera derivata. La differenza tra l'interfaccia syscall di Linux e libc è che il primo è necessario per creare un software funzionante (che è stato affermato come un'eccezione al copyright) mentre il secondo no (è possibile implementare il proprio). Non ha nulla a che fare con il modo in cui vengono invocate le operazioni, che non ha rilevanza legale. ANAL, questo non è un parere legale.

— Jules,

"70/30 dice che viola" e "30/70 non viola" - è intenzionale che la percentuale di violazione / non viola sia la stessa? "anche se essenzialmente questa è la stessa cosa" suggerisce che doveva essere diverso.

— Mateusz Konieczny,