Open source et IP Box : comment vos licences logicielles peuvent impacter votre avantage fiscal

Aujourd’hui, rares sont les logiciels développés sans composants open source. Frameworks, bibliothèques, modules utilitaires : l’open source est partout, et c’est une bonne chose. Il accélère le développement, réduit les coûts et permet de se concentrer sur ce qui crée de la valeur.

En parallèle, de plus en plus d’éditeurs de logiciels et de startups SaaS découvrent l’IP Box, ce dispositif fiscal qui permet de ramener le taux d’imposition de 25 % à 10 % sur les revenus issus de leurs logiciels. Un levier d’optimisation fiscale considérable, encore sous-exploité.

Or ces deux sujets, que l’on traite généralement séparément — l’un côté tech, l’autre côté fiscal — sont en réalité étroitement liés. Le type de licence open source que vous utilisez peut avoir un impact direct sur votre éligibilité à l’IP Box, et donc sur les économies d’impôt que vous pouvez réaliser.

Votre logiciel intègre des briques open source ? Vous envisagez l’IP Box ? Alors ce qui suit vous concerne directement.

1. L’IP Box pour les logiciels : rappel express

L’IP Box (officiellement « régime de taxation au taux réduit des revenus de certains actifs de propriété industrielle ») permet aux entreprises de bénéficier d’un taux d’imposition réduit à 10 % (au lieu de 25 %) sur les revenus issus de la cession, de la concession ou de la sous-concession de logiciels protégés par le droit d’auteur.

Pour en bénéficier, trois conditions essentielles doivent être réunies :

• Être titulaire des droits patrimoniaux sur le logiciel. C’est le point central : sans propriété, pas d’IP Box.

• Démontrer l’originalité du logiciel au sens du droit d’auteur : un effort personnalisé allant au-delà de la simple mise en œuvre d’une logique automatique.

• Percevoir des revenus issus de l’exploitation du logiciel : abonnements SaaS, vente de licences, redevances, refacturation intragroupe, etc.

Le résultat soumis au taux réduit se calcule ensuite en soustrayant les dépenses de R&D des revenus éligibles, puis en appliquant le ratio Nexus, qui mesure l’effort propre de l’entreprise dans le développement de l’actif.

À retenir

L’IP Box repose fondamentalement sur la démonstration que vous détenez les droits sur votre logiciel et que vous en tirez des revenus via la concession de ces droits. C’est précisément là que les licences open source entrent en jeu.

2. Licences open source : le paysage en clair

Toutes les licences open source ne se valent pas. La différence fondamentale tient à ce qu’elles exigent (ou non) de vous lorsque vous intégrez du code tiers dans votre propre logiciel.

Licences permissives : la voie libre

Les licences permissives (MIT, BSD, Apache 2.0) vous laissent une grande liberté. Vous pouvez intégrer le code dans un logiciel propriétaire, le modifier, le distribuer sous la licence de votre choix. La seule obligation est généralement de conserver la mention de copyright d’origine. Votre code reste le vôtre, fermé, protégé.

Licences copyleft (contaminantes) : attention danger

Les licences à copyleft fort (GPL v2/v3, AGPL 3.0, SSPL) fonctionnent sur un principe inverse : si vous intégrez un composant sous copyleft dans votre logiciel et que vous le distribuez, vous devez redistribuer l’ensemble de votre code source sous la même licence. C’est ce qu’on appelle l’effet viral ou « contaminant ». Votre code propriétaire « fermé » peut devenir « ouvert », vous faisant perdre l’exclusivité sur votre technologie.

La zone grise : LGPL et SaaS loophole

Entre les deux, il existe des situations intermédiaires. La LGPL (Lesser GPL) limite la contamination : si vous utilisez le composant via un lien dynamique (un fichier séparé chargé à l’exécution), votre propre code n’est pas soumis à la licence. En revanche, un lien statique (fusion dans un même fichier) déclenche la contamination.

Autre subtilité importante : la GPL ne considère pas l’accès via le réseau comme une distribution. Un SaaS pur peut donc utiliser du code GPL côté serveur sans être contraint de redistribuer son code. C’est ce qu’on appelle la « SaaS loophole ». Mais attention : l’AGPL 3.0 a été créée précisément pour fermer cette brèche. Elle impose la redistribution dès lors que des utilisateurs interagissent avec le logiciel via un réseau.

Vue d’ensemble

Licence	Type	Risque de contamination	Impact IP Box
MIT / BSD	Permissive	Aucun. Code propriétaire préservé.	Aucun impact négatif. Éligibilité préservée.
Apache 2.0	Permissive	Aucun. Clause brevets en plus.	Aucun impact négatif. Éligibilité préservée.
LGPL	Copyleft faible	Limité si lien dynamique. Fort si lien statique.	À analyser au cas par cas selon le mode d'intégration.
GPL v2 / v3	Copyleft fort	Élevé. Obligation de redistribuer le code source.	Risque sur la titularité et la capacité à concéder des licences.
AGPL 3.0	Copyleft fort	Très élevé. Même en mode SaaS.	Risque majeur : remet en cause le modèle de concession.
SSPL	Ultra-restrictive	Très élevé. Touche l'ensemble du service.	Incompatible avec une exploitation propriétaire.

3. Propriété du logiciel et droit d’auteur : le point de friction

C’est ici que les deux mondes se rencontrent.

Comme nous l’avons vu, l’IP Box repose sur une condition sine qua non : l’entreprise doit être titulaire des droits patrimoniaux sur le logiciel. C’est elle qui possède l’actif, c’est elle qui peut en concéder l’exploitation à des tiers, et c’est sur ces revenus de concession que s’applique le taux réduit.

Or, intégrer un composant sous licence contaminante ne vous transfère pas la propriété de ce composant — bien au contraire. La licence peut exiger que votre propre code devienne open source. Dit autrement : vous ne perdez pas la titularité de votre code au sens strict (vous en restez l’auteur), mais vous perdez la capacité de l’exploiter de manière exclusive. Et c’est cette capacité d’exploitation exclusive qui fonde l’intérêt de la concession de droits — et donc de l’IP Box.

Avec des licences permissives : pas de problème

Si vous utilisez uniquement des composants sous licence MIT, BSD ou Apache 2.0, la situation est claire. Vous pouvez les intégrer dans votre logiciel propriétaire sans que cela remette en question votre droit d’auteur sur les parties du code que vous avez développées. Votre capacité à concéder des licences d’exploitation reste intacte. L’IP Box s’applique normalement.

Avec des licences contaminantes : le doute s’installe

Si votre logiciel intègre des composants GPL, AGPL ou SSPL de manière non isolée (lien statique, copie de code, modification), la question devient : pouvez-vous encore valablement « concéder » un droit d’exploitation exclusif à vos clients ?

Si la réponse est non (ou à minima ambigüe) c’est l’ensemble du mécanisme IP Box qui se fragilise. L’administration fiscale pourrait contester que les revenus perçus correspondent à une véritable concession de droits de propriété intellectuelle, et donc refuser l’application du taux réduit.

Attention

Il ne s’agit pas de dire que tout usage d’open source est incompatible avec l’IP Box. La très grande majorité des logiciels intègrent de l’open source sans aucun problème. Le risque se concentre sur les licences contaminantes, mal intégrées ou non maîtrisées.

4. L’impact concret sur les revenus éligibles à l’IP Box

Au-delà de la question de principe sur la titularité des droits, les licences contaminantes posent des problèmes très pratiques dans le calcul de l’avantage fiscal.

La capacité à concéder une licence

L’IP Box taxe les revenus issus de la concession ou de la cession d’un droit d’exploitation. Or, si votre code est contaminé par une licence GPL, vous êtes théoriquement tenu de le redistribuer sous cette même licence, gratuitement. Peut-on encore parler de « concession d’un droit d’exploitation » au sens fiscal du terme ? La question mérite d’être posée — et anticipée.

L’isolement des revenus

Dans de nombreux cas, les contrats de licence ne portent pas uniquement sur le logiciel : ils incluent de la maintenance, de l’hébergement, de la formation, de la marque. Le régime IP Box impose de distinguer la part des revenus attribuable à la propriété intellectuelle. La présence de composants contaminants ajoute une couche de complexité supplémentaire : il faudrait potentiellement isoler les revenus attribuables aux seules parties du code dont vous maîtrisez pleinement les droits.

Le cas des SaaS : une fausse sécurité ?

Beaucoup d’éditeurs SaaS se sentent protégés par la « SaaS loophole » de la GPL : tant que le logiciel n’est pas distribué mais accédé via le réseau, pas d’obligation de redistribution. C’est vrai pour la GPL. Mais deux points méritent une vigilance particulière :

• L’AGPL ferme cette brèche et impose la redistribution même en accès réseau. Si votre stack inclut de l’AGPL (par exemple, certaines versions de MongoDB ou de projets Grafana), le risque est réel.

• Tout ce qui est exécuté côté client (code JavaScript chargé dans le navigateur, par exemple) est considéré comme de la distribution, même dans un modèle SaaS. La contamination GPL peut donc s’appliquer sur cette partie du code.

5. Et le ratio Nexus dans tout ça ?

Le ratio Nexus mesure l’effort propre de R&D de l’entreprise. Il se calcule en rapportant les dépenses internes et la sous-traitance indépendante (majorées de 30 %) à l’ensemble des dépenses de R&D (y compris sous-traitance liée et acquisitions).

Les composants open source gratuits (la majorité des cas) n’apparaissent pas comme des dépenses et n’impactent donc pas directement le ratio Nexus. En revanche, certaines situations méritent attention :

• L’acquisition de licences commerciales basées sur de l’open source (support, versions enterprise) constitue un coût d’acquisition qui entre au dénominateur du ratio Nexus et le dégrade.

• La réécriture de composants pour s’affranchir d’une licence contaminante génère des dépenses de R&D internes, ce qui est favorable au ratio Nexus (elles entrent au numérateur).

Il y a donc, paradoxalement, des situations où identifier une licence contaminante et décider de réécrire le composant concerné peut améliorer votre ratio Nexus. Encore faut-il avoir fait l’analyse en amont.

6. Le double audit : technique et fiscal

La bonne nouvelle, c’est que les bonnes pratiques pour sécuriser votre IP Box et celles pour anticiper un audit de due diligence (en vue d’une levée de fonds ou d’une cession) convergent largement. Voici les réflexes à adopter.

Cartographier vos dépendances

N’attendez pas un contrôle fiscal ou un investisseur pour faire le point. Des outils spécialisés (Black Duck, FOSSA, ou des solutions plus légères comme npm audit, pip-licenses, license-checker) permettent de détecter automatiquement l’ensemble des composants tiers utilisés dans votre code, y compris les dépendances transitives — c’est-à-dire les bibliothèques que vos bibliothèques appellent elles-mêmes.

Classifier le risque

Pour chaque composant identifié, évaluez le niveau de risque en croisant deux dimensions : le type de licence et le mode d’intégration. Un composant LGPL utilisé en lien dynamique dans un SaaS n’a pas le même profil de risque qu’un composant GPL copié directement dans votre code source.

Intégrer l’inventaire dans votre documentation IP Box

L’administration fiscale exige une documentation justificative qui inclut une description détaillée des actifs logiciels, de la méthodologie de calcul des revenus et des dépenses de R&D. Il est pertinent d’y intégrer :

• L’inventaire des composants open source utilisés et leur type de licence.

• Une démonstration que la titularité des droits n’est pas compromise par ces composants.

• Le mode d’intégration retenu et la justification de l’absence de contamination.

Cette démarche renforce considérablement la solidité de votre dossier en cas de contrôle.

Mettre en place une gouvernance technique

La prévention est toujours plus efficace que la réparation. Cela passe par une politique interne claire : validation systématique des licences avant intégration de tout nouveau composant, clauses de cession de droits dans les contrats avec les prestataires externes, et sensibilisation des équipes de développement à ces enjeux. Ce n’est pas de la bureaucratie : c’est de l’hygiène élémentaire qui protège à la fois votre PI et votre avantage fiscal.

7. Points d’attention spécifiques

Groupes de sociétés et prix de transfert

Si une société développe le logiciel avec des composants contaminants et concède les droits à une société filiale, le problème se dédouble : au risque lié à la contamination s’ajoute la nécessité de justifier le prix de la redevance intragroupe. L’administration pourrait légitimement questionner la valeur d’un actif dont l’exclusivité est fragilisée par une licence copyleft.

Code généré par l’IA : un risque émergent

Les outils d’assistance au développement (GitHub Copilot, ChatGPT, etc.) génèrent du code à partir de modèles entraînés sur des bases qui incluent du code open source. Des fragments de code sous licence contaminante peuvent ainsi s’infiltrer dans votre logiciel à votre insu. C’est un sujet encore peu traité, mais qui devrait figurer dans votre politique de gouvernance technique.

Due diligence et valorisation

L’IP Box fait désormais partie des éléments systématiquement examinés lors des due diligence fiscales en cas d’acquisition. Une contamination par licence copyleft découverte à ce stade peut simultanément faire tomber l’avantage IP Box et réduire la valorisation de l’entreprise. Double peine.

Attention

Les licences contaminantes représentent un double risque : elles menacent la valorisation de votre PI lors d’une levée ou d’une cession, et elles peuvent remettre en cause votre éligibilité au régime IP Box. Une bonne gouvernance open source n’est pas seulement un sujet technique : c’est un prérequis fiscal.

En résumé

L’open source est un atout formidable pour le développement logiciel. Mais comme tout outil puissant, il demande de la rigueur dans son utilisation. La distinction entre licences permissives et contaminantes n’est pas un détail technique réservé aux juristes en propriété intellectuelle : c’est un enjeu stratégique qui touche à la fois votre capacité à lever des fonds, à céder votre entreprise, et à bénéficier d’un avantage fiscal significatif.

Les bons réflexes ne sont pas compliqués à mettre en place : cartographier ses dépendances, classifier les risques, intégrer cette analyse dans la documentation IP Box, et installer une gouvernance technique. Le plus dur, c’est souvent de s’y mettre.

Chez Exoqua, nous accompagnons les éditeurs de logiciels et les startups SaaS dans la mise en place de leur IP Box, de l’évaluation de l’éligibilité jusqu’à la documentation justificative.

Si vous utilisez de l’open source, nous vous aidons à analyser l’interaction entre vos licences et votre avantage fiscal. Nous ne remplaçons pas vos avocats en propriété intellectuelle : nous travaillons avec eux pour que maximiser la conformité de votre dossier, aussi bien en cas de contrôle fiscal qu’en cas de due diligence.