|
|
| (28 versions intermédiaires par le même utilisateur non affichées) |
| Ligne 1 : |
Ligne 1 : |
| Mes commentaires sur la ''Politique sur l'utilisation et le développement des logiciels et du matériel libres'' ([https://github.com/VilledeMontreal/politique-libre/blob/master/Politique/PolitiqueDuLibre.md texte], [http://ville.montreal.qc.ca/pls/portal/docs/PAGE/PRT_VDM_FR/MEDIA/DOCUMENTS/politique_materiel_libres_fr.pdf PDF]) dévoilée par la Ville de Montréal mardi le 15 mai 2018.
| | #REDIRECT [[Commentaires sur la Politique sur l'utilisation et le développement des logiciels et du matériel libres de la Ville de Montréal]] |
| | |
| ----
| |
| | |
| == Général ==
| |
| Globalement une excellente nouvelle et dans son esprit général et son intention une bonne politique.
| |
| | |
| (à développer)
| |
| | |
| == Point par point ==
| |
| === Définitions ===
| |
| Il y a lieu de réécrire les définitions de manière à se rapprocher des définitions formelles ou courantes (et traductions françaises les plus recommandées) des termes «licence libre», «logiciel libre», «matériel libre». Le cas de «publication libre» (anglais: «''Open source publication''») est plus compliqué car il n'y a pas à ma connaissance de définition formelle de ce terme qui par ailleurs est ambigu et devrait sans doute être complètement remplacé un autre.
| |
| | |
| === Orientations ===
| |
| L'expression «menottage contractuel» pour traduire «''vendor lock-in''» semble être un néologisme propre à la Ville de Montréal. Le problème avec cette traduction est qu'elle est très proche du «menottage numérique» qui traduit, dans le mouvement du logiciel libre, l'expression anglaise «''digital handcuffs''» promue pour la Free Software Foundation pour parler de ce que l'industrie nomme ''Digital Rights Management'' (DRM) et qui est généralement traduit par «gestion numérique des droits». Les traductions françaises les plus courantes de «''vendor lock-in''» sont plutôt «dépendance envers un seul fournisseur», «verrouillage propriétaire», «enfermement propriétaire», etc.
| |
| | |
| === Principes directeurs (1) ===
| |
| L'expression «tous les remplacements ou développements de logiciels et de matériel» embrasse-t-elle vraiment tous les cas ? Si oui, alors rien à rajouter. Cela dit, si la Ville utile déjà un système libre et qu'elle fait appel au secteur privé pour sélectionner une fournisseur qui l'aidera à mettre à jour ce même système à une nouvelle version, ou à étendre ses fonctionnalités par exemple via des extensions, est-ce une «remplacement» ? De prime abord il me semble que non. Or, il est souhaitable que la politique embrasse ces cas qui seront courants.
| |
| | |
| === Principes directeurs (2) ===
| |
| L'expression «besoins d'affaires» (anglais : «''business needs''») est curieuse dans le contexte de l'administration publique. Il est vrai qu'on peut parler de l'administration des «affaires publiques» («''public affairs''»), mais l'on peut difficilement dire «besoins d'affaires publiques» en français. En conséquence, il est plus simple de parler des «besoins des utilisateurs». Ce choix serait particulièrement pertinent puisque la Ville de Montréal s'engage en ce moment dans la voie de la conception de logiciel centrée sur les utilisateurs («''user-centered design''»).
| |
| | |
| === Exceptions pour la publication de logiciels et du matériel libres ===
| |
| Les deux premiers des trois motifs invoqués pour justifier les exceptions («pour protéger la vie privée, les libertés civiles ou l'application de lois») sont incompréhensibles. Il y a lieu de revoir les deux premiers motifs qui sont en fait souvent les ''principaux motifs'' de vouloir rendre public, sous licence libre, les logiciels utilisés par la population. Pour ce qui est du troisième motif, il y a lieu de préciser de quelles lois il s'agit pour éviter qu'on l'invoque à tort et à travers pour contourner l'esprit ou la lettre de la politique.
| |
| | |
| Les raisons légitimes de ne pas rendre public le code source des logiciels libres sont typiquement liées au droit d'auteur, à la nature non réutilisable du code ou au manque de ressource interne. En effet, pour publier le code source sous une licence licence libre et ultimement le placer dans un dépôt public il faut être l'auteur ou du moins l'ayant droit de tout le code publié. Le code source de certains logiciels peut être trop spécifique et pas assez générique pour imaginer qu'il puisse y avoir un intérêt à le réutiliser<ref>Cela dit, l'expérience a montré que du code qu'on pensait au départ de peu d'intérêt pour les autres peut se retrouver très prisé pour des motifs insoupçonnés. Il faut donc être prudent ici de ne pas garder pour nous un peu n'importe quoi. Même si le code n'est jamais réutilisé, il peut être lu par d'autres qui s'en inspireront ou qui nous rapporteront des bogues et même des ajouts, des correctifs et des suggestions utiles.</ref>. Le manque de ressource interne peut mener à du code mal ou pas encore documenté qu'on ose pas montrer au public ou sinon à du code «présentable», mais pour lequel on n'est pas en mesure d'affecter une personne qui sera responsable d'interagir avec la communauté.
| |
| | |
| === Encadrements ===
| |
| La «Directive de contribution à un projet libre existant» traite bien de la question des licences en prescrivant tout simplement le respect des licences déjà choisies par les responsables des projets en question.
| |
| | |
| La «Directive sur la publication et le maintien d’un projet Ville en libre» ne traite par contre pas bien de la question des licences. Notamment, elle prescrit l'emploi exclusif de la licence libre MIT, c'est-à-dire une licence sans réciprocité. Ce qu'il est recommandé de faire pour une administration publique en matière de choix de licences est très bien expliqué par le juriste Stefano Gentile du Centre commun de recherche de la Commission européenne dans la présentation qu'il livrait à Libsonne en mars 2017 dans le cadre de la ''Sharing & Reuse Conference 2017''<ref>https://joinup.ec.europa.eu/sites/default/files/event/attachment/presentation_gentile.pdf</ref><ref>https://youtu.be/xlgThYuxIBU</ref>. Grosso modo, les licences sans réciprocité et les licences avec réciprocité («''copyleft''») ont des objectifs spécifiques et il est important de comprendre les cas (et les types de logiciels) où les unes sont préférables aux autres. Les motifs le plus souvent invoqués pour «standardiser» sur une licence sans réciprocité pour tous les logiciels utilisés (maximiser les cas de réutilisation et éviter l'enfer des incompatibilités de licences) sont compréhensibles, mais ils ne sont pas bien fondés. Il est possible de garder la complexité de la gestion des licences à un niveau raisonnable sans rejeter d'emblée toutes les licences à réciprocité, qui présentent de nombreux avantages pour le bien commun en plus de potentiellement ouvrir la porte à des sources de revenus supplémentaires pour la Ville de Montréal.
| |
| | |
| Notons que la licence de données prescrite par la directive de la Ville (ODbL) est une licence à réciprocité. Bien que nous n'ayons pas d'objection particulière envers cette licence, il assez curieux que la licence de données «officielle» de la Ville<ref>http://donnees.ville.montreal.qc.ca/portail/licence/</ref>, la Creative Commons BY 4.0 (une licence sans réciprocité) ne soit pas une option.
| |
| | |
| La directive indique par ailleurs que «les images et la documentation» seront sous «une des licences Creative Commons». Il est très important ici de préciser de quelles licences Creative Commons et de quelles versions on parle. Les versions les plus récentes (4.0) sont généralement recommandables et les licences qui comportent les conditions NC et ND ne sont en général pas recommandables pour les images et la documentation des logiciels. Il vaudrait mieux dans ce contexte préciser l'utilisation des licences CC BY-SA 4.0 et CC BY 4.0.
| |
| | |
| === Choix de GitHub.com, plateforme non libre ===
| |
| Le choix de GitHub.com comme forge est contestable du fait qu'il s'agit d'une plateforme non libre dont le modèles d'affaires entraîne la captivité des utilisateurs et la centralisation d'Internet au même titre que toutes les autres plateformes du même type. Il est assez paradoxal dans une Politique sur l'utilisation et le développement des logiciels et du matériel libres de négliger ce fait. Nous comprenons bien sûr l'attrait de la plateforme : le grand nombre d'utilisateurs, la visibilité que l'on s'imagine qu'elle apportera aux projets qu'elle héberge, etc. La bonne nouvelle c'est que contrairement à d'autres plateformes non libres, il est relativement aisé d'en sortir du fait qu'elle repose sur git, un logiciel libre très utilisé par les développeurs du monde entier. On peut donc migrer dans et hors de github.com beaucoup plus facilement que dans et hors de Windows pour donner une exemple extrême.
| |
| | |
| Ce qu'il est possible et recommandé de faire c'est de ne pas imposer de plateforme dans la politique de la Ville de Montréal, comme le fait notamment la ''Politique de contribution aux logiciels libres de l'État'' de la DINSIC (France).
| |
| | |
| == Notes et références ==
| |
| {{Références}}
| |