Technologie

Logiciels open source et licences : comprendre le copyright informatique

Le droit d'auteur protège le code d'un logiciel, pas ses idées ni ses fonctionnalités. Mais toutes les licences libres ne se valent pas : entre permissives et copyleft, les obligations varient. Décryptage des pièges à éviter.

Logiciels open source et licences : comprendre le copyright informatique

Ce que le droit d'auteur protège dans un logiciel

Un logiciel est protégé par le droit d'auteur dès lors qu'il constitue une œuvre originale. Cette protection naît sans formalité d'enregistrement et couvre l'expression du programme : le code source, le code objet, ainsi que la documentation et l'architecture qui en découlent. Elle ne couvre pas les idées, les algorithmes ou les fonctionnalités en tant que tels, qui restent libres d'être réimplémentés.

Cette distinction est structurante. Deux programmes peuvent résoudre le même problème avec des interfaces similaires sans que l'un porte nécessairement atteinte à l'autre, tant que le code n'a pas été copié. La frontière exacte entre idée et expression fait l'objet d'appréciations au cas par cas, et les jurisprudences nationales ne se recoupent pas toujours.

En Europe, la protection s'acquiert par la création, sans dépôt. Aux États-Unis, l'enregistrement auprès du Copyright Office reste facultatif mais conditionne l'accès à certaines actions en justice. Un éditeur qui publie du code sans mention de licence n'abandonne pas ses droits pour autant : l'absence de licence signifie que personne ne dispose d'autorisation d'usage, de copie ou de modification.

Les licences libres et leurs obligations concrètes

Une licence est un contrat par lequel le titulaire des droits accorde des permissions. Les licences dites libres ou open source garantissent quatre libertés : exécuter le programme, étudier son code, le redistribuer et le modifier. Elles diffèrent sur les conditions attachées à ces libertés, et c'est là que se jouent les usages réels.

Les licences libres et leurs obligations concrètes

Les licences permissives, comme MIT, BSD ou Apache 2.0, imposent peu de contraintes : conserver la mention de copyright et le texte de la licence lors d'une redistribution. Elles autorisent l'intégration dans un produit propriétaire. Apache 2.0 ajoute une clause explicite sur les brevets, ce qui explique son adoption dans les projets d'infrastructure.

Les licences copyleft, dont la GNU GPL est la plus connue, imposent en revanche que toute œuvre dérivée distribuée reste sous la même licence. La GPL distingue le fait d'utiliser un programme de celui de le distribuer : un logiciel propriétaire peut appeler un composant GPL par un mécanisme externe, mais l'intégration du code dans le même programme déclenche l'obligation de partage. La version 3 de la GPL ajoute des dispositions sur les brevets et sur la protection contre la « tivoïsation », c'est-à-dire le verrouillage d'un appareil malgré un logiciel libre.

La LGPL, plus souple, autorise l'édition de liens avec du code propriétaire sous conditions. La MPL, enfin, applique le copyleft fichier par fichier plutôt qu'à l'ensemble du programme.

Ce que les licences ne règlent pas

Une licence ne dit rien de la qualité, de la sécurité ou de la maintenance d'un logiciel. Elle ne garantit pas non plus la conformité réglementaire : un composant libre intégré dans un dispositif médical ou un système embarqué reste soumis aux obligations sectorielles applicables. Les clauses de garantie des licences libres excluent d'ailleurs généralement toute responsabilité de l'auteur.

Le respect des licences pose aussi des questions de traçabilité. Une entreprise qui assemble des dépendances doit connaître l'ensemble de son arbre de dépendances et les licences de chaque composant. Des outils d'analyse automatique existent, mais ils produisent des résultats à interpréter : une licence détectée dans un fichier annexe n'a pas la même portée qu'une licence déclarée à la racine du projet.

Le contentieux est rare mais réel, et il porte le plus souvent sur l'absence de mention de copyright ou sur la redistribution d'un binaire sans le code source correspondant. Les sanctions varient selon les juridictions et peuvent aller jusqu'à l'injonction de cesser la distribution.

Reste une question que se posent beaucoup d'équipes techniques : à partir de quel moment une contribution interne devient-elle une distribution au sens de la licence ? La réponse dépend du mode de mise à disposition, du public visé et du droit applicable. Elle mérite un examen au cas par cas plutôt qu'une règle générale.

Damien Lemoine

Damien Lemoine

Damien Lemoine est un spécialiste reconnu du référencement SEO et payant, qui met son expertise au service des entreprises souhaitant améliorer leur visibilité en ligne. Grâce à sa maîtrise de l'audit de sites web et de l'optimisation du contenu éditorial, il accompagne ses clients dans la mise en place de stratégies digitales performantes et durables. Son approche allie rigueur technique et créativité pour répondre aux enjeux spécifiques de chaque projet.

Voir tous les articles →

Articles similaires