Puis-je utiliser les plugins de licence Apache Software License, Version 2.0 et GNU LGPL 3 dans mon application Web commerciale?

J'ai deux plug-ins. L'un a la licence GNU LGPL 3 et l'autre a la licence du logiciel Apache, version 2.0. Puis-je les utiliser dans mon application commerciale? Et si oui, quelles précautions dois-je prendre?

licensing lgpl apache-license

— umairaslam
source

N'oubliez pas que vous ne devez JAMAIS suivre les conseils juridiques que vous obtenez sur Internet, sauf s'ils proviennent d'un avocat. De préférence celui qui se spécialise dans le domaine donné, dans ce cas: les licences de logiciels. Prenez donc toutes les réponses que vous obtenez avec un grain de sel, car sinon vous risquez de vous exposer à des poursuites (car votre application est commerciale).

— Radu Murzea

Réponses:

Puis-je les utiliser dans mon application commerciale?

Cela dépend de ce que vous avez l'intention de faire avec le logiciel que vous produisez.

Premièrement, ni ASL ¹ , GPL ni LGPL ne font de restrictions sur ce que vous pouvez utiliser pour faire des logiciels au sein de votre organisation. Les restrictions concernent toutes le code distribué en dehors de votre organisation.

Pour GPL, la restriction est que si vous intégrez du code GPL dans votre propre logiciel ET que vous distribuez ensuite votre logiciel en dehors de votre organisation, ALORS vous devez rendre le code source disponible selon les termes de la GPL ou d'une licence open source compatible.

Donc, si vous utilisez du code GPL dans votre application et que vous le distribuez, votre application doit être open source ... sinon vous violez la licence.
Pour LGPL, la restriction (voir ci-dessus) s'applique uniquement au code source de la bibliothèque LGPL elle-même; c'est-à-dire si vous changez de bibliothèque. Si vous utilisez simplement la bibliothèque, vous n'êtes pas obligé de rendre votre code source disponible.

Il existe également une restriction selon laquelle le code LGPL dans votre application doit être remplaçable par l'utilisateur de votre code. Cela signifie (en effet) que si vous distribuez votre code uniquement sous forme de fichiers binaires, vous ne pouvez pas lier statiquement votre code à celui de la bibliothèque. Vous devez utiliser la liaison dynamique.
Pour ASL, la seule restriction importante est que vous devez dire si vous avez changé quoi que ce soit par rapport à la version d'origine le code ASL que vous utilisez.

Enfin, pour être clair, ni GPL, LPGL ni ASL ne restreignent votre objectif d'utilisation du logiciel. Et cela inclut si votre but est de gagner de l'argent. Ils limitent simplement la façon dont vous pouvez gagner de l'argent ... et dans le cas de LGPL et ASL, la contrainte est assez minime.

Et si oui, quelles précautions dois-je prendre?

Pour LGPL et ASL, aucune précaution n'est nécessaire.

IANAL - Je ne suis pas avocat. Si vous avez besoin d'être sûr, demandez à un véritable expert qualifié; c'est-à-dire un avocat spécialisé dans le droit de la propriété intellectuelle des logiciels.

^{1 - Aux fins de cette réponse, ASL == Apache Software License version 2.}

— Stephen C
source

Est-ce que cela s'applique à une application Web? je veux dire que le client ne recevra que le fichier war contenant les fichiers .class et .JAR. Si tout va bien, LGPL?

— Java Main

Si vous ne modifiez pas les bibliothèques LGPL, vous pouvez les inclure avec votre code d'application dans le fichier WAR. Mais vous devez le faire de telle manière que la personne à qui vous distribuez votre code puisse remplacer le code LBPL par une autre version. Un "uber-JAR" est probablement une violation. Obscurcir les bibliothèques LGPL avec votre code est définitivement une violation. (IANAL)

— Stephen C

Il y a un dossier appelé lib où je place tous les fichiers jar. Il peut donc remplacer n'importe quel fichier Jar par son autre version. Mais je ne garantis pas que cela fonctionnera toujours. C'est toujours ok?

— Java principal

Demandez à votre avocat :-)

— Stephen C

Il s'agit simplement d'une application Web normale exécutée sur tomcat. Si vous pouvez aider, ce sera bien. Quoi qu'il en soit, merci pour vos éclaircissements vraiment utiles.

— Java Main

La licence Apache ne place aucune restriction sur les logiciels liés à un plug-in ou à une bibliothèque distribués sous la licence Apache. La LGPL, d'autre part, exige que la bibliothèque LGPL soit liée dynamiquement (et puisse être remplacée par un utilisateur) ou que l'ensemble du travail soit publié sous une licence open source compatible GPL.

Pour l'utilisation dans une application de source fermée, cela signifie effectivement que vous pouvez utiliser le plug-in sous licence Apache sans restriction et que le plug-in sous licence LGPL doit être lié dynamiquement.

Si vous distribuez l'un des plug-ins avec votre application, vous devez également fournir les sources des plug-ins ou informer vos utilisateurs où ils peuvent obtenir ces sources.

— Bart van Ingen Schenau
source

BartvanIngenSchenau qu'entendez-vous par application "de source fermée"? Voulez-vous dire une solution packagée (ne distribuant pas de code source), ou faites-vous référence à sa distribution au sein d'une organisation par rapport à quelque chose comme la distribution commerciale?

— Rachael

@Rachael: "Closed-source" est généralement utilisé pour faire référence aux logiciels pour lesquels le code source n'est pas distribué. La distribution au sein d'une organisation est un peu un cas spécial en ce qui concerne les licences de droit d'auteur, car la fourniture de copies d'un produit logiciel à des personnes au sein d'une organisation n'est pas considérée comme une distribution pour la plupart des lois sur le droit d'auteur (elle est considérée comme une copie).

— Bart van Ingen Schenau

-4

Tout d'abord, ce n'est pas un avis juridique.

Les logiciels GPL ne sont pas autorisés à être liés à (y compris via le réseau), à être compilés ou expédiés avec des logiciels non GPL sous quelque forme que ce soit. LGPL assouplit un peu cela pour permettre un support tiers non GPL, y compris pour les produits commerciaux. La partie importante ici est qu'il doit être tiers (pour ainsi dire), ce qui crée un petit trou de boucle.

En bref, vous vous connectez à une bibliothèque LGPL existante (appelez cela la première partie), mais le logiciel qui fait ce lien doit être LGPL. Appelez ce logiciel le deuxième correspondant. Bien que le logiciel tiers doive être publié en tant que LGPL, en tant que propriétaire du logiciel tiers, vous pouvez autoriser d'autres logiciels à l'utiliser en dehors de LGPL (tant que le logiciel tiers reste également disponible sous LGPL). En d'autres termes, le logiciel tiers doit être disponible en tant que LGPL, mais n'est pas requisde le concéder sous licence en tant que LGPL dans tous les cas. Chaque utilisateur individuel d'un logiciel doit avoir une licence pour utiliser ledit logiciel par la loi. Ce que je dis, c'est que tant que chaque utilisateur a accès au logiciel en tant que LGPL, vous pouvez également le concéder sous licence en utilisant des termes non viraux. Vous pouvez également créer le logiciel tiers, ce qui vous donne en fait la licence du logiciel tiers pour une utilisation par le logiciel tiers sous des conditions non LGPL. J'ai même entendu parler de gens qui s'authentifiaient d' un contrat et d'une licence pour utiliser leur propre logiciel. La loi peut être étrange! Le logiciel tiers ne doit en aucun cas être LGPL.

Donc, ce que vous faites est de créer une bibliothèque à lier à la bibliothèque LGPL comme un simple wrapper et de libérer le wrapper comme LGPL. Vous pouvez ensuite créer un lien vers ce wrapper ( votre wrapper) dans un logiciel non LGPL, tant que votre wrapper est disponible en tant que LGPL.

Je ne peux pas parler pour la licence du logiciel Apache parce que je ne la connais pas.

— JSON
source

Notez que j'utilise le terme "lien" de manière très générique, car cela ne s'applique pas uniquement aux langues compilées et peut également inclure "y compris" le logiciel LGPL (à partir d'un emplacement local ou réseau, comme PHP ou Javascript), ou autre "liaison" à un logiciel sur un réseau tel que Java RMI etc.

— JSON

"Les logiciels GPL ne sont pas autorisés à être liés à (y compris sur le réseau), à être compilés ou expédiés avec des logiciels non GPL sous quelque forme que ce soit." . Le "ou" devrait être "et". Vous POUVEZ utiliser des logiciels sous GPL dans des logiciels non GPL à condition de ne pas les «expédier».

— Stephen C

Cette réponse est fausse à tant de niveaux. La question ne concerne pas la GPL, mais la LGPL. Le code ASL peut être intégré dans le code sous presque n'importe quelle autre licence, ce qui signifie également LGPL ou même GPL (même si le contraire est interdit). Vous pouvez même l'utiliser dans un logiciel à source fermée. Et, comme l'a souligné Stephen C., vous pouvez faire ce que vous voulez tant que vous ne le publiez pas ou ne le rendez pas autrement accessible au public.

— Alexis Dufrenoy