// The maximal size for an image is 5MBconstMaxSize=5*(1<<20)
ça n'empêche pas que l'on puisse faire une image jpg de 10000x10000 entièrement noire et qui fasse moins de 1,2 Mo sur disque (mais va consommer beaucoup de mémoire à l'ouverture). Je prends un exemple extrême évidemment, pour dire que 5 MB de jpg, ça peut faire une grande image.
$ epubcheck s-occuper-pendant-les-vacances-yunohost-et-autohebergement.epub
Vérifications faites en utilisant les règles de la version epub 3.2.
ERROR(MED-004): s-occuper-pendant-les-vacances-yunohost-et-autohebergement.epub/EPUB/(-1,-1): L'en-tête du fichier image pourrait être corrompu.
ERROR(PKG-021): s-occuper-pendant-les-vacances-yunohost-et-autohebergement.epub/EPUB/(-1,-1): Fichier image corrompu rencontré.
Vérification terminée avec des erreurs
Messages: 0 fatale / 2 erreurs / 0 avertissement / 0 info
EPUBCheck terminé
$ epubcheck childrens-literature.epub
Vérifications faites en utilisant les règles de la version epub 3.2.
Aucune erreur ou avertissement détecté.
Messages: 0 fatale / 0 erreur / 0 avertissement / 0 info
EPUBCheck terminé
2) on dézippe
$ unzip childrens-literature.epub
3) on zippe bêtement
$ zip test.epub EPUB/cover.xhtml EPUB/css/epub.css EPUB/css/nav.css EPUB/images/cover.png EPUB/nav.xhtml EPUB/package.opf EPUB/s04.xhtml EPUB/toc.ncx META-INF/container.xml mimetype
updating: mimetype (stored 0%)
updating: EPUB/cover.xhtml (deflated 34%)
updating: EPUB/css/epub.css (deflated 60%)
updating: EPUB/css/nav.css (deflated 46%)
updating: EPUB/images/cover.png (deflated 13%)
updating: EPUB/nav.xhtml (deflated 82%)
updating: EPUB/package.opf (deflated 62%)
updating: EPUB/s04.xhtml (deflated 66%)
updating: EPUB/toc.ncx (deflated 90%)
updating: META-INF/container.xml (deflated 32%)
$ epubcheck test.epub
Vérifications faites en utilisant les règles de la version epub 3.2.
ERROR(PKG-005): test.epub(-1,-1): Le fichier mimetype a une extension de longueur 28. Aucune extension de nom de fichier n'est autorisée pour le fichier mimetype.
Vérification terminée avec des erreurs
Messages: 0 fatale / 1 erreur / 0 avertissement / 0 info
EPUBCheck terminé
J'ai l'impression que la validateur ne veut pas les répertoires (zip -D), ni les attributs amenés par Unix, mais je n'ai pas noté ça dans la spécification (et personne ne s'était plaint de cela avant… possible que les liseuses soient juste tolérantes).
A priori, c'est une problématique partagée par divers acteurs du domaine : MongoDB (->SSPL), Elastic (->SSPL), Graylog (->SSPL), Redis (pour les modules ->Common Clause, 1 , 2, puis RSAL), tous accusant les GAFAM / gros fournisseurs de cloud.
// The maximal size for an image is 5MBconstMaxSize=5*(1<<20)
ça n'empêche pas que l'on puisse faire une image de 10000x10000 entièrement noire et qui fasse moins de 1,2 Mo sur disque (mais va consommer beaucoup de mémoire à l'ouverture). Je prends un exemple extrême évidemment, pour dire que 5 MB de jpg, ça peut faire une grande image.
Correctif proposé : un hachage sha224 (sha256 -> 64 octets et sha224 -> 56 octets, on avait choisi moins de 60, je vais m'y tenir) pour éviter les collisions de début de path en sortie d'img, mais en calculant plus largement que juste le path, autant prendre l'URI en entier, le tout en restant en 60 octets ou moins (ici 56) + l'extension.
(où 68747470733a2f2f78756c6f70732e6e65742f696d6167652f61757472652f est la version en hexadécimal de https://xulops.net/image/autre/ )
Les 3 jpg dans epub (les 60 premiers octets du path de img sans les '/', soit les 30 premiers octets du path de l'image d'origine converti en hexa, d'où une collision fréquente sur un même domaine dès qu'on dépasse 30 octets):
Does this mean that Elasticsearch and Kibana are no longer Open Source?
Yes. Neither SSPL or the Elastic License have been approved by the OSI, so to prevent confusion, we no longer refer to Elasticsearch or Kibana as open source.
Is the SSPL on an OSI-recognized open source license?
The SSPL is based on the GNU General Public License, but it is a new license introduced by MongoDB, not the Free Software Foundation. The SSPL has not been approved by the OSI.
On sait aussi que Debian, Red Hat Enterprise Linux et Fedora Linux ont retiré MongoDB de leur distribution. Il est probable qu'Elasticsearch, Kibana et Graylog (qui a fait le même choix en novembre 2020) vont subir le même sort (en supposant qu'ils soient précédemment inclus dedans).
Je ne connais pas de prise de position FSF sur la SSPL.
Ce qui menace bien l’avenir du logiciel tel que prévu par la FSF (dont le but est de libérer l’utilisateur). Par contre ça ne menace pas l’avenir du logiciel tel que prévu par le vendeur d’enregistreur numérique qui pratique la tivoïsation (dont le but est juste de vendre son enregistreur). À chaque fois, on a les intérêts de la communauté/entreprise qui produit le logiciel, ceux des utilisateurs, et les intérêts de ceux qui pourraient utiliser le logiciel pour le revendre à d’autres, et encore ceux d’autres acteurs encore (ce logiciel libre avec chiffrement bout-en-bout va-t-il gêner les publicitaires ? les services de renseignement ? les enquêtes de police ? le contrôle parental ? ce logiciel est-il important pour les vendeurs de matériel informatique ? ce logiciel consomme-t-il de l’attention ? beaucoup d’énergie ? etc., etc.).
Personne ne peut raisonner comme ayant un seul rôle, chaque acteur a toujours une multiplicité de rôles (utilisateur et/ou développeur d’un logiciel, parent ou non, citoyen, actionnaire d’une entreprise, fan de superproduction hollywoodienne, BSDiste ou GPLien, consommateur compulsif d’électronique, minimaliste fan de Gemini, etc., etc.). Et l’impact d’un changement de licence est toujours à évaluer pour chacun des acteurs et pour chacun des rôles, en termes de bénéfices/coûts et avantages/inconvénients.
Par exemple : la FSF peut dire la GPLv3 c'est mieux pour nous FSF (cf objectif social), c'est mieux selon nous pour les utilisateurs (même s'ils s'en fichent, on considère que c'est mieux pour eux), c'est mieux pour les citoyens (on considère que c'est d'intérêt général), c'est moins bien pour le modèle économique des vendeurs d'enregistreurs numériques (et on considère que ce n'est pas grave, ni pour l'emploi, ni pour les impôts, ni pour la compétitivité nationale dans le domaine, etc.), c'est moins bien pour les MAFIAA qui seraient ravis d'avoir des enregistreurs bien verrouillés à DRM incontournables (et on considère que ce n'est pas grave), etc., etc. -> conclusion on fait une nouvelle licence libre. C'est moins binaire/manichéen/simpliste qu'une partie de la discussion autour du journal pourrait le laisser supposer.
MongoDB Inc. et Elastic se plaignent des fournisseurs de MongoDB / Elasticsearch / Kibana à la demande (en particulier les gros fournisseurs de cloud), car ça leur prendrait une part trop importante des flux financiers autour du logiciel.
D’autres éditeurs se plaignent des intégrateurs (ESN/SSII) qui captent une partie des revenus d’installation / intégration / déploiement / support / service autour de produits phare.
Dès qu’un produit est suffisamment visible et aisément déployable, alors une autre société a un intérêt financier à court terme à le proposer : elle n’a pas à payer les coûts de développement, R&D, etc. et le logiciel existe déjà, elle apprend à l’installer et ensuite chaque nouvelle installation est un gain net. Tandis que l’éditeur doit continuer à financer le développement. C’est évidemment un choix à court terme : si l’éditeur est étranglé financièrement, le produit n’évolue plus et à terme, tragédie des communs, mort du produit, fin des revenus… Si l’évaluation est purement financière, pourquoi le nouvel acteur contribuerait, améliorerait la documentation, les traductions, ferait des retours et des apports divers, etc. ? Le copyleft est parfois utilisé pour cela, mais ça ne marche pas forcément dans tous les cas : Amazon peut très bien déployer exactement le logiciel sans aucune modification, c’est juste le volume des déploiements (et la facilité de le faire) qui l’intéresse et qui lui donne un avantage commercial. Le copyleft n’aide pas forcément pour cela. (précision: aux deux extrémités, le nouvel acteur peut tout à fait devenir un acteur contributeur du logiciel faisant grossir le chiffre d’affaires de tout le monde, ou bien être un simple parasite économique opportuniste à souhait et profiteur, pour grossir le trait).
Autre effet pervers : l’éditeur a donc intérêt à ne pas avoir un logiciel facilement installable, à avoir une documentation lacunaire, une configuration trompeuse et des logs énigmatiques pour avoir des questions via son support et vendre ses services ? Avec un peu de chance son logiciel est tellement imparfait qu’il passera sous les radars des méchants concurrents potentiels, avec un risque certain de ne pas être beaucoup utilisé en général non plus.
Le périmètre fonctionnel du logiciel joue beaucoup : si c’est le seul logiciel libre du domaine concerné, alors il y a peu de risque au début, au moins le temps qu’il ait suffisamment de fonctionnalités, il peut y avoir besoin d’experts du domaine pour le coder. Puis les ajouts supplémentaires deviennent en gros de la maintenance et de l’industrialisation : c’est un peu mieux en performance mais ça marchait déjà suffisamment bien, c’est des fonctionnalités utilisées par 10% de gens, c’est des fonctions avancées orientées grosses entreprises, etc. Alors d’un côté j’ai potentiellement moins de revenus (moins de commandes d’évolution, moins de support) et de l’autre plus de concurrence (oh un logiciel suffisamment revendable).
Une licence libre offre les quatre libertés et c’est valable pour tous les usages (légaux). Sans contester cet aspect, on peut néanmoins ne pas être en accord avec l’usage : si tu utilises des outils libres pour expliquer qu’il faut flamber à tout-va, consommer un max, se gaver de tout ce qui est possible et rien à carrer de l’avenir, de considérations écologiques, etc., c’est conforme à la licence, c’est légal / ça n’est a priori pas répréhensible (ça ne sera pas considéré comme un délit écologique à première vue), je peux néanmoins ne pas être d’accord avec cela.
Alors je peux choisir la voie de la licence : je change la licence pour éviter / limiter ce type d’usage (c’est me semble-t-il le cas qui est critiqué ici), mais si j’opte pour une licence non-libre, c’est qu’effectivement les 4 libertés n’étaient pas si importantes pour moi. Ou alors je choisis une autre voie : changer la législation pour faire créer un délit dans ce cas ? militer politiquement pour une prise de conscience ? communiquer sur le sujet pour espérer faire réagir ? etc.
L’usage qui est en fait menace l’avenir de mon logiciel selon moi ? Exemples : Tivoïsation et GPLv3 ? Valeur ajoutée accaparée par les fournisseurs de cloud (selon Elastic ou MongoDB Inc. par exemple) ? Service en ligne et AGPL ? BSD et clause de publicité ?
La question n’est pas nouvelle et visiblement, suivant les cas, on a apparition d’une nouvelle licence libre, changement pour une licence non-libre, et parfois d’autres approches non liées à la licence elle-même.
Ça rejoint surtout la question : quelle est ma grille de lecture ? Quels sont mes critères de choix ? Le libre, le coût, la communauté, le maintien d’une diversité pour préserver l’avenir, les aspects techniques, etc., etc. Ce qui me semble critiqué ici est le fait de prétendre que le libre serait mon critère de choix sine qua none mais que parfois « je suis prêt à faire du non-libre pour prétendre sauver le libre » ce qui serait incohérent.
RedHat change d’avis sur CentOS -> je continue à utiliser CentOS ? je change pour RockyLinux ? je boycotte RedHat ? je m’en fiche ? ai-je une responsabilité là-dedans (j’utilise sans jamais contribuer ou financer par exemple) ? est-ce une menace sur l'avenir de CentOS à court terme ? Etc.
Elastic change la licence d’Elasticsearch/Kibana -> comment je gère ce changement ? pourquoi ce changement a eu lieu et ai-je une responsabilité là-dedans ((j’utilise sans jamais contribuer ou financer par exemple)
Des personnes d’extrême-{droite, gauche} / complotistes / {pacifistes, militaristes } / { pro,anti }{.*} contribuent à ma communauté et à mon logiciel ? Est-ce que je peux le supporter (humainement) et aussi éviter l’explosion de ma communauté / de l’équipe de développement ? Est-ce que je dois ajouter des règles supplémentaires et des barrières d’entrée ? Est-ce que je veux changer ma licence et pourquoi, et pour quoi ? Est-ce que cela amène un risque juridique pour ma communauté / mon projet (des gens qui jouent trop près des limites légales, par exemple, les transgressant de temps en temps) ?
Quelles équipes de modération seraient pertinentes/utiles ? Des bénévoles ou des professionnels ? Règles de modération ? Code de conduite / charte pour les utilisateurs et/ou l'équipe de modération ? En langue française ou non ? En droit français ou non ?
A priori il faut des contenus produits par des utilisateurs ET des contenus qui ne sont pas tous modérés a priori.
L'équipe de modération de l'AdL voit des contenus produits par des utilisateurs, modérés a priori (mais rééditables ensuite par les utilisateurs). Par contre j'imagine qu'ils ont moins de dérives que nous car les thématiques sont plus cadrées (à moins de voir passer des événéments "Conférence GPL et effet du l'HCQ", "Avortement et copyleft" ou "Les religions traditionnelles vs l'église d'Emacs", etc.).
Les modérateurs de commentaires du Framablog ?
De l'associatif hors libristes ?
Des équipes avec des problématiques un peu différentes, genre sites de vulgarisation scientifique qui doivent en plus gérer ésotérisme, fausse science, escroquerie, etc. ?
(a priori on peut exclure les problématiques des plateformes en oligopole type gros réseaux sociaux, les problèmes type robot copyright, les contenus trash que subissent les équipes des très gros réseaux, etc. ça ne relève pas vraiment de notre quotidien)
[^] # Re: J'ai faim...
Posté par Benoît Sibaud (site web personnel) . En réponse au journal de l'art et la manière de faire du gratin dauphinois. Évalué à 3.
Même en France, il n'y a pas du fromage produit dans tout le pays, dès qu'on quitte la métropole.
[^] # Re: Tea/vivlio/pocketbook HD plus
Posté par Benoît Sibaud (site web personnel) . En réponse au message Impossible de lire les journaux linuxfr avec ma liseuse kobo.. Évalué à 4.
Corrigé https://github.com/linuxfrorg/epub-LinuxFr.org/commit/3394b926b35e30bfbc1a4996f30613cd715d4b9f
[^] # Re: autres tests
Posté par Benoît Sibaud (site web personnel) . En réponse à l’entrée du suivi Téléchargement contenu au format EPub - Pb avec la gestion des images. Évalué à 4 (+0/-0). Dernière modification le 25 janvier 2021 à 13:28.
Je vais clore cette entrée qui est corrigée. https://github.com/linuxfrorg/epub-LinuxFr.org/commit/3394b926b35e30bfbc1a4996f30613cd715d4b9f
Le problème résiduel est dans https://linuxfr.org/suivi/validation-des-epub
[^] # Re: Tea/vivlio/pocketbook HD plus
Posté par Benoît Sibaud (site web personnel) . En réponse au message Impossible de lire les journaux linuxfr avec ma liseuse kobo.. Évalué à 3.
Le daemon img fait une copie locale, mais sans la modifier en dimension / poids.
# Taille max
Posté par Benoît Sibaud (site web personnel) . En réponse à l’entrée du suivi taille des images dans les fichiers epub. Évalué à 3 (+0/-0).
Il y a actuellement une taille max en poids total (pour le site web et les epub).
https://github.com/linuxfrorg/img-LinuxFr.org/blob/master/img.go#L36
ça n'empêche pas que l'on puisse faire une image jpg de 10000x10000 entièrement noire et qui fasse moins de 1,2 Mo sur disque (mais va consommer beaucoup de mémoire à l'ouverture). Je prends un exemple extrême évidemment, pour dire que 5 MB de jpg, ça peut faire une grande image.
[^] # Re: autres tests
Posté par Benoît Sibaud (site web personnel) . En réponse à l’entrée du suivi Téléchargement contenu au format EPub - Pb avec la gestion des images. Évalué à 3 (+0/-0).
Normalement j'ai corrigé le souci des noms d'images en collision en prod.
Par contre :
- il y a d'autres problèmes ailleurs, visiblement sur https://linuxfr.org/users/tonio/journaux/s-occuper-pendant-les-vacances-yunohost-et-autohebergement signalé par Ysabeau, qui ne passe pas le validateur (j'ai fait le test en distant via http://validator.idpf.org/ puis en local) :
Faisons le test avec un epub de référence (Children's Literature pris sur https://idpf.github.io/epub3-samples/30/samples.html ) :
1) le fichier initial est validé par epubcheck
2) on dézippe
3) on zippe bêtement
2) on zippe mieux…
J'ai l'impression que la validateur ne veut pas les répertoires (zip -D), ni les attributs amenés par Unix, mais je n'ai pas noté ça dans la spécification (et personne ne s'était plaint de cela avant… possible que les liseuses soient juste tolérantes).
[^] # Un peu de retenue dans les échanges
Posté par Benoît Sibaud (site web personnel) . En réponse au journal toujours pas convaincus par l'Hydroxychloroquine ?. Évalué à 4.
Merci de rester courtois dans les échanges.
[^] # Re: Un avis eclairé et correctement sourcé
Posté par Benoît Sibaud (site web personnel) . En réponse au journal Rappelons la base du libre : pour tous les usages. Évalué à 3.
A priori, c'est une problématique partagée par divers acteurs du domaine : MongoDB (->SSPL), Elastic (->SSPL), Graylog (->SSPL), Redis (pour les modules ->Common Clause, 1 , 2, puis RSAL), tous accusant les GAFAM / gros fournisseurs de cloud.
[^] # Re: Tea/vivlio/pocketbook HD plus
Posté par Benoît Sibaud (site web personnel) . En réponse au message Impossible de lire les journaux linuxfr avec ma liseuse kobo.. Évalué à 4.
Il y a une taille max en poids total.
https://github.com/linuxfrorg/img-LinuxFr.org/blob/master/img.go#L36
ça n'empêche pas que l'on puisse faire une image de 10000x10000 entièrement noire et qui fasse moins de 1,2 Mo sur disque (mais va consommer beaucoup de mémoire à l'ouverture). Je prends un exemple extrême évidemment, pour dire que 5 MB de jpg, ça peut faire une grande image.
[^] # Re: Analyse
Posté par Benoît Sibaud (site web personnel) . En réponse à l’entrée du suivi Téléchargement contenu au format EPub - Pb avec la gestion des images. Évalué à 3 (+0/-0).
Cf https://github.com/linuxfrorg/epub-LinuxFr.org/pull/1
[^] # Re: Analyse
Posté par Benoît Sibaud (site web personnel) . En réponse à l’entrée du suivi Téléchargement contenu au format EPub - Pb avec la gestion des images. Évalué à 3 (+0/-0).
URL brutes
Après img :
Avec img, epub non corrigé:
Sans img, epub non corrigé :
Correctif proposé : un hachage sha224 (sha256 -> 64 octets et sha224 -> 56 octets, on avait choisi moins de 60, je vais m'y tenir) pour éviter les collisions de début de path en sortie d'img, mais en calculant plus largement que juste le path, autant prendre l'URI en entier, le tout en restant en 60 octets ou moins (ici 56) + l'extension.
# Analyse
Posté par Benoît Sibaud (site web personnel) . En réponse à l’entrée du suivi Téléchargement contenu au format EPub - Pb avec la gestion des images. Évalué à 4 (+0/-0). Dernière modification le 24 janvier 2021 à 12:23.
Analyse de https://linuxfr.org/news/taptempo-pour-arduino-uno avec ces 3 jpg et son png
Les 3 jpg :
Les 3 jpg dans img :
(où
68747470733a2f2f78756c6f70732e6e65742f696d6167652f61757472652fest la version en hexadécimal dehttps://xulops.net/image/autre/)Les 3 jpg dans epub (les 60 premiers octets du path de img sans les '/', soit les 30 premiers octets du path de l'image d'origine converti en hexa, d'où une collision fréquente sur un même domaine dès qu'on dépasse 30 octets):
[^] # Re: Tea/vivlio/pocketbook HD plus
Posté par Benoît Sibaud (site web personnel) . En réponse au message Impossible de lire les journaux linuxfr avec ma liseuse kobo.. Évalué à 4.
Problème déjà connu d'ailleurs https://linuxfr.org/suivi/telechargement-contenu-au-format-epub-pb-avec-la-gestion-des-images
[^] # Re: Tea/vivlio/pocketbook HD plus
Posté par Benoît Sibaud (site web personnel) . En réponse au message Impossible de lire les journaux linuxfr avec ma liseuse kobo.. Évalué à 4. Dernière modification le 24 janvier 2021 à 11:36.
Dans le zip :
ça semble douteux d'avoir trois fichiers différents portant le même nom.
[^] # Re: Séparer l'aspect légal de l'aspect stratégique ?
Posté par Benoît Sibaud (site web personnel) . En réponse au journal Rappelons la base du libre : pour tous les usages. Évalué à 8. Dernière modification le 24 janvier 2021 à 10:37.
https://www.elastic.co/fr/pricing/faq/licensing#does-this-mean-that-elasticsearch-and-kibana-are-no-longer-open-source
Position très claire de l'OSI : The SSPL is Not an Open Source License
Position de Graylog : Graylog v4.0 Licensing SSPL
On sait aussi que Debian, Red Hat Enterprise Linux et Fedora Linux ont retiré MongoDB de leur distribution. Il est probable qu'Elasticsearch, Kibana et Graylog (qui a fait le même choix en novembre 2020) vont subir le même sort (en supposant qu'ils soient précédemment inclus dedans).
Je ne connais pas de prise de position FSF sur la SSPL.
[^] # Re: Séparer l'aspect légal de l'aspect stratégique ?
Posté par Benoît Sibaud (site web personnel) . En réponse au journal Rappelons la base du libre : pour tous les usages. Évalué à 7.
Ce qui menace bien l’avenir du logiciel tel que prévu par la FSF (dont le but est de libérer l’utilisateur). Par contre ça ne menace pas l’avenir du logiciel tel que prévu par le vendeur d’enregistreur numérique qui pratique la tivoïsation (dont le but est juste de vendre son enregistreur). À chaque fois, on a les intérêts de la communauté/entreprise qui produit le logiciel, ceux des utilisateurs, et les intérêts de ceux qui pourraient utiliser le logiciel pour le revendre à d’autres, et encore ceux d’autres acteurs encore (ce logiciel libre avec chiffrement bout-en-bout va-t-il gêner les publicitaires ? les services de renseignement ? les enquêtes de police ? le contrôle parental ? ce logiciel est-il important pour les vendeurs de matériel informatique ? ce logiciel consomme-t-il de l’attention ? beaucoup d’énergie ? etc., etc.).
Personne ne peut raisonner comme ayant un seul rôle, chaque acteur a toujours une multiplicité de rôles (utilisateur et/ou développeur d’un logiciel, parent ou non, citoyen, actionnaire d’une entreprise, fan de superproduction hollywoodienne, BSDiste ou GPLien, consommateur compulsif d’électronique, minimaliste fan de Gemini, etc., etc.). Et l’impact d’un changement de licence est toujours à évaluer pour chacun des acteurs et pour chacun des rôles, en termes de bénéfices/coûts et avantages/inconvénients.
Par exemple : la FSF peut dire la GPLv3 c'est mieux pour nous FSF (cf objectif social), c'est mieux selon nous pour les utilisateurs (même s'ils s'en fichent, on considère que c'est mieux pour eux), c'est mieux pour les citoyens (on considère que c'est d'intérêt général), c'est moins bien pour le modèle économique des vendeurs d'enregistreurs numériques (et on considère que ce n'est pas grave, ni pour l'emploi, ni pour les impôts, ni pour la compétitivité nationale dans le domaine, etc.), c'est moins bien pour les MAFIAA qui seraient ravis d'avoir des enregistreurs bien verrouillés à DRM incontournables (et on considère que ce n'est pas grave), etc., etc. -> conclusion on fait une nouvelle licence libre. C'est moins binaire/manichéen/simpliste qu'une partie de la discussion autour du journal pourrait le laisser supposer.
[^] # Re: Séparer l'aspect légal de l'aspect stratégique ?
Posté par Benoît Sibaud (site web personnel) . En réponse au journal Rappelons la base du libre : pour tous les usages. Évalué à 4.
Oui, Red Hat a choisi une autre voie que le changement de licence.
[^] # Re: Business model : une question de dosage et de diversification ?
Posté par Benoît Sibaud (site web personnel) . En réponse au lien AWS fork Elastic Search qui n'est plus sous licence Apache. Évalué à 6.
MongoDB Inc. et Elastic se plaignent des fournisseurs de MongoDB / Elasticsearch / Kibana à la demande (en particulier les gros fournisseurs de cloud), car ça leur prendrait une part trop importante des flux financiers autour du logiciel.
D’autres éditeurs se plaignent des intégrateurs (ESN/SSII) qui captent une partie des revenus d’installation / intégration / déploiement / support / service autour de produits phare.
Dès qu’un produit est suffisamment visible et aisément déployable, alors une autre société a un intérêt financier à court terme à le proposer : elle n’a pas à payer les coûts de développement, R&D, etc. et le logiciel existe déjà, elle apprend à l’installer et ensuite chaque nouvelle installation est un gain net. Tandis que l’éditeur doit continuer à financer le développement. C’est évidemment un choix à court terme : si l’éditeur est étranglé financièrement, le produit n’évolue plus et à terme, tragédie des communs, mort du produit, fin des revenus… Si l’évaluation est purement financière, pourquoi le nouvel acteur contribuerait, améliorerait la documentation, les traductions, ferait des retours et des apports divers, etc. ? Le copyleft est parfois utilisé pour cela, mais ça ne marche pas forcément dans tous les cas : Amazon peut très bien déployer exactement le logiciel sans aucune modification, c’est juste le volume des déploiements (et la facilité de le faire) qui l’intéresse et qui lui donne un avantage commercial. Le copyleft n’aide pas forcément pour cela. (précision: aux deux extrémités, le nouvel acteur peut tout à fait devenir un acteur contributeur du logiciel faisant grossir le chiffre d’affaires de tout le monde, ou bien être un simple parasite économique opportuniste à souhait et profiteur, pour grossir le trait).
Autre effet pervers : l’éditeur a donc intérêt à ne pas avoir un logiciel facilement installable, à avoir une documentation lacunaire, une configuration trompeuse et des logs énigmatiques pour avoir des questions via son support et vendre ses services ? Avec un peu de chance son logiciel est tellement imparfait qu’il passera sous les radars des méchants concurrents potentiels, avec un risque certain de ne pas être beaucoup utilisé en général non plus.
Le périmètre fonctionnel du logiciel joue beaucoup : si c’est le seul logiciel libre du domaine concerné, alors il y a peu de risque au début, au moins le temps qu’il ait suffisamment de fonctionnalités, il peut y avoir besoin d’experts du domaine pour le coder. Puis les ajouts supplémentaires deviennent en gros de la maintenance et de l’industrialisation : c’est un peu mieux en performance mais ça marchait déjà suffisamment bien, c’est des fonctionnalités utilisées par 10% de gens, c’est des fonctions avancées orientées grosses entreprises, etc. Alors d’un côté j’ai potentiellement moins de revenus (moins de commandes d’évolution, moins de support) et de l’autre plus de concurrence (oh un logiciel suffisamment revendable).
# Séparer l'aspect légal de l'aspect stratégique ?
Posté par Benoît Sibaud (site web personnel) . En réponse au journal Rappelons la base du libre : pour tous les usages. Évalué à 10.
Une licence libre offre les quatre libertés et c’est valable pour tous les usages (légaux). Sans contester cet aspect, on peut néanmoins ne pas être en accord avec l’usage : si tu utilises des outils libres pour expliquer qu’il faut flamber à tout-va, consommer un max, se gaver de tout ce qui est possible et rien à carrer de l’avenir, de considérations écologiques, etc., c’est conforme à la licence, c’est légal / ça n’est a priori pas répréhensible (ça ne sera pas considéré comme un délit écologique à première vue), je peux néanmoins ne pas être d’accord avec cela.
Alors je peux choisir la voie de la licence : je change la licence pour éviter / limiter ce type d’usage (c’est me semble-t-il le cas qui est critiqué ici), mais si j’opte pour une licence non-libre, c’est qu’effectivement les 4 libertés n’étaient pas si importantes pour moi. Ou alors je choisis une autre voie : changer la législation pour faire créer un délit dans ce cas ? militer politiquement pour une prise de conscience ? communiquer sur le sujet pour espérer faire réagir ? etc.
L’usage qui est en fait menace l’avenir de mon logiciel selon moi ? Exemples : Tivoïsation et GPLv3 ? Valeur ajoutée accaparée par les fournisseurs de cloud (selon Elastic ou MongoDB Inc. par exemple) ? Service en ligne et AGPL ? BSD et clause de publicité ?
La question n’est pas nouvelle et visiblement, suivant les cas, on a apparition d’une nouvelle licence libre, changement pour une licence non-libre, et parfois d’autres approches non liées à la licence elle-même.
Ça rejoint surtout la question : quelle est ma grille de lecture ? Quels sont mes critères de choix ? Le libre, le coût, la communauté, le maintien d’une diversité pour préserver l’avenir, les aspects techniques, etc., etc. Ce qui me semble critiqué ici est le fait de prétendre que le libre serait mon critère de choix sine qua none mais que parfois « je suis prêt à faire du non-libre pour prétendre sauver le libre » ce qui serait incohérent.
RedHat change d’avis sur CentOS -> je continue à utiliser CentOS ? je change pour RockyLinux ? je boycotte RedHat ? je m’en fiche ? ai-je une responsabilité là-dedans (j’utilise sans jamais contribuer ou financer par exemple) ? est-ce une menace sur l'avenir de CentOS à court terme ? Etc.
Elastic change la licence d’Elasticsearch/Kibana -> comment je gère ce changement ? pourquoi ce changement a eu lieu et ai-je une responsabilité là-dedans ((j’utilise sans jamais contribuer ou financer par exemple)
Des personnes d’extrême-{droite, gauche} / complotistes / {pacifistes, militaristes } / { pro,anti }{.*} contribuent à ma communauté et à mon logiciel ? Est-ce que je peux le supporter (humainement) et aussi éviter l’explosion de ma communauté / de l’équipe de développement ? Est-ce que je dois ajouter des règles supplémentaires et des barrières d’entrée ? Est-ce que je veux changer ma licence et pourquoi, et pour quoi ? Est-ce que cela amène un risque juridique pour ma communauté / mon projet (des gens qui jouent trop près des limites légales, par exemple, les transgressant de temps en temps) ?
[^] # Re: Un absent...
Posté par Benoît Sibaud (site web personnel) . En réponse à la dépêche Revue de presse — janvier 2021. Évalué à 5.
Planète Linux existe toujours.
numéro 118 de décembre 2020/janvier 2021
par contre http://www.dppresse.com/categories/plan%C3%A8te-linux/ -> 404 (depuis http://www.dppresse.com/ )
[^] # Re: Commentaires problématiques
Posté par Benoît Sibaud (site web personnel) . En réponse au journal LinuxFr.org : première quinzaine de janvier 2021. Évalué à 3.
On a choisi Sympa, et si tu lui réponds, il laisse passer ton message. Des fois, en étant abonné, il le laisse même directement passer.
[^] # Re: micro
Posté par Benoît Sibaud (site web personnel) . En réponse au journal [bookmark] GNU nano 5.5 est sorti malgré le couvre-feu. Évalué à 3.
Quoi, mais j'ai lu 1978 le 21/01 dans ton message précédent ? Je n'ai pas reçu le mémo par fax.
[^] # Re: Commentaires problématiques
Posté par Benoît Sibaud (site web personnel) . En réponse au journal LinuxFr.org : première quinzaine de janvier 2021. Évalué à 4.
(des réflexions en vrac)
Quelles équipes de modération seraient pertinentes/utiles ? Des bénévoles ou des professionnels ? Règles de modération ? Code de conduite / charte pour les utilisateurs et/ou l'équipe de modération ? En langue française ou non ? En droit français ou non ?
A priori il faut des contenus produits par des utilisateurs ET des contenus qui ne sont pas tous modérés a priori.
L'équipe de modération de l'AdL voit des contenus produits par des utilisateurs, modérés a priori (mais rééditables ensuite par les utilisateurs). Par contre j'imagine qu'ils ont moins de dérives que nous car les thématiques sont plus cadrées (à moins de voir passer des événéments "Conférence GPL et effet du l'HCQ", "Avortement et copyleft" ou "Les religions traditionnelles vs l'église d'Emacs", etc.).
Les modérateurs de commentaires du Framablog ?
De l'associatif hors libristes ?
Des équipes avec des problématiques un peu différentes, genre sites de vulgarisation scientifique qui doivent en plus gérer ésotérisme, fausse science, escroquerie, etc. ?
(a priori on peut exclure les problématiques des plateformes en oligopole type gros réseaux sociaux, les problèmes type robot copyright, les contenus trash que subissent les équipes des très gros réseaux, etc. ça ne relève pas vraiment de notre quotidien)
[^] # Re: Mauvais nom
Posté par Benoît Sibaud (site web personnel) . En réponse à la dépêche Changeons ces logiciels open source qui nous espionnent. Évalué à 4.
Damn'… 3 Visual Source Code et 1 Visual Code Source, il y avait un piège… Corrigé, merci.
[^] # Re: "Health Data Hub"
Posté par Benoît Sibaud (site web personnel) . En réponse à la dépêche Logiciel libre : le Premier ministre se montrera-t-il à la hauteur du rapport Bothorel ?. Évalué à 3. Dernière modification le 19 janvier 2021 à 22:13.
La plateforme française de données de la santé, évoquée plusieurs fois ici même. Information ajoutée. wikidata à défaut de page wikipédia.