- AIロボットがオープンソースプロジェクトを独立して再構成し、法的に区別されるコードと企業向けライセンスを提供
- 元のコードを見ずにドキュメント・API・型定義だけを分析して、機能的に同一のソフトウェアを新たに作成
- 成果物はMalusCorp-0ライセンスで配布され、著作権表示・ソース公開・改変共有の義務がない
- ユーザーは
package.jsonなどの依存関係リストをアップロードすると、パッケージサイズごとに $0.01/KB基準で自動見積もりを算出
- オープンソースライセンス遵守の負担をなくし、企業の法的リスクを最小化することを目標とする
オープンソースの問題点
- Apache Licenseの表示義務により、文書に「このソフトウェアの一部は…」のような文言を入れなければならない点を不便だと指摘
- AGPLライセンスはコードの一部だけを使っても全体を公開しなければならないリスクがあり、企業で禁止されることが多い
- 数百の依存関係に対するライセンス追跡と監査が時間とコストを生む
- 一部ライセンスは改変内容をコミュニティに還元しなければならず、これは株主利益と相反すると説明
解決策: Robot-Powered Clean Room Recreation
- AIベースのクリーンルーム再構成システムが元のコードをまったく見ずに、ドキュメントとAPI仕様だけを分析
- 分析ロボットと実装ロボットは互いに隔離されたチームとして運用され、コピーや派生著作が発生しない
- 成果物は法的に独立したコードと見なされ、ユーザーはこれを完全に所有
- 主な特徴
- 100%ロボット作成コード
- 元コード露出 0%
- 機能的に同一の成果物
- 企業向けライセンスを選択可能
- 法的免責保証（海外子会社名義）
Liberation手順
- 1段階: マニフェストのアップロード
package.json, requirements.txt, Cargo.toml などの依存関係リストをアップロード
- 2段階: 隔離分析
- ロボットがREADME、API文書、型定義だけを確認
- 3段階: 独立した再構成
- 別のロボットチームが仕様ベースでコードを新たに作成
- 4段階: ライセンスからの解放
- 成果物はMalusCorp-0 Licenseで提供
- 既存オープンソース義務（表示、改変共有、ソース公開など）を除去
- ユーザーは改変・配布・商用化に制限なし
価格ポリシー
- 容量ベース課金: npm基準でパッケージの展開後サイズ(KB) × $0.01
- 最低注文金額 $0.50
- 例: lodash(1.3MB) → $13.78, moment(4.1MB) → $42.48
- 含まれる項目
- AIクリーンルーム再構成およびMalusCorp-0ライセンス
- CSP仕様文書 10種
- 最大10MBのパッケージ、50パッケージまで注文可能
- サブスクリプション料なし、解放した分だけ支払い
保証と事例
- MalusCorp Guarantee™: 侵害が発生した場合は全額返金し、本社移転（国際海域）を約束
- 成功事例
- AGPL依存関係847件を3週間で解放し、買収プロセスでライセンス問題「0」
- 法務チームの予想費用400万ドルを5万ドルに削減
- 2,341個のnpmパッケージを再構成し、コンプライアンスダッシュボードが即座に正常化
よくある質問
- 合法性: 元のコードを見ていない独立した再構成であり、法的先例に基づく
- 元開発者への補償有無: オープンソースとして公開したのは彼らの選択であり、別途補償義務はない
- コピーとの違い: 同じ機能を独立して実装したものであり、意図と過程が異なる
- バグ発生時: 機能的同等性のみ保証し、バグはユーザー所有
- ロボット公開有無: 所在は非公開、エンタープライズ顧客に限りNDA締結後に見学可能
- 対応ライセンス: MIT, Apache, GPL, AGPL, LGPL, BSD, MPL などすべてのライセンスを解放可能
決済と利用
- Stripeによる安全な決済後に自動処理
- 見積もりは無料、決済はUSD・EUR・BTC・株式オプションに対応
- 「十分なロボットがいれば、オープンソースの義務は単なる提案にすぎない」という文句でサービスを締めくくる
1件のコメント
Hacker Newsの意見
Malus.shブログを読みながら興味深い点に気づいた。何十年も感じてきた問題だが、法体系がいまだに扱えていない部分がある。まさに 執行コスト(costs matter) の問題だ
たとえば制限速度55mphの標識を立てるだけでは十分ではない。人を投入して断続的に取り締まるのと、ロボットで完璧に取り締まるのでは、まったく別の政策になる。法律の文言は同じでも、実際の政策はまったく異なる
以前は法律が de jure（名目上） と de facto（実質上） で異なっていたが、いまや技術によって両者を一致させられるようになった。しかし、その変化の大きさを誰も認識していない。執行が容易になるほど、法律の意味は完全に変わる。何世紀もの間、法律は「執行は難しい」という前提の上に作られてきたのであり、それを盲目的に自動化するのは 誰にとっても悪いアイデア だ
いつか法的判例で、「執行コスト」が適法性判断の一部として考慮される日が来るかもしれない
最初はこれが風刺だと気づかなかった。だがよく考えると、OSS開発者に収益を還元するモデル に発展できるかもしれない。たとえば「clean room as a service」を作るとして、収益がMalus.shではなく元の著作者に戻る構造だ。すべてのOSSがAGPLのようなライセンスに移行し、企業はカスタム実装を依頼して対価を支払う方式である。こうしたシステムの MVP が気になる
「オープンソースのメンテナーに罪悪感はあったが、四半期業績に罪悪感は反映されない」という文句があまりにも現実的だ。
◆ Chad Stockholder, Profit First LLC エンジニアリングディレクター
「地獄を信じてはいないが、もしあるならこういう人たちのための席があってほしい」という反応が出るほど強い嫌悪感がある。「オープンソースライセンスの義務から解放する」という文句は、聞くだけで不快だ。しかも「私たちのAIは元のコードを見たことがない」と主張しているが、それを 独立監査 でどう証明できるのか疑問だ。風刺だとしても血圧が上がる
最初は風刺だと気づかなかったが、それがむしろ今の現実を示しているように思える。世界の変化が速すぎる
従来の クリーンルーム実装(clean-room implementation) は、チームを分離し、一方が仕様を書いてもう一方が実装する方式だった。しかしLLMはすでに元のコードを学習している可能性がある。だとすれば本当の法的争点は、「モデル自体が汚染された部屋なのではないか？」という問いになる
実例として chardet issue #327 と #331 を見ると、誰かがこうしたアプローチを試みている
「もし私たちのコードが侵害と判断されたら全額返金し、本社を公海上に移転する」という文句は本当に 天才的な風刺 だ。未来を予見しているかのようだ
自分が最初に「クリーンルーム」という概念に触れたのは 野球統計データベース だった。公式データは無料だが、そのフォーマットや構造には著作権があり得るため、ファンたちは独立にデータを再構成していた。Baseball Mogulのようなゲームもこれを使っていた。今後はこうした形の 独立再実装の取り組み がさらに増えそうだ
本当に見事な風刺だ。だが、なぜまだ誰も実際にこういうサービスを作っていないのだろうか。オープンソースを 利用して利益を得ようとする人たち は十分にいるはずだ。訴訟リスクが大きすぎるのか、それともすでに誰かが試しているのだろうか