Quanto sono restrittive le restrizioni di collegamento della GPL?

3

Per quanto riguarda le mie conoscenze di base, le licenze software si applicano solo quando si ridistribuiscono software. Anche se ho sbagliato su questo in generale, la GPL afferma che non è necessario accettare la GPL per ricevere o eseguire un programma coperto da GPL.

Supponiamo che ci sia il programma X. Il programma X richiede l'esecuzione della libreria L. Il Programma X è coperto da una licenza incompatibile con GPL (ad esempio, la licenza pubblica Eclipse o una licenza proprietaria). La libreria L è coperta dalla GPLv3.

Il programma X non può essere distribuito insieme alla libreria L - la combinazione dovrebbe essere coperta dalla GPL , che violerebbe la EPL.

  1. Che cosa impedisce agli utenti di installare separatamente Program X e Library L e quindi di utilizzare Program X?

  2. Forse in modo più pertinente nel mondo moderno degli auto-updaters, cosa impedisce al Programma X di includere un wrapper che scarica la Libreria L da Internet (ad esempio, dal sito web ufficiale di Library L') e poi esegue il Programma X?

    In entrambi i casi, nulla dalla Library L è distribuito dagli autori del Programma X, quindi la licenza di Library L'non dovrebbe applicarsi.

  3. Che cosa, se non altro, cambia se il Programma X invece richiede la Libreria L ', un fork della Libreria L dagli autori del Programma X, che è disponibile solo dallo stesso sito Web del Programma X ed è utilizzabile solo con il Programma X, ma non è mai distribuito nello stesso pacchetto del Programma X?

  4. Che succede se questo è tutto in un linguaggio dinamico, e nessuna parte della Libreria L è richiesta per compilare il Programma X?

  5. Cosa succede se il programma X è distribuito in forma di codice sorgente, in modo che la distribuzione non sia stata compilata dalle intestazioni di Library L'?

posta immibis 21.07.2014 - 12:10
fonte

2 risposte

5

Dal punto di vista della FSF, il programma X non può essere distribuito affatto. Il ragionamento qui è che se il Programma X ha bisogno della Libreria L per funzionare e non comunica a distanza di braccia (processi separati che comunicano attraverso un'interfaccia o file inter-processo), allora la GPL si applica anche al Programma X.
Se il Programma X non è concesso in licenza con una licenza compatibile GPL, allora il Programma X non può essere distribuito.

Per citare le loro FAQ:

I'd like to incorporate GPL-covered software in my proprietary system. Can I do this? (#GPLInProprietarySystem)

You cannot incorporate GPL-covered software in a proprietary system. The goal of the GPL is to grant everyone the freedom to copy, redistribute, understand, and modify a program. If you could incorporate GPL-covered software into a non-free system, it would have the effect of making the GPL-covered software non-free too.

A system incorporating a GPL-covered program is an extended version of that program. The GPL says that any extended version of the program must be released under the GPL if it is released at all. This is for two reasons: to make sure that users who get the software get the freedom they should have, and to encourage people to give back improvements that they make.

However, in many cases you can distribute the GPL-covered software alongside your proprietary system. To do this validly, you must make sure that the free and non-free programs communicate at arms length, that they are not combined in a way that would make them effectively a single program.

The difference between this and “incorporating” the GPL-covered software is partly a matter of substance and partly form. The substantive part is this: if the two programs are combined so that they become effectively two parts of one program, then you can't treat them as two separate programs. So the GPL has to cover the whole thing.

If the two programs remain well separated, like the compiler and the kernel, or like an editor and a shell, then you can treat them as two separate programs—but you have to do it properly. The issue is simply one of form: how you describe what you are doing. Why do we care about this? Because we want to make sure the users clearly understand the free status of the GPL-covered software in the collection.

If people were to distribute GPL-covered software calling it “part of” a system that users know is partly proprietary, users might be uncertain of their rights regarding the GPL-covered software. But if they know that what they have received is a free program plus another program, side by side, their rights will be clear.

In quale misura il punto di vista della FSF è giuridicamente valido è un po 'incerto, ma non vorrei essere il banco di prova per vedere come i tribunali trovano su di esso.

    
risposta data 21.07.2014 - 13:30
fonte
1

Q1. Niente. Un utente può unire X e L purché siano conformi a tutti i requisiti di licenza.

Q2. Non buono. I proprietari di X hanno ora il controllo e stanno eseguendo una fusione in loco, che li porta sotto i termini delle licenze L. Ma c'è spazio per il picnic di un avvocato.

Q3. Cade ancora sotto le disposizioni di fusione.

Q4. Linguaggio dinamico: nessun cambiamento. Dipende da dove e come avviene l'unione.

Q5. X in formato sorgente: nessuna modifica.

In ultima analisi, se il distributore di X possiede e controlla l'unione, sono vincolati dalla licenza che copre la distribuzione delle versioni unite, anche se "organizzano" affinché tale unione venga eseguita sul sito del cliente. O quello o c'è un argomento strong e una feroce battaglia legale prima che qualcuno sia certo.

Ma se puoi distribuire X e passare la decisione di utilizzare e unire X con L interamente sul destinatario, non sarai vincolato dalla licenza per L. Potresti scrivere termini di licenza in tal senso ed essere ragionevolmente sicuro che potrebbero non essere sfidato, o se lo fossero, che sei stato risarcito dal destinatario. Un altro picnic da avvocato.

    
risposta data 22.07.2014 - 07:36
fonte

Leggi altre domande sui tag