コーディングエージェントは「クリーンルーム」実装によりオープンソースを再ライセンスできるか？

ここ数ヶ月で、コーディングエージェントがコードの「クリーンルーム」実装の奇妙なバージョンを構築するのに極めて長けていることが明らかになってきました。 このパターンの最も有名な例は、1982年にコンパックがIBM BIOSのクリーンルーム・クローンを作成したときです。彼らは一つのエンジニアチームにBIOSをリバースエンジニアリングして仕様書を作成させ、その仕様書を別のチームに渡して新規に一から構築させました。 このプロセスは、以前は複数のエンジニアチームが数週間から数ヶ月かけて完了させていました。コーディングエージェントは、このプロセスの一形態を数時間で実行できます。私は昨年12月にJustHTMLに対してこのパターンのバリエーションを実験しました。 これについては、倫理的にも法的にも多くの未解決の問題があります。これらの問題は、由緒あるchardet Pythonライブラリで山場を迎えているようです。 chardetは2006年にマーク・ピルグリムによって作成され、LGPLの下でリリースされました。マークは2011年に公的なインターネット生活から引退し、chardetのメンテナンスは他の人々に引き継がれました。特にダン・ブランチャードは、2012年7月のバージョン1.1以降、すべてのリリースを担当してきました。 2日前、ダンはリリースノートに以下のメモを添えてchardet 7.0.0をリリースしました： > 一から書き直された、MITライセンスのchardetです。同じパッケージ名、同じ公開API——chardet 5.x/6.xのドロップイン置換です。ただ、はるかに高速で正確です！ 昨日、マーク・ピルグリムが#327: このプロジェクトのライセンスを変更する権利はないを開設しました： > [...] まず、現在のメンテナンス担当者と、長年にわたりこのプロジェクトに貢献し改善してきたすべての方々に感謝したいと思います。まさにフリーソフトウェアの成功物語です。 > > しかし、バージョン7.0.0のリリースで、メンテナンス担当者がプロジェクトを「再ライセンス」する権利があると主張していることが私の注意を引きました。彼らにはそのような権利はありません。そのような行為はLGPLの明示的な違反です。修正されたライセンスコードは、同じLGPLライセンスの下でリリースされなければなりません。彼らが「完全な書き直し」であると主張することは無関係です。なぜなら、彼らは元のライセンスコードに十分に触れていたからです（つまり、これは「クリーンルーム」実装ではありません）。洗練されたコードジェネレーターを混ぜても、彼らに追加の権利が与えられるわけではありません。 ダンの長い返信には以下の内容が含まれていました： > 私が元のコードベースに広範に触れていたことは正しいです：私は10年以上にわたりそれをメンテナンスしてきました。従来のクリーンルームアプローチでは、元のコードの知識を持つ人々と新しい実装を書く人々の間の厳格な分離が含まれますが、その分離はここには存在しませんでした。 > > しかし、クリーンルーム手法の目的は、結果としてのコードが元のコードの派生物（デリバティブワーク）ではないことを保証することです。それは目的を達成する手段であって、目的そのものではありません。この場合、私は結果が同じであること——新しいコードは構造的に古いコードから独立していること——を、プロセスの保証だけではなく直接的な測定を通じて示すことができます。 ダンはさらに、JPlagツール——「最先端のソースコード盗作（プラギアリズム）・共謀検出」と自称する——からの結果を示し、新しい7.0.0リリースが以前のリリースと最大1.29%、バージョン1.1と0.64%の類似性しかないことを示しました。他のリリースバージョンは80-93%の範囲の類似性がありました。 彼はその後、彼のプロセスに関する重要な詳細を共有し、以下を強調しました： > 完全な透明性のために、書き直しがどのように行われたかを以下に示します。私はsuperpowersブレインストーミングスキルを使用して、書き直しのために私が持っていた以下の要件に基づいて、アーキテクチャとアプローチを指定した設計文書を作成しました[...] > > **その後、私は古いソースツリーにアクセスできない空のリポジトリで開始し、ClaudeにLGPL/GPLライセンスコードに基づかないように明示的に指示しました。** その後、Claudeを使用して結果のすべての部分をレビュー、テスト、反復しました。[...] > > これは新しく不快な領域であり、長年続くオープンソースプロジェクトの書き直しにAIツールを使用することは正当な疑問を提起することを理解しています。しかし、ここでの証拠は明らかです：7.0は独立した作品であり、LGPLライセンスコードベースの派生物ではありません。MITライセンスは正当にそれに適用されます。 書き直しがClaude Codeを使用して行われたため、リポジトリには多くの興味深い成果物が利用可能です。2026-02-25-chardet-rewrite-plan.mdは特に詳細で、書き直しプロセスの各段階を順を追って説明しています——まずテストから始め、次に計画された置換コードを肉付けしています。 このケースを自信を持って解決するのを特に困難にしているいくつかの捻りがあります： * ダンは10年以上にわたりchardetに没頭しており、明らかに元のコードベースから強い影響を受けています。 * Claude Codeが作業中にコードベースの一部を参照した例が一つあります。計画に示されているように——それはmetadata/charsets.pyを見ました。これは文字セットとそのプロパティをデータクラスの辞書として表現したファイルです。 * さらに複雑なことに：Claude自体は、その膨大な量のトレーニングデータの一部としてchardetでトレーニングされた可能性が非常に高いです——ただし、これを確実に確認する方法はありません。コードベースでトレーニングされたモデルは、倫理的または法的に正当化できるクリーンルーム実装を生成できるでしょうか？ * 新しいchardetリリースが古いものと同じPyPIパッケージ名を使用したという事実は、どれほど重要でしょうか？新しい名前での新規リリースの方がより正当化しやすかったでしょうか？ これがどのように展開するかは全くわかりません。個人的には、書き直しは正当であるという考えに傾いていますが、この問題の両側の議論は完全に信頼できるものです。 私はこれを、既存の成熟したコードの新規実装に関するコーディングエージェントのより大きな問題の縮図として見ています。この問題はまずオープンソースの世界に影響を与えていますが、まもなく商業世界のコンパックのようなシナリオでも現れ始めると予想しています。 商業企業が彼らの厳重に保持された知的財産（IP）が脅威にさらされていることを認識すれば、十分な資金を持った訴訟が起こると予想しています。 タグ: ライセンス, マーク・ピルグリム, オープンソース, AI, 生成AI, LLM（大規模言語モデル）, AI支援プログラミング, AI倫理, コーディングエージェント

コーディングエージェントは「クリーンルーム」実装によりオープンソースを再ライセンスできるか？

背景や根拠まで確認しますか？

調べる

選ぶ

サイト