Comprendre les licences open source

Pour rendre votre code libre et ouvert, il convient de lui associer une licence qui accorde à des permissions précises à l’utilisateur. Dans la pratique, chaque fichier de code doit comporter une ligne de commentaire qui détaille l’identité de l’auteur et la licence de diffusion choisie, et il faut une copie complète de la licence dans un fichier, placé dans le dossier racine de votre projet et au nom explicite, par exemple “licence.txt”.

Mais avant d’arriver à ces étapes, il faut d’abord choisir une licence. Ce qui n’est pas si compliqué que cela peut paraître, sauf dans le cas où l’on n’a pas une idée bien claire des permissions que l’on souhaite donner aux utilisateurs du code, ou dans celui de certains projets complexes pouvant mettre en œuvre des parties brevetées, par exemple.

Absence de licence = code protégé

Dans le droit de la quasi-totalité des pays, il existe des dispositions protégeant la production d’œuvres intellectuelles. Que la protection s’appelle le copyright dans les pays de common law ou le droit d’auteur dans les pays de droit civil, elle est harmonisée dans le cadre d’accords internationaux comme la Convention de Berne et par le travail d’institutions comme l’Organisation mondiale de la propriété intellectuelle (OMPI).

Les dispositions de la Convention de Berne ont été adaptées à l’univers numérique en 1996, étendant la protection aux programmes d’ordinateur et aux bases de données. Par conséquent, le code que vous créez est une œuvre de l’esprit est bénéficie par défaut d’une protection de type copyright/droit d’auteur.

Même si vous ne mettez pas une mention de copyright et de nom d’auteur au début de votre code, il reste entièrement protégé. Vous conservez les droits d’utilisation et de distribution de ce code, même s’il est téléchargeable par des tiers. Vous gardez le droit de poursuivre en justice toute personne utilisant votre code. Vous pouvez céder des licences individuelles à des personnes ou à des organisations pour utiliser ce code.

Licence faite maison

Ne faites pas ça. C’est une perte de temps et comme vous n’êtes probablement pas un juriste spécialisé dans le domaine, les termes de votre licence risquent de vous trahir, par exemple en ouvrant la porte à des utilisations que vous n’auriez pas souhaitées. Il existe dans le monde suffisamment de licences, dont celles approuvées par l’Open Source Initiative (OSI), pour que vous n’ayez pas besoin de rédiger une licence. Les licences approuvées par l’OSI ont été rédigées ou contrôlées par des experts et des juristes, elles ont même pour beaucoup passé l’épreuve des tribunaux. N’obligez pas non plus à vos utilisateurs de lire et de comprendre une nouvelle licence inconnue. Lorsqu’une personne ou une entreprise souhaite utiliser un projet sous licence GPL-3.0, Apache-2.0 ou MIT, elle est en territoire connu et il lui est facile et rapide de déterminer si la licence en question accorde suffisamment de droits pour l’utilisation qu’elle souhaite faire de votre code.

Licences à fort copyleft

Une licence copyleft donne l’autorisation d’utiliser, de modifier et de redistribuer librement le code, mais uniquement si la licence originale reste intacte, tant pour le projet original que pour toute modification que vous pourriez apporter au projet original. Le premier exemple de ce type de licence fut la GPL, écrite à l’origine par Richard Stallman pour le projet GNU. Si vous utilisez du code d’un projet à licence copyleft dans votre projet, et si vous souhaitez distribuer votre projet d’une façon ou d’une autre, votre projet doit adopter exactement la même licence que le projet d’origine.

La philosophie du copyleft est de donner aux contributeurs du projet initial l’assurance que leur travail bénéficiera au monde entier et restera toujours libre, plutôt que d’être exploité par des entreprises qui n’auraient rien à donner en retour à la communauté. Par exemple, si vous réalisez un fork de WordPress qui est sous licence GPL, vous ne pouvez le distribuer que sous licence GPL. WordPress est distribué sous licence GPL, car il est lui-même un fork d’un logiciel sous licence GPL, b2/cafelog, créé par Michel Valdrighi en 2001. En quelque sorte, tous les projets dérivés héritent de la licence, même si le projet a évolué de façon très considérable depuis le fork initial.

Parmi les licences copyleft les plus populaires, on trouve GPL-3.0 et AGPL-3.0, une version de GPL plus adaptée à l’usage de programmes qui tournent sur des serveurs.

Licences à faible copyleft

Essentiellement similaires à celles à fort copyleft, elles sont plus permissives en ce qui a trait à la “viralité” de la protection qu’elles accordent, à la capacité d’“héritage forcé”. Elles sont notamment utilisées pour créer des bibliothèques qu’on peut utiliser dans un projet sans avoir à adopter une licence copyleft pour tout le projet. Seules les modifications apportées à la bibliothèque elle-même demeurent toujours sous licence copyleft.

Les plus connues sont LGPL, une version “atténuée” de GPL, MPL 2.0 de Mozilla et CDDL v1.0, initialement développée par Sun Microsystems.

Licences permissives

Les licences permissives n’imposent que de minimales contraintes dans l’utilisation, la distribution ou la modification des projets. De ce fait, elles sont toutes très similaires. Parmi les plus utilisées, on trouve Apache-2.0, BSD-2-Clause, BSD-3-Clause et MIT. Extrêmement permissives, elles ne nécessitent souvent guère plus que de mentionner les développeurs et la licence d’origine pour les portions de code réutilisé, dans les commentaires de votre code et/ou dans la documentation.

Licence de type domaine public

La seule licence de ce type approuvée par l’OSI est la Zero-Clause BSD (0BSD). Cette licence ne demande rien, pas même une attribution. Elle se résume à la phrase “l’autorisation d’utiliser, de copier, de modifier et/ou de distribuer ce logiciel à n’importe quelle fin, avec ou sans frais, est accordée par la présente”, suivie d’un paragraphe déclinant toute responsabilité de l’auteur pour tout éventuel dommage résultant de l’utilisation du programme fourni.

Aller plus loin

• Liste des licences approuvées par l’Open Source Initiative.
• La très intéressante Foire aux questions de l’OSI.
• Jim Salter, d’Ars Technica, propose une revue détaillée des principales licences approuvées par l’OSI : “Open source licenses: What, which, and why”.
• GitHub propose un outil très simple (mais peut-être trop simple) pour vous orienter dans votre choix : “Choose an open source license”.