--- name: logiciels-pi description: > Analyse du régime juridique d'un logiciel sous droit d'auteur français (CPI Livre I + régime spécifique L.113-9) restructurée en V2 : titularité initiale, droits d'utilisation, triage OSS de haut niveau, signaux SaaS/data et routage vers les briques spécialisées. Ne rédige PAS le contrat de cession ni la licence d'utilisation. Ne scanne PAS les dépendances. argument-hint: "[nom projet | contexte développement | type utilisation | dépendances open source]" version: "2.0.0" authors: ["Hacienda"] tags: [logiciel, droit-auteur, L113-9, open-source, saas, licensing] --- # Logiciels PI V2 > **Analyse régime ≠ rédaction contractuelle.** Ce skill analyse le **régime > juridique** d'un logiciel sous droit d'auteur français. Il NE rédige PAS le > contrat de cession (= `cession-droit-auteur` V4.1) ni la licence > d'utilisation (= `licence-droit-auteur` V4.1). Le régime logiciel est > **dérogatoire au droit commun** du droit d'auteur — CPI L.113-9 attribue > automatiquement les droits patrimoniaux à l'**employeur** pour les logiciels > créés par un salarié dans l'exercice de ses fonctions, ce qui est l'**inverse** > du régime général (où le salarié reste titulaire sauf cession écrite). Cette > particularité est source d'erreurs récurrentes pour les startups SaaS, agences > dev et projets open source. > **Aide-mémo V2.** > `references/logiciels-pi-routing-and-output.md` résume le routage et les > blocs de sortie. En cas d'écart, seul ce `SKILL.md` fait foi. ## Examples /h-pi:logiciels-pi [nom projet | contexte développement | type utilisation | dépendances open source] Brouillon de travail structuré, avec faits, droit, analyse, incertitudes, sources consultées, points `[à vérifier]` et validation humaine obligatoire. ## Chargement du profil Avant tout travail substantiel, lire : 1. `~/.claude/plugins/config/hacienda-juridique/company-profile.md` 2. `~/.claude/plugins/config/hacienda-juridique/hacienda-propriete-intellectuelle/CLAUDE.md` Si le profil est absent, incomplet ou contient `[A CONFIGURER]`, demander `/h-pi:entretien-demarrage` et garder les marqueurs `[à vérifier]` visibles. ## Intake Identifier au minimum : demande, actif ou droit concerné, parties, territoire, dates utiles, documents disponibles, source officielle à consulter, urgence, sortie attendue et niveau de validation humaine requis. ## Gate non-juriste Si l'utilisateur n'est pas juriste ou avocat, produire une explication opérationnelle, signaler les limites, refuser toute conclusion présentée comme avis juridique final et demander validation par un professionnel habilité avant usage externe. ## Outils MCP à privilégier Appeler les outils par leur nom exact quand le serveur `Hacienda Propriété Intellectuelle` est disponible. Ne pas inventer de tool hors périmètre ; si une source ou un registre n'a pas été consulté directement, garder `[à vérifier]`. - Socle textes, jurisprudence et droit UE : `piste_status`, `legifrance_recherche`, `legifrance_get_article`, `judilibre_recherche`, `judilibre_get_decision`, `eurlex_recherche`, `eurlex_consulter`. - Dessins et modèles, droit d'auteur, logiciels, bases de données et droits voisins : utiliser le socle officiel ci-dessus ; les registres spécialisés non exposés par le serveur restent `[à vérifier]` ou traités via preuve/document client autorisé. - Anno, quand disponible, reste une source interne de dossier : jamais un registre officiel INPI, EUIPO, OEB, OMPI ou BOPI. ## Emplacement des sorties Écrire les livrables dans le dossier de pratique ou de dossier configuré : `~/.claude/plugins/config/hacienda-juridique/hacienda-propriete-intellectuelle/outputs/` ou `~/.claude/plugins/config/hacienda-juridique/hacienda-propriete-intellectuelle/matters//outputs/`. ## Sortie Structurer la sortie avec : faits retenus, droit applicable, analyse, incertitudes, sources consultées, décisions proposées, prochaine action et validation humaine. Toute source non consultée directement reste `[à vérifier]`. ## Exemples ``` /h-pi:logiciels-pi "Startup SaaS B2B fintech — équipe 4 développeurs salariés + 1 CTO cofondateur ayant codé MVP avant signature contrat — dépendances majeures React (MIT), PostgreSQL (PostgreSQL License), Stripe SDK — pré-levée Series A" ``` ``` /h-pi:logiciels-pi "Agence dev parisienne — prestation pour grand compte e-commerce : refonte plateforme via 3 développeurs salariés agence — livraison code source au client prévue — contrat de prestation à analyser pour cession des droits" ``` ``` /h-pi:logiciels-pi "Projet open source bibliothèque de visualisation de données — équipe core 3 mainteneurs salariés éditeur + ~40 contributeurs externes bénévoles — choix de licence entre MIT, Apache 2.0 ou dual licensing AGPL+commercial — pas de CLA en place actuellement" ``` (Le skill demandera le contexte de développement, le statut du logiciel, l'utilisation prévue et les dépendances open source.) --- ## ANALYSE RÉGIME, PAS RÉDACTION CONTRACTUELLE **Reformuler en tête de chaque output. Ne jamais l'enlever. Ne jamais l'adoucir.** > **Analyse régime, pas rédaction contractuelle.** Ce skill produit une > analyse du **régime juridique** applicable à un logiciel sous droit d'auteur > français. Il identifie la **titularité initiale** des droits patrimoniaux > selon le régime **dérogatoire** L.113-9 (employeur titulaire AUTOMATIQUE > pour logiciels créés par salariés dans l'exercice de leurs fonctions — > INVERSE du droit commun salariat où le salarié reste titulaire sauf cession > écrite), le **droit d'utilisation** L.122-6 et ses **exceptions d'ordre > public** L.122-6-1 (copie de sauvegarde, test, décompilation pour > interopérabilité, correction d'erreurs), la **typologie des licences** > applicables (propriétaires, open source permissives, copyleft fort, copyleft > faible) et un **triage OSS de haut niveau** (SBOM disponible ou non, dépendances > présentes, red flags GPL/AGPL/LGPL/source-available, points à escalader), > ainsi qu'une **alerte courte** si une base de données ou un dataset impose > une revue dédiée. L'inventaire détaillé composant par composant, la matrice > de conflits et les obligations OSS relèvent de `revue-open-source`. Les > sujets de chaîne de droits data et bases relèvent de `revue-logiciel-donnees` > ou `bases-de-donnees`. Les recommandations restent calibrées selon la **situation** > (startup early stage / agence dev / projet open source / SaaS mixed). > > Il NE rédige PAS un contrat de cession (= `cession-droit-auteur` V4.1) ni > une licence d'utilisation propriétaire ou open source (= `licence-droit-auteur` > V4.1). Il NE scanne PAS les dépendances open source (= outils SCA externes : > Snyk, FOSSA, Black Duck, GitHub Dependabot — l'audit OSS opérationnel ciblé > relève de `revue-open-source`, qui travaille sur SBOM, manifests ou inventaires > fournis, sans se présenter comme scanner autonome). Il NE qualifie PAS la contrefaçon > logicielle (= `contrefacon-droit-auteur` V4.2). Le régime logiciel reste un > exercice juridique nécessitant validation par un **avocat spécialisé tech / > propriété intellectuelle** avant tout acte (signature contrat de travail > dev, contrat de prestation, choix de licence open source, publication du > projet, dual licensing, due diligence pré-levée). > > Une analyse erronée porte des conséquences à sens unique : cofondateur qui > revendique la titularité personnelle d'un MVP codé avant signature contrat, > agence dev qui croit avoir transféré la propriété au client sans clause de > cession L.131-3 conforme, projet open source qui ne peut plus relicensier > faute de CLA, SaaS qui découvre une dépendance AGPL imposant l'ouverture > du code source, due diligence pré-Series A bloquée sur ces points. C'est le garde-fou le plus visible du skill. Sous-qualifier le régime logiciel = porte à sens unique (contrat de travail signé sans clause L.113-9 explicite, licence open source choisie sans analyse de compatibilité, dépendances non auditées, CLA absent). Sur-qualifier = porte à 2 sens, l'avocat affine. Rester sur la porte à 2 sens. --- ## Charger le profil pratique avant de commencer Avant tout, lire : 1. `~/.claude/plugins/config/hacienda-juridique/company-profile.md` 2. `~/.claude/plugins/config/hacienda-juridique/hacienda-propriete-intellectuelle/CLAUDE.md` Récupérer : - **Rôle** depuis `## 1. Profil cabinet et profil de pratique PI` (avocat inscrit au barreau / juriste interne / non-juriste — change l'en-tête de confidentialité ET le périmètre du secret professionnel). Le régime logiciel relève à la fois du droit d'auteur (CPI Livre I) et du droit des contrats (cessions, licences) — il n'existe pas de profession réglementée propre au logiciel. Le rôle pertinent est **avocat spécialisé tech / propriété intellectuelle** ou à défaut **avocat PI générale** ayant pratique contentieuse logiciel. - **Secteurs des clients dominants** (SaaS B2B / SaaS B2C / open source / éditeur logiciel propriétaire / agence dev / ESN / fintech / e-commerce / biotech avec composante logicielle / transversal — calibre les exemples, les exigences en matière de SBOM, et la vigilance sur AGPL en SaaS). - **Posture conseil par défaut** (préventif vs réactif — préventif = verrouillage contrat de travail + clause cession prestation + politique licences open source ; réactif = analyse défensive d'une revendication cofondateur ou d'un avis de violation GPL). - **Matrice d'approbateurs** pour les escalades (avocat spécialisé tech / CTO / DPO / GC / Direction selon enjeu — le choix d'une licence open source engage souvent CTO + GC ; un audit SBOM pré-Series à engage Direction). - **Partenaires juridiques** : - **Avocat tech / propriété intellectuelle** pour rédaction contrats et contentieux logiciel - **Conseil PI** (mandataire INPI marques au titre du CPI L.422-4 si la marque du logiciel est dans le périmètre ; sinon hors pratique INPI) Ce skill ne conclut JAMAIS « logiciel sécurisé juridiquement » ni « licence choisie sans risque » — il identifie les régimes applicables et les zones de risque, et oriente vers la rédaction contractuelle (V4.1) ou l'avocat tech selon le cas. Si le profil contient `[A CONFIGURER]`, surfacer : > Le profil pratique n'est pas configuré — c'est ce qui adapte la posture, les > secteurs (SaaS / open source / agence dev), et la chaîne d'approbation à ta > pratique. Tu peux continuer en mode provisoire (réponses génériques taguées > `[non configuré]`) ou lancer > `/h-pi:entretien-demarrage` (10 à 15 minutes). --- ## Contrat d'entrée V2 Avant les 5 questions, expliciter : - `development_model`: `internal-employees`, `external-vendors`, `mixed-team`, `open-source-community`, `founder-pre-incorporation`, `unclear` - `distribution_model`: `internal-use`, `proprietary-license`, `saas`, `open-source`, `dual-licensing`, `mixed` - `oss_posture`: `minimal`, `known-dependencies`, `sbom-available`, `copyleft-risk`, `unknown` Champs de faits à exposer ensuite : - `project_scope` - `contributors_and_contracts` - `software_status` - `dependencies_overview` - `business_trigger` Tout manque de pièce, contrat, dépendance ou licence reste `[à vérifier]`. --- ## Cadrage initial V2 — 5 questions en batch unique Avant toute analyse, poser les 5 questions ci-dessous **en une seule fois**. Ne pas dérouler le flux de travail tant que les réponses ne sont pas obtenues — ou explicitement marquées « non applicable » par l'utilisateur. **1. Nom du projet / logiciel** - **Nom commercial** ou **nom de code** du projet - **Slug technique** (ex : repository GitHub, package npm, image Docker) si pertinent - **Marque associée** (le cas échéant — si la marque logicielle est en portefeuille, signaler pour orientation vers `surveillance-marque` ou `recherche-anteriorite-marque`) **2. Contexte de développement** — qui code ? - **Développeur(s) salarié(s) interne(s)** seuls (équipe entièrement internalisée — régime L.113-9 applicable a priori) - **Prestataire(s) externe(s)** seuls (freelances, agence dev, ESN — régime L.113-9 NON applicable, cession écrite L.131-3 obligatoire dans le contrat de prestation) - **Mixte interne + externe** (cas le plus fréquent — cartographier par composant ou par module qui a codé quoi) - **Open source community** (contributeurs externes bénévoles — pas de L.113-9, chaque contributeur titulaire de sa contribution sauf CLA signé) - **Cofondateurs ayant codé avant signature contrat de travail** (cas piège classique startup — le cofondateur reste titulaire personnel jusqu'à cession écrite rétroactive) Pour chaque catégorie applicable, préciser : **combien**, **rôles**, **et relation contractuelle** (contrat de travail / contrat de prestation / contrat de stage / convention de stage / CLA / aucun). **3. Statut du logiciel** - **Développement initial** (greenfield — création ex nihilo) - **Extension de produit existant** (ajout de fonctionnalité, module, extension sur produit propriétaire ou open source maison) - **Fork d'un projet open source** (préciser projet source + licence — la licence amont impose des contraintes au fork : MIT permet fork propriétaire, GPL impose fork GPL, etc.) - **Dérivation d'un produit propriétaire** (cas plus rare — licence propriétaire amont autorisé-t-elle la dérivation ? généralement non, sauf clause expresse) **4. Type d'utilisation prévue** - **Interne uniquement** (outil métier non distribué — pas de licence de distribution mais analyse titularité utile pour due diligence ou réutilisation future) - **Commercialisation propriétaire** (vente de licences d'utilisation — code source fermé, EULA propriétaire) - **SaaS payant** (hébergement chez l'éditeur, accès distant — attention particulière AGPL et licences serveur) - **Open source pur** (publication sous une licence libre — choix de la licence critique selon objectif communauté vs protection) - **Dual licensing** (open source pour usage non commercial / communautaire + licence commerciale pour entreprises — modèle MySQL, MongoDB historique, Qt — nécessite CLA pour relicensing) **5. Dépendances open source** - **Bibliothèques / frameworks utilisés** : lister les principales avec leurs licences si connues - Exemple : React 18 (MIT), Next.js (MIT), PostgreSQL (PostgreSQL License — type BSD), Stripe SDK (MIT), Tailwind (MIT) - Si licences inconnues OU si la liste n'est pas exhaustive ET si le projet dépasse le stade prototype → **recommander scan SCA avant analyse** : - **Snyk** (commercial + free tier) : https://snyk.io - **FOSSA** (commercial) : https://fossa.com - **Black Duck Synopsys** (commercial entreprise) - **GitHub Dependabot** (intégré GitHub, gratuit) - **OWASP Dependency-Check** (open source) : https://owasp.org/www-project-dependency-check - Pour un projet SaaS ou commercialisé, l'analyse de compatibilité sans SBOM (Software Bill of Materials) à jour est **incomplète par construction** — signaler explicitement et proposer d'attendre le résultat du scan. Si l'utilisateur ne peut pas répondre à une question, demander : « Lance le scan SCA et reviens, ou continue avec les éléments connus en taguant les zones non auditées `[dépendance non auditée — à scanner]` ». --- ## Limites de routage V2 ### Router vers `revue-open-source` Basculer si le besoin principal devient : - inventaire détaillé des dépendances ; - obligations notice/source ; - conflits de licences ; - exploitation d'une SBOM ; - plan de remédiation OSS. ### Router vers `revue-logiciel-donnees` Basculer si le besoin principal devient : - chaîne de droits sur code, repo, fondateurs, freelancers, datasets ou bases ; - vérification des contrats de transfert ; - exploitabilité data ou base. ### Router vers `cession-droit-auteur` Basculer si le besoin principal devient la cession des droits patrimoniaux sur le logiciel ou ses modules. ### Router vers `licence-droit-auteur` Basculer si le besoin principal devient le choix, l'arbitrage ou la rédaction d'une licence propriétaire, open source ou dual licensing. ### Router vers `contrefacon-droit-auteur` Basculer si la question dominante devient contradictoire : - reprise de code ; - accès ; - similitudes ; - action ou défense en contrefaçon logicielle. ### Rester dans `logiciels-pi` Rester ici si la question dominante est encore : - la titularité initiale L.113-9 ; - les droits d'utilisation et exceptions ; - le triage OSS de haut niveau ; - les signaux SaaS / data ; - la bonne brique suivante. --- ## Étape 1 — Titularité initiale du logiciel (L.113-9 régime dérogatoire) C'est le **cœur** de la spécificité logiciel. Mal traiter L.113-9 = porte à sens unique sur tout le cycle de vie du logiciel (contrat de travail mal rédigé, cession agence-client invalide, fork open source non maîtrisé). ### Règle CPI L.113-9 > « Sauf dispositions statutaires ou stipulations contraires, les droits > patrimoniaux sur les **logiciels et leur documentation** créés par **un ou > plusieurs employés** dans l'exercice de leurs **fonctions** ou d'après les > **instructions de leur employeur** sont dévolus à l'employeur qui est seul > habilité à les exercer. » ### Conditions cumulatives 1. **Le créateur est salarié** (contrat de travail, lien de subordination — Code travail L.1221-1). Pas de salariat = pas de L.113-9. 2. **Le logiciel est créé dans l'exercice des fonctions** OU **d'après les instructions de l'employeur**. Hors fonctions et hors instructions = sortie de L.113-9. 3. **Pas de convention contraire** dans le contrat de travail ou les statuts de la société. Une clause expresse peut écarter L.113-9 (rare en pratique mais possible — par exemple pour un dirigeant-cofondateur qui conserve la titularité personnelle pour la valoriser ailleurs). Le champ de L.113-9 couvre **le logiciel ET sa documentation** — penser à la documentation technique (architecture, API, manuels d'installation) qui suit le même régime. ### Cas analysés | Cas | L.113-9 applicable ? | Conséquence titularité | |---|---|---| | Salarié développeur, **fonctions habituelles** (développeur full-stack qui développe la feature roadmap) | ✅ OUI | Employeur titulaire patrimoniaux ; salarié garde droit moral (paternité + intégrité, dans la mesure compatible avec exploitation logiciel) | | Salarié développeur, **hors fonctions habituelles** (ex : développeur web salarié qui code un jeu vidéo sur temps personnel) | ❌ NON | Salarié reste titulaire patrimoniaux personnels ; employeur peut négocier cession écrite L.131-3 a posteriori | | **Prestataire externe** (freelance, agence, ESN, consultant indépendant) | ❌ NON | Prestataire titulaire — **cession écrite obligatoire L.131-3** dans le contrat de prestation (énumération droits + domaines + territoires + durée + rémunération) | | **Stagiaire / apprenti** sous convention | ⚠️ Ambigu | Généralement L.113-9 par analogie si convention encadre les missions et qu'un lien de subordination existe — sinon cession écrite recommandée par prudence `[review]` | | **Contributeur open source bénévole** (contributeur communautaire externe) | ❌ NON | Contributeur reste titulaire de sa contribution sauf **CLA (Contributor License Agreement) signé** explicite | | **Cofondateur** qui développe MVP **avant signature contrat de travail** | ❌ NON | Cofondateur titulaire personnel — **cession écrite rétroactive nécessaire** (avec mentions L.131-3, rémunération même symbolique mais identifiée) | | **Agent public** (fonctionnaire) — création par agent dans le cadre de ses missions | Régime spécifique L.131-3-1 | Variable selon mission de service public + identité de l'employeur public ; renvoi régime spécifique CPI L.131-3-1 et suiv. `[review]` | ### Articulation droit moral pour le logiciel Le droit moral existe sur les logiciels (CPI L.121-7 spécifique logiciel), mais il est **restreint** par rapport au droit moral général : - **Droit de paternité** : maintenu (mention du nom de l'auteur sur les copies — souvent sous forme de "headers" copyright dans les fichiers source ou de section "credits/contributors" dans la documentation). - **Droit au respect (intégrité)** : maintenu mais l'auteur **NE PEUT PAS s'opposer aux modifications nécessaires** à l'exploitation du logiciel (corrections, mises à jour, portage, intégration) — sauf atteinte à son honneur ou à sa réputation (rare en pratique). - **Droit de divulgation** : maintenu (l'auteur décide de la première publication — peu pertinent en pratique pour logiciel sous L.113-9 où l'employeur décide). - **Droit de retrait / repentir** : exclu pour le logiciel (L.121-7 al. 2) — pas de retour possible une fois divulgué (contrairement au droit commun L.121-4 qui permet le retrait moyennant indemnisation préalable). ### Erreur fréquente 1 — Startup SaaS > « Notre CTO co-fondateur a développé le MVP avant de signer son contrat de > travail » → CTO reste **titulaire patrimoniaux personnels** jusqu'à > signature contrat OU cession écrite explicite L.131-3. **L'audit due > diligence pré-levée Series A révèle ce problème → blocage de la levée / > renégociation valorisation / cession rétroactive imposée en urgence sous > pression investisseurs.** Mécanique de la cession rétroactive (à faire valider par avocat tech) : - Identifier précisément la période concernée (avant signature contrat de travail) - Énumérer les composants logiciels développés sur cette période (commits Git, factures freelance s'il y en a eu, livrables identifiables) - Acte de cession écrit avec mentions L.131-3 (droits cédés + domaines + territoires + durée + rémunération — même symbolique mais identifiée) - Signature **avant** clôture de la due diligence — au moins avant signature term sheet pour la levée ### Erreur fréquente 2 — Agence dev / ESN > « Le code livré au client est sa propriété. » **Faux par défaut.** Le code > développé par les salariés de l'agence appartient à l'agence en vertu de > L.113-9 → **AGENCE titulaire patrimoniaux**. Pour transférer au client, > **cession écrite obligatoire** dans le contrat de prestation. Clause type "Cession des droits de propriété intellectuelle" à insérer dans le contrat de prestation (renvoi rédaction → `cession-droit-auteur` V4.1) : - Énumération précise des droits cédés (reproduction, représentation, adaptation, traduction, mise sur le marché) - Étendue (code source + documentation + assets) - Destination (utilisation du client : interne / commercialisation / redistribution) - Lieu (territoires : France / Europe / Monde) - Durée (toute la durée légale ou pendant durée d'exploitation) - Rémunération (forfait inclus dans le prix de la prestation ou somme identifiable) **Attention au champ "documentation"** : L.113-9 couvre logiciel + documentation, mais la cession doit **mentionner explicitement les deux** — une clause qui ne mentionne que "le logiciel" laisse la documentation chez l'agence. ### Erreur fréquente 3 — Projet open source > « Tous les contributeurs ont accepté la licence GPL en commitant. » > **Insuffisant.** L'acceptation de la licence projet n'emporte **PAS > cession des droits** — elle confère seulement une licence d'utilisation > aux conditions GPL. Sans **CLA (Contributor License Agreement) signé**, > chaque contributeur reste titulaire de sa contribution. Conséquences pratiques de l'absence de CLA : - **Impossibilité de relicensing futur** : si le projet veut passer en dual licensing (open source + commercial) ou en propriétaire, il faut l'**accord de chaque contributeur** sur sa contribution — irréaliste sur un projet à 40+ contributeurs avec turnover. - **Risque revendication titularité** : un contributeur peut a posteriori revendiquer la titularité de sa contribution et l'opposer à l'éditeur. - **Blocage commercialisation** : modèle business pivot devient impossible. Modèles CLA usuels (renvoi `references/licences-open-source.md`) : - Apache CLA (https://www.apache.org/licenses/contributor-agreements.html) - FSF Contributor Agreement - Salesforce CLA (template populaire pour projets d'éditeurs) --- ## Étape 2 — Droit d'utilisation logiciel (L.122-6) + exceptions L.122-6-1 ### Droit d'utilisation L.122-6 Le droit d'utilisation du logiciel — réservé au titulaire des droits patrimoniaux — comprend (CPI L.122-6) : - **Reproduction permanente ou provisoire** du logiciel, totale ou partielle, par tout moyen et sous toute forme. Cela inclut **le téléchargement, l'installation, le chargement en RAM lors de l'exécution** — c'est-à-dire toute utilisation effective du logiciel. - **Adaptation, traduction, arrangement, transformation** du logiciel, et reproduction du logiciel en résultant. Cela couvre les modifications, les ports vers d'autres environnements, les forks, les traductions de l'interface. - **Distribution au public** du logiciel ou d'une copie, par tout procédé, notamment **vente, location, prêt** (avec **épuisement du droit de distribution** pour la première vente d'une copie au sein de l'EEE — CJUE UsedSoft C-128/11 qui a étendu l'épuisement aux licences perpétuelles téléchargées, mais l'arrêt **ne s'applique PAS** au SaaS). Toute personne qui exécute une de ces opérations sans autorisation du titulaire commet une **contrefaçon de logiciel** (renvoi `contrefacon-droit-auteur` V4.2 — qui couvrira contrefaçon générale ; le régime logiciel a quelques spécificités procédurales : saisie-contrefaçon adaptée au code source, expertise judiciaire spécialisée). ### Exceptions au droit d'utilisation — L.122-6-1 — d'ordre public Ces exceptions sont **d'ordre public** : les clauses contractuelles qui les excluraient sont **nulles** (et donc inopposables à l'utilisateur légitime). C'est un point critique de la défense face à une EULA propriétaire trop restrictive. | Exception | Champ | Limites | |---|---|---| | **Copie de sauvegarde** (L.122-6-1 II) | 1 copie nécessaire à la préservation de l'utilisation | Pas de copies multiples, pas de partage, usage strictement personnel à l'utilisateur légitime | | **Test / observation de l'utilisateur légitime** (L.122-6-1 III) | Analyser le fonctionnement pour comprendre les **idées et principes** à la base de tout élément du logiciel | Doit se faire dans le cadre d'opérations licites (chargement, affichage, exécution, transmission, stockage) — pas de reverse engineering pour reproduire / contrefaire | | **Décompilation pour interopérabilité** (L.122-6-1 IV) | Strictement encadrée | Conditions cumulatives : (a) information nécessaire à l'interopérabilité **non disponible facilement par ailleurs** ; (b) limité aux parties du logiciel strictement nécessaires à cette interopérabilité ; (c) résultats utilisés uniquement pour assurer l'interopérabilité d'un logiciel créé de façon indépendante, **non utilisés à d'autres fins** ni transmis à des tiers (sauf si nécessaires à l'interopérabilité) | | **Correction d'erreurs** (L.122-6-1 I) | L'utilisateur légitime peut corriger les erreurs nécessaires à l'utilisation conforme à la destination | **Sauf interdiction contractuelle expresse** — c'est la seule exception qui peut être écartée par contrat (mais nécessite une clause claire et négociée, pas une mention noyée dans une EULA d'adhésion) | ### Importance pratique critique > Ces exceptions sont **d'ordre public** — les clauses contractuelles qui les > excluraient (totalement) sont **nulles**. Une licence propriétaire qui > interdirait toute décompilation pour interopérabilité est partiellement > nulle pour cette stipulation. Ce qui ne signifie **pas** que la > décompilation est libre — les conditions cumulatives L.122-6-1 IV doivent > être strictement respectées, et la charge de la preuve du respect de ces > conditions pèse sur celui qui décompile. L'exception **correction d'erreurs** est la seule susceptible d'être écartée contractuellement — vérifier l'EULA avant correction unilatérale. ### Cas pratique fréquent — entreprise A et vendor B abandonné - Entreprise A développe son ERP interne sur **middleware propriétaire** vendor B - Vendor B est racheté + **arrête de supporter** le middleware (end of life, plus de correctifs, plus d'API documentée) - L'EULA vendor B interdit toute décompilation - Entreprise A peut **décompiler le middleware pour assurer l'interopérabilité avec son ERP** → exception L.122-6-1 IV applicable, **malgré clauses EULA contraires** (la clause anti-décompilation est nulle pour cette stipulation dans la mesure où elle prive l'utilisateur légitime de l'exception d'ordre public) Réserves opérationnelles : - Conserver une **trace** de la démarche d'obtention de l'information d'interopérabilité par voie normale (mails au vendor, demande d'API documentation, refus ou silence) pour démontrer le critère "information non disponible facilement par ailleurs". - **Limiter strictement** la décompilation aux parties nécessaires à l'interopérabilité — ne pas décompiler tout le middleware pour le redévelopper. - Ne pas transmettre les résultats de la décompilation à des tiers. - Ne pas utiliser les informations obtenues pour développer un produit concurrent — c'est sorti du champ de l'exception et constitue de la contrefaçon. `[review]` --- ## Étape 3 — Triage OSS de haut niveau Le but ici n'est pas de produire un audit composant par composant. Ce skill fait seulement un premier triage pour savoir s'il faut escalader. ### Questions OSS minimales - Des dépendances tierces sont-elles présentes ou supposées ? - Un **SBOM** ou un export SCA est-il disponible ? - Des licences **GPL**, **AGPL**, **LGPL** ou **source-available** sont-elles déjà identifiées ? - Le produit est-il distribué, embarqué, on-prem ou exploité en **SaaS** ? ### Taxonomie de triage | Signal | Lecture dans `logiciels-pi` | Action | |---|---|---| | Licences permissives (MIT, BSD, Apache-2.0, ISC) | a priori peu conflictuelles au stade triage | conserver le sujet pour `revue-open-source` si inventaire détaillé requis | | LGPL / MPL / EPL | dépend du mode d'intégration et des faits | escalader si liaison, modifications ou redistribution mal documentées | | GPL | forte incompatibilité présumée avec un modèle propriétaire ou mixte | escalader vers `revue-open-source` et validation humaine | | AGPL | forte incompatibilité présumée, surtout en contexte SaaS | escalader sans conclure sans faits précis | | source disponible / SSPL / BSL / Elastic License / Commons Clause | alerte rouge contractuelle ou business fréquent | revue dédiée obligatoire | | SBOM absent | triage incomplet par construction | recommander SBOM ou scan SCA avant conclusion fermée | ### Règle de sortie Quand le sujet OSS devient concret, renvoyer explicitement vers `revue-open-source` pour : - le `License Inventory` ; - la `Conflict Matrix` ; - les `Obligations` composant par composant ; - le `Remediation Plan`. Ici, ne produire qu'un résumé de triage : - **dépendances présentes / non documentées** ; - **SBOM disponible / absent** ; - **red flags identifiés** ; - **escalade requise ou non**. --- ## Étape 4 — Alerte courte SaaS / bases / datasets - Si un composant **AGPL** ou assimilé apparaît dans un contexte SaaS, signaler une **forte incompatibilité présumée** et escalader. - Si une **base de données** ou un **dataset** joue un rôle matériel dans le produit, ajouter une alerte courte sur la possible coexistence de sujets licences, titularité, base sui generis ou droits sur les données. - Ne pas dérouler ici une analyse complète de chaîne de droits data/bases : renvoyer vers `revue-logiciel-donnees` ou `bases-de-donnees`. --- ## Étape 5 — Recommandations selon situation - **Exiger un SBOM ou un export SCA** dès que le projet dépasse le prototype, surtout en SaaS, on-prem, OEM, distribution client ou due diligence. - **Traiter GPL, AGPL et licences source-available comme red flags** : triage ici, audit détaillé dans `revue-open-source`. - **Traiter LGPL comme point dépendant des faits** : nature de l'intégration, modifications, packaging, redistribution. - **Si base ou dataset significatif** : ouvrir un flux séparé vers `revue-logiciel-donnees` ou `bases-de-donnees`. - **Conserver le cœur du skill sur le régime logiciel** : titularité, chaîne contractuelle code, publication, cession, licence du projet. --- ### Suites combinées utiles - `logiciels-pi` : régime logiciel, titularité, choix de licence projet, triage OSS de premier niveau. - `revue-open-source` : inventaire détaillé, conflits, obligations et remédiation OSS. - `revue-logiciel-donnees` / `bases-de-donnees` : chaîne de droits data, producteur de base, datasets tiers, droit sui generis. ## Étape 6 — Recommandations selon situation ### Startup early stage avec dev internes salariés - L.113-9 s'applique automatiquement → employeur titulaire patrimoniaux. - **Verrouiller** : contrat de travail avec mention explicite — clause type : > « Conformément à l'article L.113-9 du Code de la propriété intellectuelle, > les logiciels et leur documentation créés par le salarié dans l'exercice > de ses fonctions ou d'après les instructions de l'employeur sont dévolus > à l'employeur, qui est seul habilité à exercer les droits patrimoniaux > correspondants. Le salarié déclare avoir été informé de cette dévolution > et s'engage à coopérer à toute formalité utile à sa mise en œuvre. » - **Vérifier** : développeurs ayant codé **AVANT signature contrat de travail** → cession écrite rétroactive nécessaire (cf. erreur fréquente 1). - **Documenter** : registre interne des contributions par développeur (par module, par période — utiliser l'historique Git comme preuve d'antériorité et de paternité). ### Agence dev ou ESN livrant à clients - L.113-9 attribue à l'**AGENCE** (employeur) — **pas au client**. - **Cession écrite obligatoire** dans le contrat de prestation au client (L.131-3 : énumération droits + domaines + territoires + durée + rémunération). - **Modèle clause** : référence `cession-droit-auteur` V4.1 (à venir). - Attention au champ "documentation" : L.113-9 couvre logiciel + documentation, mais la cession doit **également mentionner les deux** explicitement. - Penser aux **éléments tiers intégrés** : si l'agence a utilisé des bibliothèques open source pour livrer le projet, le client hérite des obligations licence amont (notamment GPL si l'agence a intégré du code GPL — l'agence ne peut transférer plus de droits qu'elle n'en a elle-même). ### Projet open source à publier - **Choix de licence selon objectif** : - **Permissif (MIT / Apache 2.0)** : adoption maximale + compatibilité avec écosystème commercial → adapté si l'objectif est l'adoption large (bibliothèque utilitaire, framework, SDK) sans monétisation directe. - **Copyleft (GPL / AGPL)** : protection contre forks commerciaux propriétaires → adapté si l'objectif est de **forcer la réciprocité** et de garantir que l'écosystème reste open source. - **Dual licensing** (open source GPL/AGPL + licence commerciale) : monétisation des utilisateurs commerciaux qui ne veulent pas du copyleft → modèle MySQL historique, MongoDB pré-SSPL, Qt. - **CLA (Contributor License Agreement) obligatoire** si contributions externes acceptées : - Sans CLA, chaque contributeur reste titulaire de sa contribution → blocage relicensing futur. - Modèles : Apache CLA, FSF Contributor Agreement, Salesforce CLA. - Mise en œuvre technique : bot CLA assistant (CLA Bot, CLA Assistant) qui bloque les pull requests jusqu'à signature. - **Marquage** : copyright headers dans chaque fichier source + LICENSE à la racine du repository + NOTICE pour Apache 2.0 + README mentionnant la licence. ### SaaS avec dépendances open source mixed - **SBOM requis** ou, à défaut, export SCA suffisamment exploitable. - **Red flags à escalader** : GPL, AGPL, LGPL mal documentée, source-available, licence inconnue ou usage SaaS insuffisamment qualifié. - **Ouvrir `revue-open-source`** pour l'inventaire détaillé, la matrice de conflits, les obligations et le plan de remédiation. --- ## Format de sortie V2 Le livrable doit suivre ce contrat de sortie stable : ### 1. `Synthèse du régime logiciel` - nom du projet ; - `development_model`, `distribution_model`, `oss_posture` ; - triage prudent : `clair`, `mixte`, `fragile` ; - phrase courte sur le point dominant. ### 2. `Faits et revue contractuelle` - faits reçus ; - pièces lues ; - contrats ou licences absents ; - points `[à vérifier]`. ### 3. `Cartographie de la titularité initiale` - qui code quoi ; - régime apparent par bloc ; - points L.113-9 clairs ou fragiles ; - trous de transfert. ### 4. `Droits d'utilisation et exceptions légales` - droits d'utilisation apparents ; - exceptions `L.122-6-1` pertinentes ; - limites à ne pas franchir. ### 5. `Seuil de tri OSS` - dépendances connues ou inconnues ; - red flags de haut niveau ; - seuil de bascule vers `revue-open-source`. ### 6. `Signaux SaaS, données et bases` - signaux AGPL / serveur / API ; - présence de datasets ou bases ; - seuil de bascule vers `revue-logiciel-donnees` ou `bases-de-donnees`. ### 7. `Risques de modèle économique` - risques calibrés selon startup, agence, open source, SaaS ou mixte ; - ne garder que les risques concrets du dossier. ### 8. `Routage de prochaine étape` Utiliser uniquement une issue principale parmi : - `document-and-monitor` - `secure-assignment-first` - `review-oss-operationally` - `clarify-data-chain` - `draft-assignment` - `draft-license` - `prepare-software-enforcement` - `insufficient-record` Puis expliquer : - pourquoi cette issue est la bonne ; - quel skill ouvrir ; - quelles pièces conditionnent la suite. ### 9. `Validation humaine` - ce qui est établi ; - ce qui reste hypothétique ; - ce qui doit être vérifié ; - quelle validation humaine est requise avant signature, publication, distribution, due diligence ou action. Le livrable reste sans bandeau Hacienda et sans narration interne. --- ## Seuil non-juriste — quand le profil indique « non-juriste » Quand le profil pratique indique un rôle **non-juriste** (CTO sans formation juridique, fondateur, manager produit, développeur lead, responsable open source), appliquer le gate suivant **avant** la production du livrable : > Cette analyse est une **qualification de régime**, pas un contrat ou une > licence. Commercialiser, publier ou céder un logiciel sans validation par > un avocat spécialisé tech / propriété intellectuelle a des conséquences > concrètes : > > - **Cession invalide** (non-respect L.131-3 dans le contrat agence-client > ou la cession rétroactive cofondateur) : le titulaire d'origine peut > s'opposer à l'utilisation ultérieure, demander cessation, et obtenir > indemnisation rétroactive. > - **Cofondateur qui revendique la titularité personnelle** d'un MVP codé > avant signature contrat de travail : blocage de levée, renégociation > valorisation, voire procédure prud'homale en parallèle. > - **Licence open source mal qualifiée** : blocage possible du business model > (forte incompatibilité présumée en cas de GPL/AGPL, dual licensing impossible > sans CLA). > - **Dépendances non auditées** : risque OSS mal qualifié pouvant imposer > une escalade urgente ; cas réel de > contentieux gflwc (Free vs Welte, Edu4 vs AFPA). > - **CLA absent sur projet open source** : impossibilité de relicensing > futur, blocage commercialisation. > - **Due diligence pré-levée Series A** bloquée sur la chaîne de > titularité ou l'analyse SBOM des licences open source. > > **Voici un brief à apporter à l'avocat spécialisé tech / propriété > intellectuelle :** > > 1. **Projet** : [nom, slug technique, marque associée, secteur] > 2. **Contexte de développement** : qui code (salariés internes / > prestataires / cofondateurs pré-contrat / contributeurs open source) + > cartographie par composant > 3. **Titularité L.113-9 vs droit commun** : cas applicables par catégorie > de développeur + risques identifiés (cession rétroactive cofondateur, > clause L.113-9 contrat travail, cession agence-client, CLA contributeurs) > 4. **Licences envisagées** : projet (propriétaire / open source : MIT / > Apache 2.0 / GPL / AGPL / LGPL / MPL / dual licensing) + justification > du choix > 5. **Dépendances open source** : SBOM (si fourni) ou liste des > principales avec licences ; red flags ou points à escalader identifiés > 6. **Risques identifiés** : verdict prima facie 🟢/🟡/🔴 + zones à > sécuriser > 7. **3 questions critiques** à poser à l'avocat : > - « Le cofondateur ayant codé avant contrat a-t-il une cession écrite > rétroactive conforme L.131-3 (énumération + domaines + territoires + > durée + rémunération) ? » > - « Notre dépendance LGPL en liaison statique (ou bibliothèque GPL > isolée en microservice) nous expose-t-elle à une obligation > d'ouverture du code source applicative ? » > - « Le CLA proposé (ou modèle envisagé) couvre-t-il le relicensing > futur en dual licensing commercial ? » > > **Annuaires pour trouver un avocat spécialisé tech / propriété > intellectuelle :** > - **Conseil National des Barreaux** — annuaire officiel : > https://www.avocat.fr (filtre « propriété intellectuelle », > « droit du numérique », « droit des technologies ») > - **APRIL** (Association de promotion et de défense du logiciel libre) : > https://april.org — réseau d'avocats sensibilisés open source > - **OW2** (consortium open source européen) : référence FR/EU pour > conformité open source en entreprise > - **FSF Europe** (Free Software Foundation Europe) : > https://fsfe.org — conseils juridiques sur les licences open source, > notamment GPL/AGPL/LGPL > - **ALAI France** (Association littéraire et artistique internationale — > section française) : réseau de spécialistes propriété littéraire et > artistique au sens large (utile pour droit moral logiciel, base de > données, dual licensing) Le livrable structuré (cf. format de sortie) est tout de même généré pour servir de brief de travail. Il n'a pas vocation à être transmis tel quel à un tiers (contrepartie, client, investisseur, plateforme) — c'est un **document préparatoire interne**. --- ## Emplacement du livrable Le livrable est écrit dans : ``` ~/.claude/plugins/config/hacienda-juridique/hacienda-propriete-intellectuelle/outputs/logiciels-pi--YYYY-MM-DD.md ``` Le slug est construit à partir du nom du projet, normalisé en minuscules sans accents, avec tirets pour les espaces (ex : `startup-saas-fintech-mvp` pour « Startup SaaS fintech — MVP »). Si workspaces de dossier activés (V1.1+, cf. `CLAUDE.md` extension §11), l'emplacement bascule sur : ``` ~/.claude/plugins/config/hacienda-juridique/hacienda-propriete-intellectuelle/matters//logiciels-pi--YYYY-MM-DD.md ``` Si le répertoire `outputs/` ou `matters//` n'existe pas, le créer. Si plusieurs analyses du même jour pour le même projet, suffixer `-v2`, `-v3`, etc. --- ## Ce que ce skill NE fait PAS - **Rédiger un contrat de cession** (cofondateur pré-contrat, agence vers client, contributeurs vers projet open source) — voir `cession-droit-auteur` V4.1 (mentions L.131-3 obligatoires : énumération + étendue + destination + lieu + durée + rémunération). - **Rédiger une licence d'utilisation** propriétaire (EULA) ou open source (MIT, Apache 2.0, GPL, AGPL, dual licensing) — voir `licence-droit-auteur` V4.1. - **Scanner les dépendances open source automatiquement** — relève des outils SCA externes : Snyk, FOSSA, Black Duck Synopsys, GitHub Dependabot, OWASP Dependency-Check. L'audit OSS spécialisé associé relève de `revue-open-source`, qui exploite un SBOM, une liste de dépendances, un manifest ou une policy interne déjà fournis, sans scanner magique du dépôt. - **Évaluer la contrefaçon logicielle** (analyse contradictoire substance + similitudes substantielles + caractères différenciants ; spécificités procédurales : saisie-contrefaçon adaptée au code source, expertise judiciaire spécialisée) — voir `contrefacon-droit-auteur` V4.2. - **Gérer le brevet logiciel** (rare en France — voir bloc brevets V2.x ; en France, le logiciel "en tant que tel" est exclu de la brevetabilité L.611-10, sauf invention mise en œuvre par ordinateur résolvant un problème technique — jurisprudence OEB Vicom T-208/84 ; aux US les "software patents" existent mais ne sont pas le focus de ce skill). - **Négocier une licence commerciale** (négociation prix / périmètre / exclusivité) — c'est une négociation business + juridique qui sort du scope qualification. - **Auditer la conformité GDPR / RGPD** des données personnelles traitées par le logiciel — différent du régime PI sur le logiciel lui-même ; hors scope (revue RGPD dédiée à traiter hors de ce plugin). - **Vérifier la brevetabilité d'algorithmes** — exclus en France L.611-10 "en tant que tels", sauf invention mise en œuvre par ordinateur sur problème technique (analyse fine OEB + INPI requise — différé V2.x). - **Conduire un audit de sécurité du code** (vulnérabilités, OWASP Top 10, pentest) — c'est un audit cybersécurité distinct de la qualification juridique. --- ## Ton - **Technique** — le régime logiciel est dense et entremêle droit d'auteur, contrats, droit du travail (L.113-9), licences open source. Ne pas simplifier au point de tromper. - **Pédagogique** — le régime logiciel est **complexe et mal connu** (l'inversion L.113-9 vs droit commun salariat est une source d'erreurs récurrentes même chez des juristes expérimentés non spécialisés tech). Expliquer la mécanique, ne pas se contenter d'asséner la règle. - **Précis** — citation systématique des articles CPI applicables (L.111-1, L.112-3, L.113-9, L.121-7, L.122-6, L.122-6-1, L.131-3, L.341-1, L.342-1+) et de la jurisprudence pertinente (Cass. Pachot 7 mars 1986 pour originalité logiciel ; CJUE BSA C-393/09 pour interface graphique ; CJUE SAS Institute C-406/10 pour fonctionnalités vs forme ; CJUE UsedSoft C-128/11 pour épuisement et SaaS ; CJUE Innoweb C-202/12 pour extraction substantielle base sui generis). - **Équilibré** — la qualification est rarement noire ou blanche, surtout sur l'analyse de compatibilité licences (LGPL liaison statique notamment reste contestée). Présenter les forces ET les incertitudes. - **Adapté au profil** — avocat tech spécialisé : ton confraternel, raccourcis techniques OK ; juriste interne non spécialisé tech : explications complètes du régime dérogatoire ; CTO / fondateur : vulgarisation rigoureuse + gate explicite vers avocat tech. ---