Licences open source : GPL ou MIT et les obligations

Page du service : Commerce numérique et IA : un avocat pour les conditions générales, la vie privée et la prospection directe.

L’open source : sans paiement, mais pas sans obligations

Un scénario connu : une start-up intègre dans son produit une bibliothèque open source sous licence GPL. Deux ans plus tard, lors de l’audit préalable (due diligence) avant une acquisition, l’acquéreur découvre la violation. L’opération est retardée, et le problème doit être résolu par des semaines de travail juridique et de programmation. Ce n’est pas un scénario imaginaire : c’est ainsi que cela se passe en pratique.

Le mythe répandu : « open source = libre d’utilisation ». C’est en partie vrai. Le code ne coûte rien, mais il n’est pas libre d’obligations. Chaque licence open source est un contrat juridique à part entière, et le non-respect de ses conditions peut aboutir à une action pour atteinte au droit d’auteur, au retard d’opérations et à une atteinte à la réputation.

Les principales licences et ce qu’elles exigent

MIT et Apache 2.0 : les licences les plus permissives. Elles permettent l’usage commercial, les modifications et l’intégration dans du code propriétaire. Exigence principale : mentionner l’attribution d’origine (attribution). Des sociétés comme Google et Microsoft apprécient ces licences.

GPL (GNU General Public License) : une « licence virale ». Si vous avez intégré du code GPL dans un produit que vous distribuez, vous devrez accorder une licence GPL sur l’ensemble de l’œuvre combinée et remettre son code source à ceux qui la reçoivent (articles 5(c) et 6 de la licence GPLv3). Un usage interne sans distribution ne déclenche pas cette obligation (article 2). Pour des sociétés qui vendent des logiciels propriétaires, cela peut être destructeur.

LGPL : une version allégée de la GPL qui permet d’utiliser la bibliothèque sans « contaminer » tout le projet. Autrement dit, il est possible d’appeler une bibliothèque LGPL depuis du code propriétaire.

AGPL : une version plus stricte de la GPL. Celui qui a modifié le logiciel et permet aux utilisateurs d’interagir avec lui à distance par un réseau doit leur offrir le code source de sa version (article 13 de la licence), même sans distribuer de copie. C’est la licence qui fait le plus peur aux sociétés SaaS israéliennes.

Règle empirique : MIT et Apache conviennent à un usage commercial. Pour toute version de la GPL, un conseil juridique est nécessaire avant l’intégration dans du code propriétaire.

Que se passe-t-il en cas de violation d’une licence open source ?

Un usage qui dépasse les conditions d’une licence open source risque de constituer une atteinte au droit d’auteur (article 47), et pas seulement une violation du contrat. En Israël, la loi sur le droit d’auteur, 5768-2007 protège le programme d’ordinateur comme une œuvre littéraire (article 1). Un programme d’ordinateur n’a pas de droit moral (article 45(a)) : l’obligation d’attribution dans l’open source découle donc des conditions de la licence elle-même. Les recours comprennent l’injonction (article 53) et une indemnisation sans preuve du préjudice jusqu’à 100 000 ₪ par atteinte, les atteintes commises dans une même série d’actes étant considérées comme une seule atteinte (article 56).

Des organisations comme la Software Freedom Conservancy surveillent les violations de la GPL et engagent des actions en justice, y compris hors des États-Unis.

Vérifier le respect des licences

Toute société qui utilise de l’open source doit faire un « audit » des licences utilisées. Des outils comme FOSSA, Black Duck et Snyk le font automatiquement. Dans une opération de fusion-acquisition (M&A), la vérification des licences open source fait partie standard de l’audit préalable (due diligence).

La licence AGPL : le piège particulier des sociétés SaaS

La licence AGPL (GNU Affero General Public License) étend l’obligation de remettre le code source au cas où le logiciel n’est pas distribué du tout. Celui qui a modifié le logiciel et permet aux utilisateurs d’interagir avec lui à distance par un réseau doit leur offrir le code source de sa version (article 13 de la licence). Une société SaaS qui intègre une bibliothèque sous licence AGPL dans son service, sans distribuer la moindre copie du logiciel à l’utilisateur, peut être tenue d’offrir aux utilisateurs le code source de la version qu’elle a modifiée, et parfois aussi du code propriétaire écrit en interne, s’il fait partie de la même œuvre. C’est une surprise fréquente pour des développeurs qui ne connaissent que des licences permissives comme MIT ou Apache, et qui ne vérifient pas si un élément caché de la pile de dépendances (dependencies) a inclus l’AGPL.

Utiliser de l’open source dans une société israélienne : points à vérifier

Avant d’ajouter une bibliothèque open source à un produit, répondez à ces questions :

1. Quelle licence ? MIT/Apache : feu vert. GPL : drapeau rouge. AGPL : double drapeau rouge pour les services en nuage
2. Distribuez-vous le code ? Si oui, la GPL vous oblige à remettre à ceux qui le reçoivent le code source de l’œuvre combinée (articles 5(c) et 6 de la licence)
3. Avez-vous mentionné l’attribution ? Une attribution manquante (nom de l’auteur, lien vers la licence) est une violation fréquente, même avec MIT
4. Avez-vous vérifié les dépendances (dependencies) ? Pas seulement la bibliothèque elle-même, mais aussi ce qu’elle apporte avec elle. La GPL peut « contaminer » par une chaîne de dépendances
5. Avez-vous une politique interne ? Les sociétés matures exigent l’autorisation d’un responsable avant l’ajout de tout composant open source sous licence stricte

Que faire si vous avez découvert une violation ?

La bonne démarche :

• Ne continuez pas à exposer le code tant que vous n’avez pas compris l’étendue du problème
• Cartographie complète : FOSSA, Black Duck ou Snyk identifieront tous les composants problématiques
• Options de correction : remplacer la bibliothèque par une alternative sous une licence adaptée, acheter une licence commerciale à l’auteur (certaines bibliothèques GPL sont aussi proposées sous licence commerciale : dual licensing), ou publier le code
• Documentation de la correction : gardez une trace de ce qui a été corrigé et quand, ce qui est important pour un futur audit préalable (due diligence)

Questions fréquentes

Nous avons intégré une bibliothèque GPL dans le produit. Devons-nous remettre tout le code ?

Seulement si vous distribuez le produit. Si vous avez intégré du code GPL dans un produit que vous distribuez, vous devrez accorder une licence GPL sur l’ensemble de l’œuvre combinée et remettre son code source à ceux qui la reçoivent (articles 5(c) et 6 de la licence GPLv3). Un usage interne sans distribution ne déclenche pas cette obligation (article 2).

Peut-on utiliser une bibliothèque LGPL dans du code propriétaire ?

Oui. La LGPL est une version allégée de la GPL qui permet d’utiliser la bibliothèque sans « contaminer » tout le projet : il est donc possible d’appeler une bibliothèque LGPL depuis du code propriétaire.

Omettre l’attribution d’une licence MIT est-il une violation ?

Oui. Une attribution manquante (nom de l’auteur, lien vers la licence) est une violation fréquente, même avec MIT. Un programme d’ordinateur n’a pas de droit moral (article 45(a) de la loi sur le droit d’auteur) : l’obligation d’attribution dans l’open source découle donc des conditions de la licence elle-même.