Guide juridique du logiciel libre dans l’administration

1. Cadre juridique de la publication des codes sources publics

La publication de codes sources par l’administration s’inscrit dans un cadre juridique précis. Ce cadre définit à la fois les obligations de diffusion, le régime de propriété intellectuelle applicable aux logiciels et les conditions de communicabilité. Il fonde la légitimité de l’ouverture des codes sources publics et prépare le choix d’une licence adaptée.

1.1 Cadre juridique et appui ministériel

Toute entité chargée d’une mission de service public doit publier tout document produit ou reçu dans ce cadre, quel qu’en soit le support ou le lieu de conservation.

Les codes sources sont reconnus comme des documents administratifs communicables au même titre que d’autres données publiques, conformément à l’ (Ouvre une nouvelle fenêtre) avis CADA du 8 janvier 2015 n° 20144578.

La publication concerne les codes « dont la diffusion présente un intérêt économique, social, sanitaire ou environnemental ».

Les règles applicables aux licences sont précisées par les articles (Ouvre une nouvelle fenêtre) L323-2 et (Ouvre une nouvelle fenêtre) D323-2-1 du Code des relations entre le public et les administrations (CRPA).

Au sein des ministères, les Administrateurs ministériels des données, des algorithmes et des codes sources (AMDAC) assurent la mise en œuvre de ce cadre légal. Ils pilotent les politiques de publication et accompagnent les services dans la diffusion des codes qu’ils développent ou font développer.

1.2 Régime juridique du logiciel

Le logiciel est une œuvre de l’esprit protégée automatiquement par le droit d’auteur, sans formalité particulière.

Ce droit comprend deux volets :

• les droits patrimoniaux (ou droits d’exploitation) ;
• les droits moraux (respect du nom, du statut d’auteur, intégrité de l’œuvre).

Toute utilisation, copie, modification ou diffusion sans autorisation du détenteur des droits patrimoniaux constitue une contrefaçon passible de trois ans d’emprisonnement et de 300 000 € d’amende ( (Ouvre une nouvelle fenêtre) Art. L. 335-2 du Code de la propriété intellectuelle).

Le droit d’utilisation du logiciel ouvre toutefois certaines possibilités encadrées ( (Ouvre une nouvelle fenêtre) Art. L122-6-1 du Code de la propriété intellectuelle) :

• corriger des erreurs, sauf si la licence s’y oppose ;
• réaliser une copie de sauvegarde nécessaire à l’usage ;
• analyser le fonctionnement externe du logiciel ;
• reproduire ou traduire du code pour assurer l’interopérabilité.

La protection patrimoniale dure 70 ans après le décès de l’auteur en France (ou après la première publication pour une personne morale). Au-delà, le logiciel entre dans le domaine public et devient librement réutilisable.

Les droits moraux, eux, sont inaliénables et garantissent notamment la mention du nom des auteurs.

Lorsque « un logiciels et leur documentation [sont] créés par un ou plusieurs employés dans l'exercice de leurs fonctions ou d'après les instructions de leur employeur » ( (Ouvre une nouvelle fenêtre) Art. L113-9 du Code de la propriété intellectuelle), les droits patrimoniaux sont automatiquement dévolus à l’État.

Dans ce cadre, l’auteur conserve ses droits moraux mais ceux-ci sont limités ( (Ouvre une nouvelle fenêtre) Art. L121-7 du Code de la propriété intellectuelle) : il ne dispose plus du droit de retrait ni du droit au respect intégral de l’œuvre.

1.3 Conditions de communicabilité d’un code source

Un code source développé par une administration est communicable lorsqu’il respecte certaines conditions :

• l’obligation s’applique aux collectivités de plus de 3 500 habitants et aux organismes publics de plus de 50 agents ;
• l’administration doit détenir la propriété intellectuelle du code ;
• le code doit être achevé : toute version effectivement utilisée, même bêta, est considérée comme telle.

La communication peut être refusée si elle porte atteinte :

• au secret commercial et industriel ;
• à la sûreté de l’État, à la sécurité publique, à la sécurité des personnes ou à la sûreté des systèmes d’information des administrations ;
• à la recherche et à la prévention d’infractions.

En dehors de ces limites, toute personne ou administration peut demander la communication d’un code source.

2. Licences : les indispensables à connaître

Une licence logicielle est un contrat entre les auteurs d’un logiciel et ses réutilisateurs.

Les licences libres donnent à chacun le droit d’étudier, de copier, de modifier et de redistribuer le code source.

Elles permettent de sécuriser et simplifier la relation entre les auteurs et les utilisateurs : elles précisent les droits de chacun, préviennent les litiges et évitent d’avoir à conclure un contrat individuel à chaque réutilisation.

Une fois le logiciel obtenu, gratuitement ou non, l’utilisateur doit se conformer à la licence qui l’accompagne :

• Avec une licence libre, la liberté d’usage et de modification est totale tant que le logiciel reste utilisé en interne.
• En revanche, en cas de redistribution à l’extérieur de l’organisation, les obligations de la licence doivent être respectées — sous peine de contrefaçon.

2.1 Licences applicables à la publication d’un code source

Pour éviter la prolifération des licences, la loi pour une (Ouvre une nouvelle fenêtre) République numérique a prévu la création d’une liste officielle de licences utilisables par les administrations pour la réutilisation à titre gratuit ( (Ouvre une nouvelle fenêtre) Art. D.323-2-1 du CRPA).

Cette liste recense les licences reconnues comme compatibles avec le cadre juridique public et recommandées pour la publication de codes sources produits par des administrations.

→ Elle est accessible sur (Ouvre une nouvelle fenêtre) data.gouv.fr/licences.

2.2 Les grandes familles de licences libres

Toutes les licences libres garantissent les mêmes libertés fondamentales (utiliser, étudier, modifier et redistribuer le code) mais elles se distinguent par la façon dont elles encadrent la redistribution.

Deux grandes familles coexistent :

• les licences permissives, qui offrent une liberté maximale, y compris pour une réutilisation dans des logiciels propriétaires ;
• les licences à réciprocité, dites copyleft, qui imposent que les versions modifiées ou redistribuées restent sous une licence libre.

Comprendre cette distinction aide à choisir le cadre le plus adapté selon vos objectifs : diffusion large et sans contrainte, ou mutualisation et partage des améliorations.

Licences permissives

Les licences permissives offrent une grande liberté de réutilisation.

Un logiciel publié sous ce type de licence peut être modifié et redistribué sous une autre licence, y compris propriétaire.

Par exemple, certains composants du système FreeBSD (sous licence BSD) ont été réutilisés pour créer macOS, distribué ensuite sous licence propriétaire.

Ces licences privilégient la souplesse de diffusion et la réutilisation la plus large possible, y compris par des acteurs commerciaux.

Exemples de licences permissives autorisées pour les administrations par décret :

• Licence Ouverte version 2.0 (etalab-2.0)
• (Ouvre une nouvelle fenêtre) Apache License 2.0 (Apache-2.0)
• (Ouvre une nouvelle fenêtre) BSD 3-Clause “New” or “Revised” License (BSD-3-Clause)
• (Ouvre une nouvelle fenêtre) CeCILL-B Free Software License Agreement (CECILL-B)
• (Ouvre une nouvelle fenêtre) MIT License (MIT)

Le copyleft

Le terme copyleft est un jeu de mots avec copyright (le droit d’auteur aux États-Unis).

Ce terme est révélateur du mouvement du logiciel libre qui, au lieu de se battre contre le copyright, a utilisé ses mécanismes de protection des œuvres pour garantir les  (Ouvre une nouvelle fenêtre) libertés essentielles des utilisateurs.

Les licences à copyleft vont plus loin que les licences permissives, elles imposent une réciprocité, c’est-à-dire que toute version modifiée ou redistribuée du logiciel doit rester sous une licence libre. Elles interdisent donc d’ajouter des restrictions qui limiteraient ces libertés.

La plus connue est la (Ouvre une nouvelle fenêtre) GNU General Public License (GPL).

D’autres exemples courants :

• (Ouvre une nouvelle fenêtre) GNU Affero General Public License v3.0 or later (AGPL-3.0-or-later)
• (Ouvre une nouvelle fenêtre) Mozilla Public License 2.0 (MPL-2.0)
• European Union Public License 1.2 (EUPL-1.2)

Les obligations peuvent varier selon que la licence est à copyleft faible ou copyleft fort :

• Le copyleft fort impose que toute œuvre dérivée (et les logiciels liés) soient redistribués sous la même licence.
• Le copyleft faible s’applique uniquement au logiciel lui-même, permettant à d’autres composants de rester sous des licences différentes.

Une précision utile : le copyleft ne retire jamais la liberté du code d’origine.

Une fois qu’un logiciel X est publié sous une licence libre, il le restera toujours, tant que son auteur détient les droits nécessaires. Si un autre développeur ajoute du code Y à ce logiciel X et le redistribue sous une licence différente, cela ne modifie en rien la licence du code d’origine. Le logiciel initial X reste libre et peut continuer à être utilisé, copié ou adapté par tous, sous sa licence d’origine.

Différence entre copyleft faible et copyleft fort

Le copyleft peut s’appliquer avec des intensités différentes selon les obligations qu’il impose à ceux qui redistribuent ou modifient le logiciel.

On distingue ainsi le copyleft fort et le copyleft faible.

• Le copyleft fort exige que toute redistribution de l’œuvre, qu’elle soit modifiée ou non, ainsi que des logiciels liés soit effectuée sous la même licence (ou une autre licence à copyleft fort compatible).
  
• Le copyleft faible, lui, impose uniquement que le logiciel lui-même reste sous la même licence, mais n’étend pas cette obligation aux logiciels liés. → Il est souvent utilisé pour les bibliothèques logicielles, afin de permettre une réutilisation plus souple avec des composants sous d’autres licences.
  

Un logiciel lié désigne tout composant assemblé avec le logiciel final lors de l’édition de lien (par exemple une bibliothèque). Ces briques, seules, ont peu d’utilité mais sont nécessaires au bon fonctionnement d’un logiciel complet.

2.3 Compatibilité entre licences libres

Lorsqu’un logiciel combine plusieurs composants libres, il faut vérifier que leurs licences sont compatibles entre elles.

Cette question a été étudiée par Benjamin Jean dans Option libre ( (Ouvre une nouvelle fenêtre) lire l’étude complète), dont est issue la table de compatibilité suivante (page 316).

Si vous publiez une application sous GPL v2 en intégrant un composant sous licence Apache, les droits accordés par Apache sont repris par la GPL v2. Mais certaines obligations spécifiques à Apache, notamment sur les brevets, ne sont pas reprises dans la GPL v2 : cela rend les deux licences incompatibles. Cette incompatibilité a été corrigée dans la GPL v3, désormais compatible avec Apache.

Dans quels cas la compatibilité devient un enjeu ?

La question de la compatibilité se pose surtout lorsque le logiciel est publié sous une licence à copyleft fort (comme la GPL). Dans ce cas, certaines licences deviennent incompatibles, comme l’EPL ou la CeCILL v2.

Une incompatibilité logique peut toutefois être levée en obtenant un accord spécifique du détenteur des droits du composant concerné.

Cela implique souvent un échange avec la communauté du projet, qui peut accorder une exception ou disposer déjà d’une clause prévue à cet effet dans la licence.

Le schéma ci-dessous illustre la zone d’influence des licences à copyleft fort : au-delà de cette zone, les licences deviennent incompatibles.

Par exemple, un composant sous licence EPL ne peut pas être intégré dans un logiciel sous GPL ou CeCILL v2.

Un logiciel peut être composé de briques sous licences à copyleft faible, mais cela demande une certaine rigueur. Chaque composant conserve sa propre licence, qu’il faut respecter individuellement.Lorsque c’est possible, on peut regrouper l’ensemble sous une licence globale compatible, qui garantit tous les droits accordés par les licences d’origine tout en respectant leurs obligations respectives.

3. Recommandations de la DINUM

La doctrine de la DINUM recommande, pour les codes sources publiés par les administrations, d’utiliser en priorité des licences permissives. Elles permettent à tout acteur, public ou privé, de réutiliser librement le code, y compris à des fins commerciales ou dans un logiciel propriétaire. Ce choix favorise la diffusion, la mutualisation et la réutilisation des logiciels produits par l’administration.

Cependant, lorsque la réutilisation commerciale exclusive d’un code public risque de nuire à l’intérêt général, une licence à réciprocité (copyleft) peut être préférable. C’est à chaque administration d’évaluer ce risque selon le contexte.

Exemple : Une mission de service public finance un logiciel A et le met à disposition des autres administrations. Une entreprise privée reprend ce code, l’améliore (logiciel B) et vend un service SaaS basé dessus. L’État paie alors deux fois pour le même service, et les améliorations ne sont pas partagées. Dans ce cas, choisir une licence AGPL est pertinent : elle oblige à redistribuer les modifications sous la même licence, même pour un service SaaS.

Enfin, pour vérifier si un code développé par une administration est communicable, un (Ouvre une nouvelle fenêtre) guide juridique interactif est à disposition.

Vous pouvez également utiliser (Ouvre une nouvelle fenêtre) l’outil de comparaison des licences de l’UE.

4. Responsabilité juridique de l’administration

Lorsqu’une administration publie ou met à disposition un logiciel libre, certaines responsabilités juridiques peuvent être engagées. Elles concernent principalement les produits défectueux et les risques de contrefaçon.

En cas de produit défectueux

La plupart des licences logicielles, qu’elles soient libres ou propriétaires, excluent toute responsabilité pour les dommages directs ou indirects liés à l’usage du logiciel.

En droit français, cette limitation de responsabilité est admise dans les contrats entre professionnels.

En revanche, elle ne peut pas s’appliquer lorsqu’il s’agit d’un contrat avec un consommateur, selon l’ (Ouvre une nouvelle fenêtre) article L.132-1 du Code de la consommation.

Pour les produits défectueux, l’ (Ouvre une nouvelle fenêtre) article 1386-15 du Code civil interdit également d’écarter cette responsabilité par voie contractuelle, sauf entre professionnels.

Dans la pratique, les logiciels diffusés par l’administration s’adressent à des professionnels de l’informatique : l’exclusion de responsabilité pour dommages directs est donc juridiquement admise.

En cas de contrefaçon

Le risque de contrefaçon existe, que le logiciel soit libre ou non, mais la diffusion publique peut accroître ce risque.

Trois cas sont à distinguer :

• Contrefaçon en matière de droit d’auteur : si le logiciel contient un composant dont l’administration ne détient pas les droits, sa responsabilité est engagée. Si le logiciel a été développé dans le cadre d’un marché public, la responsabilité peut être transférée au prestataire en cas de négligence ou de plagiat sur les développements spécifiques, via le rapport de conformité.
• Contrefaçon en matière de marque : une marque est un signe distinctif (logo), un mot ou un groupe de mots servant de reconnaissance légale pour un produit, une société, etc. L’administration doit vérifier que le nom du logiciel ou ses signes distinctifs ne contrefont pas une marque déposée, en particulier concernant le nom du logiciel. En pratique, il est recommandé de publier les logiciels en marque blanche, sans logo ni référence spécifique.
• Contrefaçon en matière de brevet : en France et en Europe, les brevets logiciels ne sont pas reconnus juridiquement, conformément à l’ (Ouvre une nouvelle fenêtre) article 52 de la Convention sur le brevet européen.

Le risque de différends entre l’administration engagée dans une démarche de mutualisation et les acteurs du logiciel libre est très faible et devrait se résoudre à l’amiable tant les objectifs des uns et des autres convergent.