GPL - Scrittura di un'eccezione per un'interfaccia plugin nella sezione 7 di GPLv3

3

Il problema

Ho scritto un'applicazione per Android con licenza GPLv3 che deve utilizzare Google Play Services, una libreria proprietaria, come plug-in per l'app.

Ora vorrei anche aggiungere libspotify come plugin.

Per tutte le librerie proprietarie utilizzate sto fornendo plugin open source alternativi ma non sono buoni come quelli proprietari, nemmeno vicini.

L'utente dovrebbe quindi essere libero di disabilitare tutte le parti proprietarie sia in fase di compilazione che in fase di esecuzione.

Possibili soluzioni

La GPLv3 ha una sezione "7. Termini aggiuntivi". in base al quale è possibile aggiungere un'eccezione "classpath". Mi piacerebbe usare questa eccezione per fare quanto segue.

L'idea di un'eccezione classpath è spiegata nelle FAQ GPLv3 qui:

L'idea di base

Implementa queste interfacce:

interface Plugin {}

interface ProprietaryPlugin extends Plugin {}

interface XYZ_1 extends Plugin {
    public void someHook();
    public void someOtherHook();
    ...
}

interface XYZ_2 extends Plugin {
    public void someHook();
    public void someOtherHook();
    ...
}

XYZ_3, 4, ...

Le interfacce di cui sopra fanno parte del progetto e sono in GPL.

Ma mi piacerebbe lasciare che tutti i codici che estendono alcune subinterfacce del Plugin tranne ProprietaryPlugin siano abilitati / autorizzati ad essere proprietari dato che si definiscono come ProprietaryPlugin.

La mia intenzione è di creare ganci plug-in stretti che devono essere seguiti da tutti i plug-in proprietari e un modo per indicare all'utente quali plugin possiamo rimuovere in fase di runtime.

Inoltre, voglio che il codice "bridge", l'implementazione delle interfacce plugin sia open source e sotto una licenza compatibile GPLv3. E il codice sorgente deve fornire almeno un'implementazione GPLv3, si spera che crei un muro di cemento tra la GPLv3 e il codice proprietario.

Spiegazione visiva

Èpossibilefarlo?Sochelamaggiorpartedeiragazziquinonsonoavvocati,matrovocheglisviluppatorisianoiprimiailluminare.

Unsuggerimentodairc.gnu.org#gnu

Iragazzidiirc.gnu.org#gnumihannodatoilseguentesuggerimento: link

Dichiara che:

As a special exception, the copyright holders of QCAD hereby grant permission 
for non-GPL compatible plug-ins and script add-ons to be used and distributed 
together with QCAD, provided that you also meet the terms and conditions of the 
licenses of those plug-ins and script add-ons.

I "plug-in e plug-in non compatibili con la GPL" sono vaghi / una scappatoia o sono chiari e si applicano al mio caso?

Un secondo suggerimento

Ho ricevuto un secondo suggerimento su #gnu: link

Dichiara che:

This file forms part of the Roundcube Webmail Software for
which the following exception is added: 
Plug-ins and Skins which merely make function calls to the Roundcube Webmail Software,
and for that purpose include it by reference shall not be
considered modifications of the software.

If you wish to use this file in another project or create a modified version that will 
not be part of the Roundcube Webmail Software, you may remove the exception above and 
use this source code under the original version of the license. 

Cosa ne pensi di questo?

Il mio tentativo di una "eccezione del classpath"

La mia prima idea è stata di aggiungere l'eccezione classpath al plugin con qualcosa di simile al seguente ... ha raggiunto il mio scopo o è pieno di scappatoie, ecc.?

Additional permission under GNU GPL version 3 section 7

0. Definitions

"FSF" means the Free Software Foundation, Inc.

"Compatible License" means any license the FSF 
considers to be compatible with the GNU GPL version 3.

"Plugin interface" means any interface definition file in the Corresponding Source
containing - in the file's header - the words 
"The licensors of this Program designates this particular file as a Plugin interface"

"Proprietary interface mark" means any interface definition file in the Corresponding Source
containing - in the file's header - the words 
"The licensors of this Program designates this particular file as a Proprietary interface mark""

"Allowed library" means any library that is linked or combined with this Program,
 or any covered work that creates a derivative work of a 
subinterface of a Plugin interface not directly linking with the library.
Such a subinterface provides at least the source code 
of one working implementation licensed under This License.
The derivative work of the subinterface linking to the 
Allowed library implements a Proprietary interface mark.
Such a derivative work is referred to as a "Proprietary plugin implementation".
A Proprietary plugin implementation is licensed under a Compatible License.

1. Exceptions

If you modify this Program, or any covered work, by linking or combining it 
with any Allowed library (or a modified version of those libraries),
containing parts covered by the terms of those libraries, the licensors of this
 Program grant you additional permission to convey the resulting work.
{Corresponding Source for a non-source form of such a combination shall include
 the source code for the parts of any Proprietary plugin implementation
used as well as that of the covered work.}
    
posta Centril 14.01.2014 - 20:15
fonte

1 risposta

3

Non penso che tu possa fare ciò che stai cercando di fare. E ti consigliamo di contattare la FSF o un avvocato specializzato in proprietà intellettuale.

Se osservi le Domande frequenti su GPL e Plugin della FSF, hanno alcune commenti per la tua situazione.

It depends on how the program invokes its plug-ins. 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.

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 the plug-ins must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when those plug-ins are distributed.

If the program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case.

Non penso che il tuo programma finirà nel primo caso di usare fork o exec. Se lo facesse, non avresti problemi. È più probabile che il tuo programma rientri nella terza categoria con collegamenti dinamici. Ma non è un buon segno quando la FSF ti dice che sei in una zona grigia. Quando si tratta della GPL e del copyleft, si vogliono risposte chiare.

La chiave per la determinazione di FSF sembra essere questa frase:

If the program dynamically links plug-ins, and they make function calls to each other and share data structures ...

che viene ripetuto in un'altra risposta FAQ. Se dovessi indovinare, sospetto che il tuo programma condividerà le strutture di dati e che i due componenti (la tua applicazione e il plugin) faranno chiamate di funzione tra loro. E questo è il caso, quindi sei esattamente nel loro secondo esempio e i plug-in dovranno essere concessi in licenza come GPL o come licenza GPL-compatibile.

    
risposta data 14.01.2014 - 21:20
fonte

Leggi altre domande sui tag