Un programma GPLv2 può fare affidamento su librerie con licenza Apache?


12

Un programma software con licenza GPL (versione 2) può fare affidamento su librerie concesse in licenza con APLv2 senza eseguire la violazione della GPL? La lingua qui mi suggerisce forse no.

Nel mio caso specifico sto guardando un demone che utilizza alcune librerie esterne con licenza APLv2.

AGGIORNAMENTO (In risposta a risposte / commenti.)

  1. Ai fini di questa domanda, non posso riconsegnare il programma principale (il demone)
  2. Il programma principale è stato esteso con funzionalità che utilizza apr-utile forse altri componenti APLv2

La mia domanda è: posso rilasciare il demone esteso sotto GPLv2 o è qualcosa che devo tenere per me (nessuna distribuzione) e / o implementare nuovamente senza APLv2 se mi impegno a (a) rilasciare questa estensione, e, (b) mantenere il demone GPL?


2
Il documento che hai collegato afferma chiaramente che no. Tuttavia, la maggior parte del codice GPL là fuori ha la disposizione "o, a tua scelta, qualsiasi versione successiva", il che significa che puoi trattarlo come GPLv3 e va bene.
Jan Hudec,

Risposte:


7

Chiariamo prima alcuni termini. Quando la FSF afferma che una licenza è compatibile con la GPL non significano cosa significhino molte persone. Molti interpretano "compatibile" nel senso che i due software possono felicemente coesistere nella stessa applicazione.

Questo è vicino a ciò che significa FSF, ma la disposizione di copyleft della GPL porta le cose un po 'oltre.

Dalle FAQ di GPL , enfatizza la mia.

Significa che l'altra licenza e la GNU GPL sono compatibili; puoi combinare il codice rilasciato con l'altra licenza con il codice rilasciato sotto GNU GPL in un programma più grande.
Tutte le versioni GNU GPL consentono tali combinazioni privatamente; consentono inoltre la distribuzione di tali combinazioni purché la combinazione sia rilasciata con la stessa versione GNU GPL .

Quindi una licenza è compatibile con la GPL se i suoi termini possono essere assorbiti sotto la GPL.


Diamo un'occhiata a APLv2 e GPLv3.

  • APLv2_Lib + GPLv3_Lib => Lib combinata poiché GPLv3 va bene.
  • APLv2_Lib + GPLv3_Lib => Lib combinata in quanto APLv2 non va bene.

E Apache dice altrettanto qui :

Evitiamo il software GPLv3 perché il semplice collegamento ad esso è considerato dagli autori di GPLv3 per creare un'opera derivata. Vogliamo onorare la loro licenza.


Ma stai lavorando con un demone che è stato concesso in licenza in GPLv2, non v3.

FSF è abbastanza chiaro che ciò che vuoi fare non è accettabile per una distribuzione pubblica.

Si noti che questa licenza non è compatibile con GPL versione 2, poiché presenta alcuni requisiti che non si trovano in quella versione GPL. Questi includono alcune disposizioni in materia di risoluzione del brevetto e indennizzo.

Quindi, per rispondere alla tua domanda:

No , non è possibile distribuire il demone combinato utilizzando materiale concesso in licenza GPLv2 e APLv2 .
FSF chiama esplicitamente quella combinazione come non ammissibile per la distribuzione pubblica.

alternative:

  1. Si è autorizzati ad utilizzarla privatamente.

  2. Andrebbe anche bene riscrivere la funzionalità APLv2 e quindi combinare il nuovo lavoro con il lavoro GPLv2.

  3. Potresti vedere se il demone può essere cambiato in GPLv3. In tal caso, saresti quindi in chiaro per unire il lavoro APLv2 nel demone GPLv3 ora.


2

La mia opinione è in accordo con l'OP sulla base del testo del link ASF dell'OP.

Ad ASF (Apache Software Foundation) non piace l'idea che il codice ASFv2 faccia parte di un sistema che utilizza GPLv2, in base alle informazioni limitate sul tuo caso e alla mia comprensione delle varie licenze FOSS: indipendentemente dal fatto che il progetto ombrello abbia GPLv2 o il progetto ombrello è GPLv2, nel tentativo di includere ASFv2.

Inoltre sembra che un progetto ombrello ASFv2 che ha il codice GPLv3 non dovrebbe accadere, ma un progetto ombrello GPLv3 può avere il codice ASFv2.

Il caveot, forse (secondo Gnu), è il modo in cui interagiscono tra loro. Se collegati, condividono le stesse copie di dati durante l'esecuzione, sono una cosa sola nello stesso programma; tuttavia, se funzionano come processi separati (ad es. biforcati) che passano dati tra diversi processi distinti, ciò che si sta facendo potrebbe essere consentito perché sono, per loro, programmi separati. Se durante l'esecuzione viene utilizzato uno spazio di dati condiviso e non funziona con processi distinti, ciò che si sta facendo potrebbe non essere consentito, poiché a loro sono uguali o troppo strettamente accoppiati per essere distinti o indipendenti.

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.