La SSPL exige de libérer toute la stack utilisée pour fournir MongoDB as a service.
A company that offers a publicly available MongoDB as a service must open source the software >it uses to offer such service, including the management software, user interfaces, >application program interfaces, automation software, monitoring software, backup software, >storage software and hosting software, all such that a user could run an instance of the >service using the source code made available.
L'AGPL oblige uniquement de refournir les sources de MongoDB.
Dans ce cas la GPL c'est pareil non? Là où avant le lien c'était un lien dans un processus là c'est un lien dans le réseau. Entre un OS qui est sur ton CPU/RAM et un autre qui est distribué entre X nœuds sur le réseau, bon ça reste dans une même philosophie. (même si un processus GPL ne forçait pas les autres processus on est d'accord, d'où le "plus libre" car il étends l'application forcée des libertés).
Je suis d'accord sur le fait que c'est plus libre que libre.
Mais oui ça va à l'encontre total des habitudes de l'open source d'aujourd'hui (dans le sens base d'outils open source pour sous tenir un service qui lui est commercial) et les consommateurs passifs (au sens production de briques open source eux même) ne vont pas aimer.
Or ils sont la grande majorité donc ça explique tout le bruit (et donc l'image négative) autour du changement de mongo.
Posté par BAud (site web personnel) .
Évalué à 6.
Dernière modification le 29 janvier 2019 à 14:21.
Dans ce cas la GPL c'est pareil non ?
nope, la SSPL ne respecte pas la liberté 0 pour le fournisseur de service. Par exemple, s'il avait le malheur de baser son service sur une base de données Oracle (chacun ses choix…), il devrait fournir les sources d'Oracle SGBD (ce que seul Oracle a…).
Avec la GPL ou l'AGPL, ce cas ne se produit pas vu qu'il n'y a que la partie de stack utilisée sous cette licence à fournir et pas toutes les couches (selon le niveau d'interfaçage).
La SSPL me paraît effectivement libre, mais son gros problème, c'est cette fameuse section 13 qui essaie de faire mieux que l'AGPL : il faut libérer les autres outils utilisés pour mettre en place le service sous SSPL.
Mais on ne peut pas changer la licence des outils qu'on utilise comme ça. Dans un monde ou tout est sous GPL, MPL, BSD ou toute licence autre qu'SSPL, je ne sais pas à quel point c'est possible légalement ou pas d'utiliser MongoDB sous SSPL dans une distribution GNU/Linux aujourd'hui pour fournir un service sans autorisation expresse de l'éditeur.
L'ensemble des choses qui ne devraient pas être concernées par la section 13 devrait être clairement défini dans cette section, ce qui n'a pas l'air d'être le cas après lecture, et ça ne devrait pas être fait sur la base d'autorisations au cas par cas du style "ah mais si, pour le noyau Linux c'est bon, pas besoin de relicencier sous SSPL" au bon vouloir de l'éditeur du logiciel.
Vu qu'il n'est potentiellement pas possible d'utiliser MongoDB sur Debian ou Red Hat pour certaines utilisations habituellement possibles avec les autres logiciels libres sans l'autorisation expresse de l'éditeur à cause des licences incompatibles, la décision de ces distributions de ne pas fournir ce logiciel même s'il est libre me paraît cohérente. Même avec l'AGPL, je ne vois pas d'exécution interdite possible si l'application n'a pas été modifiée. Une telle restriction pourrait être surprenante pour les personnes qui utilisent ces distributions.
On se croirait dans un roman d'Asimov, où on explore des effets inattendus des lois de la robotique.
# vu sur /.
Posté par BAud (site web personnel) . Évalué à 6.
https://linux.slashdot.org/story/19/01/19/057200/red-hat-rejects-mongodbs-discriminatory-server-side-public-license
le changement de licence pour la partie serveur avait été annoncé en octobre 2018 :
https://developers.slashdot.org/story/18/10/16/2039253/mongodb-switches-up-its-open-source-license
L'article sur zdnet https://www.zdnet.com/article/mongodb-open-source-server-side-public-license-rejected/
revient sur :
# SSPL vs AGPL
Posté par mzf (site web personnel) . Évalué à 2.
Je n'arrive pas à saisir les différences entre la SSPL et l'AGPL.
La FAQ de MongoDB précise:
n'est-ce pas déjà le cas dans l'AGPL de devoir publier le code source modifié lorsque le logiciel est utilisé en tant que service ?
AGPL sur Wikipédia:
Merci d'avance pour des éclaircissements :)
[^] # Re: SSPL vs AGPL
Posté par jame_s . Évalué à 4.
La SSPL exige de libérer toute la stack utilisée pour fournir MongoDB as a service.
L'AGPL oblige uniquement de refournir les sources de MongoDB.
[^] # Re: SSPL vs AGPL
Posté par Gabin_2 . Évalué à 1.
Donc la SSPL lave plus libre que libre?
Pourquoi ça ne plait pas aux puristes ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 6. Dernière modification le 29 janvier 2019 à 13:38.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: SSPL vs AGPL
Posté par Jean Gabes (site web personnel) . Évalué à 0.
Dans ce cas la GPL c'est pareil non? Là où avant le lien c'était un lien dans un processus là c'est un lien dans le réseau. Entre un OS qui est sur ton CPU/RAM et un autre qui est distribué entre X nœuds sur le réseau, bon ça reste dans une même philosophie. (même si un processus GPL ne forçait pas les autres processus on est d'accord, d'où le "plus libre" car il étends l'application forcée des libertés).
Je suis d'accord sur le fait que c'est plus libre que libre.
Mais oui ça va à l'encontre total des habitudes de l'open source d'aujourd'hui (dans le sens base d'outils open source pour sous tenir un service qui lui est commercial) et les consommateurs passifs (au sens production de briques open source eux même) ne vont pas aimer.
Or ils sont la grande majorité donc ça explique tout le bruit (et donc l'image négative) autour du changement de mongo.
[^] # Re: SSPL vs AGPL
Posté par BAud (site web personnel) . Évalué à 6. Dernière modification le 29 janvier 2019 à 14:21.
nope, la SSPL ne respecte pas la liberté 0 pour le fournisseur de service. Par exemple, s'il avait le malheur de baser son service sur une base de données Oracle (chacun ses choix…), il devrait fournir les sources d'Oracle SGBD (ce que seul Oracle a…).
Avec la GPL ou l'AGPL, ce cas ne se produit pas vu qu'il n'y a que la partie de stack utilisée sous cette licence à fournir et pas toutes les couches (selon le niveau d'interfaçage).
[^] # Re: SSPL vs AGPL
Posté par raphj . Évalué à 5.
La SSPL me paraît effectivement libre, mais son gros problème, c'est cette fameuse section 13 qui essaie de faire mieux que l'AGPL : il faut libérer les autres outils utilisés pour mettre en place le service sous SSPL.
Mais on ne peut pas changer la licence des outils qu'on utilise comme ça. Dans un monde ou tout est sous GPL, MPL, BSD ou toute licence autre qu'SSPL, je ne sais pas à quel point c'est possible légalement ou pas d'utiliser MongoDB sous SSPL dans une distribution GNU/Linux aujourd'hui pour fournir un service sans autorisation expresse de l'éditeur.
L'ensemble des choses qui ne devraient pas être concernées par la section 13 devrait être clairement défini dans cette section, ce qui n'a pas l'air d'être le cas après lecture, et ça ne devrait pas être fait sur la base d'autorisations au cas par cas du style "ah mais si, pour le noyau Linux c'est bon, pas besoin de relicencier sous SSPL" au bon vouloir de l'éditeur du logiciel.
Vu qu'il n'est potentiellement pas possible d'utiliser MongoDB sur Debian ou Red Hat pour certaines utilisations habituellement possibles avec les autres logiciels libres sans l'autorisation expresse de l'éditeur à cause des licences incompatibles, la décision de ces distributions de ne pas fournir ce logiciel même s'il est libre me paraît cohérente. Même avec l'AGPL, je ne vois pas d'exécution interdite possible si l'application n'a pas été modifiée. Une telle restriction pourrait être surprenante pour les personnes qui utilisent ces distributions.
On se croirait dans un roman d'Asimov, où on explore des effets inattendus des lois de la robotique.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.