Quelle licence adopter ?

La licence de style BSD

Apache et les projets de systèmes d'exploitation issus de BSD (FreeBSD, OpenBSD, NetBSD) l'emploient, et il peut être résumé par : « Voilà le code, employez-le comme bon vous semble, cela m'est égal. Mais faites toujours état de sa provenance. ». D'ordinaire, cette reconnaissance de l'origine est requise sous différentes formes (publicité, fichier LISEZ-MOI, ou dans la documentation imprimée, etc). D'aucuns affirment que cette exigence rend l'approche incompatible avec toute mise à l'échelle, c'est-à-dire que si quelqu'un publie un ensemble comprenant 40 modules libres sous licence BSD différents il pourrait y avoir 40 notes de copyright à afficher. En pratique cela ne pose jamais de problème, et en fait certains perçoivent ces exigences comme autant de forces positives destinées à faire prendre conscience de l'importance des logiciels libres.

Dans une perspective commerciale la licence BSD offre le meilleur contexte légal à tout nouveau participant, car elle ne laisse peser aucune inquiétude quant aux restrictions d'utilisation ou de redistribution. Vous pouvez mélanger ou comparer ce logiciel avec votre propre code propriétaire, et ne publier que ce qui, selon vous, fait progresser le projet et vous aide en retour. C'est pourquoi nous l'avons choisie pour Apache. Notre logiciel a été lancé par des webmestres commerciaux en quête d'un meilleur serveur Web pour leurs propres besoins commerciaux, contexte fort différent de celui que connurent beaucoup d'autres projets libres en phase de gestation. Vraisemblablement aucun des membres de l'équipe d'origine ne se proposait de créer un serveur commercial, aucun de nous ne savait ce que le futur nous apporterait, et nous ne souhaitions pas limiter de prime abord nos possibilités de choix.

Le groupe des développeurs d'Apache a aussi adopté ce type de licence car elle hisse à merveille un code donné en tant qu'implémentation de référence d'un protocole ou d'un service commun. Beaucoup souhaitaient voir HTTP survivre et devenir un vrai standard pluripartite, et nous n'étions absolument pas opposés à ce que Microsoft ou Netscape incorporent dans leurs produits notre moteur HTTP ou un quelconque autre composant de notre code si cela favorisait davantage l'érection de HTTP en tant que standard commun.

Ce degré d'ouverture comporte des risques. La licence ne contient aucune incitation destinée à encourager les entreprises à contribuer à améliorer le code, et donc le projet en retour. Il y a certainement eu dans l'histoire d'Apache des cas où des entreprises ont développé à partir d'Apache des approches que nous aurions voulues voir réincorporées. Mais une licence exigeant cela aurait peut-être a priori condamné de telles améliorations.

Tout cela signifie que, sur le plan stratégique, le projet a besoin d'un élan continu, et que les participants doivent réaliser davantage de bénéfices en contribuant au projet qu'en conservant par-devers eux leurs modifications. Cet état demeure délicat à maintenir, surtout si une entreprise décide d'augmenter le volume des efforts de développement qu'elle consacre à un projet dérivé et commence à douter du retour potentiel en proportion de sa contribution au projet. Les responsables s'exclament : « Nous menons à bien davantage de travail que tous les autres regroupés, et pourquoi devons-nous partager ? ». Je ne détiens pas de formule magique adaptée à ce scénario, mais affirme qu'en ce cas l'entreprise créatrice n'a probablement pas trouvé le meilleur moyen de susciter efficacement des contributions de tierces parties.

La licence publique de Mozilla (MPL)

L'équipe Mozilla de Netscape a mis au point la licence publique de Mozilla afin de protéger son projet. Cette dernière, parue plusieurs années après les autres, doit résoudre certains problèmes cruciaux posés par les licences BSD et GNU. Son style, dans le corps des groupes Open Source, ressemble surtout à celui de la licence BSD. Elles présentent toutefois deux différences majeures :

La MPL requiert que les modifications apportées à la « distribution » soient aussi publiées sous MPL, et restent ainsi intégrables au projet. « Distribution » désigne ici les fichiers du code source distribués. Cette importante disposition permet à une entreprise d'ajouter une interface à une bibliothèque de code propriétaire sans exiger que les autres bibliothèques de code soient aussi diffusées sous MPL, elle ne concerne que l'interface. Le logiciel ainsi couvert peut être plus ou moins inclus dans un environnement de produit commercial.

Plusieurs clauses de la MPL protègent à la fois le projet dans son ensemble et ses développeurs contre un brevet déposé sur le code contribué. Elle impose que l'entreprise ou la personne contribuant au projet abandonne tout droit découlant du code.

Il ne faut pas négliger l'importance de cette seconde clause, mais elle contient aussi aujourd'hui un gros défaut.

S'atteler à la question du brevet est une Très Bonne Chose. Une entreprise pourrait offrir le code à un projet afin d'essayer, après son intégration, de revendiquer ses droits pour son utilisation. Une telle stratégie commerciale pourrait paraître risible et serait très regrettable, mais malheureusement certaines sociétés n'ont pas encore saisi cela. Ainsi, la seconde clause interdit à quiconque de fournir subrepticement du code qu'il sait breveté, et de créer par là-même des ennuis à tous les autres participants.

Cela ne signifie pas qu'un tiers, détenteur d'un brevet, se manifeste ensuite. Aucun instrument légal n'offre de protection contre cela. En fait, je défendrais que cela doit faire l'objet d'une mission confiée à un nouveau service du bureau américain des brevets géré par le ministère du commerce et de l'industrie qui semble détenir le pouvoir d'attribuer certaines idées ou certains algorithmes et devraient donc être en mesure, réciproquement, de certifier qu'un code proposé est libre de droits, épargnant ainsi a priori au donateur tout tracas juridique.

Comme je l'ai dit ci-dessus, la licence MPL actuelle (décembre 1998) contient un défaut. Par essence, la section 2.2 précise (dans sa définition de « version du contributeur ») que le contributeur renonce aux droits sur toute partie de Mozilla et non seulement sur le code soumis. Cela ne semble pas fâcheux. De grandes entreprises collaboreraient ainsi sans contrainte.

Malheureusement, une certaine grosse entreprise détentrice de l'un des plus gros portefeuilles de brevets y voit un problème majeur. Non parce qu'elle a l'intention de demander un jour à Mozilla des royalties, ce qui paraîtrait fort téméraire. Mais elle est concernée car certaines parties de Mozilla utilisent des procédés dont elle détient les brevets grâce auxquels perçoit régulièrement d'importantes sommes d'argent. Elle ne souhaite donc pas renoncer à ses brevets sur le code de Mozilla, car les entreprises qui paient pour employer ces techniques incluraient alors le code de Mozilla correspondant dans leurs produits, sans leur servir de rente. Si la section 2.2 se référait simplement aux corrections contribuées plutôt qu'à l'ensemble du navigateur pour le renoncement aux brevets, ceci ne poserait pas de problème.

La licence MPL, si l'on écarte cette bizarrerie, demeure remarquablement solide. Exiger le retour des changements vers le « noyau » implique l'intégration des corrections essentielles de bogues et des améliorations, et laisse des entités commerciales développer des fonctionnalités à valeur ajoutée. La MPL reste peut-être la licence la plus adéquate pour des applications destinées à l'utilisateur final, où il est plus probable que les brevets posent problème, et où le dynamisme mène à la diversification des produits sous-jacents. Au contraire, la licence BSD est peut-être plus appropriée dans le cas d'un projet destiné à rester « invisible » ou de la réalisation de bibliothèques de fonctions essentielles, comme par exemple un système d'exploitation ou un serveur Web.

La licence publique GNU (GNU Public Licence, GPL)

Bien qu'à première vue elle n'incite guère au commerce, certains aspects de la licence GNU sont, croyez-le ou non, favorables à des objectifs commerciaux.

Fondamentalement, la GPL requiert la publication sous une même licence des améliorations, des dérivés, et même du code qui incorpore un code sous GPL. Des tenants du logiciel libre défendirent cette disposition « infectieuse » car elle constitue selon eux un moyen de s'assurer que le code libre le demeure et qu'aucune entité ne propose sa propre version du logiciel sans la rendre publique. Ceux qui placent leur logiciel sous GPL préfèrent priver le projet d'une contribution plutôt que de risquer de ne pouvoir l'utiliser librement. Cette approche présente un certain attrait d'ordre théorique, bien sûr, et certains affirment que le succès de Linux doit beaucoup à la GPL, car une récupération commerciale, très tentante, aurait sinon perturbé de façon décisive la cohérence de son développement.

Ainsi, à première vue, la GPL semble peu compatible avec tout objectif commercial lié au logiciel libre. Les modèles traditionnels grâce auxquels la plus-value du logiciel se matérialise sous forme d'argent paraissent a priori écartés. Elle pourrait toutefois offrir un moyen extraordinairement efficace d'établir une plate-forme interdisant à un concurrent de proposer la sienne, et donc de vous protéger lorsque vous vous déclarez premier fournisseur de biens et de services pour elle.

La relation entre Cygnus™ et GCC illustrent bien cela. L'entreprise Cygnus™ assure de fréquentes et nombreuses modifications de GCC en le portant vers différents types de matériels. Elle verse la plus grande partie de ces modifications, en accord avec la GPL, sous forme de contributions à la distribution de GCC, et les rend donc disponibles. Cygnus™ facture ses prestations de portage et de maintenance, et non le code lui-même. L'histoire de Cygnus™ et de sa prééminence sur ce marché en font une société de référence pour ce type de service.

Si un concurrent tentait de concurrencer Cygnus™, il lui faudrait redistribuer ses modifications sous GPL. Cela signifie que GCC ne lui offrirait aucune niche technique ou commerciale exploitable sans donner à Cygnus™ la même occasion d'en prendre avantage. Cygnus™ a créé une situation dans laquelle les concurrents ne peuvent la concurrencer sur le plan technique, à moins de dépenser beaucoup de temps et d'argent et d'utiliser une autre plate-forme que GCC.

La GPL peut aussi être utilisée à des fins commerciales en tant que sentinelle technologique, proposée avec une version non GPL du même logiciel. Examinons par exemple le cas d'un excellent programme de chiffrement des connexions TCP/IP. Vous ne vous souciez pas des utilisations non commerciales ou même commerciales mais souhaitez percevoir des droits lorsque d'autres entreprises incluent le code dans un produit ou le redistribuent et réalisent des bénéfices. Si vous placez le code sous GPL, nul ne peut l'intégrer librement dans un produit commercial sans le placer sous GPL, et la plupart d'entre eux s'y refuseront. Cependant, si vous maintenez une branche séparée de votre projet non protégée par la GPL vous pouvez la breveter. Vous devez toutefois vous assurer que tout code apporté par des tiers est explicitement rendu disponible pour cette branche commerciale en déclarant que vous en restez seul auteur et restez libre d'y intégrer tout code soumis pour intégration dans la version sous GPL.

Cela offre à certaines entreprises un modèle commerciale viable. Transvirtual, à Berkeley, applique ce schéma à une machine virtuelle Java légère et à un projet de bibliothèque de classes. Selon certains le nombre de contributeurs attirés par un tel modèle s'avérera faible et les versions GPL et non GPL convergeront donc. À mon sens si vous traitez les contributeurs comme il se doit, peut-être même en leur offrant de l'argent ou tout autre forme de compensation (ils épaulent, après tout, votre approche commerciale), ce modèle devrait fonctionner.

Le champ d'action de la licence Open Source évoluera à mesure que les gens valideront les approches efficaces et écarteront les autres. Vous restez libre de mettre au point une nouvelle licence placée où bon vous semble dans le spectre disponible (représenté par BSD à ma droite et GPL à ma gauche). Ne négligez pas que ceux qui utilisent et étendent votre code se sentiront d'autant plus incités à continuer qu'ils se sentiront libres.