Que signifie logiciel libre : définition, licences et différences avec l’open source

Logiciel libre, open source, licences GNU GPL, MIT, Apache… Derrière ces sigles familiers aux équipes techniques se cachent des choix stratégiques qui engagent une marque, un produit et parfois toute une architecture SI. Pour une PME, un éditeur ou une équipe marketing, mal comprendre ces notions revient à signer des contrats sans lire les petites lignes. Liberté d’usage, obligations de redistribution, modèle économique, image de marque : chaque décision sur le logiciel libre laisse une trace, visible ou non, dans la durée.

La nuance clé tient en quelques mots : le logiciel libre défend d’abord des libertés d’usage, quand l’open source insiste plutôt sur la qualité de la collaboration technique autour du code source. Les deux mondes se chevauchent, partagent des outils et des communautés, mais ne racontent pas la même histoire. Comprendre cette différence évite les contresens du type « open source = gratuit » ou « libre = bricolage militant ». Dans les faits, certains des logiciels les plus robustes et les plus utilisés en production sont issus de ces deux univers.

Pour une entreprise qui prépare un nouveau site, un SaaS B2B ou un outil interne, la question n’est donc pas théorique. Choisir une licence copyleft comme la GPL ou une licence permissive type MIT oriente ce qu’il sera possible de vendre, d’héberger, de redistribuer ou de garder propriétaire. C’est exactement le genre de point qui, s’il est anticipé, permet d’aligner juridique, technique et marketing. S’il est ignoré, il revient plus tard sous la forme d’un audit douloureux ou d’un produit qu’on ne peut plus faire évoluer librement.

En bref

• Logiciel libre signifie d’abord libertés d’usage pour l’utilisateur : exécution, étude, modification, distribution des versions originales et modifiées.
• Le terme open source se concentre sur l’accès au code source et le modèle de développement collaboratif, avec une charge philosophique moins marquée.
• Tous les logiciels libres sont open source, mais certains projets open source ne respectent pas pleinement les quatre libertés du mouvement GNU.
• Les licences copyleft (GPL, AGPL…) imposent la réciprocité, les licences permissives (MIT, Apache, BSD) laissent plus de marge aux produits propriétaires.
• Pour une PME, choisir entre libre et open source revient à arbitrer entre contrôle, vitesse de mise sur le marché et stratégie de différenciation.

Logiciel libre : définition détaillée, origines GNU et libertés concrètes

La bonne porte d’entrée, c’est la définition historique posée par la Free Software Foundation dans les années 1980, avec le projet GNU. Un logiciel libre n’est pas seulement un programme dont le code source est visible. C’est un logiciel qui garantit à chaque utilisateur quatre libertés bien précises, numérotées de 0 à 3 dans la littérature officielle. Ces libertés sont formulées pour être vérifiables, presque comme un cahier des charges.

Première liberté, la numéro 0 : la liberté d’exécuter le programme pour n’importe quel usage. Un ERP libre peut servir autant à gérer une coopérative agricole qu’une maison de Champagne, sans restriction sectorielle ou géographique. L’auteur ne peut pas écrire dans la licence « interdit d’utiliser ce logiciel dans tel contexte ». Ce point paraît anodin, mais il protège concrètement contre certaines dérives contractuelles.

Deuxième liberté, étudier comment fonctionne le logiciel et l’adapter à ses besoins. Là, le code source devient central. Sans accès au code, pas d’analyse possible, pas d’audit, pas de personnalisation fine. Pour une DSI qui veut vérifier ce que fait un module de tracking ou adapter un workflow industriel, cette liberté change tout. Elle ouvre la porte à des intégrations propres, à des audits de sécurité et à des optimisations métiers.

Troisième liberté, redistribuer des copies du logiciel. Cela couvre la distribution interne comme externe : à ses clients, à ses sous-traitants, à sa filiale étrangère. Un cabinet de conseil qui déploie un outil libre chez ses clients a le droit de transmettre le programme, éventuellement facturer son accompagnement, tant qu’il respecte la licence. C’est souvent le socle économique des intégrateurs open source.

Quatrième liberté, améliorer le programme et publier ces améliorations. C’est là que les choses deviennent intéressantes pour les communautés et les écosystèmes métiers. Une équipe de dev dans l’industrie peut corriger un bug bloquant, ajouter un connecteur spécifique et décider ensuite de reverser ces changements au projet. Tout le monde en bénéficie, y compris les concurrents. Ce choix peut surprendre, mais il évite de maintenir une branche privée fragile et coûteuse.

Derrière ces quatre points se cache une posture éthique assez nette. Le logiciel libre considère l’utilisateur comme un acteur à part entière, pas comme un simple consommateur. Il doit garder le contrôle sur ses outils, pouvoir quitter un prestataire sans perdre ses données, ajuster l’outil à sa réalité. Ce n’est pas un hasard si l’école, l’université et la recherche ont historiquement adopté ces solutions en nombre.

Un exemple assez parlant : une collectivité locale qui choisit un système de gestion documentaire libre plutôt qu’un équivalent propriétaire. Sur le papier, les fonctionnalités semblent proches. En pratique, la collectivité garde la main sur les formats, sur l’archivage, sur la capacité à changer de prestataire sans racheter des licences ni perdre son historique. Le choix du libre agit ici comme une assurance de long terme.

Cette vision n’est pas qu’idéologique. Elle a un impact direct sur la stratégie numérique, au même titre que le choix d’un CMS pour un site. Quand une entreprise s’oriente vers un développement spécifique, la question « doit-on publier ce code sous une licence libre ? » rejoint celle d’un développement logiciel sur mesure pensé comme un actif, et non comme une dépense isolée.

Au final, retenir la définition officielle, c’est se donner un filtre simple : si l’une des quatre libertés manque, le logiciel n’est pas libre, même si le marketing parle d’« ouverture ». Cette grille, une fois intégrée, sert de boussole pour tous les arbitrages à venir.

Logiciels libres vs open source : différences philosophiques et pratiques

Les termes « logiciel libre » et « open source » forment souvent un duo indissociable. Pourtant, les deux mouvements ne racontent pas la même histoire. Le premier se concentre sur les droits des utilisateurs, le second sur l’efficacité du processus de développement. Dire « c’est de l’open source » ne dit rien, en soi, sur le respect des quatre libertés évoquées juste avant.

Historiquement, le mouvement open source s’est structuré plus tard, avec l’Open Source Initiative, pour rendre ce modèle de développement plus acceptable dans le monde des affaires. Le vocabulaire a été adouci, le discours recentré sur la qualité, la sécurité, la rapidité d’innovation. On parle moins de liberté, plus de productivité et de fiabilité. Cette nuance continue de peser dans la manière dont les entreprises adoptent ces outils.

Dans la pratique, beaucoup de projets très connus sont à la fois libres et open source. Le noyau Linux, par exemple, respecte les critères des deux mouvements. Idem pour de nombreux frameworks web qui, sous licence GPL ou MIT, cochent les cases techniques et philosophiques. La confusion vient surtout des cas limites, ceux qui affichent un code source visible, mais encadré par des clauses qui restreignent fortement la réutilisation ou la redistribution.

On voit émerger, depuis quelques années, des licences dites « source available ». Le code se consulte, parfois se modifie, mais sans droit de redistribution ni d’usage commercial concurrent. Ces projets se présentent volontiers comme « open source friendly », mais n’entrent ni dans la définition du logiciel libre ni dans les critères officiels de l’open source. Pour une direction produit, se tromper sur ce point peut fausser le calcul du ROI.

Pour clarifier ce paysage, on peut résumer les principaux critères dans un tableau comparatif simple.

Pour les équipes non techniques, une règle simple évite les mélanges hasardeux : tous les logiciels libres sont open source, mais l’inverse n’est pas garanti. En cas de doute, le réflexe à adopter consiste à remonter à la licence précise et à vérifier si les quatre libertés sont bien présentes. Les discours marketing se recyclent vite, les clauses juridiques beaucoup moins.

Dans une agence qui conçoit des sites, cette nuance peut influencer le choix de l’outil. Un constructeur de pages web sous licence permissive sera plus simple à intégrer dans un socle propriétaire ou dans une logique de prestation clé en main. Un CMS sous licence copyleft forte demandera un cadre contractuel plus précis, mais offrira à vos clients une indépendance plus grande. C’est d’ailleurs un sujet qui rejoint le choix d’outils no-code ou low-code, comme on peut le voir dans des comparatifs du type Framer vs Webflow.

Au bout du compte, opposer libre et open source n’a pas beaucoup de sens opérationnel. Mieux vaut comprendre le socle commun, identifier la coloration philosophique de chaque projet et, surtout, regarder de près la licence qui encadre l’usage. C’est là que se nichent les vraies différences.

Comprendre les licences libres et open source : copyleft, permissives et effets de bord

Une fois la distinction posée, tout se joue dans les licences. C’est elles qui traduisent les intentions en droits et obligations concrets. Pour un dirigeant ou un responsable marketing, la meilleure approche consiste à classer ces licences en deux grandes familles : les licences dites « permissives » et celles qualifiées de copyleft. Ce découpage offre une grille de lecture claire, sans entrer dans tous les détails juridiques.

Les licences permissives, comme MIT, BSD ou Apache 2.0, autorisent une grande liberté de réutilisation. Vous pouvez intégrer le code source dans un produit propriétaire, modifier le logiciel sans publier vos changements, vendre une solution packagée sans ouvrir toute votre pile. En échange, vous conservez la notice de copyright et la mention de la licence, parfois une clause autour des brevets, comme c’est le cas avec Apache 2.0.

Côté copyleft, la logique est inversée. Une licence comme la GPL impose que tout dérivé distribué soit publié sous la même licence. Si votre produit embarque du code GPL et que vous le livrez à des clients, vous devez offrir l’accès au code source correspondant. L’idée est de protéger les libertés initiales et d’éviter qu’un acteur s’approprie le travail communautaire pour en faire un produit fermé.

Des variantes existent. La LGPL adoucit cette obligation pour les bibliothèques : vous pouvez lier dynamiquement une lib LGPL à un logiciel propriétaire, à condition que l’utilisateur puisse la remplacer par une version modifiée. L’AGPL, elle, étend la logique au SaaS : si vous modifiez un logiciel AGPL et le proposez comme service en ligne, vos modifications doivent être publiées, même s’il n’y a pas de distribution de binaire au sens classique.

Pour une entreprise, ces nuances se traduisent par des questions très concrètes. Peut-on garder confidentiels certains modules métiers alors qu’on contribue à des briques ouvertes ? Doit-on prévoir une politique interne pour approuver l’usage de nouvelles dépendances ? Comment documenter les éléments soumis à des obligations de redistribution ? Beaucoup découvrent ces sujets lors d’un audit de conformité imposé par un grand compte, parfois tard dans le cycle de vente.

Une démarche simple consiste à construire une petite cartographie des licences présentes dans votre stack. Une SBOM (Software Bill of Materials) basique, même dans un tableur, suffit pour repérer les zones sensibles. À partir de là, on définit des règles internes : pas de nouvelle dépendance en GPL sans validation, documentation systématique des briques MIT et Apache, processus clair lorsqu’un client demande le code source d’une composante.

D’ailleurs, les outils d’analyse de licences se démocratisent. Des solutions comme FOSSA, ScanCode ou leurs équivalents open source s’intègrent aux chaînes CI/CD et signalent les changements de licences lors des mises à jour. Ce n’est pas un luxe, surtout quand on voit la fréquence des releases sur certains frameworks JavaScript. Une modification discrète de licence peut transformer un risque potentiel en obligation immédiate.

Sur le plan stratégique, une position se dessine chez les acteurs numériques matures : accepter les licences permissives sans crispation, cadrer l’usage des licences copyleft et, surtout, documenter les choix. Cette transparence interne évite de se retrouver coincé par un module « magique » ajouté à la hâte, qui change subitement les règles du jeu juridique.

Communautés, éthique et modèles économiques autour du logiciel libre

Parler de logiciel libre sans évoquer les communautés, c’est passer à côté de la moitié du sujet. Derrière chaque projet mature se cache un mélange de mainteneurs, de contributeurs occasionnels, d’entreprises qui financent du temps de développement et d’utilisateurs qui remontent des bugs. Le tout organisé autour de règles implicites ou explicites, parfois plus strictes qu’une charte RH.

Les communautés issues du mouvement GNU mettent souvent en avant une dimension éthique. Liberté de l’utilisateur, respect de la vie privée, transparence sur ce que fait le logiciel. Ce n’est pas qu’un discours, on le retrouve dans des choix concrets : refus d’intégrer certaines formes de télémétrie, préférences pour des formats ouverts, documentation publique des arbitrages. Ces décisions ont un coût, mais elles construisent une relation de confiance différente avec les utilisateurs.

Les projets purement open source, eux, se montrent parfois plus pragmatiques. L’accent se déplace vers la qualité du code, la performance, la gouvernance technique. Les enjeux éthiques ne disparaissent pas, mais occupent moins le centre de la conversation. Pour une entreprise qui contribue, ce cadre peut sembler plus familier : on parle roadmap, backlog, sprints communautaires, pas manifeste politique.

Pourtant, sur le terrain, les frontières se mélangent. Une PME qui mise sur un CRM libre, par exemple, cherche rarement à défendre une cause. Elle veut avant tout un outil qu’elle peut adapter à ses processus, faire évoluer sans attendre la prochaine release d’un éditeur, auditer pour vérifier le traitement des données clients. Le bénéfice éthique existe, mais la motivation reste très opérationnelle.

Côté modèles économiques, les scénarios sont variés. On retrouve souvent les mêmes ingrédients.

• Prestations de service autour d’un socle libre : intégration, formation, TMA, développement de modules spécifiques.
• Offres SaaS construites sur des briques open source, avec une valeur ajoutée sur l’hébergement, la sécurité, le support.
• Dual-licensing : une version communautaire sous licence copyleft, une édition entreprise propriétaire avec fonctionnalités avancées.
• Financement par des acteurs publics ou privés qui ont un intérêt stratégique à la pérennité du projet.

La fameuse question « si c’est libre, comment gagnent-ils leur vie ? » trouve donc plusieurs réponses, rarement spectaculaires, mais plutôt structurantes. Ce sont des business modérés, ancrés dans le temps long, avec une forte dépendance à la confiance. D’ailleurs, les entreprises qui adoptent massivement ces solutions finissent souvent par contribuer en retour, ne serait-ce que pour sécuriser un composant critique.

Un point mérite d’être souligné : la promesse de sécurité liée à l’accès au code source. La transparence ne garantit rien si la communauté reste passive. Un logiciel très utilisé, doté d’une base active de contributeurs, bénéficie d’une relecture continue et d’un temps de réaction raisonnable en cas de faille. Un projet peu maintenu, même libre, peut devenir un angle mort. La vraie question n’est donc pas « open source ou pas ? », mais « qui surveille, qui corrige, à quel rythme ? ».

Pour les entreprises, ce sujet rejoint celui de l’industrialisation web et applicative. Miser sur un CMS libre à forte communauté, par exemple, s’inscrit dans la même logique que confier son site à un prestataire structuré, capable de suivre les mises à jour, de gérer les migrations, de penser la performance. Le choix d’un site internet appuyé sur un socle open source sérieux s’aligne alors sur une politique de sobriété technique et de maîtrise budgétaire.

En résumé, la force des logiciels libres ne vient pas uniquement de leur statut juridique, mais de l’écosystème humain qui les entoure. Comprendre la culture d’un projet, ses règles de contribution, son mode de gouvernance, devient un critère aussi important que la liste des fonctionnalités.

Comment choisir entre logiciel libre, open source permissif et solutions propriétaires

Une fois le décor posé, reste la question qui intéresse vraiment les équipes dirigeantes : comment trancher pour un projet précis. Refondre un intranet, lancer une plateforme e-commerce, créer un outil métier… Faut-il opter pour un logiciel libre, un composant open source sous licence permissive, une solution propriétaire prête à l’emploi, ou un mix de tout cela ? Il n’existe pas de recette universelle, mais une série de questions utiles pour cadrer la décision.

Premier axe, le niveau de contrôle souhaité. Si l’enjeu principal est de garder la main sur l’évolution fonctionnelle, sur la portabilité des données et sur les intégrations, un socle libre ou open source bien choisi donne de l’air. On peut internaliser une partie du développement, confier des chantiers à différents prestataires, négocier des SLA sur mesure. À l’inverse, si le besoin est très standardisé et le time-to-market critique, une solution SaaS propriétaire peut se défendre.

Deuxième axe, la stratégie de différenciation. Une startup B2B dont la valeur repose sur un algorithme original hésitera à l’exposer sous copyleft. Elle préférera peut-être publier des briques non sensibles en licence permissive, pour gagner en crédibilité et en adoption, tout en gardant son cœur métier sous contrôle. Un industriel, lui, pourra ouvrir certains outils internes pour standardiser ses échanges avec ses partenaires et réduire ses coûts d’intégration.

Troisième axe, la capacité interne à assumer le modèle choisi. Adopter un ERP libre ou un framework web open source performant suppose d’avoir, en face, des compétences pour suivre les mises à jour, arbitrer les contributions, négocier avec la communauté. Sans cela, la promesse de liberté peut se retourner en dette technique. Inversement, déléguer à 100 % à un éditeur propriétaire crée une autre forme de dépendance.

Dans la pratique, de nombreuses organisations finissent par adopter une architecture hybride. Des briques profondes et techniques, souvent open source, cohabitent avec des modules métiers parfois propriétaires. L’important reste de ne pas se raconter d’histoires : un composant clé sous GPL ne se traite pas comme un simple script sous MIT. Les choix de licences orientent la façon dont on pourra faire évoluer, packager, redistribuer la solution finale.

Du coup, pour décider de façon plus sereine, un mini-cadre de décision peut aider à y voir clair :

1. Cartographier les besoins : fonctionnalités indispensables, données sensibles, intégrations à prévoir, horizons de temps (2 ans, 5 ans, plus). Plus le projet touche au cœur de l’activité, plus la question du contrôle doit peser.

2. Lister les options réalistes : solutions libres existantes, briques open source, offres propriétaires. Vérifier les licences de chacune, sans se contenter du mot « gratuit ». C’est là qu’un rapide inventaire des dépendances fait gagner du temps.

3. Évaluer les contraintes juridiques : présence de copyleft fort, obligations de distribution du code source, clauses de brevets. Un échange ponctuel avec un juriste spécialisé peut éviter des interpretations erronées.

4. Confronter à la réalité interne : équipe technique disponible, budget pour la maintenance, capacité à contribuer à un projet communautaire. Sans sous-estimer l’effort invisible que représente la simple mise à jour régulière.

5. Décider… puis documenter : pourquoi tel socle, telle licence, telle part de propriétaire. Cette mémoire des choix devient précieuse quand l’équipe change ou quand un audit externe apparaît.

Il reste un point souvent mis de côté : la perception de la marque. Associer un produit à l’open source peut envoyer un signal de transparence, d’ancrage technique, de communauté. S’ancrer dans l’univers du logiciel libre peut, de son côté, porter une promesse plus politique autour de l’indépendance et de la responsabilité numérique. Dans un paysage saturé de discours, ces nuances contribuent à ce qui distingue vraiment une offre.

Au fond, le choix n’oppose pas moderne et ancien, gratuit et payant, high-tech et bricolage. Il oppose surtout des façons différentes de répartir le pouvoir entre éditeur, intégrateur, client et utilisateur final. C’est ce rapport de force qu’il vaut la peine de regarder de près, bien avant de signer.

Quelles sont exactement les quatre libertés d’un logiciel libre ?

Un logiciel libre garantit à l’utilisateur la liberté d’exécuter le programme pour tout usage, d’accéder au code source pour l’étudier et l’adapter, de redistribuer des copies, et de modifier le logiciel puis de publier ces versions modifiées. Si l’une de ces libertés manque ou est restreinte par la licence, le logiciel ne peut pas être qualifié de libre au sens du projet GNU et de la Free Software Foundation.

Tous les logiciels open source sont-ils des logiciels libres ?

Non. Tous les logiciels libres sont open source, car leur code source est disponible, mais certains logiciels open source ne respectent pas pleinement les quatre libertés du libre. Par exemple, des licences dites source available laissent voir le code, mais limitent la redistribution ou l’usage commercial, ce qui sort du cadre du logiciel libre.

Que signifie le terme copyleft sur une licence comme la GPL ?

Le copyleft désigne une clause de réciprocité présente dans des licences comme la GPL ou l’AGPL. Elle impose que tout travail dérivé ou toute distribution combinant ce code reste sous la même licence, avec les mêmes libertés pour les utilisateurs. En d’autres termes, vous pouvez utiliser et modifier le code, mais si vous le redistribuez, vous devez publier vos modifications sous la même licence.

Peut-on vendre un logiciel libre ou open source ?

Oui. Rien dans les définitions du logiciel libre ou de l’open source n’interdit la vente. Ce qui compte, ce sont les droits accordés à l’utilisateur via la licence : accès au code source, droits de modification, obligations éventuelles de redistribution. De nombreux éditeurs bâtissent leur modèle économique sur des services, de l’hébergement ou des éditions enrichies proposées autour d’un socle libre.

Comment une PME peut-elle limiter les risques liés aux licences open source ?

La méthode la plus pragmatique consiste à établir un inventaire des composants utilisés, à identifier leurs licences, puis à fixer quelques règles internes : par exemple, validation obligatoire pour toute nouvelle dépendance GPL, documentation systématique des bibliothèques MIT ou Apache, et intégration d’un outil de scan de licences dans la chaîne de développement. Cette hygiène de base suffit souvent à éviter les mauvaises surprises lors d’un audit ou d’un appel d’offres.