Esiste una lacuna nella GPL che consente di collegare il software proprietario alle librerie GPL?

15

Esaminiamo uno scenario ipotetico:

L'azienda 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 sotto licenza GPL, quindi scrive una libreria wrapper (D) che collega dinamicamente sia A che C e traduce le chiamate API utilizzate da A alle chiamate API utilizzate da C.

Poiché D è destinato ad 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 Compagnia Y, la Compagnia 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 anche sotto licenza GPL.

Questa è la scappatoia: non c'è nulla che impedisca a Company X di scrivere la sua versione di D, distribuendola separatamente da A, e di dire agli utenti finali di usare D invece di B quando esegue A. Sembra che un'azienda sia in grado di progettare un programma proprietario per usare una libreria GPL senza violare la GPL, purché un modulo wrapper sia usato per isolare il programma proprietario dalla libreria GPL e quel modulo sia distribuito separatamente.

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

* D è anche un'opera derivata di A, ma ai fini di questo scenario, la Compagnia X ha autorizzato esplicitamente la creazione di D e ha permesso che fosse concessa sotto licenza GPL.

    
posta Michael Kourlas 26.05.2013 - 07:21
fonte

4 risposte

9

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

  • distribuire l'opera combinata "A - B" in pubblico: bene, può essere eseguita con qualsiasi licenza proprietaria

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

  • usa internamente il prodotto combinato "A - D - C": anche bene, GPL non richiede l'open source A fintanto che la combinazione non viene distribuita al pubblico

  • distribuire il lavoro combinato "A - D - C" in pubblico: questo richiederà che A sia open source e che sia messo sotto GPL (e non importa se X o Y hanno distribuito questa combinazione; , se Y vuole farlo, richiederebbe una licenza di distribuzione per A da X, ovviamente)

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

Qui la modifica finale a "A-B" che rende A dipendente da libs D & C viene eseguito dall'utente finale - dopo la distribuzione . Quindi si potrebbe sostenere che la modifica finale è eseguita internamente solo dall'utente finale. E sembra che questo sia effettivamente possibile senza violare la GPL - e ciò che ottieni è una combinazione funzionante di "A-C & D" dove A è sotto licenza proprietaria e C & D sotto GPL.

Ovviamente, un avvocato o un giudice possono avere un'opinione diversa al riguardo. Per ottenere una risposta definitiva, penso che devi aspettare che qualcuno lo provi e un secondo lo faccia causa.

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

EDIT: pensando un po 'a questo, mi è venuta in mente una situazione simile: scrivere e distribuire plugin con licenza GPL per applicazioni closed-source. Prendiamo ad esempio, Photoshop. Non penso che qualcuno proverebbe seriamente a imporre Adobe ad Photoshop open-source solo perché esistono alcuni plugin GPL di fornitori di terze parti. Qui, nemmeno una "wrapper lib" è necessaria 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 con licenza GPL? Penso che per un caso del genere possa diventare davvero difficile decidere dove disegnare la linea, a quel punto il prodotto closed-source è un'opera "basata sulla" GPL lib.

EDIT2: Sono disponibili librerie a doppia licenza, con 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 libertà (usando la versione commerciale, quindi GPL non si applica al tuo prodotto), consegnare il tuo prodotto come closed-source senza la pubblicazione al pubblico e lasciare che il prodotto finale l'utente ottiene e installa la versione GPLed da solo. Per un caso del genere, suppongo che il venditore della libreria avrà buone possibilità di citarti con successo per violazione della licenza (se non paghi la sua lib, ovviamente). Vale la pena la seccatura? Probabilmente no. Soprattutto nell'esempio a cui mi sono collegato, dovresti acquistare anche la lib, poiché il prezzo non dipende dalla frequenza con cui vendi il tuo prodotto, ma solo dal numero di sviluppatori che utilizzano la lib durante lo sviluppo.

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

    
risposta data 26.05.2013 - 16:05
fonte
4

Un esempio pratico sono driver di grafica proprietari per Linux che l'utente finale deve installare autonomamente. Importante 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 è in grado di soddisfare) ma non il creatore del driver.

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

Ma alla fine, se ti affidi a "scappatoie" allora dovresti considerare che il tuo approccio potrebbe non essere quello giusto in primo luogo.

    
risposta data 09.06.2017 - 21:16
fonte
1

Il collegamento definisce una derivata dalla GPL. Questa situazione specifica è ciò che la LGPL è stata progettata per gestire: in cui si desidera rilasciare la libreria come GPL, ma definire il collegamento come limite esplicito della licenza applicata, o in alternativa, dove si desidera collegare un codice GPL ma è necessario il proprio lavoro essere rilasciato sotto una licenza non GPL stessa.

Nel caso in cui l'utente finale faccia il collegamento (costruisca il proprio codice da fonti non GPL che possono collegarsi a una libreria GPL) l'utente finale ha non 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. Questo generalmente preclude la distribuzione da parte dell'utente finale in qualsiasi forma, ma non proibire l'uso.

Detto questo, se un progetto richiede che sia compilato dal sorgente e sia distribuito in questo modo, è irrilevante la licenza della libreria collegata, poiché questo è interamente fuori dalle mani degli sviluppatori non GPL. Cioè, come puoi sapere che la tua distribuzione di sola origine sarà costruita su gcc contro glibc VS, costruito su un compilatore IBM contro la loro libc, a meno che tu non lo specifichi sotto i tuoi termini di licenza? Questo si traduce rapidamente in un uso corretto e in proibizioni contro condizioni legali inapplicabili (non che la fantasia non sia stata trasposta in legge in diverse occasioni di recente).

    
risposta data 25.03.2014 - 23:02
fonte
0

Non sono un avvocato, ma per quanto posso dire non sei corretto, dal momento che il programma dipende dalla libreria - è ancora un lavoro derivativo. Allo stesso modo in cui un sequel è un lavoro derivativo. Come minimo si basa sulle API definite nella libreria.

    
risposta data 26.05.2013 - 07:35
fonte

Leggi altre domande sui tag