Un programme GPLv2 peut-il s'appuyer sur des bibliothèques sous licence Apache?


12

Un logiciel sous licence GPL (version 2) peut-il s'appuyer sur des bibliothèques sous licence APLv2 sans s'exécuter contre la GPL? Le langage ici me suggère peut-être pas.

Dans mon cas spécifique, je regarde un démon qui utilise des bibliothèques externes sous licence APLv2.

MISE À JOUR (En réponse aux réponses / commentaires.)

  1. Aux fins de cette question, je ne peux pas remettre en licence le programme principal (le démon)
  2. Le programme principal a été étendu avec des fonctionnalités qui utilisent apr-utilet peut-être d'autres composants APLv2

Ma question est, puis-je libérer le démon étendu sous la GPLv2, ou est-ce quelque chose que je dois garder pour moi (pas de distribution) et / ou ré-implémenter sans APLv2 si je me suis engagé à (a) publier cette extension, et, (b) garder le démon sous GPL?


2
Le document que vous avez lié indique clairement que non. Cependant, la plupart des codes GPL ont la disposition "ou, à votre choix, toute version ultérieure", ce qui signifie que vous pouvez le traiter comme GPLv3 et c'est OK.
Jan Hudec

Réponses:


7

Clarifions d'abord une terminologie. Lorsque la FSF dit qu'une licence est compatible avec la GPL, cela ne signifie pas ce que beaucoup de gens interprètent comme cela. Beaucoup interprètent «compatible» comme signifiant que les deux logiciels peuvent coexister avec bonheur dans la même application.

C'est proche de ce que signifie la FSF, mais la disposition sur le copyleft de la GPL va un peu plus loin.

Dans la FAQ GPL , mettez l'accent sur moi.

Cela signifie que l'autre licence et la GNU GPL sont compatibles; vous pouvez combiner le code publié sous l'autre licence avec le code publié sous la GNU GPL dans un programme plus grand.
Toutes les versions de GNU GPL permettent de telles combinaisons en privé; ils permettent également la distribution de telles combinaisons à condition que la combinaison soit publiée sous la même version GNU GPL .

Une licence est donc compatible avec la GPL si ses termes peuvent être absorbés sous la GPL.


Examinons donc l'APLv2 et la GPLv3.

  • APLv2_Lib + GPLv3_Lib => La bibliothèque combinée comme GPLv3 est correcte.
  • APLv2_Lib + GPLv3_Lib => La bibliothèque combinée comme APLv2 n'est pas correcte.

Et Apache en dit autant ici :

Nous évitons le logiciel GPLv3 car un simple lien vers celui-ci est considéré par les auteurs de la GPLv3 pour créer une œuvre dérivée. Nous voulons honorer leur licence.


Mais vous travaillez avec un démon sous licence GPLv2, pas v3.

FSF est assez clair que ce que vous voulez faire n'est pas acceptable pour une distribution publique.

Veuillez noter que cette licence n'est pas compatible avec la version 2 de la GPL, car elle a certaines exigences qui ne sont pas dans cette version de la GPL. Il s'agit notamment de certaines clauses de résiliation et d'indemnisation des brevets.

Donc, pour répondre à votre question:

Non , vous ne pouvez pas distribuer le démon combiné à l'aide de matériel sous licence GPLv2 et APLv2 .
La FSF appelle explicitement cette combinaison comme non autorisée pour la distribution publique.

Alternatives:

  1. Vous êtes autorisé à l'utiliser en privé.

  2. Vous pouvez également réécrire la fonctionnalité APLv2, puis combiner votre nouveau travail avec le travail GPLv2.

  3. Vous pouvez voir si le démon peut être remplacé par GPLv3. Si c'est le cas, vous seriez alors en clair pour fusionner le travail APLv2 dans le démon désormais GPLv3.


2

Mon avis est d'accord avec OP sur la base du texte du lien ASF d'OP.

ASF (Apache Software Foundation) n'aime pas l'idée que le code ASFv2 fasse partie d'un système qui utilise GPLv2, sur la base des informations limitées de votre cas et de ma compréhension des différentes licences FOSS: indépendamment du fait que le projet-cadre ait GPLv2 ou le projet parapluie est GPLv2, tentant d'inclure ASFv2.

De plus, il semble qu'un projet parapluie ASFv2 qui a du code GPLv3 ne devrait pas se produire, mais un projet parapluie GPLv3 peut avoir du code ASFv2.

Le caveot, peut-être (selon Gnu), est la façon dont ils interagissent les uns avec les autres. S'ils sont liés, partageant les mêmes copies de données pendant l'exécution, ils sont un dans le même programme; cependant, s'ils fonctionnent en tant que processus séparés (c'est-à-dire fourchus) transmettant des données entre différents processus distincts, ce que vous faites peut être autorisé car ce sont, pour eux, des programmes distincts. S'il utilise un espace de données partagé pendant l'exécution et ne fonctionne pas avec des processus distincts, ce que vous faites peut ne pas être autorisé, car pour eux, ils sont identiques ou trop étroitement couplés pour être distincts ou indépendants.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.