AGPL - ce que vous pouvez faire et ce que vous ne pouvez pas
AGPL est une licence relativement nouvelle qui était destinée à passer sur les réseaux GPL. Cependant, n'étant pas avocat et n'ayant pas lu l'intégralité de la licence, je ne comprends pas exactement ce que vous pouvez faire librement et ce qui ne l'est pas avec AGPL.
Mon incertitude est alimentée par cet article à propos de MongoDB (qui est AGPL) et encore plus par les commentaires ci-dessous.
Si nous suivons les commentaires, il s'avère que vous pouvez utiliser les bibliothèques AGPL avec votre logiciel côté serveur commercial à source fermée, tant que vous ne modifiez pas 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 avec MongoDB est qu'il utilise une 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 à code source fermé? Par exemple, prenez iText - c'est une bibliothèque AGPL:
- si vous l'utilisez et le modifiez, devez-vous open-source l'intégralité de votre application ou devez-vous redistribuer uniquement les modifications dans iText?
- si vous l'utilisez et ne le modifiez pas , devez-vous open-source l'intégralité de votre application?
- Si vous encapsulez iText dans une autre application que vous démarrez en tant que processus distinct, mais que vous l'utilisez à partir de votre application principale, devriez-vous tout open-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 comme JSON). Peut-elle être utilisée pour contourner la licence AGPL?
Remarque: La question concerne AGPLv3
L'AGPL est basé sur la GPL, pas sur la LGPL. Il ne contient aucune exception de liaison, et tout travail utilisant le code AGPL (lié ou non, modifié ou non) doit également être autorisé et distribué par AGPL.
L'utilisation de processus séparés peut contourner la (A) GPL, mais c'est un terrain trouble. Si votre application finale dépend du processus externe, de sorte qu'elle ne fonctionnerait pas correctement sans elle, alors elle serait considérée comme un travail dérivé du logiciel AGPL.
Dans la plupart des cas où les gens utilisent des applications GPL distinctes dans des programmes source fermés, ils fournissent le travail GPL comme une extension facultative, ou un back-end alternatif à un autre morceau 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 bien de fournir des instructions sur où trouver le travail GPL et comment l'utiliser avec votre application.
AGPL est identique à GPL; par conséquent, si votre application utilise le code AGPL, elle doit être sous licence AGPL.
Ce que fait AGPL en plus de GPL, c'est la redéfinition de l'utilisateur. Pour les programmes GPL exécutés sur votre serveur, vous êtes l'utilisateur, pour AGPL, les vrais utilisateurs de l'application sont les utilisateurs de votre site Web ou service. Par conséquent, vous distribuez l'application si quelqu'un d'autre que vous l'utilise. Et cela implique bien sûr toutes les exigences GPL standard.
Quant à Mongo, je suppose que les applications qui l'utilisent n'utilisent pas son code, seulement certaines API, qui ne sont pas sous licence AGPL.