Posso usare i plugin di licenza Apache Software License, Version 2.0 e GNU LGPL 3 nella mia applicazione web commerciale?


31

Ho due plug-in. Uno ha la licenza GNU LGPL 3 e l'altro ha la licenza software Apache, versione 2.0. Posso usarli nella mia app commerciale? E se sì, quali precauzioni dovrei prendere?


17
Tieni presente che non dovresti MAI seguire MAI la consulenza legale che ricevi su Internet, tranne se proviene da un avvocato. Preferibilmente uno che si specializza nel campo dato, in questo caso: licenze software. Quindi prendi tutte le risposte che ottieni con un pizzico di sale, perché altrimenti potresti essere esposto a cause legali (poiché la tua app è commerciale).
Radu Murzea,

Risposte:


34

Posso usarli nella mia app commerciale?

Dipende da cosa intendi fare con il software che produci.

In primo luogo, né ASL 1 , GPL o LGPL impongono restrizioni su ciò che è possibile utilizzare il software all'interno della propria organizzazione. Le restrizioni riguardano tutti il ​​codice distribuito al di fuori della propria organizzazione.

  • Per GPL la restrizione è che se si incorpora il codice GPL nel proprio software E poi si distribuisce il software al di fuori della propria organizzazione, POI è necessario rendere disponibile il codice sorgente in base ai termini della GPL o di una licenza open source compatibile.

    Quindi, se usi il codice GPL nella tua applicazione e lo distribuisci, allora la tua applicazione deve essere open source ... altrimenti stai violando la licenza.

  • Per LGPL, la restrizione (vedi sopra) si applica solo al codice sorgente della libreria LGPL stessa; cioè se cambiate la libreria. Se si utilizza semplicemente la libreria, non è necessario rendere disponibile il codice sorgente.

    Esiste anche una restrizione che il codice LGPL nella tua applicazione deve essere sostituibile dall'utente del tuo codice. Ciò significa (in effetti) che se distribuisci il tuo codice solo come binario, non puoi collegare staticamente il tuo codice a quello della libreria. È necessario utilizzare il collegamento dinamico.

  • Per ASL, l'unica restrizione significativa è che devi dire se hai modificato qualcosa dalla versione originale del codice ASL che stai usando.

Infine, solo per chiarire, né GPL, LPGL o ASL pongono restrizioni al tuo scopo nell'uso del software. E questo include se il tuo scopo è quello di fare soldi. Limitano solo la strada cui puoi guadagnare ... e nel caso di LGPL e ASL, il vincolo è piuttosto minimo.

E se sì, quali precauzioni dovrei prendere?

Per LGPL e ASL, non sono necessarie precauzioni.

IANAL - Non sono un avvocato. Se hai bisogno di essere sicuro, chiedi a un vero esperto qualificato; vale a dire un avvocato specializzato in diritto del software IP.


1 - Ai fini di questa risposta, ASL == Apache Software License versione 2.


Questo vale per un'applicazione Web? intendo che il cliente riceverà solo il file di guerra contenente i file .class e .JAR. Se LGPL è ancora tutto ok?
Java Main,

Se non si stanno modificando le librerie LGPL, è possibile includerle con il codice dell'applicazione nel file WAR. Ma devi farlo in modo tale che la persona a cui stai distribuendo il tuo codice possa sostituire il codice LBPL con un'altra versione. Un "uber-JAR" è probabilmente una violazione. Offuscare le librerie LGPL insieme al tuo codice è sicuramente una violazione. (IANAL)
Stephen C

C'è una cartella chiamata lib in cui inserisco tutti i file jar. Quindi può spostare qualsiasi file Jar con l'altra versione. Ma non garantisco che funzionerà sempre. Va ancora bene?
Java Main,

Chiedi al tuo avvocato :-)
Stephen C

È solo una normale app Web in esecuzione su Tomcat. Se puoi aiutare sarà buono. Comunque grazie per il tuo chiarimento davvero di aiuto.
Java Main,

5

La licenza Apache non pone alcuna limitazione al software collegato a un plug-in o una libreria distribuito sotto la licenza Apache. D'altra parte, la LGPL ha il requisito che la libreria LGPL si colleghi dinamicamente (e possa essere sostituita da un utente) o che l'intero lavoro debba essere rilasciato con una licenza open source compatibile GPL.

Per l'uso in un'applicazione chiusa, ciò significa che è possibile utilizzare il plug-in con licenza Apache senza restrizioni e che il plug-in con licenza LGPL deve essere collegato in modo dinamico.

Se distribuisci uno dei plug-in insieme alla tua applicazione, devi anche fornire le fonti per i plug-in o informare i tuoi utenti dove possono ottenere tali fonti.


BartvanIngenSchenau cosa intendi per applicazione "chiusa"? Intendi una soluzione in pacchetto (non distribuire il codice sorgente) o ti riferisci alla sua distribuzione all'interno di un'organizzazione rispetto a qualcosa come la distribuzione commerciale?
Rachael,

1
@Rachael: "Closed-source" viene generalmente utilizzato per fare riferimento a software per il quale il codice sorgente non è distribuito. La distribuzione all'interno di un'organizzazione è un po 'un caso speciale quando si tratta di licenze di copyright, perché fornire copie di un prodotto software a persone all'interno di un'organizzazione non è considerata distribuzione per la maggior parte delle leggi sul copyright ( è considerata copia).
Bart van Ingen Schenau,

-4

Prima di tutto, questo non è un consiglio legale.

Il software GPL non può essere collegato (incluso in rete), compilato o spedito con software non GPL di qualsiasi forma. LGPL si allenta un po 'per consentire il supporto di terze parti non GPL, anche per i prodotti commerciali. La parte importante qui è che deve essere di terze parti (per così dire), il che crea un piccolo foro circolare.

In breve, si collega a una libreria LGPL esistente (chiamare questa la prima parte), ma il software che crea questo collegamento deve essere reso LGPL. Chiama questo software come seconda parte. Sebbene il software di seconda parte debba essere rilasciato come LGPL, in quanto proprietario del software di seconda parte è possibile consentire ad altri software di utilizzarlo al di fuori di LGPL (purché il software di seconda parte rimanga disponibile anche sotto LGPL). In altre parole, il software di seconda parte deve essere reso disponibile come LGPL, ma non lo è necessarioconcedere in licenza come LGPL in tutti i casi. Ogni singolo utente di un software deve disporre della licenza per utilizzare detto software per legge. Quello che sto dicendo è che fino a quando ogni utente ha accesso al software come LGPL, puoi anche concederlo in licenza usando termini non virali. Puoi anche creare software di terze parti, in effetti concedendo in licenza il software di terze parti a te stesso per l'utilizzo da parte del software di terze parti in condizioni non LGPL. Ho anche sentito di persone che scrivono se stessi un contratto e la licenza di utilizzare il proprio software. La legge può essere strana! Il software di terze parti non deve in ogni caso essere LGPL.

Quindi, ciò che fai è creare una libreria per collegarti alla lib LGPL come un semplice wrapper e rilasciare il wrapper come LGPL. È quindi possibile collegarsi a questo wrapper (il proprio wrapper) in software non LGPL, purché il wrapper sia disponibile come LGPL.

Non posso parlare per la licenza del software Apache perché non ne ho familiarità.


Si noti che sto usando il termine "collegamento" in modo molto generico perché questo non si applica solo alle lingue compilate e può anche includere "compreso" il software LGPL (da una posizione locale o di rete, come con PHP o Javascript), o altrimenti "collegamento" a un software su una rete come Java RMI ecc.
JSON

1
"Il software GPL non può essere collegato (incluso in rete), compilato o spedito con software non GPL di qualsiasi forma." . "O" dovrebbe essere "e". È possibile utilizzare il software GPL in software non GPL purché non venga "spedito".
Stephen C

2
Quella risposta è sbagliata su così tanti livelli. La domanda non riguarda GPL, ma LGPL. Il codice ASL può essere integrato nel codice con quasi tutte le altre licenze, il che significa anche LGPL o persino GPL (anche se è vietato il contrario). Puoi persino usarlo nel software chiuso. E, come ha sottolineato Stephen C., puoi fare quello che vuoi purché non lo pubblichi o rendilo altrimenti disponibile al pubblico.
Alexis Dufrenoy,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.