MALUS - Clean Room as a Service pour se libérer des mentions de droits d’auteur de l’open source

• Des robots IA reconstituent indépendamment des projets open source, afin de fournir un code juridiquement distinct et une licence adaptée aux entreprises
• Sans voir le code d’origine, ils n’analysent que la documentation, les API et les définitions de types pour réécrire un logiciel fonctionnellement identique
• Le résultat est distribué sous licence MalusCorp-0, sans obligation de mention de droits d’auteur, de publication du code source ni de partage des modifications
• L’utilisateur peut téléverser une liste de dépendances comme package.json, et un devis automatique est calculé à raison de 0,01 $/KB selon la taille du paquet
• L’objectif est d’éliminer la charge de conformité aux licences open source et de réduire au minimum le risque juridique pour les entreprises

---

Les problèmes de l’open source

• L’obligation de mention de l’Apache License est présentée comme contraignante, car elle impose d’ajouter dans la documentation des formules du type « Une partie de ce logiciel… »
• La licence AGPL est perçue comme risquée, car l’utilisation même partielle de code peut obliger à publier l’ensemble, ce qui conduit souvent les entreprises à l’interdire
• Le suivi et l’audit des licences de centaines de dépendances entraînent du temps et des coûts
• Certaines licences imposent de reverser les modifications à la communauté, ce qui est décrit comme contraire aux intérêts des actionnaires

La solution : Robot-Powered Clean Room Recreation

• Un système de reconstitution clean room basé sur l’IA analyse uniquement la documentation et les spécifications d’API, sans jamais voir le code d’origine
  • Le robot d’analyse et le robot d’implémentation fonctionnent comme des équipes isolées l’une de l’autre, évitant toute copie ou œuvre dérivée
• Le résultat est considéré comme un code juridiquement indépendant, dont l’utilisateur devient pleinement propriétaire
• Principales caractéristiques
  • Code écrit à 100 % par des robots
  • 0 % d’exposition au code source d’origine
  • Résultat fonctionnellement identique
  • Choix possible d’une licence adaptée aux entreprises
  • Garantie d’indemnisation juridique (au nom d’une filiale étrangère)

Procédure de libération

• Étape 1 : téléverser le manifeste
  • Téléversement de listes de dépendances comme package.json, requirements.txt, Cargo.toml
• Étape 2 : analyse isolée
  • Les robots n’examinent que le README, la documentation API et les définitions de types
• Étape 3 : reconstitution indépendante
  • Une autre équipe de robots réécrit le code à partir des spécifications
• Étape 4 : libération de la licence
  • Le résultat est fourni sous licence MalusCorp-0
    • Suppression des obligations habituelles de l’open source (mentions, partage des modifications, publication du code source, etc.)
    • L’utilisateur peut modifier, distribuer et commercialiser sans restriction

Tarification

• Facturation selon la taille : taille décompressée du paquet (KB) sur npm × 0,01 $
  • Commande minimale : 0,50 $
  • Exemples : lodash (1.3MB) → 13,78 $, moment (4.1MB) → 42,48 $
• Ce qui est inclus
  • Reconstitution clean room par IA et licence MalusCorp-0
  • 10 documents de spécification CSP
  • Jusqu’à 10 MB par paquet, et jusqu’à 50 paquets par commande
  • Aucun abonnement, paiement uniquement pour ce qui est libéré

Garanties et cas d’usage

• MalusCorp Guarantee™ : remboursement intégral en cas d’infraction et promesse de transfert du siège social (en eaux internationales)
• Cas de réussite
  • Libération de 847 dépendances AGPL en 3 semaines, avec « 0 » problème de licence lors d’une acquisition
  • Réduction d’un coût estimé par l’équipe juridique de 4 millions de dollars à 50 000 dollars
  • Reconstitution de 2 341 paquets npm, permettant au tableau de bord de conformité de revenir immédiatement à la normale

Questions fréquentes

• Légalité : reconstitution indépendante sans consultation du code d’origine, fondée sur des précédents juridiques
• Rémunération des développeurs d’origine : la publication en open source relève de leur choix, sans obligation de compensation supplémentaire
• Différence avec la copie : il s’agit d’une implémentation indépendante de fonctionnalités identiques, avec une intention et un processus différents
• En cas de bug : seule l’équivalence fonctionnelle est garantie, les bugs appartiennent à l’utilisateur
• Publication des robots : emplacement non divulgué, visite possible sous NDA pour les clients enterprise
• Licences prises en charge : libération possible depuis toutes les licences, dont MIT, Apache, GPL, AGPL, LGPL, BSD, MPL

Paiement et utilisation

• Traitement automatique après paiement sécurisé via Stripe
• Le devis est gratuit, paiement pris en charge en USD, EUR, BTC et stock-options
• Le service se conclut sur la formule : « Avec suffisamment de robots, les obligations de l’open source ne sont qu’une suggestion »

[GN⁺]

Commentaires sur Hacker News

• En lisant le blog de Malus.sh, j’ai remarqué quelque chose d’intéressant. C’est un problème que je ressens depuis des décennies, mais que le système juridique ne traite toujours pas vraiment : la question du coût de l’application de la loi (costs matter).
  Par exemple, installer un panneau de limitation à 55 mph ne suffit pas. Faire contrôler ponctuellement par des humains et faire respecter parfaitement la règle par des robots, ce sont deux politiques complètement différentes. Le texte de loi est identique, mais la politique réelle ne l’est pas du tout.
  Autrefois, il y avait un écart entre le droit de jure (formel) et de facto (réel), mais la technologie permet désormais de faire coïncider les deux. Pourtant, personne ne semble prendre la mesure de ce changement. Plus l’application devient facile, plus le sens même de la loi change complètement. Pendant des siècles, les lois ont été conçues avec l’hypothèse que leur application serait difficile ; automatiser cela aveuglément est une mauvaise idée pour tout le monde.
  Peut-être qu’un jour, la jurisprudence prendra en compte le « coût de l’application » comme un élément du jugement sur la légalité.

  • Je pense qu’il faut accueillir favorablement une application plus précise de la loi. Une application imparfaite conduit à des contrôles sélectifs, ce qui donne à ceux qui appliquent la loi le pouvoir de la modifier arbitrairement. Mais plus l’application devient parfaite, plus il faut aussi ajuster les règles et les sanctions. Sinon, cela provoquera du chaos social. La loi a été pensée pour évoluer lentement, mais elle risque désormais de ne plus suivre le rythme.
  • Dean Ball a évoqué le même sujet dans l’émission d’Ezra Klein. Je pensais qu’une application parfaite apporterait la justice, mais sans plan de migration, cela ne veut rien dire. L’IA promet un avenir formidable, mais c’est la transition pour y parvenir qui est la partie la plus difficile.
  • Le problème fonctionne dans les deux sens. Beaucoup d’administrations ont l’obligation légale de répondre aux demandes écrites des citoyens, mais autrefois les gens écrivaient rarement des lettres. Avec les LLM, n’importe qui peut désormais produire facilement un courrier officiel. Si une IA qui rédige automatiquement des « lettres de plainte » apparaît, le système administratif risque de ne pas pouvoir suivre.
  • D’après un article de Pamela Samuelson et Suzanne Scotchmer (PDF du Yale Law Journal), le droit d’auteur considérait aussi positivement l’existence de « voies de contournement coûteuses ». Autrement dit, un contournement totalement gratuit ou automatique n’était pas jugé souhaitable. Il est intéressant de voir que le système juridique reconnaissait implicitement l’importance du coût.
  • J’aime beaucoup cette idée selon laquelle « le coût de l’application compte ». Les lois des XVIIIe et XIXe siècles ont été élaborées en partant du principe que les moyens policiers étaient limités, mais aujourd’hui les technologies de surveillance changent tout. Une application parfaite entraîne un coût en matière de vie privée. Cela dit, on peut objecter qu’une application automatisée pourrait aussi réduire l’injustice des contrôles sélectifs.

• Au début, je n’avais pas compris que c’était une satire. Mais en y réfléchissant, cela pourrait aussi devenir un modèle qui redistribue de la valeur aux développeurs OSS. Par exemple, créer un « clean room as a service » où les revenus reviendraient non pas à Malus.sh, mais aux auteurs originaux. Tous les projets OSS passeraient à des licences du type AGPL, et les entreprises paieraient pour commander des implémentations sur mesure. Je me demande à quoi ressemblerait le MVP d’un tel système.

  • En réalité, ce site n’est pas une satire. Il accepte les paiements via Stripe et génère vraiment du code. C’est simplement emballé dans un langage satirique.
  • Si c’était une proposition sérieuse, ce serait déjà faisable avec un système de double licence. En tant que blague, c’est drôle, mais si c’est sincère, c’est peut-être un malentendu.
  • L’objectif initial du copyleft était de préserver la liberté (freedom) du logiciel. Proposer de verrouiller une partie du code va directement à l’encontre de ce principe.
  • Moi non plus, je n’avais pas compris au départ que c’était satirique, mais les faux témoignages en bas du site m’ont immédiatement mis la puce à l’oreille. Des phrases comme « nous avons libéré 847 dépendances AGPL en 3 semaines » étaient vraiment hilarantes.
  • Ce modèle pourrait en fait bien fonctionner. Les développeurs OSS pourraient se concentrer uniquement sur le développement, sans avoir à se soucier de vente ou de conseil. Plus besoin non plus de sponsoring d’entreprise.

• La phrase « Je me sentais coupable vis-à-vis des mainteneurs open source, mais la culpabilité n’apparaît pas dans les résultats trimestriels » est d’un réalisme absolu.
  ◆ Chad Stockholder, directeur de l’ingénierie chez Profit First LLC

  • La relation entre l’OSS et le logiciel commercial a toujours mêlé tension morale et idéalisme naïf.

• Cela provoque un tel rejet qu’on en arrive à des réactions du type : « Je ne crois pas à l’enfer, mais s’il existe, j’espère qu’il y a une place pour ces gens-là. » La formule « vous libérer des obligations de licence open source » est déjà désagréable à entendre. En plus, ils affirment que « notre IA n’a jamais vu le code original », mais je me demande bien comment cela pourrait être prouvé par un audit indépendant. C’est satirique, mais ça fait monter la tension.

  • C’est une satire, mais en réalité les licences FLOSS n’imposent pas d’obligation de publication pour un usage interne. Même si une IA produit une implémentation totalement nouvelle, la protection par le droit d’auteur reste incomplète.
  • En réalité, ce projet est une satire présentée à la FOSDEM. Ses auteurs viennent eux aussi de la communauté open source.

• Au départ, je n’avais pas compris que c’était une satire, et c’est justement ce qui semble refléter la réalité actuelle. Le monde change trop vite.

  • Ce site accepte réellement les paiements Stripe. Cela ressemble à une satire, mais c’est un vrai service.
  • Moi aussi, je n’avais pas compris au début que c’était satirique, mais les faux témoignages m’ont rassuré. Heureusement que ce n’est pas encore la réalité.
  • Mais quand on voit que le nom est « Malus », on finit par comprendre plus tard que c’est satirique.
  • Quel que soit le nom, on a l’impression que ce genre de chose finira de toute façon par devenir réel.

• Une implémentation clean-room traditionnelle séparait les équipes : l’une rédigeait la spécification et l’autre réalisait l’implémentation. Mais un LLM a peut-être déjà été entraîné sur le code d’origine. Dans ce cas, la vraie question juridique devient : « le modèle lui-même est-il une salle contaminée ? »

• Si l’on regarde des cas réels comme l’issue chardet #327 et #331, on voit que quelqu’un tente déjà ce type d’approche.

  • Il existe un exemple où le modèle Opus 4.6, sans accès au web, s’est souvenu et a reproduit l’intégralité du code source de chardet (lien gist).
  • Un développeur qui maintient le projet depuis plus de dix ans a essayé de produire une réimplémentation sous licence MIT, et la communauté l’a au contraire blâmé. Ce genre de réaction est vraiment regrettable.
  • C’est un cas suffisamment important pour mériter une discussion séparée.

• La phrase « si notre code est jugé contrefaisant, nous vous rembourserons intégralement et déplacerons notre siège dans les eaux internationales » est une satire géniale. On dirait presque une prophétie du futur.

  • Le niveau de finition satirique est très élevé. Au début, cela paraît authentique, mais à mesure qu’on lit, on remarque partout des indices intentionnels. Le plus inquiétant est que cela pourrait réellement arriver.

• J’ai découvert pour la première fois le concept de clean room avec les bases de données de statistiques de baseball. Les données officielles étaient gratuites, mais leur format et leur structure pouvaient être protégés par le droit d’auteur, donc des fans reconstituaient les données de manière indépendante. Des jeux comme Baseball Mogul s’en servaient aussi. Je pense qu’on verra davantage à l’avenir ce type d’efforts de réimplémentation indépendante.

• C’est une satire vraiment excellente. Mais alors, pourquoi personne n’a-t-il encore réellement lancé un service de ce genre ? Il y a pourtant suffisamment de gens prêts à tirer profit de l’open source. Est-ce que le risque juridique est simplement trop élevé, ou bien est-ce que quelqu’un essaie déjà ?

  • En réalité, comme tout le monde peut utiliser un LLM moderne, il n’y a pas vraiment de raison de payer un tiers pour une « implémentation clean room ». La vraie valeur serait plutôt dans l’habillage juridique qui prendrait le risque à sa charge.
  • Le monde offre beaucoup d’occasions d’agir de manière malveillante, mais la plupart des gens ont encore des freins moraux. Cela dit, si ce genre d’idée est rendue publique, on pourrait voir se multiplier des tentatives réelles, comme dans les copycat crimes.
  • En fait, cela se produit déjà. Quand un développeur demande à une IA « implémente cette fonctionnalité, en t’inspirant de ce dépôt GitHub », une réimplémentation peut se produire involontairement.
  • Le vrai problème, c’est la confiance et la sécurité. Je pense qu’il vaut mieux traiter les secrets d’entreprise avec une IA locale plutôt que de les confier à un SaaS. De tels systèmes existent déjà et sont largement utilisés.
  • Et en pratique, les LLM ne sont pas encore au niveau pour écrire parfaitement du code complexe. C’est pourquoi il serait difficile pour un service de ce type de réellement fonctionner.