🎲 Article Aléatoire

Les licences open source en 2026 : un tournant pour les SaaS ?
Par Anna Miatrié

🎨 Introduction : L’art éphémère des licences

Imaginez une toile où chaque coup de pinceau, chaque couleur, représente une ligne de code. Depuis des décennies, les licences open source ont été cette toile collective, ouverte à tous, où chacun pouvait ajouter sa touche, modifier, partager, sans restriction. Mais aujourd’hui, cette toile se craquelle. Les éditeurs, comme des artistes déçus, retirent leurs œuvres des galeries publiques pour les placer dans des ateliers privés, accessibles seulement sous conditions.

En 2026, le paysage des licences open source a radicalement changé, et ces transformations ont des répercussions majeures sur les projets SaaS. Entre relicenciements massifs, retours partiels à l’open source, et nouvelles réglementations, les entreprises doivent naviguer dans un environnement de plus en plus complexe.

Ce n’est plus seulement une question de code, mais de stratégie, de conformité, et même de survie pour certains modèles économiques.

🔄 1. La grande migration : de l’open source au « source-available »

Un mouvement de fond
Depuis 2018, une tendance lourde s’est imposée : les éditeurs majeurs quittent les licences open source approuvées par l’Open Source Initiative (OSI) pour adopter des licences dites « source-available ». Ces licences, bien que rendant le code visible, imposent des restrictions strictes, notamment pour empêcher les cloud providers de monétiser leur code sans contribuer en retour.

Exemples marquants :
- MongoDB (2018 → SSPL) : Une licence conçue pour empêcher les géants du cloud de proposer MongoDB comme service managé sans reverser de contributions.
- Elastic (2021) : Passage à une licence restrictive pour protéger son modèle économique.
- HashiCorp (2023 → BSL) : Terraform, Vault et d’autres outils phares sont désormais sous Business Source License, limitant leur usage commercial concurrent.
- Redis (2024 → RSALv2 + SSPL) : Une tentative de contrôle sur l’exploitation de sa base de données en mode SaaS.

Conséquences pour les SaaS
Si votre projet SaaS dépend de l’une de ces technologies, vous pourriez vous retrouver du jour au lendemain avec une restriction unilatérale sur votre droit à proposer ce service. L’audit des licences de toutes vos dépendances critiques devient une nécessité absolue.

> « Un algorithme, c’est comme une aquarelle : plus on ajoute de couches, plus l’image devient riche. Mais si quelqu’un vol votre toile, il faut savoir la protéger. »

🔁 2. Redis fait demi-tour : le retour à l’open source sous AGPLv3

Un revirement inattendu
En mai 2025, Redis a surpris la communauté en republiant Redis 8 sous AGPLv3, une licence approuvée par l’OSI. Ce retour à l’open source était une réponse aux critiques sur la restriction trop forte du SSPL. Mais l’AGPLv3 n’est pas une licence neutre pour les SaaS.

L’AGPLv3 : une licence qui « ferme la faille SaaS »
L’AGPLv3 (Affero General Public License) est une variante de la GPLv3 conçue pour combler la « faille SaaS » :
- Si vous modifiez du code AGPL et que vous le servez sur un réseau (comme un SaaS), vous devez partager vos modifications avec vos utilisateurs.
- Sinon, vous devez acheter une licence commerciale auprès de l’éditeur.

Pour un SaaS, intégrer de l’AGPL équivaut à :
✅ Obligation de divulgation du code (si vous le modifiez).
✅ Ou achat d’une licence commerciale pour éviter cette obligation.

> « Le code, comme une peinture, peut être admiré, copié, ou transformé. Mais si vous l’exposez dans votre galerie sans créditer l’artiste, vous risquez de devoir payer le prix fort. »

📜 3. La Business Source License (BSL 1.1) : le nouveau standard du « source-available »

Un modèle à bascule
La BSL, popularisée par HashiCorp, fonctionne selon un modèle temporel :
- Le code est visible et gratuit pour un usage interne ou sous un certain seuil.
- Mais il impose des restrictions sur l’usage commercial concurrent, notamment pour les services managés.
- Après 3 à 4 ans (la « change date »), la licence se convertit automatiquement en une licence open source classique (GPL, Apache, etc.).

Impact sur les SaaS
- Une dépendance sous BSL peut être gratuite aujourd’hui, mais interdire son utilisation en SaaS jusqu’à la date de conversion.
- Vérifiez les seuils et la date de conversion de chaque composant BSL dans votre stack.

> « La BSL, c’est comme une exposition temporaire : vous pouvez admirer l’œuvre, mais vous ne pouvez pas l’emporter chez vous avant la fin de l’exposition. »

⚖️ 4. MIT vs Apache 2.0 : le duel des licences permissives

MIT : la simplicité en question
La licence MIT a longtemps été la favorite des développeurs pour sa simplicité et sa permissivité. Cependant, elle ne contient aucune clause de protection contre les brevets, ce qui peut exposer votre SaaS à des risques juridiques.

Apache 2.0 : la nouvelle reine des SaaS
En 2026, Apache 2.0 est devenue la licence privilégiée pour les projets SaaS, car elle offre :
- Un grant de brevets explicite : protège contre les litiges liés aux brevets.
- Des clauses de contribution : assure une meilleure gouvernance des contributions.

Le copyleft recule : Les licences comme la GPLv3 deviennent rares dans les SaaS orientés client, au profit des licences permissives.

> « Choisir entre MIT et Apache 2.0, c’est comme choisir entre une toile vierge et une toile déjà apprêtée : la première est libre, mais la seconde vous protège des craquelures. »

🇪🇺 5. Nouveau cadre réglementaire : CRA et Open Source AI

Le Cyber Resilience Act (CRA) : une révolution pour la sécurité
Le Règlement européen 2024/2847 (CRA) impose de nouvelles obligations aux éditeurs de logiciels, y compris ceux intégrant des composants open source :
- Signalement des vulnérabilités actives dès le 11 septembre 2026.
- Conformité complète requise au 11 décembre 2027.
- Sanctions : jusqu’à 15 millions d’euros ou 2,5 % du chiffre d’affaires mondial.

Pour votre SaaS :
- Maintien d’un SBOM (Software Bill of Materials) pour tracer toutes vos dépendances.
- Mise en place d’un processus de signalement des vulnérabilités.

L’Open Source AI Definition (OSAID)
Validée par l’OSI fin 2024 et déployée en 2026, cette définition clarifie ce qu’est un modèle IA open source. Si votre SaaS intègre des modèles comme Llama, assurez-vous qu’ils répondent bien aux critères de l’OSAID — tous les modèles « open » en marketing ne le sont pas forcément selon l’OSI.

> « La réglementation, c’est comme le vernis sur une peinture : elle protège l’œuvre, mais elle peut aussi en altérer les couleurs si elle est mal appliquée. »

✅ Actions concrètes pour votre SaaS

1. Inventorier et auditer
- Listez toutes vos dépendances et identifiez leur licence exacte.
- ✅ MIT/Apache 2.0 : Sans risque majeur.
- ⚠️ AGPL/BSL/SSPL : À examiner de près.

2. Surveiller les relicenciements
- Suivez les annonces des éditeurs de vos dépendances critiques (Redis, Terraform, Elastic, MinIO, etc.).
- Utilisez des outils comme [FOSSA](https://fossa.com/) ou [Snyk](https://snyk.io/) pour automatiser la détection des changements de licence.

3. Choisir Apache 2.0 pour vos propres projets
- Privilégiez Apache 2.0 plutôt que MIT pour vos propres publications, afin de bénéficier de la protection brevet.

4. Éviter l’AGPL sans licence commerciale
- Si vous devez intégrer de l’AGPL, prévoyez :
- Un plan de divulgation de votre code modifié.
- Ou l’achat d’une licence commerciale auprès de l’éditeur.

5. Se préparer au CRA
- Générez un SBOM pour toutes vos dépendances.
- Mettez en place un processus de signalement des vulnérabilités conforme au CRA.
- Échéance : 11 septembre 2026 pour le signalement des vulnérabilités actives.

🖌️ Conclusion : Peindre l’avenir de votre SaaS

Les licences open source ne sont plus un simple détail technique. Elles sont devenues un élément stratégique pour les SaaS, avec des implications juridiques, économiques et même artistiques. Comme un peintre face à sa toile, vous devez choisir vos couleurs avec soin : chaque dépendance, chaque licence, chaque décision a un impact sur l’œuvre finale.

En 2026, la question n’est plus seulement « Puis-je utiliser ce code ? », mais aussi « À quel prix ? », « Sous quelles conditions ? », et « Quels risques pour demain ? ».

> « Le présent est un modèle 3D que nous sculptons à chaque instant, mais il fond comme de la cire sous les doigts. »

📚 Ressources et lectures complémentaires
- [Goodwin Law – Moving Away From Open Source](https://www.goodwinlaw.com/en/insights/publications/2024/09/insights-practices-moving-away-from-open-source-trends-in-licensing)
- [SoftwareSeni – MongoDB to Redis timeline 2018–2026](https://www.softwareseni.com/the-open-source-license-change-pattern-mongodb-to-redis-timeline-2018-to-2026-and-what-comes-next/)
- [Redis blog – AGPLv3](https://redis.io/blog/agplv3/)
- [InfoQ – Redis Returns to Open Source under AGPL](https://www.infoq.com/news/2025/05/redis-agpl-license/)
- [FOSSA – Business Source License](https://fossa.com/blog/business-source-license-requirements-provisions-history/)
- [Commission européenne – Cyber Resilience Act](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act)
- [OSI – Open Source AI Definition](https://opensource.org/2025-annual-report)

« Et vous, comment voyez-vous l’équilibre entre ouverture et protection dans votre projet SaaS ? »