Commentaires sur la Politique sur l'utilisation et le développement des logiciels et du matériel libres de la Ville de Montréal

Ce document contient les commentaires critiques de FACiL sur la Politique sur l'utilisation et le développement des logiciels et du matériel libres dévoilée par la Ville de Montréal mardi le 15 mai 2018.

---

En général

FACiL a reçu positivement l'annonce de la Politique sur l'utilisation et le développement des logiciels et du matériel libres de la Ville de Montréal du 15 mai 2018 à l'hôtel de ville de Montréal. Heureusement, nous n'avons pas changé d'avis après avoir lu la politique elle-même!

Globalement, dans son esprit général, et aussi dans le détail de ses objectifs, de ses orientations et de ses principes directeurs, il s'agit selon notre analyse d'une bonne politique.

L'intention du législateur, telle qu'exprimée par la bouche de M. François Croteau, responsable des technologies de l'information, est également encourageante. FACiL n'avait à ce jour jamais entendu d'élu haut placé dans le pouvoir exécutif d'un gouvernement situé en sol québécois dire devant les caméras que les logiciels libres sont avantageux par rapport aux logiciels non libres car ils facilitent le partage de solutions réutilisables par les administrations publiques. Jamais non plus nous n'avions entendu une personne en position de donner des orientations politiques parler de la nécessité pour une organisation de contribuer aux logiciels libres qu'elle utilise. Nous avons souvent vu des élus montrer clairement qu'ils comprenaient l'urgence pour le secteur public de bâtir une expertise interne en technologies de l'information (TI), mais jamais avant M. Croteau on avait aussi clairement indiqué que cette expertise devait obligatoirement inclure une importante expertise en développement de logiciels libres. C'était aussi la première fois que dans la bouche d'un élu du peuple on entendait dire que les logiciels non libres sont, règle générale, désavantageux en raison des restrictions de leurs licences, restrictions assimilées à une forme de «menottage» dans lequel le «menotteur» est le propriétaire du logiciel et le «menotté», son utilisateur.

Au-delà des mots de M. Croteau, nous applaudissons une politique qui, bien qu'elle vise initialement le rattrapage, s'inscrit dans le mouvement très actuel des administrations publiques du monde qui formalisent et documentent leur processus de contribution aux communautés de logiciels libres.

La Ville de Montréal ne le formule pas exactement ainsi, mais il s'agit bien, à ne pas s'y tromper, d'un exemple d'une politique par laquelle le secteur public cherche à contribuer directement à la protection, au soutien et au développement des communs numériques que sont les logiciels libres. Ces communs numériques, qui sont hors de la propriété privée d'un côté et de la propriété publique de l'autre, permettent d'inventer une nouvelle économie reposant sur des valeurs de liberté et de collaboration. La politique dévoilée le 15 mai parle déjà du «matériel libre» en plus du «logiciel libre» : il y a donc lieu d'espérer que la Ville de Montréal se dotera à terme d'une véritable politique publique favorable aux communs en général. S'agissant des communs numériques, cette politique pourrait notamment comporter des dispositions par lesquelles la Ville de Montréal favoriserait et soutiendrait la contribution non seulement de son administration publique mais également de l'ensemble des Montréalais aux communautés de logiciel, de matériel, de savoir et de culture libres.

Mais redescendons sur Terre et revenons à la politique qui est devant nous aujourd'hui. Avons-nous quelques commentaires critiques à formuler à son endroit ? Oui, nous en avons en effet à soumettre à la Ville de Montréal et nous les avons réunis dans la section «Point par point» ci-bas.

Aussi, FACiL ayant pour mission l'appropriation collective de l'informatique libre par les Québécoises et les Québécois, nous sommes particulièrement intéressés à savoir si l'application de cette politique au cours des prochaines années aura bel et bien pour effet d'accroître l'utilisation et le développement des logiciels libres par la Ville de Montréal et plus généralement par le secteur public municipal. Pour être en mesure d'effectuer un bon suivi du progrès de l'informatique libre au sein de l'administration publique montréalaise, nous aurons besoin de données sur différents objets qui nous permettront de répondre aux questions élémentaires suivantes :

• Quelle place occupent les logiciels libres dans l'ensemble des logiciels utilisés et développés par la Ville de Montréal ?
• Combien payons-nous collectivement pour l'utilisation des logiciels installés sur les appareils numériques de la Ville de Montréal (en distinguant le logiciel libre du logiciel non libre) ?
• Quelles sont les contributions de la Ville de Montréal aux communautés de logiciels libres qu'elle utilise ?

Au cours des années à venir, nous tâcherons de collaborer directement avec le Laboratoire de l'innovation urbaine de Montréal pour que des données utiles non seulement à FACiL, mais également au public en général, aux élus, aux fonctionnaires et aux entreprises, soient libérées dans les règles de l'art. À l'aide d'indicateurs de mesure (encore à définir) et d'outils de visualisation exploitant des données de qualité (encore à produire), il devrait être possible d'arriver à des résultats satisfaisants pour tous.

Point par point

Définitions

Il y a lieu de réécrire les définitions de la politique 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 à notre connaissance de définition formelle de ce terme, qui par ailleurs est ambigu et devrait sans doute être complètement remplacé par un autre. En effet, le terme «publication libre» est déjà employé dans le même sens que «document libre» depuis des années. Peut-être que «processus de libération» d'un projet de logiciel serait plus adéquat ? Nous parlons en effet déjà de «processus de libération des données» dans un sens qui est selon notre compréhension très proche.

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)», c'est-à-dire en français la «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 utilise déjà un système libre et qu'elle fait appel au secteur privé pour sélectionner un fournisseur qui l'aidera à mettre à jour ce même système à une nouvelle version, est-ce un «remplacement» ? De prime abordm il nous semble que la réponse soit «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 d'employer un autre terme comme «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 ces 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 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» (ou dans l'autre sens pas assez «générique») pour imaginer qu'il puisse y avoir un intérêt à le réutiliser. 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 certes «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.

Code. Pour le code, 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. Grosso modo, les licences sans réciprocité et les licences avec réciprocité («copyleft» ou «share alike») 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.

Données. 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 est assez curieux que la licence de données «officielle» de la Ville, la Creative Commons BY 4.0 (une licence sans réciprocité) ne soit pas une option.

Image et documentation. La directive indique que «les images et la documentation» seront sous «une des licences Creative Commons». Il est très important de préciser dans la directive à quelles licences Creative Commons et à quelles versions de celles-ci on réfère. 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 libres. 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

NOTE : Ce point de commentaire a été rédigé avant l'annonce de l'acquisition de l'entreprise GitHub par Microsoft. Évidemment, le rachat de l'entreprise qui a produit la plateforme non libre GitHub.com par un des géants du numérique privateur de libertés n'améliore en rien la situation, au contraire.

Le choix de GitHub.com comme forge est contestable du fait qu'il s'agit d'une plateforme non libre dont le modèle d'affaires participe ultimement à la centralisation d'Internet et à la perte de contrôle sur nos données 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 un exemple extrême. Il est même possible de planifier une transition en douceur en gardant un miroir de code sur GitHub.com.

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).

Mais n'est-il pas désavantageux pour la Ville et même pour l'ensemble de la vaste communauté du logiciel libre d'avoir des projets de code dispersés un peu partout sur Internet ? N'est-il pas avantageux de tout retrouver dans un même grand catalogue ? Oui, c'est avantageux, mais pas si cela se fait au prix de la centralisation et de ses conséquences néfastes. Dans les faits, la Ville de Montréal se retrouvera nécessairement (si ce n'est déjà le cas) à travailler avec du code qui vient de plusieurs forges. Elle devra donc, comme toutes les grandes organisations qui utilisent et développent du logiciel libre, garder la trace de ses propres contributions via une forme ou une autre d’agrégation et de comptabilisation d'informations tenues à jour en interne.

Version anglaise de la politique

Dans la langue anglaise, plusieurs termes concurrents sont employés pour désigner le logiciel libre depuis environ 1998 quand on a proposé «open source» comme substitut à «free software». Bien que les deux termes renvoient essentiellement aux mêmes logiciels et aux mêmes communautés, ils sont promus par deux camps distincts qui s'affrontent sur le terrain idéologique. Pour éviter de s'aliéner un camp ou l'autre, ou pour signaler qu'on est neutre sur la question ou indifférent à celle-ci, certains personnes et certains organismes parlent de «free and open source software (FOSS)» et même de «free, libre and open source software (FLOSS)».

Étant donnée, d'une part, que la Ville de Montréal ne souhaite sans doute pas se positionner sur une question qu'elle n'a pas étudiée et, d'autre part, qu'elle emploie le terme «logiciel libre» en français, il est peut-être préférable qu'elle adopte l'usage du terme «FOSS» ou «FLOSS». Cela dit, si la Ville de Montréal désire véritablement faire un choix politique en adoptant exclusivement le terme d'un camp au détriment de l'autre, FACiL lui recommande l'usage de «free software» qui est à l'origine de «logiciel libre» dans la langue française. Ce choix correspondrait à une plus grande cohérence à la fois idéologique et «linguistique».