Par son mécanisme de copyleft, l’Open Software License (OSL) offre aux créateurs de logiciels un cadre contractuel qui sécurise leurs droits tout en favorisant la circulation du code. Cet article décrypte son périmètre, son fonctionnement et les raisons de choisir (ou non) cette licence libre afin de guider les décideurs qui envisagent de l’adopter.
1. À qui s’adresse l’Open Software License ?
Destinée en priorité aux entreprises innovantes, start-up technologiques et éditeurs qui souhaitent publier leur code source sans pour autant renoncer à un contrôle juridique solide, l’Open Software License (OSL) cible un public bien plus large que les seuls développeurs passionnés.
D’abord, elle séduit les sociétés qui misent sur un modèle « open core ». Le cœur de l’application reste libre, alors que des modules premium sont commercialisés sous des conditions distinctes. Ensuite, elle parle aux collectivités, universités ou laboratoires publics tenus de respecter les principes de l’« open data » et d’une diffusion non discriminatoire des résultats de la recherche. Enfin, les intégrateurs et prestataires de services technologiques y trouvent un instrument fiable pour bâtir des offres de maintenance ou de conseil, puisque la licence garantit un accès pérenne au code et aux brevets éventuellement incorporés (articles L. 613-1 et L. 615-1 du Code de la Propriété intellectuelle). Ainsi, l’OSL s’adresse à tous ceux qui veulent concilier partage et sécurité, tout en évitant les incertitudes liées à la multiplicité de licences permissives moins protectrices.
2. Comment fonctionne concrètement la licence ?
Sur le plan juridique, l’OSL repose sur un contrat de licence non exclusif, gratuit et perpétuel qui couvre à la fois les droits d’auteur (articles L. 122-6 et suivants du Code de la Propriété Intellectuelle) et les brevets pertinents. Le licencié peut copier, modifier et distribuer le logiciel, y compris en sous-licence, à la condition impérative de conserver le même texte de licence : c’est l’effet copyleft.
Une clause dite de « déploiement externe » étend l’obligation de partage du code aux scénarios SaaS (Software as a Service). Ainsi, la simple mise à disposition du logiciel via réseau est assimilée à une distribution.
Par ailleurs, toute action en contrefaçon de brevet dirigée contre l’auteur ou un autre utilisateur entraîne la résiliation automatique des droits accordés par l’OSL, créant un puissant effet dissuasif. La licence contient également une limitation de garantie qui renvoie au minimum légal. Enfin, toute procédure doit être portée devant les tribunaux du siège social du concédant, ce qui simplifie la défense en cas de litige international.
3. Quels avantages et inconvénients pour l’entreprise ?
Le premier atout de l’OSL est sa portée étendue. Brevets et droits d’auteur sont couverts, réduisant le risque de brevets « piégés » qui bloqueraient l’exploitation du logiciel. De plus, la clause de déploiement externe évite qu’un tiers garde ses améliorations derrière une interface web propriétaire.
L’obligation de réciprocité sur les brevets instaure un « pot commun ». Chacun bénéficie donc des inventions des autres, ce qui limite la menace. Cependant, cette rigidité peut inquiéter certains investisseurs : impossible de relicencier sous une forme propriétaire sans accord unanime des contributeurs. Par ailleurs, la compatibilité avec d’autres licences copyleft reste délicate. La Free Software Foundation considère que l’OSL n’est pas totalement compatible avec la GPL v3, ce qui complique les projets multi-licences.
Enfin, l’élection de for obligatoire peut décourager des partenaires étrangers peu familiers du droit français ou américain.
4. OSL, GPL, MPL : comment choisir ?
- Comparée à la GPL v3, l’OSL se rapproche par l’effet copyleft mais va plus loin sur la question des brevets et du SaaS. La GPL oblige seulement à publier le code en cas de distribution de copies. La mise à disposition en mode service n’est pas couverte, sauf ajout de la clause « Affero ».
- La Mozilla Public License (MPL 2.0) est, elle, semi-copyleft. Seule la partie modifiée doit être redistribuée, permettant un usage mixte avec du code propriétaire, atout apprécié des éditeurs qui veulent garder une « part secrète ».
- À l’inverse, la licence Apache 2.0 est permissive. Elle autorise l’incorporation du code dans un produit fermé, mais exige la mention des brevets octroyés.
En résumé, si votre priorité est de recevoir les améliorations de tous vos utilisateurs, optez pour l’OSL ou la GPL. Si vous souhaitez davantage de souplesse commerciale, la MPL ou l’Apache 2.0 peuvent être plus adaptées. Dans tous les cas, la cohérence du portefeuille de licences est essentielle. Intégrer du code OSL dans une base Apache crée une incompatibilité juridique qui pourrait bloquer une levée de fonds ou une cession d’actifs logiciels. Ces questions de compatibilité peuvent être illustrées par le tableau ci-dessous.
Source : Benjamin Jean, Option libre, Du bon usage des licences libres, Frambook, 2011.
Conclusion
L’Open Software License offre un équilibre subtil entre partage communautaire et maîtrise juridique : copyleft fort, couverture des brevets, clause SaaS et limitation de garantie minimale. Ce cocktail séduit les organisations qui veulent diffuser leur logiciel tout en s’assurant un retour des contributions. Toutefois, sa rigidité et son incompatibilité avec certaines licences imposent une analyse détaillée du projet, de la stratégie commerciale et des contraintes de financement.
Deshoulières Avocats vous conseille et vous accompagne dans le choix, la rédaction et la mise en conformité de vos licences libres, afin de sécuriser la valorisation de vos actifs logiciels et de prévenir tout litige.
RESSOURCES :
- Open Software License v 3.0, texte original (opensource.org)
- Directive 2009/24/CE du 23 avril 2009 sur la protection juridique des programmes d’ordinateur
- « Licence GNU GPL : entre protection juridique et diffusion ouverte du code », Deshoulières Avocats
