Garantir l’autonomie des utilisateurs sur le long terme

(le terme « fondation » devrait être partout remplacé par « association »)

La question des licences n’est pas une question technique réservée aux juristes. C’est une question politique au sens noble du terme : elle détermine qui contrôle les outils numériques, qui peut les modifier, qui peut les partager, et surtout qui peut empêcher les autres de le faire. Le choix d’une licence est le premier acte concret par lequel une fondation traduit ses valeurs en garanties juridiquement opposables.

Ce document expose la politique de licences de la Fondation Européenne pour l’Autonomie Numérique : les raisons de nos choix, les risques contre lesquels nous nous protégeons et les mécanismes que nous mettons en place pour garantir que les utilisateurs de logiciels hébergés par la fondation ne seront jamais contraints de migrer, de payer pour continuer à utiliser ce qu’ils utilisent déjà, ni de renoncer à leur autonomie.

La fondation fonde sa définition du logiciel libre sur les quatre libertés telles qu’elles ont été formulées dès 1986 par le projet GNU et qui font l’objet d’un consensus mondial depuis près de quarante ans :

• Liberté 0 : la liberté d’utiliser le logiciel, pour quelque usage que ce soit.
• Liberté 1 : la liberté d’étudier le fonctionnement du logiciel et de l’adapter à ses besoins. L’accès au code source en est une condition préalable.
• Liberté 2 : la liberté de redistribuer des copies du logiciel, pour aider son prochain.
• Liberté 3 : la liberté d’améliorer le logiciel et de publier ses améliorations, pour que l’ensemble de la communauté en bénéficie. L’accès au code source en est une condition préalable.

Un logiciel qui respecte ces quatre libertés est un logiciel libre. Un logiciel qui n’en respecte pas au moins une est un logiciel propriétaire. Il n’y a pas de catégorie intermédiaire.

Ces quatre libertés sont des principes universels, nés de la pratique et de la réflexion de communautés de développeurs et d’utilisateurs du monde entier. Elles ne sont la propriété d’aucune organisation, d’aucun État, d’aucun système juridique. Elles sont un bien commun intellectuel.

Deux organisations sont couramment citées comme garantes de la définition du logiciel libre : la Free Software Foundation (FSF), fondation américaine créée en 1985, et l’Open Source Initiative (OSI), organisation de droit californien fondée en 1998. Toutes deux maintiennent des listes de licences qu’elles considèrent conformes à leurs définitions respectives.

La fondation reconnaît le rôle historique de ces deux organisations. Mais elle ne fait dépendre sa politique de licences d’aucune d’entre elles, pour trois raisons.

La première est l’autonomie juridique. L’OSI est une “California public-benefit nonprofit corporation”. La FSF est une organisation à but non lucratif de droit américain basée à Boston. Leurs définitions, leurs processus d’approbation et leurs décisions sont régis par le droit américain. Or, la fondation est une AISBL de droit belge, ses projets sont destinés en premier lieu aux citoyens, aux administrations et aux entreprises européennes, et ses licences sont interprétées par les tribunaux européens selon le droit européen. Fonder notre politique sur l’approbation d’une organisation soumise à un ordre juridique étranger créerait une dépendance incompatible avec notre mission d’autonomie.

La deuxième est la stabilité. L’OSI a été critiquée à de multiples reprises pour ses processus de décision. Son cofondateur Bruce Perens a démissionné en 2020 en désaccord avec l’approbation de certaines licences. Sa définition de l’intelligence artificielle “open source” publiée en 2024 a été largement contestée, y compris par Perens lui-même qui l’a qualifiée de “défaillante”, par des développeurs Debian qui ont remis en cause sa conformité avec les principes fondamentaux du logiciel libre, et par des experts qui ont noté que le conseil d’administration de l’OSI ne comptait pas un seul membre revendiquant une expertise en intelligence artificielle.

La troisième est la cohérence avec le cadre européen. L’Union européenne dispose désormais de ses propres instruments juridiques pour le logiciel libre. Le règlement (UE) 2024/903, dit Interoperable Europe Act, reconnaît explicitement le rôle du logiciel libre et cite l’EUPL v1.2 comme exemple de licence standard. La directive 2009/24/CE fournit le cadre d’interprétation du droit d’auteur applicable au logiciel dans l’Union. Le Joinup Licensing Assistant de la Commission européenne permet la comparaison de plus de cinquante licences. L’Europe a les outils juridiques pour définir elle-même ce qu’est un logiciel libre. La fondation s’inscrit dans ce cadre.

La fondation définit comme libre tout logiciel distribué sous une licence qui garantit effectivement les quatre libertés fondamentales à toute personne qui reçoit une copie du logiciel, et dont les conditions remplissent les critères suivants :

1. Redistribution libre : la licence ne restreint pas la vente ou le don du logiciel comme composant d’une distribution.
2. Accès au code source : le code source doit être accessible et la licence doit permettre la distribution sous forme de code source.
3. Travaux dérivés : la licence doit permettre les modifications et les travaux dérivés, et doit permettre leur distribution.
4. Intégrité du code source de l’auteur : la licence peut exiger que les modifications soient distribuées sous forme de correctifs.
5. Absence de discrimination envers des personnes ou des groupes.
6. Absence de discrimination envers des domaines d’activité : la licence ne doit pas interdire l’usage commercial, la recherche ou tout autre domaine.
7. Distribution de la licence : les droits attachés au logiciel s’appliquent à quiconque reçoit le logiciel, sans nécessité d’une licence supplémentaire.
8. Neutralité technologique : la licence ne doit pas dépendre d’une technologie ou d’une interface particulière.

Ces critères sont substantiellement identiques à ceux qui font consensus dans la communauté mondiale du logiciel libre depuis les Debian Free Software Guidelines (1997). La fondation les adopte en tant que principes autonomes, interprétés à la lumière du droit européen. Son comité des licences évalue les licences à cette aune ; ses décisions sont souveraines et ne sont pas subordonnées à l’approbation d’une organisation tierce.

Un logiciel peut être libre aujourd’hui et ne plus l’être demain. L’autonomie ne se décrète pas. Elle se construit par des choix juridiques, statutaires et techniques qui rendent la capture impossible, pas simplement improbable. Notre politique de licences est conçue pour bloquer cinq mécanismes distincts de capture.

Le modèle “open core” : un coeur libre est maintenu dans un état volontairement limité pour pousser les utilisateurs vers une version propriétaire payante.

Le changement de licence : un éditeur qui détient l’intégralité du copyright, souvent grâce à un CLA asymétrique, relicencie unilatéralement le code. Du jour au lendemain, un logiciel libre devient propriétaire ou “source available”.

La migration forcée : les anciennes versions sont rendues inutilisables par l’arrêt du support de sécurité, des changements d’API incompatibles, la complexification délibérée des mises à jour, ou l’obsolescence programmée des formats de données.

Le verrouillage par le service : le logiciel n’est proposé qu’en SaaS. L’utilisateur ne contrôle ni ses données ni la possibilité de faire fonctionner le logiciel de manière autonome.

Le verrouillage par les formats : les données sont stockées dans des formats propriétaires ou mal documentés. Même si le logiciel est libre, les données sont prisonnières.

L’histoire d’Odoo illustre comment ces mécanismes s’enchaînent.

En 2005, Fabien Pinckaers crée TinyERP sous GPLv2. En 2009, devenu OpenERP, le logiciel passe sous AGPLv3. La communauté grandit. Des centaines d’entreprises investissent dans le développement de modules, forment leurs employés, migrent leurs données.

En 2015, le logiciel est renommé Odoo et la licence du coeur passe de l’AGPLv3 à la LGPLv3 : il devient légalement possible de construire des modules propriétaires au-dessus du coeur libre. Odoo SA crée alors “Odoo Enterprise”, une version payante sous licence propriétaire. Les années suivantes, des fonctionnalités migrent de la version communautaire vers Enterprise. Les migrations entre versions majeures deviennent si complexes qu’elles nécessitent des prestataires spécialisés, et le service de migration officiel n’est disponible que pour les abonnés Enterprise. Les utilisateurs de la version communautaire doivent recourir à OpenUpgrade, un outil tiers maintenu par l’OCA avec des moyens limités.

Le résultat : les utilisateurs qui ont investi des années dans Odoo se trouvent face à un choix entre payer un abonnement croissant, rester sur une version de plus en plus limitée, ou migrer vers un autre système. L’autonomie promise par le logiciel libre a été vidée de sa substance.

Ce scénario n’est pas isolé. MongoDB est passé de l’AGPL à la SSPL, Redis a abandonné sa licence BSD pour une licence propriétaire, Elastic a quitté Apache 2.0 pour la SSPL et l’Elastic License. À chaque fois, le même mécanisme : une entreprise détenant le copyright via un CLA relicencie le code, piégeant la communauté.

La fondation adopte la Licence Publique de l’Union Européenne, version 1.2 (EUPL v1.2) comme licence par défaut. Ce choix est la conséquence directe de notre identité et de notre refus de toute dépendance à un cadre juridique extra-européen.

L’EUPL est la première licence de logiciel libre publiée par un organe gouvernemental international. Rédigée par la Commission européenne sur la base d’une étude du Centre de Recherches Informatique et Droit de l’Université de Namur (CRID/FUNDP, 2006), elle existe en version authentique dans les 23 langues officielles de l’Union, toutes les versions linguistiques ayant la même valeur juridique. Un développeur à Athènes peut lire la licence dans sa langue. Un juriste à Helsinki peut l’analyser dans la sienne. Un tribunal à Lisbonne peut l’interpréter sans traduction.

L’EUPL est régie par le droit de l’État membre où le donneur de licence réside. Pour la fondation, siège à Bruxelles, ce sera le droit belge. Cette prévisibilité juridique est un atout pour les administrations publiques, qui ont besoin de certitudes avant d’engager des migrations vers des solutions libres.

Par contraste, les licences GNU (GPL, AGPL, LGPL) ont été rédigées dans un contexte de copyright law américain. La notion de “derivative work” ne se superpose pas exactement aux notions d’oeuvre dérivée en droit continental européen. La directive 2009/24/CE sur la protection juridique des programmes d’ordinateur pose un cadre différent, notamment en matière d’interopérabilité. L’EUPL a été conçue dans ce cadre.

L’EUPL v1.2 impose un copyleft fort : toute personne qui distribue le logiciel ou un travail dérivé doit le faire sous les mêmes conditions, en incluant le code source. Sa définition de la “communication” inclut la mise à disposition des fonctionnalités essentielles du logiciel à toute personne par voie électronique, couvrant explicitement le SaaS, le cloud et l’accès distant.

C’est un point essentiel. La GPL classique ne couvre que la distribution de copies, laissant une faille pour les services en ligne. L’EUPL la ferme, comme le fait l’AGPL, mais dans un cadre juridique européen. Quiconque modifie le logiciel et l’offre en tant que service doit partager le code source de ses modifications.

L’objection la plus fréquente contre les licences copyleft fortes est leur effet prétendument “contaminant”. L’EUPL y répond par le droit européen lui-même.

La directive 2009/24/CE, en ses considérants 10 et 15, établit que la reproduction du code nécessaire à l’interopérabilité entre deux programmes indépendants est autorisée sans constituer une contrefaçon. L’EUPL intègre ce principe : les interfaces, les API et les structures de données couvertes peuvent être librement copiées et réutilisées pour implémenter une liaison avec tout autre composant indépendant, sans que la licence de ce composant soit affectée.

Une PME européenne peut donc développer un module complémentaire communiquant avec un logiciel sous EUPL via ses API publiques, sans devoir ouvrir le code de son module. Le copyleft protège le logiciel et ses dérivés réels, pas tout ce qui y touche. Le droit européen pose cette distinction avec plus de netteté que la tradition juridique américaine, où les frontières entre “derivative work” et “mere aggregation” alimentent des débats depuis des décennies. L’avocat allemand Niklas Plutte a synthétisé cette propriété en qualifiant l’EUPL de “licence copyleft interopérable”.

L’EUPL v1.2 inclut une clause de compatibilité permettant d’intégrer du code EUPL dans des projets sous d’autres licences copyleft : GPLv2, GPLv3, AGPLv3, MPL 2.0, LGPL v2.1 et v3, EPL, CeCILL v2.0 et v2.1, CC-BY-SA 3.0.

Cette compatibilité est “aval” : du code EUPL peut être intégré dans un projet GPL, et le projet résultant sera distribué sous GPL. Le projet original reste sous EUPL. La fondation ne crée pas un îlot juridique isolé : elle s’inscrit dans le tissu du logiciel libre.

La compatibilité est unilatérale : du code GPL ne peut pas être intégré dans un projet EUPL, car la GPL ne reconnaît la compatibilité qu’avec les licences évaluées par la FSF. Ce n’est pas un obstacle : les projets existants sous GPL ou AGPL conservent leur licence d’origine au sein de la fondation.

L’EUPL fait partie d’un écosystème juridique européen en construction. Le règlement (UE) 2024/903 (Interoperable Europe Act) la cite explicitement comme licence standard pour les logiciels libres du secteur public et impose le partage des solutions d’interopérabilité, y compris le code source. Le règlement (UE) 2024/2847 (Cyber Resilience Act) et le règlement (UE) 2024/1689 (AI Act) contiennent des dispositions reconnaissant la situation particulière du logiciel libre.

En choisissant l’EUPL, les projets de la fondation sont nativement conformes aux exigences européennes d’interopérabilité. Leurs utilisateurs bénéficient d’une sécurité juridique fondée sur leur propre droit.

Tout nouveau projet créé sous l’égide de la fondation est publié sous EUPL v1.2.

La fondation héberge des projets existants sous les licences suivantes, à condition qu’ils respectent les cinq garanties fondatrices. Le comité des licences vérifie la conformité avec les critères de la section 1.3.

L’AGPL v3 est acceptée : copyleft forte avec clause réseau, utilisée par Nextcloud, les modules OCA et de nombreux projets web.

La GPL v3 est acceptée pour les logiciels qui ne sont pas principalement utilisés via un réseau. Pour les applications web, la fondation recommandera une migration vers l’EUPL ou l’AGPL lors d’une version majeure.

La CeCILL v2.1 est acceptée : licence copyleft française, compatible avec la GPL, ancrée dans le droit continental, utilisée par l’INRIA et le CNRS.

La LiLiQ-R+ (Licence Libre du Québec - Réciprocité forte) est acceptée : elle témoigne du besoin de licences ancrées dans le droit local au-delà de l’Europe. Elle figure dans la liste de compatibilité de l’EUPL v1.2.

La MPL 2.0 est acceptée pour les bibliothèques et les implémentations de référence des standards d’interopérabilité. Son copyleft au niveau du fichier maximise l’adoption des standards.

La LGPL v3 est acceptée uniquement pour les bibliothèques techniques. Aucune application complète hébergée par la fondation ne sera sous LGPL.

Les licences permissives (MIT, BSD, Apache 2.0) ne sont pas acceptées : elles permettent la fermeture du code et ne protègent pas contre la capture. Un projet sous licence permissive peut rejoindre la fondation à condition de passer sous EUPL ou sous une autre licence acceptée.

Les licences “source available” (SSPL, BSL, Elastic License, Commons Clause) ne remplissent pas les critères de la section 1.3 et ne sont pas acceptées.

Les licences propriétaires, y compris “freemium” ou “open core”, ne sont pas acceptées.

Les licences avec restriction géographique ou d’usage ne sont pas acceptées.

Un Contributor License Agreement (CLA) classique transfère l’intégralité du copyright à l’éditeur, lui permettant de relicencier le code sous n’importe quelle licence. C’est le mécanisme qui a permis à MongoDB, Redis et Elastic de piéger leurs communautés.

La fondation interdit les CLA qui permettent un relicenciement sous licence non libre. Deux mécanismes sont possibles :

Le Developer Certificate of Origin (DCO), identique à celui du noyau Linux : le contributeur certifie qu’il a le droit de contribuer et accepte la licence du projet. Il conserve son copyright. Personne ne peut relicencier son code sans son accord.

Le transfert de copyright à la fondation, et uniquement à la fondation, pour les projets nécessitant une gestion centralisée (par exemple pour faire respecter la licence en justice). Les statuts de la fondation stipulent alors que le code détenu ne peut être publié que sous une licence figurant dans la liste des licences acceptées. Cette obligation statutaire ne peut être modifiée qu’à l’unanimité de l’assemblée générale.

En aucun cas le copyright ne peut être transféré à un éditeur commercial ou à toute entité non liée par les statuts de la fondation.

Les statuts de la fondation contiennent une clause de non-relicenciement :

“Aucun projet hébergé par la fondation ne peut être relicencié sous une licence qui ne figure pas dans la liste des licences acceptées par la politique de licences de la fondation. Tout changement de licence requiert l’approbation des deux tiers de l’assemblée générale et ne peut en aucun cas conduire à l’adoption d’une licence qui ne garantisse pas les quatre libertés fondamentales telles que définies par la présente politique. La présente clause ne peut être modifiée que par un vote unanime de l’assemblée générale.”

Le verrou de l’unanimité rend le relicenciement vers une licence non libre pratiquement impossible, quelle que soit l’évolution de la composition de la fondation.

La fondation inscrit dans sa politique un principe simple : tout utilisateur a le droit de rester sur la version qu’il utilise.

Les versions majeures des logiciels hébergés bénéficient d’un support de sécurité garanti pendant vingt ans après la date de publication, financé par les cotisations des membres. Ce support comprend les correctifs de sécurité critiques et les corrections de bogues bloquants.

Vingt ans n’est pas un chiffre arbitraire. C’est l’horizon de planification des administrations publiques et des établissements d’enseignement, qui sont les premiers utilisateurs visés par la fondation. Une administration qui déploie un logiciel dans ses services doit pouvoir garantir à ses agents et à ses usagers que ce logiciel fonctionnera de manière sécurisée sur la durée d’un cycle budgétaire complet, d’un mandat politique, d’une génération d’élèves. Cinq ans, c’est l’horizon d’un projet. Dix ans, c’est l’horizon d’un plan stratégique. Vingt ans, c’est l’horizon d’une infrastructure. Les logiciels de la fondation ont vocation à devenir des infrastructures.

Ce support de vingt ans est un engagement de la fondation, financé collectivement par ses membres. Il est mutualisé : le coût de la maintenance de sécurité d’une version ancienne est réparti entre tous les membres, pas facturé aux seuls utilisateurs de cette version. C’est la logique même d’une fondation : mutualiser les coûts pour garantir les droits de tous.

L’utilisateur qui ne souhaite pas migrer vers une nouvelle version majeure peut continuer à utiliser sa version actuelle avec l’assurance qu’elle restera sécurisée. Il n’est pas poussé vers la sortie par l’obsolescence programmée. La migration reste un choix, jamais une contrainte.

Tout projet hébergé doit respecter les règles suivantes :

Les formats de stockage sont documentés publiquement, sous licence CC-BY-SA 4.0 ou CC0, avec suffisamment de détail pour qu’un développeur tiers puisse écrire un outil de lecture et d’écriture sans avoir accès au code du projet.

Toute nouvelle version majeure lit les données de la version précédente. Un outil de migration libre et gratuit est fourni pour chaque transition de version.

Les formats de données privilégient les standards ouverts (ODF, JSON, XML, CSV, SQL standard, etc.).

L’export complet des données dans un format ouvert et documenté est possible à tout moment, sans restriction et sans coût.

Tout le code d’un projet hébergé par la fondation est sous licence libre, sans exception. Il ne peut pas exister de version “Enterprise”, “Professional” ou “Premium” propriétaire. Un projet maintenant une version propriétaire parallèle doit, avant son admission, soit ouvrir l’intégralité de son code, soit séparer clairement les composants libres (pleinement fonctionnels de manière autonome) des composants propriétaires (qui restent hors de la fondation).

Si un contributeur majeur cesse ses activités ou décide de ne plus contribuer, la fondation dispose des droits juridiques nécessaires (DCO ou transfert de copyright) pour assurer la continuité du projet. Le code ne disparaît pas. La communauté peut le reprendre, le maintenir, le développer. Contrairement aux projets contrôlés par une entreprise unique (où un changement de licence force un fork coûteux et déstabilisant, comme OpenSearch après Elastic ou Valkey après Redis), la fondation rend ce scénario structurellement impossible.

La fondation veut faire prospérer un écosystème de PME européennes autour des logiciels qu’elle héberge : hébergement, support, intégration, formation, développement sur mesure, modules complémentaires.

L’interopérabilité de l’EUPL, fondée sur la directive 2009/24/CE (section 3.3), permet à ces PME de développer des modules communiquant avec les logiciels de la fondation via des API ouvertes, sans obligation de publier le code de ces modules sous la même licence. Leur modèle économique repose sur l’expertise, le service et la connaissance du métier du client, pas sur le verrouillage.

Un acteur de très grande taille pourrait prendre le code libre, développer une offre SaaS gratuite ou à bas prix pour étouffer les PME locales, puis monétiser sa position dominante.

Le copyleft de l’EUPL est la meilleure protection : tout acteur qui met le logiciel à disposition, y compris en tant que service, doit publier le code source de ses modifications et respecter la licence. Les investissements massifs d’un acteur dominant profitent à l’ensemble de l’écosystème. Une licence permissive laisserait le champ libre à cette prédation : c’est ce qui a poussé MongoDB, Redis et Elastic à abandonner les licences libres par désespoir. La fondation refuse de créer les conditions de ce cercle vicieux.

La documentation technique (guides, tutoriels, documentation des API) est publiée sous CC-BY-SA 4.0, cohérente avec l’esprit copyleft de l’EUPL et compatible avec celle-ci.

Les spécifications des standards d’interopérabilité sont publiées sous CC-BY-SA 4.0. Les implémentations de référence sous MPL 2.0 ou EUPL v1.2 selon le contexte, afin de maximiser l’adoption des standards.

Les bases de données sont publiées sous ODbL v1.0, conformément aux pratiques établies par OpenStreetMap.

La fondation crée un comité des licences de trois à cinq membres nommés par le conseil d’administration, dont au moins un juriste spécialisé en propriété intellectuelle formé au droit continental européen, et au moins un développeur expérimenté dans la gestion de projets libres.

Le comité évalue les licences à l’aune des critères de la section 1.3, audite les projets candidats à l’hébergement, conseille les projets hébergés, surveille l’évolution du cadre juridique et propose des mises à jour de la présente politique. Ses décisions sont souveraines et ne sont subordonnées à l’approbation d’aucune organisation tierce. Il peut consulter les travaux de toute organisation qu’il juge pertinente.

Tout projet candidat fait l’objet d’un audit vérifiant que sa licence figure dans la liste des licences acceptées ou remplit les critères de la section 1.3, qu’aucun CLA asymétrique n’est en place, que le copyright est compatible avec les règles de la fondation, qu’aucune dépendance propriétaire n’est requise, et que les formats de données sont ouverts et documentés.

La politique est révisée tous les trois ans. Toute modification requiert les deux tiers du conseil d’administration. L’ajout de licences à la liste des licences refusées peut être décidé à la majorité simple. L’ajout à la liste des licences acceptées requiert les deux tiers.

1. Les quatre libertés sont notre boussole. La fondation définit le logiciel libre à partir des quatre libertés fondamentales, interprétées à la lumière du droit européen. Elle ne délègue cette définition à aucune organisation tierce.
2. L’EUPL v1.2 est la licence par défaut. Européenne, multilingue, copyleft forte, interopérable, régie par le droit européen, adossée au cadre réglementaire de l’Interoperable Europe Act.
3. Le copyleft est la condition de l’autonomie. Seules les licences copyleft sont acceptées pour les projets hébergés.
4. Les CLA asymétriques sont interdits. Le copyright est protégé par un DCO ou transféré à la fondation avec obligation statutaire de ne publier que sous licence libre.
5. Le modèle “open core” est interdit. Tout le code d’un projet hébergé est sous licence libre, sans exception.
6. Les utilisateurs ont le droit de rester. Chaque version majeure bénéficie d’un support de sécurité de vingt ans. La migration n’est jamais obligatoire.
7. Les données sont libres. Formats ouverts, documentés, exportables. Les données appartiennent aux utilisateurs, pas au logiciel.

L’AGPL reste une excellente licence. Le problème n’est pas l’AGPL en elle-même, mais le fait qu’elle peut être instrumentalisée par un éditeur unique détenant le copyright via un CLA : l’éditeur se relicencie le code à lui-même sous d’autres termes, et l’effet dissuasif de l’AGPL décourage la concurrence. Ce n’est pas un problème inhérent à l’AGPL, c’est un problème de gouvernance que la fondation résout par l’interdiction des CLA asymétriques.

Nous préférons l’EUPL pour des raisons d’ancrage juridique : droit européen, multilinguisme, interopérabilité clarifiée par la directive 2009/24/CE, familiarité du secteur public, indépendance vis-à-vis d’organisations extra-européennes. Mais nous acceptons l’AGPL et ne considérons pas ces deux licences comme étant en opposition.

Ce qui distingue fondamentalement notre approche est la combinaison de cinq éléments : le refus des licences permissives, l’interdiction des CLA asymétriques, l’obligation statutaire de ne jamais relicencier vers une licence non libre, l’ancrage dans le droit européen, et une gouvernance démocratique qui empêche la capture. Ces cinq piliers forment un rempart que le choix de licence seul ne peut pas offrir.

Ce document est publié sous licence Creative Commons Attribution - Partage dans les Mêmes Conditions 4.0 International (CC-BY-SA 4.0).

Contact : Nicolas Pettiaux, fondation@educalibre.eu ASBL EduCode – 175 avenue Léopold Wiener, 1170 Watermael-Boitsfort https://educode.be – https://educalibre.eu//