01 Définition
L'open source désigne des logiciels dont le code source est rendu accessible publiquement, assorti de droits formels d'utilisation, d'étude, de modification et de redistribution — selon une licence conforme à la définition publiée par l'Open Source Initiative (OSI).
Le terme a été forgé en 1998 par Christine Peterson lors du Mozilla release meeting, et popularisé par Eric S. Raymond et Bruce Perens. Il répond à un besoin pragmatique : dissocier la question de la liberté du logiciel des considérations éthiques portées par le mouvement du logiciel libre (GNU/FSF).
02 Les 10 critères de la définition OSI
La définition officielle de l'Open Source Initiative liste dix conditions qu'une licence doit respecter :
- Redistribution libre — personne ne peut empêcher la revente ou le don du logiciel.
- Code source accessible — le code compilé doit être accompagné du source ou d'un moyen d'y accéder.
- Travaux dérivés autorisés — modifications et redistribution des dérivés doivent être permises sous la même licence.
- Intégrité du code source de l'auteur — la licence peut imposer que les patches soient distribués séparément pour protéger la réputation de l'auteur.
- Pas de discrimination envers des personnes ou des groupes — la licence s'applique à tous sans distinction.
- Pas de discrimination envers des domaines d'activité — utilisation commerciale, militaire, académique : tous autorisés.
- Distribution de la licence — les droits s'appliquent automatiquement à tous les destinataires du logiciel.
- Non-spécificité à un produit — les droits ne dépendent pas du fait que le logiciel fasse partie d'un ensemble précis.
- Non-contamination d'autres logiciels — la licence ne peut pas imposer des restrictions à d'autres logiciels distribués avec le logiciel.
- Neutralité technologique — aucune disposition ne peut être liée à une technologie ou interface particulière.
03 Open source, source disponible & logiciel libre
🔓 Open Source
Code accessible avec une licence OSI-approuvée. Met l'accent sur la collaboration, la transparence et l'innovation collective. Pragmatique.
👁 Source disponible
Le code est visible mais les droits de réutilisation ou de modification sont limités. Ex : SSPL (Server Side Public License), BSL. Non reconnu OSI.
🕊 Logiciel libre (Free Software)
Défini par la FSF via les quatre libertés : utiliser, étudier, modifier, redistribuer. Philosophie éthique portée par Richard Stallman et GNU.
🤝 FOSS / FLOSS
Free and Open Source Software — terme parapluie qui réunit les deux courants. La plupart des licences libres sont aussi open source.
04 Pourquoi publier en open source ?
🔍 Transparence technique
Les utilisateurs et clients peuvent auditer le code. Gage de confiance dans les secteurs sensibles (santé, finance, défense).
🛡 Audit de sécurité
Des milliers de yeux relèvent les failles. Le principe de Kerckhoffs : la sécurité ne doit pas reposer sur le secret du code.
📈 Adoption plus large
Pas de barrière de coût à l'entrée. Facilite le déploiement dans les universités, ONG, pays en développement.
🔬 Innovation collective
Contributions extérieures, forks productifs, nouvelles fonctionnalités venues de la communauté mondiale.
♾ Pérennité
Le projet survit à l'entreprise ou au mainteneur d'origine. Le code ne disparaît pas si une société fait faillite.
🌐 Écosystème
Plugins, intégrations, traductions, documentation multilingue, packages, extensions — générés par la communauté.
05 Modèles économiques
L'open source et la viabilité économique ne sont pas incompatibles. Il existe de nombreux modèles :
| Modèle | Description | Exemples |
|---|---|---|
| Support professionnel | Le code est gratuit, le support, la formation et les garanties sont payants. | Red Hat, Canonical |
| SaaS / Hébergement | Le logiciel est open source, mais l'hébergement géré est facturé. | GitLab.com, Sentry.io |
| Open Core | Version communautaire open source + version entreprise avec fonctions avancées propriétaires. | GitLab CE/EE, Elasticsearch |
| Formation & Conseil | Expertise, audit, intégration, personnalisation facturée. | Acquia (Drupal), Elastic |
| Dual Licensing | Licence open source pour usage personnel + licence commerciale pour redistribution. | Qt, MySQL |
| Sponsoring & Dons | Particuliers et entreprises financent le développement voluntairement. | OpenSSL, Vim, Wikipedia |
| Subventions publiques | Financements d'États, Commissions européennes, fondations. | Linux Foundation, NLnet |
| Marketplace d'extensions | Le noyau est gratuit, les plugins/thèmes premium sont vendus. | WordPress, WooCommerce |
06 Les grandes licences open source
L'OSI recense plus de 80 licences approuvées. Les plus utilisées :
MIT
Très courte, très permissive. Autorise usage commercial, modification, redistribution. Seule obligation : conserver le copyright et la licence.
Apache 2.0
Permissive avec concession de brevets explicite. Protège contre les poursuites liées à des brevets détenus par les contributeurs.
BSD (2, 3-clause)
Famille de licences très permissives. BSD 3-clause ajoute l'interdiction d'utiliser le nom de l'organisation pour promouvoir des produits dérivés.
GPL v2 / v3
Copyleft fort : tout logiciel distribuant du code GPL doit lui-même être distribué sous GPL. GPLv3 ajoute des clauses anti-tivoisation et anti-brevet.
LGPL
Comme la GPL mais permet à des logiciels propriétaires de lier dynamiquement des bibliothèques LGPL sans être contaminés.
MPL 2.0
Copyleft au niveau du fichier : les fichiers modifiés restent MPL, mais peuvent être combinés avec du code propriétaire dans d'autres fichiers.
AGPL v3
Comme la GPL, mais le copyleft s'applique aussi lorsque le logiciel est utilisé comme service réseau (SaaS). Vise à fermer la "faille ASP".
CC0 / Unlicense
Renonce à tous les droits d'auteur. Équivalent légal du domaine public. Utile pour les données, contenus, petits utilitaires.
07 Permissif vs Copyleft
✅ Permissif
Peu de contraintes. Le code peut être intégré dans un produit propriétaire sans obligation de publier les modifications. Facilite l'adoption commerciale. Ex : MIT, Apache 2.0, BSD.
🔄 Copyleft
Protège les libertés en cascade : toute redistribution d'une œuvre dérivée doit conserver les mêmes libertés. Empêche la privatisation du commun. Ex : GPL, AGPL.
08 Anatomie d'un bon projet open source
Un projet bien structuré devrait contenir au minimum :
| Fichier | Contenu attendu |
|---|---|
| README.md | Description, installation, exemples d'utilisation, badges (CI, couverture, version). |
| LICENSE | Texte complet de la licence choisie. Sans ce fichier, le code est sous droit d'auteur exclusif. |
| CONTRIBUTING.md | Comment soumettre un bug, une PR, les conventions de code, le processus de revue. |
| CODE_OF_CONDUCT.md | Règles de comportement dans la communauté. Souvent basé sur le Contributor Covenant. |
| SECURITY.md | Comment signaler une faille de sécurité de façon responsable (responsible disclosure). |
| CHANGELOG.md | Historique des changements par version, idéalement au format Keep a Changelog. |
09 Contribution communautaire
Contribuer à un projet open source va bien au-delà du code :
💻 Code
Correctifs (bugfix), nouvelles fonctionnalités, refactoring, optimisations de performance.
📖 Documentation
Tutoriels, guides de démarrage rapide, exemples, traductions, corrections de fautes.
🔬 Tests
Tests unitaires, d'intégration, tests de non-régression, rapports de bugs reproductibles.
🎨 Design
Interfaces, icônes, logos, maquettes UX pour améliorer l'ergonomie du projet.
💬 Support
Répondre aux questions sur les forums, Slack, Discord, Stack Overflow, GitHub Discussions.
📢 Promotion
Articles de blog, conférences, podcasts, démonstrations qui font connaître le projet.
Le flux de contribution standard est le Fork → Branche → Commit → Pull Request → Review → Merge. Un bon mainteneur réduit la friction d'entrée par des templates de PR/issue et des guides clairs.
10 Gouvernance
Un projet open source n'est pas forcément sans structure. La gouvernance détermine :
- qui peut merger des contributions (mainteneurs, comité technique),
- comment sont prises les décisions importantes (vote, consensus, BDFL),
- comment sont gérés les conflits et les personnes toxiques,
- comment sont planifiées et publiées les versions,
- qui détient la marque et le nom de domaine.
👤 BDFL
Benevolent Dictator For Life — un mainteneur principal a le dernier mot. Ex : Guido van Rossum (Python jusqu'en 2018), Linus Torvalds (Linux).
🏛 Fondation
Entité juridique indépendante. Ex : Apache Software Foundation, Linux Foundation, GNOME Foundation, Python Software Foundation.
🏢 Pilotage entreprise
Une entreprise contrôle le projet et paye les développeurs principaux. Ex : Android (Google), React (Meta), TypeScript (Microsoft).
🗳 Comité technique
Groupe élu ou coopté qui prend les décisions par consensus ou vote. Ex : Node.js TSC, OpenSSF.
11 Sécurité et open source
L'open source facilite l'audit et la correction rapide des vulnérabilités, mais il n'assure pas automatiquement la sécurité.
✔ Avantages sécurité
Audit public possible. Corrections rapides par la communauté mondiale. Transparence sur les dépendances.
✖ Limites
Code ouvert ≠ code audité. Les failles restent si personne ne cherche. Ex : HeartBleed (OpenSSL) non détecté pendant 2 ans.
🔐 Bonnes pratiques
Processus de divulgation responsable (SECURITY.md), signatures GPG des releases, builds reproductibles, analyse SAST/DAST.
📦 Chaîne de dépendances
Un projet open source hérite des vulnérabilités de ses dépendances. Outils : Dependabot, Snyk, OSV, SBOM.
12 Risques fréquents
😴 Abandon
Le mainteneur principal part, le projet cesse d'évoluer. Solutions : forks, fondations, transfert de propriété.
🧑💻 Bus factor
Dépendance à une seule personne clé. Risque critique. Besoin de documentation et de montée en compétence de la communauté.
📄 Licence mal choisie
Une licence choisie sans réflexion peut bloquer l'adoption commerciale ou créer des conflits légaux.
📭 Absence de documentation
Sans doc, même un excellent projet reste inaccessible. La courbe d'apprentissage bloque les contributions.
🔥 Communauté toxique
Comportements agressifs ou excluants freinent les contributions. Un CODE_OF_CONDUCT est indispensable.
💸 Financement insuffisant
La majorité des projets critiques sont maintenus bénévolement. Des projets comme Log4j affectent des milliards d'appareils malgré un manque de ressources.
13 Open source et IA
L'IA soulève de nouvelles questions sur ce que signifie « open source » pour un système d'apprentissage. Le débat distingue plusieurs composants :
🤖 Modèles « ouverts »
Certains modèles publient leurs poids (Llama 3, Mistral, Falcon) mais avec des licences restrictives sur l'usage commercial. Débat : sont-ils vraiment open source ?
📋 OSI AI Definition
L'OSI a publié en 2024 sa première définition de l'IA open source, exigeant le code + les poids + les données ou leur description détaillée.
⚖️ Enjeux légaux
Copyright des données d'entraînement, droits des créateurs, licences des sorties générées — domaine légal en pleine construction.
14 Exemples de grands projets open source
| Projet | Licence | Gouvernance | Impact |
|---|---|---|---|
| Linux Kernel | GPL v2 | Linus Torvalds + sous-mainteneurs | Équipe Android, serveurs, cloud, IoT |
| Python | PSF License | Python Software Foundation | Langage n°1 IA/data science |
| Firefox | MPL 2.0 | Mozilla Foundation | Navigateur web, moteur Gecko |
| PostgreSQL | PostgreSQL License | Comité global | SGBD relationnel de référence |
| React | MIT | Meta + comité OSS | Bibliothèque UI la plus utilisée |
| WordPress | GPL v2+ | Automattic + communauté | 43% des sites web mondiaux |
| Kubernetes | Apache 2.0 | CNCF (Linux Foundation) | Orchestration de conteneurs |
| TensorFlow | Apache 2.0 | Google + comité | Framework ML majeur |
15 Choisir une licence — guide pratique
Questions à se poser avant de choisir :
- Voulez-vous que les modifications restent open source ? → Copyleft (GPL, AGPL).
- Voulez-vous permettre un usage dans des logiciels propriétaires ? → Permissif (MIT, Apache 2.0).
- Y a-t-il des brevets associés ? → Choisir Apache 2.0 (concession de brevets explicite).
- Le logiciel sera-t-il utilisé comme service réseau (SaaS) ? → AGPL pour garder le copyleft.
- Est-ce une bibliothèque devant être intégrable partout ? → MIT ou LGPL.
- Voulez-vous le domaine public ? → CC0 ou Unlicense.
16 Résumé
L'open source n'est pas seulement un modèle de licence. C'est une façon d'organiser la collaboration, la confiance technique, la maintenance à long terme et l'innovation distribuée.
Du noyau Linux aux frameworks web, en passant par les bases de données, les outils IA et les systèmes embarqués, l'open source est devenu l'infrastructure invisible sur laquelle repose l'essentiel du numérique mondial.