Livre blanc Ouvert en premier : Logiciels libres - Contribution

Droit d’auteur

La licence et le droit d’auteur sont deux choses distinctes. Dans certains cas, la licence peut accorder des droits supplémentaires au titulaire du droit d’auteur. Les œuvres réalisées par des employés du gouvernement du Canada pendant les heures de travail sont visées par un droit d’auteur qui appartient à l’État ou au gouvernement du Canada.

De plus, certains projets LL exigent que les contributeurs attribuent la propriété de leur contribution au projet, en utilisant des ententes de cession de droits d’auteur. Afin qu’un employé du gouvernement du Canada puisse contribuer au code pour de tels projets, une analyse plus poussée sera nécessaire.

Collaboration pour réduire les frais de développement

Lorsque nous diffusons un programme logiciel interne en vertu d’une licence de LL, cela a pour effet de stimuler les contributions externes des gouvernements, des entreprises, des étudiants et des citoyens sous forme de codes sources, de bogues et de documentation. Il peut s’agir d’un projet constituant un effort réuni de plusieurs entreprises, de travailleurs du secteur public et de bénévoles. Les entreprises investissent régulièrement une part de leurs ressources pour participer aux projets LL : 40 % des promoteurs des collectivités de LL sont rémunérés pour leur participation. (source : The MIT Press Journals) (en anglais seulement)

Lorsqu’une entreprise ou une organisation collabore à l’élaboration de nouvelles caractéristiques ou à la création d’un nouveau projet fondé sur les systèmes d’exploitation existants, elle ou il tire également parti de tous les efforts que les collaborateurs ont déjà investis. Si l’on distribue des modifications en tant que LL, les travaux antérieurs peuvent même inclure le code et les bibliothèques en vertu de licences réciproques (qu’une entreprise ou une organisation ne peut distribuer que si son projet constitue également un LL).

En raison de la concurrence mondiale croissante, de l’augmentation des coûts de R&D et de la réduction du cycle de vie des produits, les entreprises réduisent leur dépendance aux modèles traditionnels d’innovation fermée. Elles dépendent de plus en plus de l’accès à des sources externes de connaissances et de la collaboration avec des personnes, des entreprises et d’autres organisations qui possèdent des connaissances pertinentes pouvant être utilisées au profit du processus d’innovation de l’organisation. (source : SSRN) (en anglais seulement)

Viabilité à long terme

La diffusion d’un logiciel en tant que LL pour inciter d’autres personnes à y collaborer peut aussi contribuer à assurer la viabilité d’un projet futur. Par exemple, une organisation ou une entreprise peut mettre au point un outil logiciel à l’aide d’un budget fixe et limité pour la recherche et le développement. Pour que le projet se poursuive et se développe, la participation d’autres collaborateurs est nécessaire.

En publiant le code source, le projet peut continuer au-delà de l’investissement initial et demeure disponible pour d’autres parties intéressées à poursuivre son développement et sa maintenance. De plus, même si sa collectivité ne prend plus en charge la maintenance du projet initial de façon plus active, une organisation pourrait décider de continuer de maintenir et de poursuivre le développement du projet si celui-ci est bénéfique pour ses affaires.

En revanche, une application à code fermée ne saurait offrir le même degré de flexibilité si le manufacturier venait qu’à cesser ses activités.

Établissement de la réputation

Pour les personnes qui participent au développement d’un LL, l’établissement d’une bonne réputation représente un facteur de motivation conjoint et un avantage concret. Dans certains cas, l’objectif consiste à démontrer les compétences et les talents aux employeurs; dans d’autres cas, il s’agit d’obtenir un statut auprès d’une collectivité.

La plupart des projets de LL sont ouverts à la contribution de tous les développeurs. Ainsi, les participants sont en mesure de mettre en valeur et de démontrer leur talent aux employeurs potentiels. Non seulement les participants peuvent-ils inclure leur participation dans leur CV, mais les employeurs peuvent également sélectionner et embaucher des talents directement à partir d’un bassin de développeurs qui contribuent à un projet de LL. Ces développeurs peuvent avoir des compétences éprouvées dans des domaines d’expertise souhaitables. (source : The MIT Press Journals) (en anglais seulement).

La présence d’une culture de « méritocratie » populaire dans de nombreux projets de LL profite également aux contributeurs ayant un statut et un privilège. Règle générale, les contributeurs les plus importants ont tendance à avoir un contrôle accru du projet – par exemple, lorsqu’il s’agit de décider des priorités pour de nouvelles fonctions. (source : OSS Watch) (en anglais seulement).

Certes, la réputation et la bonne volonté sont aussi extrêmement importantes pour les contributeurs du secteur public. La participation à un LL peut contribuer à l’établissement d’une réputation positive parmi d’autres développeurs et utilisateurs de LL.

Avantages pour le public

Les LL peuvent s’harmoniser parfaitement avec le rôle des organisations du secteur public pour offrir de vastes avantages au grand public, notamment le maintien de l’infrastructure technologique de la société et une contribution à son évolution.

L’émergence des entreprises sociales et l’intérêt entrepreneurial pour l’amélioration du fonctionnement des gouvernements, en particulier au niveau local, représente un phénomène nouveau. Les technologues mobilisés sur le plan civil élaborent des applications de LL pour résoudre des problèmes sociaux comme les retards attribuables à la bureaucratie. Bien que tous les projets de logiciels ayant des objectifs sociaux plus larges ne soient pas du type LL, les avantages des LL pour l’amélioration de la disponibilité globale des technologies réutilisables dans la société correspondent souvent aux objectifs de ces entrepreneurs sociaux.

Même hors des entreprises sociales, la diffusion de LL par les organisations du secteur public peut aider à stimuler l’innovation dans le secteur privé. Elle permet aux entreprises de créer des offres spécialisées basées sur les LL, même lorsque ces logiciels pourraient autrement être trop coûteux pour que l’entreprise puisse les développer à l’interne.

Les LL peuvent aussi contribuer à maximiser l’efficacité économique globale au sein de la société. Lorsque les logiciels sont disponibles gratuitement et que n’importe qui peut ajouter les nouvelles fonctions nécessaires, les entreprises peuvent utiliser ces ressources existantes plutôt que de déployer des efforts pour reproduire un projet existant.

Avantages pour l’employeur

Pendant les processus d’embauche, la direction de la TI peut utiliser les contributions comme mesure d’évaluation de la qualité des embauches potentielles. De plus, les candidats peuvent être incités à se familiariser avec certaines parties du code source en vue du processus d’entrevue. Par conséquent, les employés peuvent entrer dans le milieu de travail en connaissant bien certaines parties de la base des codes, réduisant ainsi le temps nécessaire pour la formation de l’employé en tant que membre de l’équipe le plus productif possible.

Sécurité

Comme nous l’avons vu en ce qui a trait au Logiciel libre - Utilisation, la distribution de LL présente également des avantages et des inconvénients en matière de sécurité. Le LL surveille davantage le code pour régler les problèmes de sécurité, mais, en même temps, il le met à la disposition de ceux qui ont des objectifs malveillants.

Science ouverte

La portée des jeux de données utilisés dans la recherche scientifique s’est considérablement élargie dernièrement. Les études génétiques utilisent maintenant couramment des téraoctets de données séquentielles. Les technologies qui génèrent ces données se développent rapidement, et une analyse rigoureuse exige de plus en plus que les scientifiques modifient les logiciels existants ou créent des programmes entièrement nouveaux. Cela n’est possible que parce que la collectivité scientifique a adopté la création et le partage de codes informatiques à l’aide de licences de logiciels libres.

Par conséquent, la pleine participation de la collectivité scientifique exigera de plus en plus que les scientifiques du gouvernement produisent et partagent des codes informatiques. En effet, à mesure que les logiciels deviennent plus importants pour la science, les revues commencent à exiger la diffusion du code en tant que condition de publication. PLLSOne (en anglais seulement), l’un des principaux éditeurs scientifiques en libre accès, s’attend à ce que « tous les chercheurs qui soumettent à PLLS des articles dans lesquels le logiciel constitue la partie centrale du manuscrit rendent disponibles tous les logiciels pertinents sans restrictions lors de la publication de leurs travaux ». À mesure qu’augmente la proportion de la recherche à laquelle les logiciels sont essentiels au travail, il est clair que les scientifiques du gouvernement auront besoin de politiques de soutien pour continuer à participer.

Transparence

Le Canada a établi un mandat très clair de gouvernement ouvert afin d’améliorer la transparence et la responsabilisation, d’accroître la participation des citoyens, et de stimuler l’innovation et les débouchés économiques par l’intermédiaire de données ouvertes, d’information ouverte et de dialogue ouvert. Le partage de logiciels internes en vertu d’une licence libre s’harmonise naturellement avec ces objectifs et constitue une excellente façon de remettre quelque chose aux contribuables. De plus, le libre accès à un projet de LL (p. ex., code source, problèmes/bogues, procès-verbaux de gouvernance/réunions, documentation/forum de soutien) permet une évaluation réelle de sa maturité ainsi que du niveau d’activité de sa collectivité et de ses fournisseurs de soutien. Par conséquent, il est plus facile de comparer la vitesse de développement et la santé de multiples projets/solutions.

Manque de revenus pour les licences directes

Le fait que n’importe qui puisse redistribuer gratuitement les LL constitue un obstacle évident pour de nombreux fournisseurs de logiciels qui n’utilisent pas le modèle d’exploitation de LL. Outre les frais nominaux pour la distribution sur support matériel, il n’est généralement pas possible de tirer profit du LL en utilisant le modèle commercial traditionnel de vente directe de licences de logiciels. Le manque de recettes directes provenant de l’octroi de licences peut également constituer un obstacle dans les organisations du secteur public où des politiques de « recouvrement des coûts » sont en place. Même si les LL peuvent contribuer à l’atteinte de nombreux objectifs de la fonction publique, ceux-ci ne favorisent pas nécessairement la compensation des coûts et risques associés au développement de logiciels.

Il convient toutefois de prendre note que, dans le cas de nombreux projets de logiciels auxquels les fonctionnaires, et en particulier les scientifiques, peuvent participer, la valeur économique d’un programme d’ordinateur individuel sera minime. Dans les organisations où il n’existe pas de mécanisme établi de vente de logiciels, les efforts nécessaires pour établir et gérer la vente de programmes et pour fournir le niveau de soutien auquel on s’attendrait dans un marché commercial sont susceptibles de dépasser les revenus potentiels qui pourraient être réalisés.

La collectivité peut ne pas se regrouper

Il existe de nombreux exemples de projets de LL florissants comme le noyau Linux, le serveur Apache et le navigateur Web Firefox. Ces projets font appel à la participation de collectivités actives qui comptent des centaines, et dans certains cas des milliers, de développeurs de logiciels. Cependant, il y a aussi un nombre relativement élevé de projets de LL où le développement actif a cessé. Bien entendu, bon nombre de ces projets sont probablement ceux de développeurs individuels qui ont enregistré un projet, mais qui n’ont pas fait d’efforts subséquents ou de progrès dans le développement d’une collectivité. Quoi qu’il en soit, les chiffres présentent une mise en garde, à savoir que pour exécuter correctement un projet de LL, vous devriez être prêt à investir les ressources nécessaires pour que le projet passe par une première version et fasse face à tout retard dans la participation de la collectivité.

Cela dépend également des objectifs lors de la publication du code en tant que LL. Pour le gouvernement du Canda, il pourrait simplement s’agir d’héberger le code source publiquement (pour le rendre accessible aux autres ou pour travailler ouvertement) et le projet n’a pas besoin de contributions externes pour le maintenir. Dans ce cas, une collectivité est un avantage collatéral apprécié si cela se produit. Dans d’autres cas, vous voudrez peut-être créer une collectivité et que le projet continue d’exister sans que le gouvernement du Canada soit le principal contributeur.

Complexité juridique

La diffusion d’un logiciel en tant que LL exige habituellement un examen juridique attentif des licences, surtout lorsque le logiciel comprend des bibliothèques et des codes provenant de sources multiples. Bien que les licences de source fermée exigent également un examen juridique minutieux, de nombreuses licences de LL sont étoffées et contiennent des complexités juridiques desquelles le personnel du contentieux n’est peut-être pas conscient. Certaines ententes internationales d’interopérabilité peuvent comporter des clauses qui empêchent l’utilisation des composantes de LL.

Risque de responsabilité en matière de brevets

Les avis sont partagés quant à savoir si la diffusion de logiciels augmente ou diminue le risque de responsabilité en matière de brevets. D’une part, la distribution de votre code en tant que LL l’expose à un examen plus approfondi. D’autres peuvent consulter le code et tenter de trouver des cas de contrefaçon de brevet. D’autre part, les collaborateurs des projets de LL peuvent contribuer à la restructuration des brevets dès la découverte d’une contrefaçon. Les conséquences négatives possibles sur les relations publiques et les crédits de bienveillance de poursuites en matière de brevets contre une collectivité de LL peuvent également avoir un effet dissuasif important. Des organisations sans but lucratif comme le Software Freedom Law Center (en anglais seulement) offrent également des ressources pour aider les auteurs de projets de LL à se défendre contre les poursuites pour contrefaçon de brevet et les revendications de brevet invalides. Autre inconvénient : les bénévoles ont rarement des portefeuilles de brevets de défense. Toutefois, du même coup, le fait de s’en prendre à des particuliers est également coûteux pour les avocats plaidants en matière de brevets. La plupart des particuliers n’ont pas une valeur nette suffisante pour qu’une poursuite en matière de brevets contre eux en vaille la chandelle.

Participation communautaire

En général, les LL qui ont du succès s’appuient sur la collaboration et la participation de la collectivité, et ils en dépendent. Il est considéré comme une pratique exemplaire de tenter de redonner à la collectivité de qui vous tirez des avantages. Cette réciprocité contribue non seulement à maintenir en vie un projet de LL, mais elle vous aide aussi à établir des liens et de bonnes relations avec les autres membres de la collectivité. Cela peut vous aider à obtenir l’aide de la collectivité ou à présenter des demandes de caractéristiques. Cette question fait l’objet d’un examen dans un document de recherche de 2005 intitulé « The Role of Social Capital in Open Source Software Communities (en anglais seulement) ».

Même sans fournir de code, il y a de nombreuses autres façons de contribuer à un projet de LL. Par exemple, un utilisateur peut envisager une ou plusieurs des activités suivantes :

• Soumettre des suggestions de logiciels : Fournir des rapports sur les bogues et suggérer toute nouvelle fonctionnalité susceptible d’améliorer le logiciel.
• Améliorer la documentation : Aider à rédiger de nouveaux guides d’utilisation, à corriger et à améliorer la documentation existante, ou à soumettre des œuvres d’art telles que des icônes, des arrière-plans et des logos.
• Aider les autres : Participer à des forums d’aide et à des listes d’envoi de produits de soutien.
• Faire des contributions financières : Surtout si un utilisateur profite du logiciel, celui-ci peut en partager une partie avec la collectivité sous forme de dons au projet.
• Contribuer à l’infrastructure : Fournir du matériel, offrir du temps sur un serveur ou même aider à maintenir le contenu du portail Web du projet.
• Promouvoir le logiciel : Faire profiter les autres des avantages d’un logiciel et rédiger des critiques.

Décision de distribuer le logiciel en tant que logiciel libre

La décision d’octroyer ou non une licence de logiciel en tant que LL passe toujours par une évaluation des exigences opérationnelles et des objectifs du projet. Les exigences opérationnelles auront une grande incidence sur la pondération que vous devriez accorder aux divers avantages et inconvénients. Les entreprises et les organisations lancent des logiciels sous forme de LL à de nombreuses étapes du cycle de développement. Dans certains cas, le logiciel a connu de nombreuses versions et itérations avant de devenir LL. Dans d’autres cas, le logiciel peut commencer sa vie en tant que projet collaboratif de LL entre plusieurs parties. La philosophie de développement des LL est parfois décrite comme suit : « diffusez tôt, diffusez souvent et soyez à l’écoute de vos clients ». Toutefois, il est généralement de bon aloi d’avoir un plan pour l’architecture initiale du projet avant de commencer la distribution en tant que LL. Ce plan peut simplement consister à demander à plusieurs collaborateurs de commencer à travailler sur l’architecture au début du projet. Toutefois, lorsqu’il n’existe aucun plan, les développeurs œuvrant sur différents éléments du projet pourraient éprouver des difficultés à intégrer leurs éléments respectifs ou à travailler en fonction d’une application cohésive.

Classification de sécurité

La Directive sur la gestion de la sécurité ministérielle du Conseil du Trésor entend par information désignée une information « pouvant faire l’objet d’une exemption ou d’une exclusion en vertu de la Loi sur l’accès à l’information et de la Loi sur la protection des renseignements personnels parce qu’il serait raisonnable de s’attendre à ce que sa divulgation compromette les intérêts non nationaux ».

Pour que le code source puisse être considéré comme protégé, il doit contenir l’un ou l’autre des renseignements suivants :

• Information obtenue à titre confidentiel
• Information sur les affaires fédérales-provinciales
• Information sur les affaires internationales et la défense
• Information sur l’application de la loi et les enquêtes
• Information sur la sécurité des personnes
• Information sur les intérêts économiques du Canada
• Renseignements personnels
• Renseignements de tiers
• Conseils sur certains aspects des activités du gouvernement
• Information sur les procédures d’essai, les essais et les audits
• Renseignements protégés par le secret professionnel de l’avocat
• Renseignements visés par des interdictions légales
• Certains types de renseignements détenus par la Société Radio-Canada et Énergie atomique du Canada limitée
• Renseignements confidentiels du Conseil privé de la Reine

Il est très peu probable que les développeurs incluent intentionnellement de tels renseignements dans leur code source. Par conséquent, la catégorisation proposée pour la confidentialité du code source est réputée non classifiée à moins que le développeur n’ait inclus, par inadvertance ou non, des renseignements qui relèvent des exemptions et exclusions de la Loi sur l’accès à l’information énumérées ci-dessus. Dans la mesure du possible, cette information devrait être retirée du code source afin d’accroître la capacité de partage du code.

Voici quelques aspects de sécurité à garder à l’esprit lors du développement de logiciels :

• Conserver les données sensibles comme les justificatifs d’identité en lieu sûr et séparément du code source.
• Éviter d’entreposer des clés et d’autres documents de nature délicate dans des systèmes non approuvés à cette fin.
• L’examen des codes augmente la probabilité de détecter les bogues, les vulnérabilités en matière de sécurité et réduit le risque d’engager des données sensibles.
• Mettre en œuvre des mesures de contrôle suffisantes pour la prévention des changements non autorisés ou accidentels comme signer le code et établir des droits d’accès pour les utilisateurs des dépôts de code.

Choisir une licence

Vous devez publier votre code sous une licence approuvée par l’Open Source Initiative (en anglais seulement). Par exemple, le Service numérique canadien (SNC) utilise la licence du MIT. Les autres licences recommandées sont Apache 2.0, GPL 3.0, LGPL 3.0 et AGPL 3.0. Tous les codes produits par des fonctionnaires sont automatiquement couverts par le droit d’auteur de la Couronne.

Vous n’aurez pas toujours le choix de la licence que vous demanderez. Lorsqu’une obligation afférente à une licence réciproque est en vigueur, vous devez accorder une licence à votre code en vertu de la même licence – voir la section Gérer les obligations relatives aux licences. De plus, même si vous n’êtes pas strictement tenu par la loi d’appliquer une licence particulière, vous pourriez quand même vouloir adopter la même licence qu’un projet ou une collectivité de logiciels existants afin d’y participer.

Lorsque vous distribuez un projet constitué entièrement de votre propre code ou de votre propre code ainsi qu’un code autorisé et un code qui n’engage pas d’obligations réciproques, vous pouvez choisir vous-même la licence de LL. La licence que vous choisissez doit correspondre à vos exigences opérationnelles. Toutes les licences de LL communes peuvent être adoptées pour les travaux effectuées par le gouvernement, l’industrie ou le secteur de l’éducation – vous devez examiner les objectifs des projets particuliers.

Le choix d’une licence appropriée tend à dépendre de la décision d’appliquer une licence réciproque ou permissive :

• les licences permissives maximisent la portée des utilisateurs en aval (et comportent un grand attrait pour l’ensemble du secteur privé);
• tandis que les licences réciproques sont appropriées dans les cas où il est important de recevoir les modifications en aval ou lorsqu’il est important de veiller à ce que les travaux fondés sur un investissement initial demeurent ouverts et libres. Les licences réciproques peuvent également mettre l’accent sur la prestation de services et de soutien à d’autres entreprises du secteur privé.

Le tableau suivant présente d’autres différences clés relativement à cette décision :

Choosealicence.com (en anglais seulement) simplifie le processus de sélection d’une licence de LL en présentant les définitions des licences les plus utilisées.

Choisir un référentiel de code source

Vous devez rendre votre code source publiquement disponible ouvertement par l’entremise d’Internet dans un référentiel de code source. Par exemple, le code du SNC est sur GitHub (en anglais seulement). Cela inclut le code développé pour vous par un tiers, tel qu’une organisation de développement.

Des exemples de référentiels de code source Internet ouverts comprennent, sans toutefois se limiter à :

• Gitlab
• Github
• Framagit
• Bitbucket
• SourceForge

Gérer la participation aux projets

Les logiciels ouverts rassemblent souvent une collectivité disparate de développeurs, allant des amateurs bénévoles aux entreprises commerciales. En l’absence d’une structure officielle de gestion et de communication, comme c’est le cas dans un environnement de développement organisationnel unifié, les collectivités de LL utilisent diverses techniques pour autogérer leurs projets dans cet environnement.