Une question un peu réthorique pour le collectif . Peut-on souscrire à une édition entreprise (avec une license non libre) d’un logiciel tout en respectant la charte CHATONS?
Ou plutôt: Comment bénéficier des fonctionnalités entreprises (sous licences non libres) dans logiciel tout en respectant la chartre CHATONS?
Par exemple avec OnlyOffice comme discuté içi https://forum.chatons.org/t/depasser-la-limite-donlyoffice-pour-nextcloud/1451 on a donc plusieurs options: 1. On souscrit à l’édition entreprise pour ne pas avoir la limitation et potentiellement d’autres fonctionnalités - je ne sais pas si c’est le cas d’ailleurs pour OnlyOffice
2. On fait péter la limite nous même avec soit un build fait maison soit en la contournant en loadbalancant plusieurs instances (théoriquement c’est possible). En gros on fait un fork et on le maintient avec une version Community Enterprise à la centos
3. On souscrit à l’offre support tout en continuant à adopter l’option 2.
On peut avoir la même problématique avec du Gitlab, Rocketchat, Mattermost etc. qui sont, si je ne dis pas de bêtises, sur des modèle économiques open-core avec une version communauté et une version entreprise.
A vrai dire je ne me pose pas, pour l’instant, la question pour ces autres logiciels, par contre pour OnlyOffice je me retrouve face à cette problématique aujourd’hui.
Donc de mon point de vue, l’option 1 est hors équation.
Si j’adopte l’option 2, je ne contribue pas directement au développement du logiciel et il va falloir investir pas mal de ressources. Je vais avoir besoin de vous.
Si j’adopte l’option 3, c’est la double peine.
Il y a une quatrième option (et j’ai l’impression que c’est la plus fréquemment adoptée): faire un build maison non maintenu en priant pour qu’il tienne le plus longtemps possible.
Et une cinquième (qui est celle que j’adopte mais qui n’est pas la plus populaire) qui consiste à considérer que les anti-features font partie de la distribution libre et ne pas tenter de les enlever. Ce qui peut vouloir dire se retrouver sans solution du tout ou bien se tourner vers une autre solution qui présente peut-être d’autres inconvénients mais pas celui la.
Un autre cas qui m’intéresse particulièrement est Signal dont les développeurs ne sont pas intéressés du tout par la dynamique libre, au point de ne pas être amicaux à l’idée d’être packagés pour Debian GNU/Linx et/ou Ubuntu. La question se pose donc de maintenir un package sur un dépôt tiers, avec les mêmes problèmes de charge de travail. Du coup il y a de nombreux contextes ou je n’utilise pas Signal parce qu’il n’est pas packagé et je suis obligé de me tourner vers des solutions qui sont techniquement moins bien mais qui ont une charge de maintenance plus faible.
En effet, j’aimairais bien réussir à sortir de ce mécanisme
Oué c’est là où ca fait mal à la tête, je pense en effet que le plus important dans un projet libre au-delà du contenu technique de la licence c’est l’intention qui est mise. Et donc théoriquement si il y a des anti-fonctionnalités je devrais respecter ce choix.
C’est compliqué… J’aimerais trouver un modèle de contribution autre
Mon point de vue d’amateur sur deux aspects : l’aspect légal (la licence) et l’aspect philosophique.
(PS : je ne suis ni juriste ni philosophe)
Tout d’abord le cadre légal (exemple d’OnlyOffice, AGPL v3) :
Le développeur est libre d’inclure ce que bon lui semble dans son code, dont une « anti-feature ».
Le modifier pour s’en affranchir en vu de l’utiliser comme bon nous semble est également un droit selon l’AGPL.
Il est néanmoins nécessaire de mettre à disposition du public la version modifiée.
Donc, d’un point de vue légal, pas de problème.
Maintenant du point de vue de la philosophie du Libre, implémenter une fonctionnalité qui, in fine, bride le logiciel me parait plus que limite au vu des valeurs qui sont promues par ce mouvement (mais cela ne poserai peut-être pas de soucis du point de vue de l’Open Source ?).
Dans son manifeste GNU, Richard Stallman indique « […]Soutirer de l’argent aux utilisateurs d’un programme en restreignant son usage est destructeur[…] ».
On en revient, il me semble, inlassablement à la question des modèles économiques en lien avec le logiciel libre qui viennent régulièrement se heurter à ses valeurs.
Bien dit On pourrait même varier la formulation en définissant un modèle économique logiciel libre comme une façon de générer un revenu sans heurter ses valeurs. Du coup les modèles Open Core n’en font pas partie, puisque le revenu ne vient pas du logiciel libre mais des extensions propriétaires. Et ceux qui exploitent ce qu’ils pensent être des faiblesses des licences (je pense à https://gpgtools.org/ ou https://grsecurity.net/ par exemple) n’ont pas non plus de modèle économique libre puisqu’ils heurtent ses valeurs en plus de jouer avec les termes des licences. Mes 2cts de philosophie de comptoir, à prendre moyennement au sérieux
En français, on dirait « contrat (de maintenance, de formation, de suivi…) », c’est plus simple. Mais comme les clients apprécient généralement d’être enfumés par un jargon incompréhensible, c’est correct.
Quand même préciser que généralement quand on en arrive à devoir dépasser la limite même artificielle c’est que l’on a une base utilisateurs conséquente et parfois (souvent?) un budget possible pour rétribuer le travail des développeurs.
Oui en effet arrive un stade où probablement on peut payer le support, on est d’accord c’est d’ailleurs déjà écrit dans ma point 3. Là n’est pas la question dans ce sujet.
Si je paye le support et que je bénéficie d’un onlyoffice sans limitation et donc de la version non libre du logiciel alors exit CHATONS parce que je ne respecte plus la charte.
Ma question n’est pas comment éviter de payer ? Mais comment comme bénéficier de fonctionalités non libres tout en restant libre ?
Dans le cas précis de OnlyOffice cela reste un logiciel libre vu que malgré la limitation, le code reste ouvert, librement modifiable et librement redistribuable, non ?
Du coup pour clarifier, c’est donc proposer un service qui va exécuter du code non libre côté client (si j’ai bien compris, les sources du client pour éditer des docs sur mobile ne sont plus distribuées) ?
Je dirais que si vous utilisez la licence oo pour faire tourner le paquet community (sans la limite du coup), je serais tenté de dire que c’est sans doute bon au regard de la charte.
Si en revanche, il s’agit de faire tourner du code propriétaire, là je dirais que ça ne va pas au regard de la charte.
Si c’est comme collabora online à l’époque, il y a peut être 0 lignes de code distinctes entre Docs Community et Docs Enterprise. Si tel n’est pas le cas, à vous de proposer une modification de la charte et un argumentaire qui puisse être accepté (sachant que ça plaira sans doute pas à l’April et d’autres chatons).
Il me semble que @Framasoft doit aussi se poser ce genre de question, vu qu’il est question de OO et CO dans la description de frama.space (à moins qu’une instance soit prévue par asso ?).
De ce que je comprends, dans OO, il y a du code proprio coté back (mode cluster) et front (online mobile edition). (Je ne me vois pas payer sans ces fonctionnalités)
@Zaclys je vous laisse faire cette proposition?
Je pense qu’il peut y avoir de bons arguments, comme financer la partie open core. Mais ce n’est pas trivial.
De notre coté, on utilise toujours que la version libre.
Je me pose cette même question pour Seafile (ou OCIS).
Est-ce qu’il ne serait pas pertinent d’assumer un fork, de changer le nom et la charte graphique, etc. tout en faisant un don qui semble juste aux développeurs ?
Ça permettrait de dire à la fois que :
Un modèle open core c’est pas l’esprit du libre
Qu’on est enclin à rétribuer le travail de développement ?
Ça peut aussi être l’occasion de faire des modifications plus en profondeur du logiciel ?
Ça peut aussi être l’occasion de mutualiser le travail de patch qu’on fait beaucoup dans notre coin pour favoriser des modifications avec de la valeur ajoutée.
Par exemple, pour ma part, je me suis cogné le repackaging de Jitsi qui est infernal à déployer autrement (repackaging en conteneurs Docker indépendants, sans la couche de scripts bash, avec homogénéisation de la configuration). J’ai des travaux en cours sur SoGo également (seul un build de la nightly est proposé, et là aussi tous les composants sont bundlés ensemble sans doc) ainsi que sur Seafile (dockerisation des différents composants : ccnet, fileserver, frontend; ajout du support d’un support de S3 en libre, etc.).
Je trouve que cette approche est celle qui est le plus susceptible de porter l’idée que je me fais du Libre.
. 
