Distribuzione di un'applicazione proprietaria insieme al software GPL [chiuso]

Naviga le tue risposte
6

Per prima cosa, ci sono molte domande simili qui, ma non ne ho trovato nessuna con risposte dirette su questo scenario specifico . Se trovi un duplicato, ti preghiamo di essere gentile a collegarti alla / e risposta / i specifica / e. Inoltre, per evitare che la domanda sia troppo ampia, considera solo questo specifico scenario.

Assumi un'applicazione Linux proprietaria, che collega in modo dinamico le librerie LGPL e non si collega alle librerie GPL. Esegue anche i file binari GPL dal file system tramite le API standard del sistema operativo, tuttavia, per eseguire alcune azioni.

Quindi assumere una distribuzione Linux mainstream personalizzata, con i marchi visibili con marchio registrato ecc.

Quindi assumere un prodotto autonomo, che include hardware, diciamo Raspberry Pi con una scheda SD avviabile con questo sistema operativo personalizzato. Quindi ha il software proprietario, che alla fine deve essere avviato all'avvio del dispositivo.

Come distribuire questa combinazione legalmente?

Più in particolare, vedo (almeno) tre distinti dubbi:

  1. In generale, come distribuire solo la distro Linux personalizzata legalmente? Per esempio, ci sono strumenti, o quali distribuzioni hanno strumenti, per scaricare tutti i pacchetti sorgente predefiniti, pronti per essere inclusi nella distribuzione o archiviati localmente?

    Penso che a volte si pensi, che se si distribuisce una derivata di una distro Linux mainstream, non è necessario distribuire da soli le fonti dei pacchetti predefiniti, o semplicemente si può puntare ai repository dei sorgenti di distribuzione se qualcuno li richiede , ma non sono sicuro che questo sia un modo giuridicamente valido per adempiere agli obblighi GPL.

  2. Come includere legalmente il software proprietario con la distribuzione? Ad esempio, è giusto avere il software proprietario già installato nella suddetta SD? È corretto averlo disinstallato sullo stesso supporto e chiedere all'utente di installarlo al primo avvio? È necessario averlo su un supporto separato o scaricato dalla rete, e installato da quello? Quali sono i limiti di "Certamente OK" e "Certamente non OK", c'è un consenso o addirittura un precedente legale?

  3. È in esecuzione programmi GPL con stringhe di comando codificate da un'applicazione proprietaria OK? La mia comprensione è, questo è OK e non crea un lavoro derivato. Ma se questo è un problema, lavorare attorno ad esso è semplice come creare un wrapper con licenza LGPL? O semplicemente avere i comandi in un file di configurazione modificabile (una buona idea comunque, indipendentemente dai problemi di licenza)?

Nota : ad eccezione degli aspetti tecnici del primo punto, capisco che le risposte qui non sono alcun tipo di consulenza legale, ma le risposte devono essere sostenute in qualche modo, questo sito non è per l'opinione sondaggi.

    
posta hyde 12.09.2013 - 11:55
fonte

2 risposte

6

Quindi, dopo alcune ricerche, ecco la mia risposta. CONSIGLI NON GIURIDICI, e anche come consigli profani, non sono un esperto in materia.

  1. Se stai creando un prodotto da vendere, è meglio farlo sul sicuro. Scaricare tutti i pacchetti sorgente per tutti i pacchetti installati è così semplice, e con le attuali capacità di archiviazione ci vuole così poco spazio, che non c'è motivo di non farlo. Uno script di shell come questo dovrebbe farlo, comandi di esempio per distro basati su Debian, script non testato: 

    # use dpkg to get list of current packages,
# then download source package for each using apt-get
for pkg in $(dpkg --get-selections) ; do
    apt-get source --download-only $pkg
done

    Questo dovrebbe probabilmente essere fatto per ogni versione distribuita fisicamente, per avere versioni corrette delle fonti. Non è molto difficile dopo averlo impostato una volta, e una spesa trascurabile, quindi perché accontentarsi di meno ... Per il lancio di versioni online, potrebbe essere appropriato un approccio diverso, come disporre di un repository di pacchetti adeguato, inclusi i pacchetti sorgente.

  2. e 3. sono coperti da queste voci nelle Domande frequenti sulla GPL della FSF:

    Fondamentalmente, per quanto ho capito, purché chiarisca che c'è una parte GPL / LGPL nel tuo prodotto, non cercare di impedire all'utente di modificare la parte GPL ("tivoization"), e solo l'accesso I programmi GPL attraverso le interfacce normalmente utilizzate tra i programmi , come i parametri di esecuzione e le pipe, stai bene.

    Inoltre, penso che queste voci delle FAQ potrebbero avere un certo peso in un'aula di tribunale nella maggior parte delle giurisdizioni, se si tratta di questo, come sono scritte dagli autori di GPL, e spiegare l'intento del testo della licenza, nel caso in cui la causa fino a disaccordo sull'interpretazione di GPL e LGPL.

Ripeti il disclaimer: non sono un avvocato, o anche un esperto esperto in materia.

    
risposta data 13.09.2013 - 08:10
fonte
2

  1. Se leggo correttamente GPL, è consentito solo per i download di Internet e purché tu abbia appena preso il file binario così com'era. Altrimenti dovresti avere una copia della fonte da qualche parte. Tutte le distribuzioni hanno archivi di fonti, ma include tutte le versioni. Devi scegliere le versioni corrispondenti alle versioni che distribuisci. Inoltre probabilmente non distribuirai tutti i pacchetti, le distribuzioni sono enormi in questi giorni.

  2. Va tutto bene. Per esempio. I dispositivi Android sono dotati di GPL Linux e applicazioni proprietarie preinstallate e nessuno ha problemi con esso. Devono solo essere programmi separati.

  3. Va bene. Sono ancora programmi separati. Per cose che non sono OK, il wrapper LGPL non ti aiuterà, perché è permesso solo per quanto riguarda il codice sotto qualsiasi altra licenza.

risposta data 12.09.2013 - 13:34
fonte

Leggi altre domande sui tag

Concetto per gestire appuntamenti ricorrenti Project / DLL separazione delle preoccupazioni in ASP.NET MVC