Rue du Sablon 2
1110 Morges
hello@vaudnumerique.ch
+41 21 561 34 97
Back

Qui possède votre code : salariés, cofondateurs partis et bibliothèques open source

TLDR — « Par auteur, on entend la personne physique qui a créé l’œuvre » (art. 6 LDA). Une société ne crée rien, elle ne peut qu’acquérir. La seule cession automatique du droit suisse en informatique est l’art. 17 LDA, et elle est doublement étroite : le logiciel uniquement, et seulement s’il a été créé par un travailleur « dans l’exercice de son activité au service de l’employeur et conformément à ses obligations contractuelles ». Design, textes, visuels, documentation et base de données restent chez leurs auteurs sans clause de cession. Le cofondateur non salarié des premiers mois, le stagiaire sans contrat écrit et le code antérieur à l’inscription au registre du commerce cassent la chaîne de titularité. Seconde moitié du dossier : une licence open source est un contrat, pas une absence de droits. Le copyleft de la GPL se déclenche à la distribution — « Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying » — mais l’AGPL vise l’usage en réseau : une dépendance AGPL dans un SaaS peut obliger à publier le code source du service.


Le principe : votre société n’a jamais rien créé

Le droit suisse ne connaît pas le work made for hire. Il rattache l’œuvre à un être humain, et à lui seul :

« Par auteur, on entend la personne physique qui a créé l’œuvre. » (art. 6 LDA)

Une SA ou une Sàrl n’est pas une personne physique : elle ne peut jamais être auteur, seulement cessionnaire. Le code est bien couvert — « Les programmes d’ordinateurs (logiciels) sont également considérés comme des œuvres » (art. 2 al. 3 LDA) — et l’Institut fédéral de la propriété intellectuelle en précise l’assiette : « Le droit d’auteur s’étend en particulier au code source des programmes d’ordinateur, mais il ne porte pas sur les algorithmes ». La méthode reste libre ; son expression est protégée. Rien à déposer non plus : « La protection […] naît automatiquement avec la création de l’œuvre. Il ne faut donc procéder à aucune formalité ni aucun enregistrement » (IPI). Il n’existe donc aucun registre où vérifier qui détient les droits sur votre produit : cette preuve, c’est à vous de la fabriquer, contrat par contrat, et elle doit tenir 50 ans après la mort de l’auteur pour un logiciel.

Les droits se transmettent, mais par un acte, et jamais plus loin que ce qu’il dit : « Sauf convention contraire, le transfert d’un des droits découlant du droit d’auteur n’implique pas le transfert d’autres droits partiels » (art. 16 al. 2 LDA). Céder le droit d’utiliser un module ne cède pas celui de le modifier. Et « le transfert de la propriété d’une œuvre, qu’il s’agisse de l’original ou d’une copie, n’implique pas celui de droits d’auteur » (art. 16 al. 3 LDA) : avoir les fichiers sur son dépôt Git n’est pas avoir les droits.

L’exception logicielle : l’art. 17 LDA et ses deux conditions

Il existe une exception, une seule, écrite en une phrase :

« L’employeur est seul autorisé à exercer les droits exclusifs d’utilisation sur le logiciel créé par le travailleur dans l’exercice de son activité au service de l’employeur et conformément à ses obligations contractuelles. » (art. 17 LDA)

Elle pose deux conditions cumulatives, qui ne disent pas la même chose.

« Dans l’exercice de son activité au service de l’employeur » : le logiciel doit avoir été écrit dans le cadre de la fonction, pas seulement pendant la durée du contrat. Le développeur qui code un projet personnel le week-end, sur son matériel, sur un sujet étranger à son cahier des charges, n’y est pas.

« Conformément à ses obligations contractuelles » : il faut encore que produire du logiciel entre dans ce que le contrat demande. Le growth manager ou le designer qui écrit un script d’automatisation utile à toute l’équipe est salarié et agit dans l’intérêt de la société, mais écrire du code ne fait pas partie de ses obligations : la condition n’est pas remplie. C’est le cas le plus souvent ignoré dans les petites structures, où tout le monde touche au dépôt.

Deux limites de plus. L’art. 17 n’attribue pas la titularité : il autorise l’employeur à exercer les droits exclusifs d’utilisation, l’auteur restant le développeur. Et il ne parle que du logiciel : pour tout le reste, on retombe sur les art. 6 et 16 LDA, où rien n’est cédé sans clause.

Ce que le salarié produit Ce que la société détient sans clause de cession
Code source, scripts d’infrastructure, tests L’exercice exclusif des droits d’utilisation, si les deux conditions de l’art. 17 LDA sont réunies
Maquettes, système de design, icônes, identité visuelle Rien d’automatique
Textes du produit, documentation, base de connaissances Rien d’automatique
Photographies, vidéos, illustrations de la marque Rien d’automatique
Structure et contenu d’une base de données Rien d’automatique ; protégée seulement si elle est un recueil au sens de l’art. 4 LDA
Invention brevetable ou design créé dans le cadre de la fonction Régime distinct de l’art. 332 CO, plus favorable à l’employeur que la LDA

L’art. 4 al. 1 LDA ne protège les recueils que s’ils constituent « des créations de l’esprit qui ont un caractère individuel en raison du choix ou de la disposition de leur contenu » : une table de clients triée par ordre alphabétique n’a rien d’individuel et se protège par le contrat, comme nous l’avons détaillé à propos de ce qu’un NDA protège vraiment. Le contraste avec le brevet est parlant : le CO attribue bien à l’employeur les inventions et les designs créés dans l’exercice de la fonction et conformément aux obligations contractuelles (art. 332 CO). Le législateur a su écrire une règle d’attribution générale ; pour le droit d’auteur, il ne l’a pas fait.

Les quatre cas qui cassent la chaîne

Le cofondateur non salarié

Le trou le plus coûteux, et le plus banal. L’un des trois fondateurs écrit le prototype pendant six mois, sans contrat ni salaire, avant même que la société existe, puis reçoit des parts à la constitution. Recevoir des actions n’est pas céder des droits d’auteur : pas de contrat de travail, donc pas d’art. 17 LDA ; pas de contrat du tout, donc pas de cession. Le prototype — souvent le noyau que le produit actuel n’a fait qu’étendre — appartient à une personne physique. Si elle est partie fâchée trois ans plus tôt, c’est elle que votre acquéreur devra retrouver et faire signer, en position de force.

Le stagiaire et le junior sans contrat écrit

Le contrat de travail n’exige pas la forme écrite : un stagiaire rémunéré et intégré à l’équipe est en règle générale un travailleur, et l’art. 17 LDA peut jouer. Le problème est probatoire. Sans écrit, vous ne démontrez ni le rapport de travail, ni surtout que produire ce logiciel relevait de ses obligations. Un stage « découverte » non rémunéré est plus fragile encore — et pour les maquettes du stagiaire designer, l’art. 17 ne joue de toute façon pas.

Le code écrit avant la société, ou le soir

Une société ne peut pas acquérir de droits avant d’exister. Ce qui a été écrit avant l’inscription au registre du commerce l’a été par des personnes physiques pour leur propre compte : la reprise se documente par une cession écrite signée de chaque fondateur à la constitution. Symétriquement, le projet personnel du soir échappe à l’art. 17. Le devoir de fidélité du travailleur (art. 321a CO) lui interdit de concurrencer son employeur pendant les rapports de travail, mais un devoir de loyauté n’est pas une cession : il empêche certains usages, il ne transfère rien.

Le prestataire externe

Le sous-traitant indépendant n’est pas un travailleur : l’art. 17 LDA ne s’applique pas, payer une facture ne transfère rien, et le raisonnement complet figure dans notre article sur la sous-traitance du développement à l’étranger.

Le droit moral : ce qu’il empêche vraiment

Le droit moral n’est pas cessible : il reste attaché à la personne de l’auteur, même après une cession patrimoniale complète. L’art. 11 al. 1 LDA lui réserve « le droit exclusif de décider […] si, quand et de quelle manière l’œuvre peut être modifiée » et si elle peut servir à créer une œuvre dérivée. L’al. 2 est celui qui survit à tout contrat :

« Même si un tiers est autorisé par un contrat ou par la loi à modifier l’œuvre ou à l’utiliser pour créer une œuvre dérivée, l’auteur peut s’opposer à toute altération de l’œuvre portant atteinte à sa personnalité. » (art. 11 al. 2 LDA)

Ce qu’il empêche : une altération portant atteinte à la personnalité de l’auteur — cas qui se rencontre sur une identité visuelle défigurée ou un texte signé dénaturé, rarement sur du code métier. Et le droit à la paternité.

Ce qu’il n’empêche pas, et c’est l’essentiel pour une équipe technique : refactoriser, réécrire ou supprimer le code d’un ancien développeur. Celui-ci ne peut pas davantage s’opposer à la vente de la société ni exiger que son nom figure dans l’interface. La parade n’est pas d’« acheter » le droit moral — c’est impossible — mais d’obtenir une renonciation écrite à son exercice, signée par la personne physique, à côté de la cession patrimoniale.

L’open source : un contrat, pas une absence de droits

« C’est open source, c’est gratuit, on peut l’utiliser. » Une licence open source est un contrat : elle autorise un usage sous conditions. Si vous ne les respectez pas, l’autorisation tombe et vous utilisez une œuvre protégée sans droit. Ce n’est plus un manquement contractuel mineur : c’est une contrefaçon, avec les actions en cessation, en dommages-intérêts et en remise du gain que la LDA ouvre à l’auteur. Le titulaire n’est pas une abstraction : c’est un mainteneur identifiable, souvent une fondation dotée de moyens juridiques.

Famille Licences typiques Obligation centrale Risque pour un produit propriétaire
Permissive MIT, BSD, Apache 2.0 Conserver la notice de copyright et le texte de licence Faible ; le risque réel est l’oubli de la notice
Copyleft faible ou de fichier LGPL, MPL 2.0 Publier les modifications des fichiers couverts Contenu ; le code propriétaire qui l’appelle reste en principe fermé
Copyleft fort GPL-2.0, GPL-3.0 Distribuer l’ensemble de l’œuvre sous la même licence, sources comprises Élevé, mais seulement en cas de distribution
Copyleft réseau AGPL-3.0 Offrir le code source aux utilisateurs qui interagissent avec le service à distance Élevé, y compris pour un SaaS qui ne distribue rien

La question qui décide de tout : y a-t-il distribution ?

La GPL-3.0 définit le fait de convey comme « any kind of propagation that enables other parties to make or receive copies », puis ajoute la phrase que tout éditeur de SaaS devrait connaître :

« Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying. » (GPL-3.0, section 0)

Un service en ligne qui n’expédie aucun binaire n’est donc, en principe, pas dans un cas de distribution au sens de la GPL : c’est pourquoi des milliers de SaaS tournent sur des piles GPL sans rien publier. L’exception commence dès que vous livrez quelque chose — application mobile, client lourd, agent installé chez le client, image Docker remise à un grand compte, version on-premise. Là il y a copie, donc distribution, et la section 5 let. c s’applique : « You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. »

L’AGPL-3.0 a été écrite pour fermer cette porte. Sa section 13 vise l’interaction à distance :

« Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge […] » (AGPL-3.0, section 13)

La conséquence est brutale : une dépendance AGPL intégrée à votre service, modifiée et exposée à vos utilisateurs par le réseau, peut vous obliger à mettre le code source correspondant à leur disposition, gratuitement. Pour un SaaS dont la valeur est le code, l’obligation vide la thèse d’investissement. Beaucoup d’éditeurs de bases de données et d’outils d’automatisation publient en AGPL pour cette raison, puis vendent une licence commerciale d’exemption : c’est un modèle d’affaires, pas un accident.

Les licences permissives ne sont pas sans obligations

La MIT autorise à peu près tout, à une condition : la notice de copyright et le texte de la licence doivent accompagner toutes les copies ou parties substantielles du logiciel. Un bundle JavaScript minifié qui a mangé les en-têtes viole la MIT — le manquement le plus répandu, et le plus simple à corriger par un écran d’attributions accessible depuis le produit.

Apache 2.0 impose quatre obligations en cas de redistribution (section 4) : remettre une copie de la licence, signaler les fichiers modifiés, conserver les mentions de copyright, de brevet, de marque et d’attribution, et reproduire le fichier NOTICE s’il existe. Elle ajoute surtout une licence de brevet expresse de chaque contributeur, « perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable ». Avec un interrupteur : si vous intentez une action en contrefaçon de brevet visant l’œuvre, « any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed ».

Cinq choses à mettre par écrit ce trimestre

  1. Une clause de cession large dans tout contrat de travail et de prestation : tous les droits patrimoniaux, sur tous les types d’œuvres — logiciel, design, textes, visuels, documentation, bases de données — de manière exclusive, mondiale, sans limite de durée, en mentionnant expressément le droit de modifier et de créer des œuvres dérivées, avec renonciation à l’exercice du droit moral. L’art. 16 al. 2 LDA n’étend jamais une cession partielle.
  2. Une cession rétroactive signée par chaque cofondateur et chaque ancien contributeur. Une page, couvrant tout ce qui a été créé avant et depuis la constitution. Faites-la signer tant que la relation est bonne : gratuite aujourd’hui, elle devient une ligne de négociation le jour où un acquéreur en fait une condition suspensive.
  3. Un inventaire des dépendances et de leurs licences — un SBOM (software bill of materials) généré à chaque construction, dépendances transitives comprises, conservé avec chaque version livrée. C’est là que se trouvent les surprises : le copyleft arrive rarement par une décision consciente, il arrive par la dépendance de la dépendance.
  4. Une politique open source d’une page : licences autorisées, licences interdites sans validation, qui décide d’une exception, et un contrôle automatisé qui bloque la fusion en cas de licence non conforme.
  5. Une documentation de l’origine du code : historique Git attribué à des identités réelles, registre des contributeurs externes, journal des composants repris d’un projet antérieur. C’est la seule preuve que vous produirez le jour où quelqu’un demandera qui a écrit quoi.

Sources primaires

  • LDA, loi fédérale sur le droit d’auteur et les droits voisins, RS 231.1, Fedlex, état le 1er janvier 2022 — art. 2 al. 3, 4, 6, 11, 16, 17.
  • Code des obligations, RS 220 — art. 321a et 332 (voir l’avertissement).
  • Institut fédéral de la propriété intellectuelle (IPI, ige.ch), « Droit d’auteur — notions fondamentales » : naissance automatique de la protection, protection du code source et non des algorithmes, durée de 70 ans et de 50 ans pour les logiciels.
  • GNU General Public License version 3 (GPL-3.0), texte publié par l’Open Source Initiative — section 0, section 5 let. c.
  • GNU Affero General Public License version 3 (AGPL-3.0), texte publié par l’Open Source Initiative — sections 0, 6 et 13.
  • Apache License 2.0, texte publié par l’Open Source Initiative — sections 3 et 4.

Avertissement — La FVN est une fédération professionnelle, pas une étude d’avocats. Ce texte est un repère de gestion, non un avis de droit.

État des textes consultés : LDA au 1er janvier 2022 sur Fedlex. La liste des versions n’y étant pas consultable sans JavaScript, nous n’avons pas pu confirmer qu’aucune modification de la LDA n’est entrée en vigueur depuis cette date.

Ce qui n’a pas pu être vérifié dans sa version officielle : les art. 321a et 332 CO — le fichier Fedlex du Code des obligations est tronqué à l’art. 191 par l’outil de consultation utilisé ; ces deux dispositions sont ici reformulées, non citées entre guillemets, et leur teneur exacte doit être vérifiée à la source. Nous n’avons pas pu ouvrir gnu.org (robots.txt) : les passages de la GPL-3.0 et de l’AGPL-3.0 sont cités d’après la publication de l’Open Source Initiative, non d’après celle de la Free Software Foundation. Le texte de la licence MIT n’a pas pu être reproduit verbatim ; son obligation de notice est reformulée. L’affirmation selon laquelle le droit suisse ne connaît pas de droit voisin propre au producteur de base de données, comparable au droit sui generis de l’Union européenne, n’a pas été vérifiée sur une source primaire. Enfin, la qualification d’une dépendance donnée — liaison statique ou dynamique, œuvre dérivée ou œuvre séparée, portée de la section 13 AGPL sur un composant non modifié — dépend de l’architecture concrète et n’est pas tranchée ici.

Pour une clause de cession, une régularisation rétroactive avec d’anciens contributeurs ou une question de compatibilité de licences avant une levée, adressez-vous à un mandataire qualifié en propriété intellectuelle.

Haider Alleg
Haider Alleg
https://haideralleg.com/
Entrepreneur Haider developed a toolbox for bringing brand performances to life, helping organisations of various shapes and sizes navigate the unknown and generate growth. This led him to build Kainjoo in 2012, a fast-growing consulting firm supporting ambitious leaders from top 500 Fortune companies. With Allegory Capital, he supports regulated industries to innovate through portfolios of emerging tech and channels.

Leave a Reply

Your email address will not be published. Required fields are marked *