Comprendre les licences open source (2021)

Laurent Gloaguen

English

Il est important de comprendre qu’il ne suffit pas de mettre gratuitement du code à la disposition des gens, pour que celui-ci soit considéré comme libre et ouvert, ou “open source”. Du code librement disponible sans licence clairement déclarée est implicitement intégralement protégé par le droit d’auteur dans la plupart des juridictions. Il serait donc risqué de l’utiliser, car vous ne savez rien des intentions présentes ou futures de son auteur et vous risqueriez ultérieurement des poursuites.

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

Understanding Open Source Licensing

Does “open source” mean “freely available”? Nope. That is important to understand. Code that is freely available without a clearly stated license is implicitly fully protected by copyright in most jurisdictions. Given that they know nothing about the present or future intentions of its author, users could eventually risk being sued.

To make your code free and open, you should assign it a license that grants specific permissions to potential users. In practice, each code file should have a comment line that details the identity of the author and the selected distribution license. You also need to place a complete copy of the license in the root folder of your project, in a file with an explicit name (for example, “licence.txt”).

But before getting to this point, you must first choose a license. This is not as complicated as it may seem. However, a couple of case exceptions come to mind: when you don’t have a clear idea of the permissions you want to grant, or when complex projects involve patented parts.

No License = Protected Code

Most countries’ legislation includes laws to protect the production of intellectual works. Whether this protection is called copyright (in common law) or author’s rights (in civil law), it is harmonized under international agreements such as the Berne Convention and through the work of institutions such as the World Intellectual Property Organization (WIPO).

The provisions of the Berne Convention were adapted to the digital world in 1996, extending protection to computer programs and databases. As a result, the code you create is an intellectual work and is covered by copyright/author’s rights protection.

Even without a copyright notice featuring the author’s name at the beginning of your code, it remains fully protected. You retain the rights to use and distribute this code, even if it is downloadable by third parties. You retain the right to sue anyone using your code. You may grant discrete licenses to individuals or organizations to use this code.

Home-Made License

Don’t bother with home-made licensing. It’s a waste of time. As you’re probably not a lawyer specialized in the field, the terms of your license might betray you by opening the door to uses you couldn’t foresee. There are enough types of licenses out there, including those approved by the Open Source Initiative (OSI), that you don’t need to write your own. OSI-approved licenses have been written or reviewed by experts and lawyers, and many have even passed the test in court.

Furthermore, you can’t expect users to read and understand an untried license. When a person or company wants to use a project licensed under the GPL-3.0, Apache-2.0, or MIT licenses, they are in familiar territory. It’s quick and easy for them to determine whether the license in question grants sufficient rights for the use they want to make of your code.

Strong Copyleft Licenses

A copyleft license gives permission to use, modify and redistribute the code freely, but only if the original license remains intact, both in the original project and in any modification made to the original project. The first instance of this type of license was the GPL (General Public License) written by Richard Stallman for the GNU project. When you use code from a copyleft-licensed project in your own work that you then distribute, it must adopt exactly the same license as the source project.

The philosophy underpinning copyleft is to assure the contributing authors that their work will benefit the world and always remain free while preventing exploitation by companies that would give nothing back to the community. For example, if you write a fork of WordPress that is licensed under the GPL, you can only distribute it under the GPL. WordPress is distributed under the GPL because it is itself a fork of a GPL software, b2/cafelog, created by Michel Valdrighi in 2001. To put it more simply, all derivative projects inherit the license, even if the project has evolved considerably since the initial fork.

Among the most popular copyleft licenses are GPL-3.0 and AGPL-3.0, a version of the GPL that is better adapted to the use of programs running on servers.

Weak Copyleft Licenses

Essentially similar to those with strong copyleft, they are more permissive in terms of the “virality” of the protection they grant, the capacity for “forced inheritance.” In particular, weak copyleft licenses are attributed when creating libraries that may be reused without requiring a copyleft license for the entire project. Only modifications made to the library itself always remain under the copyleft license.

The best known are LGPL, an “attenuated” version of the GPL, Mozilla MPL 2.0 and CDDL v1.0, originally developed by Sun Microsystems. 

Permissive Licenses

Permissive licenses impose minimal constraints on the use, distribution, or modification of projects. As a result, they all look very similar. Among the most commonly used are Apache-2.0, BSD-2-Clause, BSD-3-Clause and MIT. Extremely permissive, they often require little more than mentioning the developers and the original license for portions of reused code in the comments of your code and/or in the documentation.

Public Domain License

The only license of this type approved by the OSI is the Zero-BSD Clause (0BSD). This license does not require anything, not even an attribution. It boils down to the sentence “Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted,” followed by a paragraph disclaiming any responsibility on the part of the author for any possible damage resulting from the use of the provided program.

Go Further