Utilizzo facoltativo della libreria GPL tramite API di sistema in applicazione closed-source

3

Considerare la seguente situazione:

Si scrive un'applicazione closed-source, chiamiamola A. A dipende da un'API di sistema (cioè fornita dal sistema operativo), che è a sua volta configurabile per utilizzare back-end diversi. Ogni backend è identificato da un semplice valore stringa e anche selezionato tramite questo identificatore. L'API stessa non è vincolata da alcun requisito simile a GPL.

Ora, un back-end specifico (B) sarebbe preferito ma è concesso in licenza con licenza GPL. L'applicazione funzionerebbe senza di essa e ci sono altri backend disponibili, solo con prestazioni peggiori o altri aspetti negativi.

È consentito uno dei seguenti casi?

  1. Hard codifica l'identificatore su B
  2. Selezione automatica di qualsiasi back-end disponibile, ma preferendo B se disponibile
  3. Permettendo all'utente di selezionare un back-end (e suggerendo strongmente B)

Dipenderà anche dal fatto che spedisco A e B insieme, o solo A e suggerisco all'utente che installare B migliori le prestazioni dell'applicazione?

In genere penso che tutte e tre le opzioni siano o.k. dal momento che passare una stringa specifica a un'API di sistema difficilmente si qualifica per un lavoro derivato (IMHO), ma le FAQ di B indicano fondamentalmente che non importa come si chiama una funzione di B, qualsiasi utilizzo rende il tuo programma un lavoro derivato . Hanno ragione anche nei tre casi sopra descritti?

P.S .: Non è una mia decisione prendere A closed-source, quindi GPLing non è un'opzione. Post scriptum 2: Ho omesso i nomi dell'API di sistema e B per mantenere la domanda più generica, ma posso aggiungerli se fa alcuna differenza.

modifica: da un altro punto di vista: quando l'utente (al contrario del programmatore) crea un'opera derivata? Nel terzo caso, dovrebbe essere chiaro che l'utente crea il lavoro derivato dal momento che ha installato A e B e selezionato attivamente B. Questo sarebbe in linea con gli argomenti di MSalters nel suo commento. Il secondo caso chiarisce almeno che il lavoro non dipende da B, quindi anche questo potrebbe essere o.k.

Probabilmente sarebbe la maggior parte nello spirito della GPL a contattare solo gli autori; tuttavia, non sono sicuro che la loro voce delle domande frequenti sia in linea con il testo effettivo della GPL.

    
posta anderas 11.03.2014 - 10:09
fonte

2 risposte

3

TL; DR: La FSF non distingue tra processo e programma, suggerendo restrizioni sul programma che si applicano solo al processo risultante.

La GPL funziona fondamentalmente tramite copyright. In particolare, è una licenza di distribuzione (non copre l'uso) ed è limitata alle opere che sono poste sotto la GPL.

Ora uno dei problemi è quando un lavoro inizia a cadere sotto la GPL e cosa gli succede. Credo che la FSF sia giusta, e il tuo processo rientra nella GPL quando carica il plugin B.

Il tuo processo . Non è il tuo programma. Solo il processo in memoria che combina i due, cioè il lavoro derivato. Prima della combinazione, nessun lavoro derivato esiste in senso giuridico. Pertanto la GPL non può dettare termini sul tuo programma. Semplicemente non ha basi legali.

Naturalmente, puoi utilizzare il lavoro derivato creato combinando il tuo programma e il plugin B in un unico processo. La GPL consente esplicitamente l'uso. Ora, se hai eseguito questo processo in una VM e clonato la VM, ti verrà impedito di distribuire questa immagine VM. Quelle cose rare sono coperte. Ma di solito, i processi non vengono copiati, quindi la loro protezione legale sotto copyright è piuttosto inutile.

    
risposta data 11.03.2014 - 15:46
fonte
2

Se la libreria B utilizza la semplice licenza GPL (non la LGPL o una variante, come GPL con classpath o l'eccezione di collegamento), allora le FAQ per B sono corrette in quanto la Free Software Foundation (quelle che hanno redatto il Licenze GPL) considera un programma un'opera derivata da un pezzo di codice GPL se quel codice GPL viene eseguito nello stesso processo del resto del programma.

Per chiarire la posizione della FSF, vedi queste risposte dalle loro FAQ:

If a library is released under the GPL (not the LGPL), does that mean that any software which uses it has to be under the GPL or a GPL-compatible license? (#IfLibraryIsGPL)

Yes, because the software as it is actually run includes the library.

Does the GPL have different requirements for statically vs dynamically linked modules with a covered work? (#GPLStaticVsDynamic)

No. Linking a GPL covered work statically or dynamically with other modules is making a combined work based on the GPL covered work. Thus, the terms and conditions of the GNU General Public License cover the whole combination. See also What legal issues come up if I use GPL-incompatible libraries with GPL software?

Can I apply the GPL when writing a plug-in for a non-free program? (#GPLPluginsInNF)

If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for them. So you can use the GPL for a plug-in, and there are no special requirements.

If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means that combination of the GPL-covered plug-in with the non-free main program would violate the GPL. However, you can resolve that legal problem by adding an exception to your plug-in's license, giving permission to link it with the non-free main program.

See also the question I am writing free software that uses a non-free library.

Il fatto che la libreria B implementa un'API non GPL potrebbe fare la differenza, ma (vedendo l'ultima FAQ citata sopra) non sembra essere considerato diverso dalla FSF.

Puoi utilizzare la libreria B nel tuo programma a sorgente chiuso, ma non ti è permesso distribuire la combinazione dei due. Se il tuo programma è scritto per funzionare con un'API generica (non GPL) e funziona bene senza la libreria B, allora puoi distribuire il tuo programma senza la libreria e gli utenti possono anche scaricare la libreria B separatamente e usarla in combinazione con la tua applicazione.

La grande domanda è se puoi fare attivamente riferimento alla libreria B nel tuo codice sorgente o documentazione senza che sia considerata un'opera derivata della libreria B. Questa è una domanda legale a cui non abbiamo l'esperienza per rispondere. Dovrai consultare un avvocato per quello.
Senza menzionare la libreria B, avresti almeno la possibilità di difenderti che non eri a conoscenza delle implementazioni dell'API con licenza GPL, ma solo un avvocato può dirti quanto ti avrebbe portato in tribunale.

    
risposta data 11.03.2014 - 12:22
fonte

Leggi altre domande sui tag