Ne connaissant rien à Java et aux composants évoqués, ce que tu écris reste assez opaque pour moi. Il me faudrait un petit diagramme d'architecture.
Pour commencer, à ma connaissance, Maven est un outil de gestion des dépendances et d'automatisation du build, et d'aucune manière un composant lié à l'exécutable généré. Sa licence importe donc peu ici.
Ensuite, il me semble que JDBC est une simple abstraction, une interface définissant une API utilisée par les applications Java pour se connecter à des bases de données. Cette API est incluse dans la plateforme standard (sauf erreur de ma part, on la trouve donc aussi bien dans OracleJDK que dans OpenJDK). Mais cette interface ne permet rien en elle-même. Il faut ajouter un connecteur (« driver »), spécifique à chaque SGBDR. C'est donc la licence de ce connecteur qui importe. Quel SGBDR, et donc quel connecteur, utilises-tu ?
il faut étudier dépendance par dépendance, donc on peut mettre certains service en GPLv3, et laisser le reste en Apache v2.
Oui ou non. Cela dépend de la licence des différents composants, de leur assemblage et de leur mode d'interaction.
Je peux mettre en (L?)GPL v3 les service qui devraient être immuables chez les utilisateurs. Laisser le reste en Apache v2 pour ne rien imposer d'ennuyeux.
Je ne sais pas ce qu'est un service immuable.
Par contre, ce que je peux te dire, c'est que si la compilation de ton code aboutit à la génération de composants diffusés sous des licences différentes, tu as intérêt, pour le bien de tout le monde à commencer par le tien, à scinder le code desdits composants dans plusieurs dépôts et à les gérer séparément. Ton projet sera bien plus lisible sur le plan juridique.
J'oubliais, il est recommandé d'exclure du SBOM les composants qui ne sont utilisés qu'en phase de développement (JUnit par exemple) et ne sont pas liés aux versions de ton outil distribuées sous forme binaire.
Cf. un exemple de SBOM au format CycloneDX pour un composant Java :
Savoir si tu es à ton propre compte ou non ne suffit pas à déterminer si tu es en droit de décider de la licence de ton cadriciel, ni même de sa publication. Par exemple, si tu as développé ce cadriciel dans le cadre d'un contrat de prestation qui prévoit la cession des droits patrimoniaux à ton client (cas de figure assez fréquent), la décision appartient entièrement à ton client, et il n'a aucunement à te consulter ou à obtenir ton approbation pour cela.
Si ce n'est pas le cas (i.e. si tu as développé ce cadriciel de ta propre initiative, en le finançant sur fonds propres, ou si le contrat de prestation ne prévoit pas la cession des droits patrimoniaux), tu es en droit de décider de publier ton cadriciel sous licence libre.
La licence choisie doit être compatible avec celles des composants intégrés. Il faut donc commencer par établir leur liste. Selon les langages considérés et les outils disponibles, cette liste en profondeur – que l'on appelle un « Software Bill of Materials » (SBOM) ou « Software Supply Chain » – peut être établie de manière automatique ou non. De nos jours, il est de bon ton de publier ce SBOM au format CycloneDX. Publier le SBOM va même devenir une obligation en Europe avec la publication récente du « Cyber Resilience Act » (CRA).
Je ne l'ai jamais utilisé, mais je sais qu'un greffon Maven permet effectivement d'établir la liste exhaustive et en profondeur des composants intégrés. En effectuant une recherche rapide, je suis tombé sur l'article How to create SBOMs in Java with Maven and Gradle.
Si aucun des composants intégrés n'a de licence plus exigeante que la licence permissive Apache v2.0, tu peux décider de diffuser ton cadriciel sous cette licence ou sous une licence diffusive (faiblement, comme la licence GNU LGPL ou fortement, comme la licence GNU GPL). S'agissant d'un cadriciel, je déconseille le recours à une licence fortement diffusive qui dissuaderait beaucoup de personnes de l'utiliser (cette licence se diffusant alors à leur propre application), mais ce choix peut être une stratégie assumée.
La licence Apache v2.0 exige qu'une copie de la licence soit fournie à la racine du projet, dans un fichier nommé LICENSE(.txt), ainsi qu'un fichier NOTICE(.txt) contenant la liste des composants intégrés (liste de premier niveau, ceux que tu utilises explicitement et non ceux qui se trouvent intégrés en cascade, du fait des dépendances de dépendances).
Il est ensuite de bon ton de placer à la racine du projet un fichier README(.txt|.md|.rst) dans lequel tu auras inséré une mention de copyright et de licence (en renvoyant vers le fichier LICENSE(.txt).
Pour terminer, il est recommandé de placer une entête de copyright au début de chaque fichier dont le format le permet. Pour la licence Apache, cet entête peut être :
/* * Copyright (C) 2022-2024 John Doe * * This file is part of Taack-UI * * https://taack-ui.org/ * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */
À ce stade, tu commences à avoir fait les choses plutôt bien. Reste éventuellement à choisir une licence différente et plus adaptée pour la documentation, les exemples et les ressources tierces. Pour plus d'informations à ce sujet, cf. mon article Projet libre : à chaque ressource sa licence.
Étant (simple) adhérent à Artilect, je pense utile de fournir quelques informations supplémentaires :
Artilect est un fablab situé au cœur de Toulouse, et même, d'un point de vue historique, le premier fablab de France.
Le lien fourni dans le journal est issu d'une campagne de mailing. Les formations professionnelles dispensées par Artilect sont listées à l'adresse suivante, plus pérenne : https://artilect.fr/formation-professionnelle/.
Artilect n'est donc pas un simple organisme de formation ; c'est un tiers-lieu où l'on rencontre des personnes aux profils très variés, qui n'hésitent pas à partager leur savoir-faire et leur expérience. J'adore y passer le samedi après-midi, même lorsque je n'ai pas d'atelier à animer ou que je n'ai pas prévu d'utiliser les moyens de fabrication d'Artilect.
Vous l'aurez deviné, si vous êtes dans la région, je vous invite vivement à venir découvrir Artilect.
En tant qu'initiateur et animateur de l'OSPO de CS GROUP, j'adresse mes plus chaleureux remerciements aux membres du jury. Ce prix récompense 10 ans de travail, et même 15 ans si l'on considère la date de publication d'Orekit, premier logiciel libre publié par l'entreprise.
La bibliothèque Orekit est devenue une référence dans son domaine (la mécanique spatiale) et un véritable projet communautaire, utilisé aussi bien à des fins opérationnelles, que de recherche ou d'enseignement. Nous en sommes fiers. Nous avons investi 44 années.hommes à ce jour dans Orekit et ce projet reste notre plus belle réussite.
Nous avons cependant publié d'autres logiciels (certains sont tombés dans l'oubli, d'autres rencontrent un succès d'estime, tel EODAG) et versé de nombreuses contributions à des projets libres tiers (certaines étant récurrentes et s'inscrivant dans une logique l'implication durable, comme c'est le cas pour le noyau Linux).
À titre personnel, je suis heureux de travailler pour une entreprise qui ne se contente pas de puiser dans l'inestimable ressource qu'est le logiciel libre, mais y apporte de substantielles contributions.
Pour aller plus loin que l'arrosage, il y a déjà FarmBot, projet libre tant sur le plan logiciel que matériel. Certes, je le reconnais, ce projet a de très nombreuses limites dès qu'on envisage une culture à grande échelle ou de faire pousser autre chose que des carottes ou des salades. Les pieds de tomates et de haricots doivent être un vrai casse-tête pour lui, tout comme les plantes coureuses telles que les courges.
Mais l'idée qu'un robot s'occupe (presque) de tout est séduisante quand on ne s'épanouit pas dans le jardinage, tout en appréciant les légumes issus du jardin et fraichement cueillis. :)
Je fais moi aussi partie des gens qui impriment leur billet pour parer tout problème en cas de décharge impromptue de mon smartphone. Mais l'idée d'imprimer des encarts de publicité m'irrite au plus haut point. Je n'ai jamais cherché à extraire le QR-Code, mais j'ai trouvé une parade facile à mettre en œuvre pour tous les billets, qu'ils soient émis par la SNCF ou toute autre entité : j'édite le billet dans LibreOffice (qui sait lire les PDF), je sélectionne et je supprime toutes les images et autres éléments d'information sans intérêt. Puis j'imprime ce billet expurgé de tout superflu. Je conserve ainsi le QR-Code et toutes les informations importantes.
La version est française est également très bien pour les francophones pas encore polyglottes.
Je n'en doute pas, mais à ma connaissance, le livre n'a pas encore été édité en français, contrairement à la version anglaise qui trône désormais dans le coin de ma bibliothèque où je regroupe tous les ouvrages libres (bandes dessinées, romans, essais et manuels) que j'ai achetés ici et là.
En outre, si Benoit indique que le texte a été traduit, je n'ai pas trouvé en ligne de version PDF incluant les images et le texte.
J’ai découvert le livre lors d’un séminaire interne des référents Open Source/logiciel libre
Je fais partie des heureux gagnants d'un exemplaire en anglais. Je n'avais jamais eu vent moi non plus de ce livre auparavant.
Même s'il s'agit avant tout d'un conte moderne à l'attention des enfants, je l'ai beaucoup apprécié. L'histoire est sympa, le vilain n'est pas très méchant au fond, il semble même « très cool » au début puisqu'il fait le bonheur des gens en leur fournissant moult machines plus géniales les unes que les autres. Mais cela lui donne les moyens de régenter leur vie et, au détour d'une contrariété, il cède à cette facilité. S'en suit la découverte des problèmes induits par le contrôle centralisé de la technologie, de l'importance de la loi qui peut interdire ou autoriser, de la connaissance émancipatrice et, bien sûr, du rôle central que joue le logiciel dans notre société.
Ces sujets a priori un peu ésotériques pour les enfants sont présentés dans ce livre d'une manière imagée et accessible. Je vous recommande chaudement ce conte si un livre en anglais ou en allemand ne rebute pas vous ou vos enfants.
J'ai réalisé mon boitier à Artilect, grâce aux machines mises à disposition par ce fablab et avec les précieux conseils des bénévoles et permanents. Même à supposer que nous ayons les moyens d'acquérir une machine à découpe laser, réaliser nos projets dans un tiers lieu permet de mutualiser les moyens et donc, de maximiser leur utilisation. En outre, cet environnement s'avère stimulant. Chez vous, vous n'aurez jamais l'opportunité d'échanger et de profiter de l'intelligence collective qui imprègne un tel lieu.
Artilect traverse une mauvaise passe financière et a besoin de notre soutien. Voici la campagne que vient de lancer l'équipe sur helloasso :
Mais maintenant, j'ai pu acquérir sur LE site de vente en ligne un NAS WD de 8To (4To utile) pour 378 euros.
Je n'ai qu'une objection à cette approche : le système d'exploitation n'est pas libre. ;)
D'ailleurs, au boulot, j'ai introduit les NAS Synology il y a une douzaine d'années et la qualité de ces produits (WebOS ergonomique et socle logiciel maintenu pendant au moins 7 ans) a fait que les NAS Synology ont progressivement évincé tous les autres. Mais à titre personnel, je voulais un NAS doté d'un OS libre. J'ai opté pour TrueNAS Core pour monter en compétence, mais vu mes besoins immédiats, j'aurais pu me contenter d'une distribution OpenMediaVault, voire Debian.
Dans le cas présent, pour le même prix qu'un NAS Synology DS220+ doté des mêmes disques de stockage des données, j'ai un NAS doté d'un Celeron de 11ème génération à 4 cœurs (au lieu d'un Celeron à 2 cœurs), de 16 Go de RAM extensibles (au lieu de 2 Go non extensibles), d'un disque système NVMe de 500 Go (128, voire 64 Go auraient été largement suffisants, mais le modèle 500 Go de la même gamme était meilleur marché) et de deux interfaces réseau à 2,5 Gbit/s (au lieu d'une à 1 Gbit/s).
Le plug & play n'est pas utile dans mon cas. En cas de défaillance d'un disque, je peux largement prendre le temps d'arrêter mon NAS, de le démonter et de changer le disque.
J'ai posé à question aux membres du fablab Artilect, ils m'ont dit que le polycarbonate jaunissait lorsqu'on le découpait au laser (information que j'ai aussi trouvée sur le net, où il est indiqué que le problème empire avec l'épaisseur de la plaque).
Error-correcting code or ECC RAM detects and corrects in-memory bit errors as they occur. If errors are severe enough to be uncorrectable, ECC memory causes the system to hang (become unresponsive) rather than continue with errored bits. For ZFS and TrueNAS, this behavior virtually eliminates any chances that RAM errors pass to the drives to cause corruption of the ZFS pools or file errors.
To summarize the lengthy, Internet-wide debate on whether to use error-correcting code (ECC) system memory with OpenZFS and TrueNAS:
Most users strongly recommend ECC RAM as another data integrity defense.
However:
* Some CPUs or motherboards support ECC RAM but not all
* Many TrueNAS systems operate every day without ECC RAM
* RAM of any type or grade can fail and cause data loss
* RAM failures usually occur in the first three months, so test all RAM before deployment.
La recommandation n'a rien de spécifique à ZFS, il n'est pas indiqué « si vous n'utilisez pas de RAM ECC, n'utilisez pas ZFS ». Il est simplement dit que la RAM ECC évite la propagation d'une erreur en RAM au système de stockage, puisqu'elle engendre le gel instantané du système. Cela est vrai quel que soit le système de stockage considéré.
Les cartes supportant la mémoire ECC sont bien plus couteuses, tout comme la RAM ECC elle-même. La configuration requise aurait donc eu un tout autre cout (sans même parler de l'encombrement). In fine, le jeu n'en vaut pas la chandelle vu que ce NAS ne va être que l'un des supports de mes données et sauvegardes.
Une machine de découpe laser permet de découper, mais aussi de graver, tout dépend de la puissance du laser et de la focalisation du faisceau. Les traits qui apparaissent en rouge sur le plan et ont une épaisseur de 0,001 mm désignent des traits de découpe, ceux qui apparaissent en noir et sont plus épais désignent des zones à graver.
La pièce est découpée en 23 minutes sur la machine que j'ai utilisée, mais ce temps dépend de la puissance du laser (j'ai utilisé une machine 35 Watts, mais Artilect en dispose d'une à 120 Watts, qui était en maintenance ces dernières semaines). En outre, la gravure du QR-Code prend plusieurs minutes à elle seule (ce QR-Code fournit l'url du projet sur ma forge, ce faisant, une personne tombant sur un exemplaire du NAS peut découvrir les sources du projet).
Le temps de travail est assez difficile à estimer. J'ai passé 6 après-midi à Artilect, mais c'est un lieu d'échange où l'on bénéficie des conseils de membres plus expérimentés et où on a par contre vite fait de se disperser. À part cela, j'ai passé une poignée de soirées à modéliser, à faire des recherches pour étudier les différentes solutions d'assemblage qui s'offraient à moi et à rechercher les pièces qu'il me fallait. Au total, quelques dizaines d'heures d'essai et, surtout, 3 prototypes qui m'ont permis de valider ou d'invalider des pistes, et de découvrir lors du montage, que j'avais raté un ou deux trucs. :)
Bien vu, je n'avais pas remarqué ce problème, car je ne suis pas l'auteur du fichier LICENSE.txt fourni dans l'archive. C'est Thingiverse qui le génère.
Je ne suis jamais dans l'approximation lorsque je parle de licence (c'est un peu mon job) et quand j'ai publié ce projet sur Thingiverse, j'ai explicitement choisi la licence CC-BY 4.0. C'est elle qui apparait d'ailleurs en bas de la colonne de gauche, sur la page du projet :
La chimie et moi, ça fait deux et je ne connais pas vraiment les avantages de l'un et de l'autre. Ceci étant, j'ai au moins deux arguments pour justifier ce choix :
- Sauf erreur de ma part, Artilect ne propose pas de polycarbonate dans son catalogue de matériaux (mais j'aurais pu aller en acheter ailleurs) ;
- Il semble que le polycarbonate n'est pas conseillé pour la découpe laser, notamment lorsque les plaques sont épaisses.
Bien sûr qu'il appartient aux communautés de choisir les outils qui leur conviennent le mieux. Dans les exemples cités, j'ai proposé l'outil, en développant mon argumentaire, et les contributeurs ont accepté cette migration. Ce que je souligne, c'est que même si certains étaient tièdes ou sans avis à l'époque, je suis sincèrement convaincu qu'ils ne reviendraient plus en arrière aujourd'hui quand je vois à quel point ils se sont appropriés le nouvel outil.
Pour ma part, les listes de diffusion ne me dérangent pas, mais je suis un vieux (une preuve parmi d'autres : le client mail que j'utilise à titre privé est Mutt !) et je sais qu'elles ne conviennent pas à tout le monde, notamment à cause du fait qu'une fois abonné, on reçoit tout le trafic dans sa boite mail et que même lorsqu'un mode « digest » est proposé, la réception quotidienne d'un mail dérange certaines personnes, qui se sentent débordées (véridique, on me l'a déjà exprimé ouvertement).
Si j'ai proposé à ces projets de migrer vers Discourse, c'est parce que je vois bien que les listes de diffusion auxquelles je suis abonné connaissent une fréquentation et un trafic décroissant au fil des ans, y compris au sein de projets qui restent très dynamiques, et que les forums modernes et les messageries instantanées prennent le dessus. Quoi qu'on pense de ces outils, en 2022, ils répondent mieux aux attentes de la plupart des gens. Il appartient dès lors aux projets de s'adapter en proposant à leur communauté les outils aux gout du jour. Offrir les moyens de communication et de travail collaboratif adéquats est un facteur de succès pour un projet libre.
J'ai proposé il y a quelques années aux communautés de deux projets libres – Orekit et Orfeo Toolbox – d'abandonner les listes de diffusion au profit de Discourse. Aujourd'hui, personne ne reviendrait en arrière, y compris parmi les membres qui étaient déjà très actifs sur les listes de diffusion, car il est difficile de se passer des fonctions proposées par Discourse une fois qu'on y a goûté.
Pour Orekit, un trimestre après la bascule, le nombre d'échanges avait été multiplié par 2,5, preuve que les listes de diffusion ne convenaient pas à tout le monde, même si cela n'avait jamais été exprimé.
Les gâches de mes fenêtres – faites dans un matériau qui me rappelle la bakélite – se cassent parfois. J'ai besoin de les remplacer, mais je ne trouve pas en magasin des gâches identiques à celles de mes fenêtres (de vieux modèles des années 70/80). J'ai donc fini par prendre les dimensions d'une gâche avec un pied à coulisses, par apprendre à utiliser OpenSCAD (deux heures pour en découvrir les bases, puis deux heures pour créer mon modèle) et par modéliser la pièce. Puis j'ai adhéré au fablab toulousain Artilect, suivi la formation à l'impression 3D et, depuis, j'imprime à chaque fois que j'en ai besoin un lot de gâches.
En bon geek, j'achèterais volontiers une imprimante 3D, mais elle prendrait une place déraisonnable dans mon appartement et l'usage que j'en fait est trop ponctuel pour justifier cet achat. La mutualisation proposée par les fablabs fait bien plus sens et m'apporte plus de satisfaction intellectuelle. En outre, dans les fablabs, on croise parfois des gens passionnants et on y découvre de temps à autres des projets géniaux.
Ils ont annoncé redistribuer le code en apache avec un délai. C'est ce qu'on retrouve avec l'open core de gitlab par exemple.
Je ne sais pas ce qu'il en est d'Elastic Search, mais Gitlab n'a pas de politique de publication à retard « programmée ».
Certaines fonctions sont ajoutées simultanément dans toutes les versions de Gitlab.
Certaines fonctions sont réservées depuis de longues années aux versions payantes de Gitlab et ne sont sans doute pas près d'être étendues à la version libre, car elles font partie de celles qui incitent les entreprises à payer (celles qui le peuvent vu le cout que représente une licence de Gitlab).
D'autres fonctions sont d'abord réservées aux versions payantes de Gitlab, puis un jour, Gitlab décide de les étendre à la version libre. Le second évènement arrive parfois quelques mois après le premier, parfois des années après.
Je suis admiratif de la maturité de Gitlab vis-à-vis du libre et de sa communauté. L'entreprise a opté pour un modèle open core assez classique, mais la plupart des éditeurs qui optent pour ce modèle n'ont pas l'intelligence d'enrichir continuellement (et avec des fonctions attrayantes) la version libre. Ils ne songent qu'à accroitre l'écart fonctionnel qui sépare la version libre de la version payante, en espérant que cela conduira les clients à payer. Or, en faisant cela, ils nourrissent l'amertume des utilisateurs de la version libre, qui finissent par se tourner vers une alternative dès qu'ils le peuvent. Ils frustrent en outre terriblement les quelques contributeurs qu'ils arrivent à ferrer et ceux-ci finissent eux aussi par tourner le dos au projet. Le modèle open core, souvent mal géré, asphyxie les communautés. L'éditeur ne réalise pas qu'il se condamne à endurer tous les inconvénients du libre, sans jamais bénéficier de ses avantages et de la dynamique qu'il peut susciter.
Gitlab a compris cela et entretient intelligemment sa communauté, il la nourrit de nouvelles fonctions chaque mois (une nouvelle version de Gitlab étant publiée le 22 de chaque mois), organisant même le buzz à l'approche de la libération des fonctions les plus excitantes. Il interagit avec elle, lui pointe des bugs faciles à corriger, des fonctions qu'il serait ravi d'intégrer, mais qu'il a décidé – en tout cas pour l'instant – de ne pas implanter lui-même (cf. label Accepting merge request). Bref, Gitlab sait qu'il a une communauté exigeante et il sait être à la hauteur. Sa communauté accepte du coup plutôt bien la logique open core qui la révulse chez d'autres.
Ceci étant, notons que cette intelligence est sans doute aiguillonnée par le fait que Gitlab doit évoluer dans un écosystème très concurrentiel, entre outils libres (Gitea), outils propriétaires gratuits (Github) ou payants (suite Atlassian), sans oublier d'autres outils open core (Tuleap).
Déjà fait : The SSPL is Not an Open Source License
Quant à la license ELv2 elle ne respecte par le point 3 de l'OSD
Je sais que ni la SSPL, ni l'ELv2 ne sont libres, de nombreux commentaires ont été fait un peu partout sur Internet à ce sujet. Mon message n'avait pas pour but d'évoquer un doute à ce sujet, mais juste de signaler que la justification donnée dans le message que j'ai commenté n'était pas valide.
Je suis un peu pointilleux sur le sujet, cela fait partie de mon job.
[^] # Re: Marche à suivre
Posté par Sébastien Dinot (site web personnel) . En réponse au journal Java et les licences Open Source. Évalué à 1 (+0/-0). Dernière modification le 13 avril 2024 à 18:06.
Ne connaissant rien à Java et aux composants évoqués, ce que tu écris reste assez opaque pour moi. Il me faudrait un petit diagramme d'architecture.
Pour commencer, à ma connaissance, Maven est un outil de gestion des dépendances et d'automatisation du build, et d'aucune manière un composant lié à l'exécutable généré. Sa licence importe donc peu ici.
Ensuite, il me semble que JDBC est une simple abstraction, une interface définissant une API utilisée par les applications Java pour se connecter à des bases de données. Cette API est incluse dans la plateforme standard (sauf erreur de ma part, on la trouve donc aussi bien dans OracleJDK que dans OpenJDK). Mais cette interface ne permet rien en elle-même. Il faut ajouter un connecteur (« driver »), spécifique à chaque SGBDR. C'est donc la licence de ce connecteur qui importe. Quel SGBDR, et donc quel connecteur, utilises-tu ?
Oui ou non. Cela dépend de la licence des différents composants, de leur assemblage et de leur mode d'interaction.
Je ne sais pas ce qu'est un service immuable.
Par contre, ce que je peux te dire, c'est que si la compilation de ton code aboutit à la génération de composants diffusés sous des licences différentes, tu as intérêt, pour le bien de tout le monde à commencer par le tien, à scinder le code desdits composants dans plusieurs dépôts et à les gérer séparément. Ton projet sera bien plus lisible sur le plan juridique.
[^] # Re: Marche à suivre
Posté par Sébastien Dinot (site web personnel) . En réponse au journal Java et les licences Open Source. Évalué à 3 (+2/-0).
J'oubliais, il est recommandé d'exclure du SBOM les composants qui ne sont utilisés qu'en phase de développement (JUnit par exemple) et ne sont pas liés aux versions de ton outil distribuées sous forme binaire.
Cf. un exemple de SBOM au format CycloneDX pour un composant Java :
https://github.com/CycloneDX/bom-examples/blob/master/SBOM/dropwizard-1.3.15/bom.xml
# Marche à suivre
Posté par Sébastien Dinot (site web personnel) . En réponse au journal Java et les licences Open Source. Évalué à 8 (+7/-0).
Bonjour,
Savoir si tu es à ton propre compte ou non ne suffit pas à déterminer si tu es en droit de décider de la licence de ton cadriciel, ni même de sa publication. Par exemple, si tu as développé ce cadriciel dans le cadre d'un contrat de prestation qui prévoit la cession des droits patrimoniaux à ton client (cas de figure assez fréquent), la décision appartient entièrement à ton client, et il n'a aucunement à te consulter ou à obtenir ton approbation pour cela.
Si ce n'est pas le cas (i.e. si tu as développé ce cadriciel de ta propre initiative, en le finançant sur fonds propres, ou si le contrat de prestation ne prévoit pas la cession des droits patrimoniaux), tu es en droit de décider de publier ton cadriciel sous licence libre.
La licence choisie doit être compatible avec celles des composants intégrés. Il faut donc commencer par établir leur liste. Selon les langages considérés et les outils disponibles, cette liste en profondeur – que l'on appelle un « Software Bill of Materials » (SBOM) ou « Software Supply Chain » – peut être établie de manière automatique ou non. De nos jours, il est de bon ton de publier ce SBOM au format CycloneDX. Publier le SBOM va même devenir une obligation en Europe avec la publication récente du « Cyber Resilience Act » (CRA).
Je ne l'ai jamais utilisé, mais je sais qu'un greffon Maven permet effectivement d'établir la liste exhaustive et en profondeur des composants intégrés. En effectuant une recherche rapide, je suis tombé sur l'article How to create SBOMs in Java with Maven and Gradle.
Si aucun des composants intégrés n'a de licence plus exigeante que la licence permissive Apache v2.0, tu peux décider de diffuser ton cadriciel sous cette licence ou sous une licence diffusive (faiblement, comme la licence GNU LGPL ou fortement, comme la licence GNU GPL). S'agissant d'un cadriciel, je déconseille le recours à une licence fortement diffusive qui dissuaderait beaucoup de personnes de l'utiliser (cette licence se diffusant alors à leur propre application), mais ce choix peut être une stratégie assumée.
La licence Apache v2.0 exige qu'une copie de la licence soit fournie à la racine du projet, dans un fichier nommé LICENSE(.txt), ainsi qu'un fichier NOTICE(.txt) contenant la liste des composants intégrés (liste de premier niveau, ceux que tu utilises explicitement et non ceux qui se trouvent intégrés en cascade, du fait des dépendances de dépendances).
Il est ensuite de bon ton de placer à la racine du projet un fichier README(.txt|.md|.rst) dans lequel tu auras inséré une mention de copyright et de licence (en renvoyant vers le fichier LICENSE(.txt).
Pour terminer, il est recommandé de placer une entête de copyright au début de chaque fichier dont le format le permet. Pour la licence Apache, cet entête peut être :
À ce stade, tu commences à avoir fait les choses plutôt bien. Reste éventuellement à choisir une licence différente et plus adaptée pour la documentation, les exemples et les ressources tierces. Pour plus d'informations à ce sujet, cf. mon article Projet libre : à chaque ressource sa licence.
# Quelques informations supplémentaires
Posté par Sébastien Dinot (site web personnel) . En réponse au lien Formation professionnelle Modélisation avec FreeCAD pour l'impression 3D (à Artilect, Toulouse). Évalué à 3.
Bonjour,
Étant (simple) adhérent à Artilect, je pense utile de fournir quelques informations supplémentaires :
# Un grand merci aux membres du jury !
Posté par Sébastien Dinot (site web personnel) . En réponse à la dépêche Les lauréats des Acteurs du Libre 2023 révéles à Open Source Experience #OSXP2023. Évalué à 3.
En tant qu'initiateur et animateur de l'OSPO de CS GROUP, j'adresse mes plus chaleureux remerciements aux membres du jury. Ce prix récompense 10 ans de travail, et même 15 ans si l'on considère la date de publication d'Orekit, premier logiciel libre publié par l'entreprise.
La bibliothèque Orekit est devenue une référence dans son domaine (la mécanique spatiale) et un véritable projet communautaire, utilisé aussi bien à des fins opérationnelles, que de recherche ou d'enseignement. Nous en sommes fiers. Nous avons investi 44 années.hommes à ce jour dans Orekit et ce projet reste notre plus belle réussite.
Nous avons cependant publié d'autres logiciels (certains sont tombés dans l'oubli, d'autres rencontrent un succès d'estime, tel EODAG) et versé de nombreuses contributions à des projets libres tiers (certaines étant récurrentes et s'inscrivant dans une logique l'implication durable, comme c'est le cas pour le noyau Linux).
À titre personnel, je suis heureux de travailler pour une entreprise qui ne se contente pas de puiser dans l'inestimable ressource qu'est le logiciel libre, mais y apporte de substantielles contributions.
# FarmBot ?
Posté par Sébastien Dinot (site web personnel) . En réponse à la dépêche Agrolink : L'open source au service de l'irrigation & cie pour le jardin et les cultures. Évalué à 4.
Bonjour,
Pour aller plus loin que l'arrosage, il y a déjà FarmBot, projet libre tant sur le plan logiciel que matériel. Certes, je le reconnais, ce projet a de très nombreuses limites dès qu'on envisage une culture à grande échelle ou de faire pousser autre chose que des carottes ou des salades. Les pieds de tomates et de haricots doivent être un vrai casse-tête pour lui, tout comme les plantes coureuses telles que les courges.
Mais l'idée qu'un robot s'occupe (presque) de tout est séduisante quand on ne s'épanouit pas dans le jardinage, tout en appréciant les légumes issus du jardin et fraichement cueillis. :)
# Autre contournement
Posté par Sébastien Dinot (site web personnel) . En réponse au journal Ah la SNCF!. Évalué à 10.
Bonjour,
Je fais moi aussi partie des gens qui impriment leur billet pour parer tout problème en cas de décharge impromptue de mon smartphone. Mais l'idée d'imprimer des encarts de publicité m'irrite au plus haut point. Je n'ai jamais cherché à extraire le QR-Code, mais j'ai trouvé une parade facile à mettre en œuvre pour tous les billets, qu'ils soient émis par la SNCF ou toute autre entité : j'édite le billet dans LibreOffice (qui sait lire les PDF), je sélectionne et je supprime toutes les images et autres éléments d'information sans intérêt. Puis j'imprime ce billet expurgé de tout superflu. Je conserve ainsi le QR-Code et toutes les informations importantes.
[^] # Re: J'ai adoré !
Posté par Sébastien Dinot (site web personnel) . En réponse à la dépêche Ada & Zangemann, un conte sur le logiciel, les skateboards et les crèmes glacées. Évalué à 1.
Je n'en doute pas, mais à ma connaissance, le livre n'a pas encore été édité en français, contrairement à la version anglaise qui trône désormais dans le coin de ma bibliothèque où je regroupe tous les ouvrages libres (bandes dessinées, romans, essais et manuels) que j'ai achetés ici et là.
En outre, si Benoit indique que le texte a été traduit, je n'ai pas trouvé en ligne de version PDF incluant les images et le texte.
# J'ai adoré !
Posté par Sébastien Dinot (site web personnel) . En réponse à la dépêche Ada & Zangemann, un conte sur le logiciel, les skateboards et les crèmes glacées. Évalué à 4.
Je fais partie des heureux gagnants d'un exemplaire en anglais. Je n'avais jamais eu vent moi non plus de ce livre auparavant.
Même s'il s'agit avant tout d'un conte moderne à l'attention des enfants, je l'ai beaucoup apprécié. L'histoire est sympa, le vilain n'est pas très méchant au fond, il semble même « très cool » au début puisqu'il fait le bonheur des gens en leur fournissant moult machines plus géniales les unes que les autres. Mais cela lui donne les moyens de régenter leur vie et, au détour d'une contrariété, il cède à cette facilité. S'en suit la découverte des problèmes induits par le contrôle centralisé de la technologie, de l'importance de la loi qui peut interdire ou autoriser, de la connaissance émancipatrice et, bien sûr, du rôle central que joue le logiciel dans notre société.
Ces sujets a priori un peu ésotériques pour les enfants sont présentés dans ce livre d'une manière imagée et accessible. Je vous recommande chaudement ce conte si un livre en anglais ou en allemand ne rebute pas vous ou vos enfants.
# Artilect a besoin de nous
Posté par Sébastien Dinot (site web personnel) . En réponse au journal [DIY] Boitier en acrylique pour NAS. Évalué à 3.
J'ai réalisé mon boitier à Artilect, grâce aux machines mises à disposition par ce fablab et avec les précieux conseils des bénévoles et permanents. Même à supposer que nous ayons les moyens d'acquérir une machine à découpe laser, réaliser nos projets dans un tiers lieu permet de mutualiser les moyens et donc, de maximiser leur utilisation. En outre, cet environnement s'avère stimulant. Chez vous, vous n'aurez jamais l'opportunité d'échanger et de profiter de l'intelligence collective qui imprègne un tel lieu.
Artilect traverse une mauvaise passe financière et a besoin de notre soutien. Voici la campagne que vient de lancer l'équipe sur helloasso :
Artilect a besoin de vous
[^] # Re: DIY le plaisir de construire ce genre de truc
Posté par Sébastien Dinot (site web personnel) . En réponse au journal [DIY] Boitier en acrylique pour NAS. Évalué à 6.
Je n'ai qu'une objection à cette approche : le système d'exploitation n'est pas libre. ;)
D'ailleurs, au boulot, j'ai introduit les NAS Synology il y a une douzaine d'années et la qualité de ces produits (WebOS ergonomique et socle logiciel maintenu pendant au moins 7 ans) a fait que les NAS Synology ont progressivement évincé tous les autres. Mais à titre personnel, je voulais un NAS doté d'un OS libre. J'ai opté pour TrueNAS Core pour monter en compétence, mais vu mes besoins immédiats, j'aurais pu me contenter d'une distribution OpenMediaVault, voire Debian.
Dans le cas présent, pour le même prix qu'un NAS Synology DS220+ doté des mêmes disques de stockage des données, j'ai un NAS doté d'un Celeron de 11ème génération à 4 cœurs (au lieu d'un Celeron à 2 cœurs), de 16 Go de RAM extensibles (au lieu de 2 Go non extensibles), d'un disque système NVMe de 500 Go (128, voire 64 Go auraient été largement suffisants, mais le modèle 500 Go de la même gamme était meilleur marché) et de deux interfaces réseau à 2,5 Gbit/s (au lieu d'une à 1 Gbit/s).
Le plug & play n'est pas utile dans mon cas. En cas de défaillance d'un disque, je peux largement prendre le temps d'arrêter mon NAS, de le démonter et de changer le disque.
Et pour la découpe laser, je suis effectivement passé par l'un des fablabs toulousains, nommé Artilect, dont je suis membre. Plus de détails dans mes deux articles :
- 2023-06-18 – Boitier en découpe laser pour NAS DIY
- 2023-05-10 – NAS DIY à base de carte Odroid-H3
[^] # Re: J'ai oublié le lien le plus important
Posté par Sébastien Dinot (site web personnel) . En réponse au journal [DIY] Boitier en acrylique pour NAS. Évalué à 3.
J'ai posé à question aux membres du fablab Artilect, ils m'ont dit que le polycarbonate jaunissait lorsqu'on le découpait au laser (information que j'ai aussi trouvée sur le net, où il est indiqué que le problème empire avec l'épaisseur de la plaque).
[^] # Re: Compatible TrueNAS
Posté par Sébastien Dinot (site web personnel) . En réponse au journal [DIY] Boitier en acrylique pour NAS. Évalué à 4.
Il est indiqué dans la documentation du projet TrueNAS (section Error Correcting Code Memory) :
La recommandation n'a rien de spécifique à ZFS, il n'est pas indiqué « si vous n'utilisez pas de RAM ECC, n'utilisez pas ZFS ». Il est simplement dit que la RAM ECC évite la propagation d'une erreur en RAM au système de stockage, puisqu'elle engendre le gel instantané du système. Cela est vrai quel que soit le système de stockage considéré.
Les cartes supportant la mémoire ECC sont bien plus couteuses, tout comme la RAM ECC elle-même. La configuration requise aurait donc eu un tout autre cout (sans même parler de l'encombrement). In fine, le jeu n'en vaut pas la chandelle vu que ce NAS ne va être que l'un des supports de mes données et sauvegardes.
[^] # Re: J'ai oublié le lien le plus important
Posté par Sébastien Dinot (site web personnel) . En réponse au journal [DIY] Boitier en acrylique pour NAS. Évalué à 1.
Merci ! :)
[^] # Re: J'y connais rien
Posté par Sébastien Dinot (site web personnel) . En réponse au journal [DIY] Boitier en acrylique pour NAS. Évalué à 4.
Je donne des informations supplémentaires dans l'article que j'ai publié sur mon blog et que j'ai oublié de pointer dans le journal :
https://www.palabritudes.net/2023/06/18/boitier-decoupe-laser-nas-diy.html
Une machine de découpe laser permet de découper, mais aussi de graver, tout dépend de la puissance du laser et de la focalisation du faisceau. Les traits qui apparaissent en rouge sur le plan et ont une épaisseur de 0,001 mm désignent des traits de découpe, ceux qui apparaissent en noir et sont plus épais désignent des zones à graver.
La pièce est découpée en 23 minutes sur la machine que j'ai utilisée, mais ce temps dépend de la puissance du laser (j'ai utilisé une machine 35 Watts, mais Artilect en dispose d'une à 120 Watts, qui était en maintenance ces dernières semaines). En outre, la gravure du QR-Code prend plusieurs minutes à elle seule (ce QR-Code fournit l'url du projet sur ma forge, ce faisant, une personne tombant sur un exemplaire du NAS peut découvrir les sources du projet).
Le temps de travail est assez difficile à estimer. J'ai passé 6 après-midi à Artilect, mais c'est un lieu d'échange où l'on bénéficie des conseils de membres plus expérimentés et où on a par contre vite fait de se disperser. À part cela, j'ai passé une poignée de soirées à modéliser, à faire des recherches pour étudier les différentes solutions d'assemblage qui s'offraient à moi et à rechercher les pièces qu'il me fallait. Au total, quelques dizaines d'heures d'essai et, surtout, 3 prototypes qui m'ont permis de valider ou d'invalider des pistes, et de découvrir lors du montage, que j'avais raté un ou deux trucs. :)
[^] # Re: J'ai oublié le lien le plus important
Posté par Sébastien Dinot (site web personnel) . En réponse au journal [DIY] Boitier en acrylique pour NAS. Évalué à 1.
Du coup, je me renseignerai lorsque je retournerai à Artilect.
[^] # Re: Licence
Posté par Sébastien Dinot (site web personnel) . En réponse au journal [DIY] Boitier en acrylique pour NAS. Évalué à 6.
Bien vu, je n'avais pas remarqué ce problème, car je ne suis pas l'auteur du fichier LICENSE.txt fourni dans l'archive. C'est Thingiverse qui le génère.
Je ne suis jamais dans l'approximation lorsque je parle de licence (c'est un peu mon job) et quand j'ai publié ce projet sur Thingiverse, j'ai explicitement choisi la licence CC-BY 4.0. C'est elle qui apparait d'ailleurs en bas de la colonne de gauche, sur la page du projet :
https://www.thingiverse.com/thing:6084483
L'information est tout aussi explicite et précise sur ma forge :
https://factory.palabritudes.net/zebulon/odroid-h3-nas-case
Que ce soit dans les fichiers LICENSE ou README.md, ou dans la licence annoncée dans l'interface de Gitlab.
Et pour finir, le « bien évidemment » s'explique par mes 25 ans de militantisme en faveur le libre dans tous ses états. ;)
[^] # Re: J'ai oublié le lien le plus important
Posté par Sébastien Dinot (site web personnel) . En réponse au journal [DIY] Boitier en acrylique pour NAS. Évalué à 1.
Le meuble en bois, j'y songe comme base de travail d'une baie d'hébergement. :)
[^] # Re: J'ai oublié le lien le plus important
Posté par Sébastien Dinot (site web personnel) . En réponse au journal [DIY] Boitier en acrylique pour NAS. Évalué à 2.
La chimie et moi, ça fait deux et je ne connais pas vraiment les avantages de l'un et de l'autre. Ceci étant, j'ai au moins deux arguments pour justifier ce choix :
- Sauf erreur de ma part, Artilect ne propose pas de polycarbonate dans son catalogue de matériaux (mais j'aurais pu aller en acheter ailleurs) ;
- Il semble que le polycarbonate n'est pas conseillé pour la découpe laser, notamment lorsque les plaques sont épaisses.
# J'ai oublié le lien le plus important
Posté par Sébastien Dinot (site web personnel) . En réponse au journal [DIY] Boitier en acrylique pour NAS. Évalué à 5.
Dans la fièvre de l'instant, j'ai oublié de pointer l'article de mon blog qui donne quelques précisions sur ce boitier :
Boitier en découpe laser pour NAS DIY
[^] # Re: Retour d'expérience
Posté par Sébastien Dinot (site web personnel) . En réponse à la dépêche La communauté GNOME remplace ses listes de discussion par Discourse. Évalué à 7.
Bien sûr qu'il appartient aux communautés de choisir les outils qui leur conviennent le mieux. Dans les exemples cités, j'ai proposé l'outil, en développant mon argumentaire, et les contributeurs ont accepté cette migration. Ce que je souligne, c'est que même si certains étaient tièdes ou sans avis à l'époque, je suis sincèrement convaincu qu'ils ne reviendraient plus en arrière aujourd'hui quand je vois à quel point ils se sont appropriés le nouvel outil.
Pour ma part, les listes de diffusion ne me dérangent pas, mais je suis un vieux (une preuve parmi d'autres : le client mail que j'utilise à titre privé est Mutt !) et je sais qu'elles ne conviennent pas à tout le monde, notamment à cause du fait qu'une fois abonné, on reçoit tout le trafic dans sa boite mail et que même lorsqu'un mode « digest » est proposé, la réception quotidienne d'un mail dérange certaines personnes, qui se sentent débordées (véridique, on me l'a déjà exprimé ouvertement).
Si j'ai proposé à ces projets de migrer vers Discourse, c'est parce que je vois bien que les listes de diffusion auxquelles je suis abonné connaissent une fréquentation et un trafic décroissant au fil des ans, y compris au sein de projets qui restent très dynamiques, et que les forums modernes et les messageries instantanées prennent le dessus. Quoi qu'on pense de ces outils, en 2022, ils répondent mieux aux attentes de la plupart des gens. Il appartient dès lors aux projets de s'adapter en proposant à leur communauté les outils aux gout du jour. Offrir les moyens de communication et de travail collaboratif adéquats est un facteur de succès pour un projet libre.
# Retour d'expérience
Posté par Sébastien Dinot (site web personnel) . En réponse à la dépêche La communauté GNOME remplace ses listes de discussion par Discourse. Évalué à 6.
J'ai proposé il y a quelques années aux communautés de deux projets libres – Orekit et Orfeo Toolbox – d'abandonner les listes de diffusion au profit de Discourse. Aujourd'hui, personne ne reviendrait en arrière, y compris parmi les membres qui étaient déjà très actifs sur les listes de diffusion, car il est difficile de se passer des fonctions proposées par Discourse une fois qu'on y a goûté.
Pour Orekit, un trimestre après la bascule, le nombre d'échanges avait été multiplié par 2,5, preuve que les listes de diffusion ne convenaient pas à tout le monde, même si cela n'avait jamais été exprimé.
[^] # Re: fablab
Posté par Sébastien Dinot (site web personnel) . En réponse au sondage Parlons d'imprimantes 3D…. Évalué à 3.
Je suis entièrement d'accord.
Les gâches de mes fenêtres – faites dans un matériau qui me rappelle la bakélite – se cassent parfois. J'ai besoin de les remplacer, mais je ne trouve pas en magasin des gâches identiques à celles de mes fenêtres (de vieux modèles des années 70/80). J'ai donc fini par prendre les dimensions d'une gâche avec un pied à coulisses, par apprendre à utiliser OpenSCAD (deux heures pour en découvrir les bases, puis deux heures pour créer mon modèle) et par modéliser la pièce. Puis j'ai adhéré au fablab toulousain Artilect, suivi la formation à l'impression 3D et, depuis, j'imprime à chaque fois que j'en ai besoin un lot de gâches.
J'ai publié le modèle sur Thingiverse, bien évidemment sous licence libre !
En bon geek, j'achèterais volontiers une imprimante 3D, mais elle prendrait une place déraisonnable dans mon appartement et l'usage que j'en fait est trop ponctuel pour justifier cet achat. La mutualisation proposée par les fablabs fait bien plus sens et m'apporte plus de satisfaction intellectuelle. En outre, dans les fablabs, on croise parfois des gens passionnants et on y découvre de temps à autres des projets géniaux.
[^] # Re: libre
Posté par Sébastien Dinot (site web personnel) . En réponse à la dépêche Amazon OpenSearch - fruit d'une rivalité avec Elastic ?. Évalué à 4.
Je ne sais pas ce qu'il en est d'Elastic Search, mais Gitlab n'a pas de politique de publication à retard « programmée ».
Je suis admiratif de la maturité de Gitlab vis-à-vis du libre et de sa communauté. L'entreprise a opté pour un modèle open core assez classique, mais la plupart des éditeurs qui optent pour ce modèle n'ont pas l'intelligence d'enrichir continuellement (et avec des fonctions attrayantes) la version libre. Ils ne songent qu'à accroitre l'écart fonctionnel qui sépare la version libre de la version payante, en espérant que cela conduira les clients à payer. Or, en faisant cela, ils nourrissent l'amertume des utilisateurs de la version libre, qui finissent par se tourner vers une alternative dès qu'ils le peuvent. Ils frustrent en outre terriblement les quelques contributeurs qu'ils arrivent à ferrer et ceux-ci finissent eux aussi par tourner le dos au projet. Le modèle open core, souvent mal géré, asphyxie les communautés. L'éditeur ne réalise pas qu'il se condamne à endurer tous les inconvénients du libre, sans jamais bénéficier de ses avantages et de la dynamique qu'il peut susciter.
Gitlab a compris cela et entretient intelligemment sa communauté, il la nourrit de nouvelles fonctions chaque mois (une nouvelle version de Gitlab étant publiée le 22 de chaque mois), organisant même le buzz à l'approche de la libération des fonctions les plus excitantes. Il interagit avec elle, lui pointe des bugs faciles à corriger, des fonctions qu'il serait ravi d'intégrer, mais qu'il a décidé – en tout cas pour l'instant – de ne pas implanter lui-même (cf. label Accepting merge request). Bref, Gitlab sait qu'il a une communauté exigeante et il sait être à la hauteur. Sa communauté accepte du coup plutôt bien la logique open core qui la révulse chez d'autres.
Ceci étant, notons que cette intelligence est sans doute aiguillonnée par le fait que Gitlab doit évoluer dans un écosystème très concurrentiel, entre outils libres (Gitea), outils propriétaires gratuits (Github) ou payants (suite Atlassian), sans oublier d'autres outils open core (Tuleap).
[^] # Re: libre
Posté par Sébastien Dinot (site web personnel) . En réponse à la dépêche Amazon OpenSearch - fruit d'une rivalité avec Elastic ?. Évalué à 2.
Je sais que ni la SSPL, ni l'ELv2 ne sont libres, de nombreux commentaires ont été fait un peu partout sur Internet à ce sujet. Mon message n'avait pas pour but d'évoquer un doute à ce sujet, mais juste de signaler que la justification donnée dans le message que j'ai commenté n'était pas valide.
Je suis un peu pointilleux sur le sujet, cela fait partie de mon job.