Imported from jamon8888/hacienda-juridique (plugins/hacienda-propriete-intellectuelle/skills/logiciels-pi/SKILL.md). Install upstream with npx skills add jamon8888/hacienda-juridique --skill logiciels-pi. Copyright stays with the author.

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

Chargement du profil

Avant tout travail substantiel, lire :

~/.claude/plugins/config/hacienda-juridique/company-profile.md
~/.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/<slug-dossier>/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 :

~/.claude/plugins/config/hacienda-juridique/company-profile.md
~/.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

Le créateur est salarié (contrat de travail, lien de subordination — Code travail L.1221-1). Pas de salariat = pas de L.113-9.
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.
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 :

Projet : [nom, slug technique, marque associée, secteur]

Contexte de développement : qui code (salariés internes / prestataires / cofondateurs pré-contrat / contributeurs open source) + cartographie par composant

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)

Licences envisagées : projet (propriétaire / open source : MIT / Apache 2.0 / GPL / AGPL / LGPL / MPL / dual licensing) + justification du choix

Dépendances open source : SBOM (si fourni) ou liste des principales avec licences ; red flags ou points à escalader identifiés

Risques identifiés : verdict prima facie 🟢/🟡/🔴 + zones à sécuriser

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-<projet-slug>-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/<slug-dossier>/logiciels-pi-<projet-slug>-YYYY-MM-DD.md

Si le répertoire outputs/ ou matters/<slug-dossier>/ 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.

About