AGPL est une toute nouvelle licence destinée à utiliser la GPL sur les réseaux. Cependant, n'étant pas avocat et n'ayant pas lu la totalité de la licence, je ne comprends pas ce que vous pouvez faire librement et ce que vous ne pouvez pas faire avec AGPL.
Mon incertitude est alimentée par cet article sur MongoDB (qui est AGPL) et encore plus par les commentaires ci-dessous.
Si nous suivons les commentaires, il s'avérera que vous pouvez utiliser les bibliothèques AGPL avec votre logiciel côté serveur commercial à source fermée, à condition de ne pas modifier la bibliothèque. Est-ce le cas? Ou vous devez distribuer l'intégralité de votre application lorsque vous utilisez une bibliothèque sous licence AGPL?
Le cas de MongoDB est qu’il utilise la licence Apache pour le code client, ce qui pose une autre question. Que se passe-t-il si vous utilisez le logiciel AGPL, mais que vous le déployez en tant qu'application différente de votre application commerciale à source fermée? Par exemple, prenez iText - c'est une bibliothèque AGPL:
- si vous l'utilisez et le modifiez, devez-vous ouvrir votre application au complet ou devez-vous redistribuer uniquement les modifications apportées à iText?
- si vous l'utilisez et ne le modifiez pas, devez-vous ouvrir votre application au complet?
- Si vous intégrez iText dans une autre application que vous démarrez en tant que processus distinct, mais que vous utilisez depuis l'application principale, devez-vous tout ouvrir en source ou simplement l'application wrapper? (L'application d'encapsulation sera une API basée sur HTTP qui prendra les fichiers PDF et renverra les résultats de l'utilisation d'iText en tant que JSON). Cela peut-il être utilisé pour contourner la licence AGPL?
Note: La question concerne AGPLv3
Réponses:
L'AGPL est basé sur la GPL et non sur la LGPL. Il ne contient aucune exception de lien et tout travail utilisant le code AGPL (lié ou non, modifié ou non) doit également être sous licence et distribué par AGPL.
L'utilisation de processus distincts peut contourner la (A) GPL, mais il s'agit d'un terrain trouble. Si votre application finale dépend du processus externe, de sorte qu'elle ne fonctionnerait pas correctement sans celui-ci, elle serait alors considérée comme un travail dérivé du logiciel AGPL.
Dans la plupart des cas, lorsque des utilisateurs utilisent des applications GPL distinctes dans des programmes à sources fermées, ils fournissent le travail GPL en tant qu'extension facultative, ou alternative de base de données à un autre élément de code, etc.
Le travail (A) GPL ne peut pas être distribué avec l'application finale même en tant qu'application distincte (par exemple, en les plaçant dans la même archive ou le même référentiel), bien qu'il soit correct de fournir des instructions sur l'emplacement du travail GPL et sur son utilisation avec votre application.
la source
mainse compose de packages compatibles DFSG , qui ne dépendent pas de logiciels extérieurs à cette zone pour fonctionner. Ce sont les seuls paquets considérés comme faisant partie de la distribution Debian .contribles paquets contiennent des logiciels compatibles avec DFSG , mais ont des dépendances qui ne sont pas dans main (éventuellement emballées pour Debian dans une version non-free).non-freecontient des logiciels non conformes au DFSG .AGPL est identique à GPL; Par conséquent, si votre application utilise le code AGPL, elle doit être sous licence AGPL.
Ce qu’AGPL fait au-dessus de la GPL est la redéfinition de l’utilisateur. Pour les programmes GPL s'exécutant sur votre serveur, vous êtes l'utilisateur, pour AGPL, les utilisateurs réels de l'application sont les utilisateurs de votre site Web ou de votre service. Par conséquent, vous distribuez l'application si quelqu'un d'autre que vous l'utilisez. Et cela implique bien sûr toutes les exigences standard de la GPL.
En ce qui concerne Mongo, je suppose que les applications qui l'utilisent n'utilisent pas son code, mais uniquement certaines API, qui ne sont pas sous licence AGPL.
la source