La version web proposée ici constitue une version simplifiée de la fiche technique. Vous pouvez retrouver la version complète, comportant plus de précisions et de références juridiques, en pdf, ici.
Le recours à une licence permet de : Il est donc important d’identifier les licences applicables en fonction de chaque contexte d’application. Il existe différentes licences Open Data, chacune avec ses spécificités.
→formaliser le cadre de réutilisation défini par la loi, renforçant par ce fait la sécurité juridique et la confiance établie entre l’administration et les réutilisateurs ;
→en présence de droits de propriété intellectuelle (notamment droit d’auteur), d’accorder une licence à l’égard des droits de propriété intellectuelle détenus aux bénéfices des réutilisateurs et dans le respect de la loi.
Les licences sont des contrats de cession non exclusive de droits de propriété intellectuelle, consentis pour le monde entier et toute la durée des droits, par lesquels un titulaire de droit autorise gracieusement un licencié à copier, modifier et distribuer sa création. Reposant sur une assiette plus large que le seul droit d’auteur, ces licences incluent également le droit des contrats et le droit sui generis des bases de données.
Le choix de la licence initiale est fondamental : en termes de marketing afin d’interpeller des communautés déjà existantes, en termes stratégiques, car le modèle économique développé autour du logiciel peut en dépendre, et enfin en termes juridiques puisque l’ouverture du projet peut avoir pour conséquence de provoquer des contributions suite auxquels le titulaire initial ne pourra plus unilatéralement changer de licence (sauf à ce faire céder l'ensemble des droits des autres contributeurs). Une licence adaptée au logiciel et aux attentes de l'Acheteur permettra de faciliter la structuration de la collaboration future, cette dernière n’étant alors concentrée que sur l’optimisation et la mutualisation dans le développement et l’exploitation du logiciel (les licences assurant, elles, les cessions de droits de propriété intellectuelle nécessaires à l’évolution du projet).
S'il peut être tentant de s’orienter vers la rédaction d’une licence spécifique, particulièrement lorsque le logiciel est important, il est par principe déconseillé de se lancer dans cet exercice risqué en termes juridiques (que la licence contienne des failles non existantes), de communication et de mise à jour. À l'inverse, le choix d'une licence existante permet de capitaliser sur les usages qui en sont déjà fait. Par ailleurs, l'utilisation d'une telle licence au sein de l'administration imposerait de suivre la procédure d'homologation prévue à l’article D.323-2-2 du CRPA. Ce choix est généralement complexe, savant mélange de stratégie et de tactique qui doit intégrer les contraintes issues de l’utilisation de composants Open Source au sein du logiciel. Il est nécessaire d’adopter la licence la plus adaptée à son projet en se concentrant sur ses obligations, son étendue, son élément déclencheur et éventuellement la compatibilité qu’elle organise avec les licences des autres logiciels proches. L’existence de centaines de licences laisse présager un nombre tout aussi grand de situations particulières les ayant justifiées, il n’est donc en rien étonnant de personnaliser la licence pour s’assurer qu’elle réponde en tout point aux objectifs du projet : on parle d’ « interprétation » lorsqu’il s’agit de préciser la licence pour lui donner une portée précise qui tiendra les parties et le juge ; on parle d' « exception » lorsqu’il s’agit de déroger aux termes initiaux avec pour effet de rendre la licence finale plus ou moins contraignante.
Références :
Les éléments structurants dans le choix d’une licence
Il existe des centaines de licences libres, toutes harmonisées autour des définitions du logiciel libre et de l’Open Source Définition. Au-delà des aspects politiques, philosophiques ou communautaires qui peuvent fortement influencer le choix d’une licence, les considérations juridiques qui suivent doivent être prises en compte :
obligations : ce sont ces obligations (de faire, ne pas faire, de donner) sont ce qui distingue le plus les licences les unes des autres (licences de brevets, clause de paternité spécifique, etc.). L’obligation la plus représentative est la clause « copyleft » qui impose le maintien de la licence sur le logiciel et ses dérivés ;
L'étendue permet de déterminer dans quelle mesure les créations qui lui sont rattachées (une œuvre dérivée par exemple) subissent les contraintes de la licence. Plusieurs gradations existent :
l’élément déclencheur : l'acte qui emporte – généralement la distribution d’une copie du logiciel ou l’interaction par le réseau avec le logiciel – les effets contraignants de la licence (avant lequel le licencié est libre de ses actes).
La compatibilité : implique tous les mécanismes mis en œuvre dans les licences libres afin de permettre la favoriser la combinaison de logiciels libres entre eux.
Les obligations héritées des composants Open Source utilisés par le projet
L’utilisation d’une licence traduit une exploitation choisie par le ou les titulaires de droits et, mis à part les cas où l’auteur (ou la licence qu’il utilise) le permet expressément, il est impossible de remplacer la licence d’un composant.
Ainsi, toute personne qui développe à partir de composants logiciels libres préexistants doit nécessairement veiller à ce que la licence finale utilisée pour distribuer la solution logicielle (et qui s’ajoute ainsi aux licences présentes), voire l’ensemble de licences utilisé à cette fin, respecte l’ensemble des licences des composants intégrés et inversement (que les composants utilisés soient bien diffusés selon une licence permettant in fine la distribution du tout sous la licence du projet).
Exemples de choix de licences
Une licence type Apache 2.0 (APL 2.0)
Très utilisée, la licence apache conjugue un caractère très ouvert et permissif avec des engagements minimums qui justifient la confiance accordée à la licence par le secteur industriel. La licence Apache 2.0 ne prévoit pas de clause de partage à l’identique (copyleft) qui imposerait de mettre à disposition chaque version modifiée du programme sous la même licence. Chacune peut ainsi être distribuée par le licencié sous licence propriétaire ou sous une autre licence libre.
Un tel choix mettrait ainsi en avant la collaboration entre les partenaires du projet (qui mutualiserait les développements finalisés selon ces termes tout en permettant une réutilisation non libre des mêmes développements en dehors du projet).
Références :
Une licence type GNU Affero GPL v3.0 (avec autorisation de modules non Open Source)
Licence Copyleft (imposant un partage sous la même licence de toutes les améliorations apportées), la licence GNU Affero GPL 3.0 est aussi spécifique en ce que la simple mise à disposition à des tiers des fonctionnalités de la plateforme (l’utilisation par le réseau) impose à l’hébergeur de rendre accessible toutes les modifications apportées à la plateforme.
Le choix d’une telle licence sur le cœur de la plateforme pourrait être un signal fort quant au caractère ouvert et, à terme, communautaire du projet (au-delà des partenaires initiaux).
Néanmoins, afin d’être adapté à l’architecture modulaire souhaitée du logiciel (permettant d’intégrer des modules non libres sous réserve d’une documentation des spécifications permettant à terme leur remplacement), un tel choix pourrait être assorti d’une exception à la licence autorisant spécifiquement la liaison avec de tels modules.
Références :
Cette fiche technique est une publication réalisée collectivement par le cabinet Vercken & Gaullier et le cabinet inno³ pour le compte du Labo Société Numérique (labo.societenumerique.gouv.fr). Destinée à favoriser l'émergence d'une doctrine juridique commune en matière de communs produits ou soutenus par l'administration, elle s'adresse à la fois aux acteurs porteurs de communs ainsi qu'aux personnes en charge d'accompagner ces démarches. Destinée à être mise à jour en fonction notamment des évolutions législatives et jurisprudentielles et à être complétée en fonction des contributions et remarques, elle ne constitue pas un conseil juridique et ne se substitue en aucun cas aux avis qu'il est nécessaire de prendre auprès des personnes compétentes au sein de chaque service. Enfin, n'hésitez pas à consulter le site http://labo.societenumerique.gouv.fr afin de prendre connaissance des dernières versions de ces documents, de consulter toute autre ressource à destination d’acteurs publics souhaitant mobiliser le potentiel des communs numériques dans leur stratégie ou encore contribuer à cette dynamique.
Doctrine juridique appliquée aux communs numériques développés sous l’impulsion ou avec la participation d’une personne publique
Fiche technique 5.1 : Les licences libres
La version web proposée ici constitue une version simplifiée de la fiche technique. Vous pouvez retrouver la version complète, comportant plus de précisions et de références juridiques, en pdf, ici.
Le recours à une licence permet de : Il est donc important d’identifier les licences applicables en fonction de chaque contexte d’application. Il existe différentes licences Open Data, chacune avec ses spécificités.
→formaliser le cadre de réutilisation défini par la loi, renforçant par ce fait la sécurité juridique et la confiance établie entre l’administration et les réutilisateurs ;
→en présence de droits de propriété intellectuelle (notamment droit d’auteur), d’accorder une licence à l’égard des droits de propriété intellectuelle détenus aux bénéfices des réutilisateurs et dans le respect de la loi.
Les licences sont des contrats de cession non exclusive de droits de propriété intellectuelle, consentis pour le monde entier et toute la durée des droits, par lesquels un titulaire de droit autorise gracieusement un licencié à copier, modifier et distribuer sa création. Reposant sur une assiette plus large que le seul droit d’auteur, ces licences incluent également le droit des contrats et le droit sui generis des bases de données.
Le choix de la licence initiale est fondamental : en termes de marketing afin d’interpeller des communautés déjà existantes, en termes stratégiques, car le modèle économique développé autour du logiciel peut en dépendre, et enfin en termes juridiques puisque l’ouverture du projet peut avoir pour conséquence de provoquer des contributions suite auxquels le titulaire initial ne pourra plus unilatéralement changer de licence (sauf à ce faire céder l'ensemble des droits des autres contributeurs). Une licence adaptée au logiciel et aux attentes de l'Acheteur permettra de faciliter la structuration de la collaboration future, cette dernière n’étant alors concentrée que sur l’optimisation et la mutualisation dans le développement et l’exploitation du logiciel (les licences assurant, elles, les cessions de droits de propriété intellectuelle nécessaires à l’évolution du projet).
S'il peut être tentant de s’orienter vers la rédaction d’une licence spécifique, particulièrement lorsque le logiciel est important, il est par principe déconseillé de se lancer dans cet exercice risqué en termes juridiques (que la licence contienne des failles non existantes), de communication et de mise à jour. À l'inverse, le choix d'une licence existante permet de capitaliser sur les usages qui en sont déjà fait. Par ailleurs, l'utilisation d'une telle licence au sein de l'administration imposerait de suivre la procédure d'homologation prévue à l’article D.323-2-2 du CRPA. Ce choix est généralement complexe, savant mélange de stratégie et de tactique qui doit intégrer les contraintes issues de l’utilisation de composants Open Source au sein du logiciel. Il est nécessaire d’adopter la licence la plus adaptée à son projet en se concentrant sur ses obligations, son étendue, son élément déclencheur et éventuellement la compatibilité qu’elle organise avec les licences des autres logiciels proches. L’existence de centaines de licences laisse présager un nombre tout aussi grand de situations particulières les ayant justifiées, il n’est donc en rien étonnant de personnaliser la licence pour s’assurer qu’elle réponde en tout point aux objectifs du projet : on parle d’ « interprétation » lorsqu’il s’agit de préciser la licence pour lui donner une portée précise qui tiendra les parties et le juge ; on parle d' « exception » lorsqu’il s’agit de déroger aux termes initiaux avec pour effet de rendre la licence finale plus ou moins contraignante.
Références :
Les éléments structurants dans le choix d’une licence
Il existe des centaines de licences libres, toutes harmonisées autour des définitions du logiciel libre et de l’Open Source Définition. Au-delà des aspects politiques, philosophiques ou communautaires qui peuvent fortement influencer le choix d’une licence, les considérations juridiques qui suivent doivent être prises en compte :
obligations : ce sont ces obligations (de faire, ne pas faire, de donner) sont ce qui distingue le plus les licences les unes des autres (licences de brevets, clause de paternité spécifique, etc.). L’obligation la plus représentative est la clause « copyleft » qui impose le maintien de la licence sur le logiciel et ses dérivés ;
L'étendue permet de déterminer dans quelle mesure les créations qui lui sont rattachées (une œuvre dérivée par exemple) subissent les contraintes de la licence. Plusieurs gradations existent :
l’élément déclencheur : l'acte qui emporte – généralement la distribution d’une copie du logiciel ou l’interaction par le réseau avec le logiciel – les effets contraignants de la licence (avant lequel le licencié est libre de ses actes).
La compatibilité : implique tous les mécanismes mis en œuvre dans les licences libres afin de permettre la favoriser la combinaison de logiciels libres entre eux.
Les obligations héritées des composants Open Source utilisés par le projet
L’utilisation d’une licence traduit une exploitation choisie par le ou les titulaires de droits et, mis à part les cas où l’auteur (ou la licence qu’il utilise) le permet expressément, il est impossible de remplacer la licence d’un composant.
Ainsi, toute personne qui développe à partir de composants logiciels libres préexistants doit nécessairement veiller à ce que la licence finale utilisée pour distribuer la solution logicielle (et qui s’ajoute ainsi aux licences présentes), voire l’ensemble de licences utilisé à cette fin, respecte l’ensemble des licences des composants intégrés et inversement (que les composants utilisés soient bien diffusés selon une licence permettant in fine la distribution du tout sous la licence du projet).
Exemples de choix de licences
Une licence type Apache 2.0 (APL 2.0)
Très utilisée, la licence apache conjugue un caractère très ouvert et permissif avec des engagements minimums qui justifient la confiance accordée à la licence par le secteur industriel. La licence Apache 2.0 ne prévoit pas de clause de partage à l’identique (copyleft) qui imposerait de mettre à disposition chaque version modifiée du programme sous la même licence. Chacune peut ainsi être distribuée par le licencié sous licence propriétaire ou sous une autre licence libre.
Un tel choix mettrait ainsi en avant la collaboration entre les partenaires du projet (qui mutualiserait les développements finalisés selon ces termes tout en permettant une réutilisation non libre des mêmes développements en dehors du projet).
Références :
Une licence type GNU Affero GPL v3.0 (avec autorisation de modules non Open Source)
Licence Copyleft (imposant un partage sous la même licence de toutes les améliorations apportées), la licence GNU Affero GPL 3.0 est aussi spécifique en ce que la simple mise à disposition à des tiers des fonctionnalités de la plateforme (l’utilisation par le réseau) impose à l’hébergeur de rendre accessible toutes les modifications apportées à la plateforme.
Le choix d’une telle licence sur le cœur de la plateforme pourrait être un signal fort quant au caractère ouvert et, à terme, communautaire du projet (au-delà des partenaires initiaux).
Néanmoins, afin d’être adapté à l’architecture modulaire souhaitée du logiciel (permettant d’intégrer des modules non libres sous réserve d’une documentation des spécifications permettant à terme leur remplacement), un tel choix pourrait être assorti d’une exception à la licence autorisant spécifiquement la liaison avec de tels modules.
Références :
Cette fiche technique est une publication réalisée collectivement par le cabinet Vercken & Gaullier et le cabinet inno³ pour le compte du Labo Société Numérique (labo.societenumerique.gouv.fr). Destinée à favoriser l'émergence d'une doctrine juridique commune en matière de communs produits ou soutenus par l'administration, elle s'adresse à la fois aux acteurs porteurs de communs ainsi qu'aux personnes en charge d'accompagner ces démarches. Destinée à être mise à jour en fonction notamment des évolutions législatives et jurisprudentielles et à être complétée en fonction des contributions et remarques, elle ne constitue pas un conseil juridique et ne se substitue en aucun cas aux avis qu'il est nécessaire de prendre auprès des personnes compétentes au sein de chaque service. Enfin, n'hésitez pas à consulter le site http://labo.societenumerique.gouv.fr afin de prendre connaissance des dernières versions de ces documents, de consulter toute autre ressource à destination d’acteurs publics souhaitant mobiliser le potentiel des communs numériques dans leur stratégie ou encore contribuer à cette dynamique.
