Esiste una scappatoia nella GPL che consente al software proprietario di essere collegato con le librerie GPL?

Esaminiamo uno scenario ipotetico:

La società X scrive un programma proprietario (A) che si collega dinamicamente con una libreria proprietaria (B). La società Y desidera utilizzare una libreria sostitutiva (C) concessa in licenza in base alla GPL, quindi scrive una libreria wrapper (D) che si collega dinamicamente sia ad A che a C e traduce le chiamate API utilizzate da A alle chiamate API utilizzate da C.

Poiché D è destinato a essere utilizzato con C e utilizza le chiamate API di C, è un lavoro derivato di C e deve quindi essere distribuito secondo i termini della GPL *. Di conseguenza, il lavoro combinato di A e D deve anche essere distribuito secondo i termini della GPL, il che è impossibile dato che la società Y non possiede il codice sorgente per A. Detto questo, fintanto che la società Y distribuisce D da sola , non c'è problema. Tuttavia, indipendentemente dalle azioni della società Y, la società X non viola la GPL distribuendo A, anche senza B. La semplice esistenza di D non significa che A sia improvvisamente un'opera derivata di C (attraverso D) che deve essere concessa in licenza ai sensi del Anche GPL.

Ora questa è la scappatoia: non c'è nulla che impedisca all'azienda X di scrivere la propria versione di D, distribuirla separatamente da A e dire agli utenti finali di usare D invece di B quando eseguono A. Sembra che un'azienda sia in grado di progettare un programma proprietario per utilizzare una libreria GPL senza violare la GPL, purché venga utilizzato un modulo wrapper per isolare il programma proprietario dalla libreria GPL e tale modulo venga distribuito separatamente.

Sono corretto nel mio ragionamento? È una vera scappatoia nella GPL?

* D è anche un lavoro derivato di A, ma ai fini di questo scenario, la società X ha esplicitamente autorizzato la creazione di D e le ha consentito la licenza ai sensi della GPL.

IANAL, ma ecco la mia opinione su ciò che è consentito nei limiti di GPL:

• distribuire il lavoro combinato "A - B" in pubblico: bene, può essere fatto con qualsiasi licenza proprietaria

• creare un lib wrapper D per C di Y: bene, questo non implica che A debba essere messo sotto GPL

• usa il prodotto combinato "A - D - C" internamente da Y: anche bene, GPL non richiede di aprire la sorgente A fintanto che la combinazione non è distribuita al pubblico

• distribuire in pubblico l'opera combinata "A - D - C": ciò richiederà che A sia di provenienza aperta e sia posto sotto GPL (e non importa se X o Y hanno distribuito questa combinazione; inoltre, se Y vuole fare questo che, richiederebbero una licenza di distribuzione per A da X, ovviamente)

La domanda interessante ora è: D&C può essere distribuito separatamente come open source sotto GPL, A&B (o solo A senza B) può essere distribuito con una licenza proprietaria e l'utente finale sostituisce B con D&C da solo?

Qui la modifica finale a "AB" che rende A dipendente dalle librerie D e C viene effettuata dall'utente finale - dopo la distribuzione . Quindi si potrebbe sostenere che la modifica finale viene eseguita solo internamente dall'utente finale. E sembra che ciò sia effettivamente possibile senza violare la GPL - e quello che ottieni è una combinazione funzionante di "AC&D" in cui A è sotto licenza proprietaria e C&D sotto GPL.

Naturalmente, un avvocato o un giudice può avere un'opinione diversa su questo. Per ottenere una risposta definitiva, penso che tu debba aspettare fino a quando qualcuno lo proverà e un secondo lo farà causa.

Immagino per la maggior parte dei sistemi, sarà difficile creare una tale costellazione senza progettare "A" dall'inizio in un modo in modo che funzioni perfettamente con B o C. E in questo caso, si potrebbe arrivare al sospetto che A è stato in qualche modo derivato da C.

EDIT: pensando a questo proposito, mi è venuta in mente una situazione simile: scrivere e distribuire plugin con licenza GPL per applicazioni a sorgente chiuso. Prendiamo ad esempio Photoshop. Non penso che qualcuno proverebbe seriamente a imporre ad Adobe di Photoshop open source solo perché esistono alcuni plugin GPL di fornitori di terze parti. Qui, non è nemmeno necessaria una "lib wrapper" poiché esiste un'interfaccia ben definita. Tuttavia, cambierebbe la situazione se Photoshop incorporasse alcune delle sue funzioni centrali da un plug-in di terze parti GPL? Penso che per un caso del genere possa diventare davvero difficile decidere dove tracciare la linea, a quel punto il prodotto a sorgente chiuso è un lavoro "basato" sulla lib GPL.

EDIT2: sono disponibili librerie a doppia licenza, con una licenza GPL per uso non commerciale e una licenza proprietaria per uso commerciale come questa, ad esempio. Quindi la tua "scappatoia" significherebbe sviluppare un prodotto basato su tale lib (usando la versione commerciale, quindi GPL non si applica al tuo prodotto), consegnare il tuo prodotto come open-source senza la lib al pubblico e lasciare che il fine- l'utente ottiene e installa la versione GPL da solo. In tal caso, immagino che il venditore della libreria abbia buone probabilità di denunciarti con successo per violazione della licenza (se non paghi per la sua libreria, ovviamente). Ne vale la pena? Probabilmente no. Soprattutto nell'esempio che ho collegato, dovresti acquistare anche la lib, poiché il prezzo non dipende dalla frequenza con cui vendi il tuo prodotto, ma solo da quanti sviluppatori usano la lib durante lo sviluppo.

Infine, a causa di tali rischi legali, se intendo utilizzare librerie open source all'interno di un prodotto a sorgente chiuso, eviterei le librerie GPL, se possibile, e non tenterei di utilizzare questa "scappatoia". LGPL o GPL con l'eccezione del collegamento è molto più sicuro o qualsiasi tipo di licenza del sistema operativo non virale.

Un esempio pratico sono i driver grafici proprietari per Linux che l'utente finale deve installare autonomamente. È importante sottolineare che per il creatore del driver proprietario, se l'utente finale distribuisce il lavoro combinato, ciò crea un obbligo legale per l'utente finale (che non può possibilmente adempiere) ma non per il creatore del driver.

Un'altra risposta afferma che "poiché il programma dipende dalla libreria è ancora un lavoro derivato" - ma se il programma in realtà non funziona perché la libreria non è presente, non è derivata.

Ma alla fine, se fai affidamento su "scappatoie", dovresti considerare che il tuo approccio potrebbe non essere quello giusto in primo luogo.

Il collegamento definisce una derivata dalla GPL. Questa situazione specifica è ciò che LGPL è stato progettato per gestire: dove si desidera rilasciare la libreria come GPL ma definire il collegamento come limite esplicito della licenza applicata, o in alternativa, dove si desidera collegarsi con un codice GPL ma è necessario che il proprio l'opera verrà rilasciata con una licenza non GPL stessa.

Nel caso in cui l'utente finale esegua il collegamento (crea il proprio codice da fonti non GPL che potrebbero collegarsi a una libreria GPL), l'utente finale non ha effettivamente creato una versione GPL di qualunque sia il prodotto finale, in quanto non è autorizzato a modificare la licenza della parte non GPL del progetto perché non ne è il proprietario. Ciò generalmente impedisce la distribuzione da parte dell'utente finale in qualsiasi forma, ma non ne vieterebbe l'uso.

Detto questo, se un progetto richiede che sia costruito dalla fonte e distribuito solo in questo modo, è irrilevante la licenza della biblioteca collegata, poiché questo è completamente fuori dalle mani dello sviluppatore non GPL. Cioè, come puoi sapere che la tua distribuzione solo di origine sarà costruita su gcc contro glibc VS costruita su un compilatore IBM contro la loro libc a meno che tu non lo specifichi nei tuoi termini di licenza? Ciò si traduce rapidamente in un uso equo e divieti contro condizioni legali inapplicabili (non che la fantasia non sia stata scritta in legge in alcune occasioni di recente).

Non sono un avvocato, ma per quanto posso dire che non sono corretti, dal momento che il programma dipende dalla biblioteca - è ancora un lavoro derivato. Allo stesso modo in cui un sequal è un'opera derivata. Come minimo si basa sulle API definite nella libreria.