どこで線を引くべきか迷ってる。コードが違ってもAPI互換性があれば、Google JavaとOracle Javaのケースみたいに、実装が十分に異なれば新しい実装と見なされることもあるよね。クリーンルームかどうかは関係ない。

クリーンルームの議論、全然意味がわからない。プロジェクトがガバナンスを変えて、かなりリファクタリングや再実装されたなら、メンテナはそれを自分たちのものとして呼ぶ権利があると思う。元のMIT以前のリリースはLGPLのままでいいし、これが前例になるとも思わない。ライセンスを変えたプロジェクトはたくさんあるし、GPLライセンスの話は時々ホラー話として浮かんでくる。もしかして、ライセンスが今の基準に合ってないだけなのかも？

FastAPIの基盤ライブラリ、Starletteも最近ライセンスの問題に巻き込まれてるみたいだね。気をつけて、プロジェクトのキーを誰に渡すかは慎重にね！

それは全然関係ない気がする。これは単に帰属を追加してるだけで、LLMでの洗浄を通じてライセンスを変更してるわけじゃないよ。

コンサルティングの一環で、商業的な文脈でこの問題に出くわしたよ。モバイルアプリをオープンソースにしているSaaS企業から、次のような懸念を持って相談された。一人のエンジニアが、Claude Codeを使ってアプリとウェブフロントエンドを逆コンパイルして、機能的に同じAPI互換のバックエンドを再現したんだ。仕事の後に一週間かかったらしい。安定性はあまりないし、ユニットテストももっと手を加える必要があるし、コードには不要な重複もあるけど、エンドツーエンドのテストハーネスは彼らのものよりも安定してる。「競合がこれをやってきたら、どうやって自分たちを守る？」今、これについて考えてるところ。

面白いケースだね。法律の専門家じゃないけど、合法的に聞こえる。AIは再実装したバックエンドにはアクセスしてなかったし、API自体は公開されてて保護されてない。

もしかしたら、もっといい質問は「競合他社はこれに対してどうやって自分たちを守ってるの？」かもね。

ここでのダークファクトリーの作業に興味があるかもね。https://factory.strongdm.ai/ 彼らは似たようなことをやってるよ。外部サービスを使うのが難しいから、それを複製してるんだ。コストも「馬鹿なこと言うな、スプリント中にSlackやGoogle Driveを再実装してテストを早くするなんて無理」から現実的になった。彼らはSDKをライブサービスと自分たちの実装に対して動かして、挙動の違いが見えなくなるまでやってる。今、彼らは速いSlackやDriveを持ってて、テストに必要なことを全部こなしてるから、他の作業も加速してる。開発における「高い」と「安い」の概念が劇的に変わってきてる。君が言ってることは以前に誰かがやったかもしれないけど、そのバックエンドを構築する難易度がものすごく下がったんだ。アプリケーションがクローズドでも、今か近い将来に、コアのユーザーストーリーから始めてアプリを構築することができるかもしれない。アプリケーションを非常に正確な仕様として見ることもできる。ほんとに変化の面白い瞬間だね。

> 「競合がこれをやることに対してどうやって自分たちを守るの？」 もしプラットフォームが、バカなフロントエンドからAIエージェントによってリバースエンジニアリングできるほど簡単なら、何を守る必要があるの？彼らの防御線はバックエンドのその部分じゃなくて、サービスの提供方法に関する別の何かだと考えるべきだね。

もし君のバックエンドが大規模言語モデルで実装できるほど簡単なら、君は何の価値を提供してるの？挑発的な質問かもしれないけど、それが競合が競合でない理由だよね。

> 「競合がこれをやってくるのにどうやって自分たちを守る？」 DMCAだね。EULAは逆コンパイルを禁止してるはず。もし競合がそれをやったら、弁護士を使ってやっつければいい。あるいは、夜ぐっすり眠りたいなら、これを脅威じゃなくてチャンスとして認識することだね。

新しいことを説明してるんじゃなくて、進歩について話してるんだよね。企業が製品を作るために時間やお金、専門知識を投資して、製品が確立される。そしたら、他の人たちはその製品を1/10の時間で真似するようになって、業界全体の製品の質が向上する。生成AIが登場するずっと前に、インスタグラムは週末にスナップチャットのストーリー機能を真似して、それが今やメタの利益に多大な貢献をしてる。エンジニアとしては、コードのことばかり考えがちだけど、実際にはビジネスの成功を決めるのはコードじゃないんだよね。もしクライアントが自分たちのビジネスの主な価値が自分たちが書いたモバイルアプリのコードにあると思ってるなら、1) なんでオープンソースなの？ 2) ビジネスは終わりだよ。現実的には、これは重要じゃないし、これについて心配する時間は無駄だよ。競合が自分のモバイルアプリを真似することを心配しても、自分を守ることにはならないからね。

AIがモバイルOSの二大独占を終わらせるのはいつなんだろうって思う。

真剣な企業向けSaaSは、製品だけで差別化することはないよ（製品は大体ひどいから）。営業チャネル、ビッグ企業に請求する方法、現場に派遣されるエンジニア、24/7のサポートライン、顧客が合法的に運営できるようにする規制フレームワーク、製品を使ったことがあって理解している潜在的な雇用者がたくさんいること。これらが差別化要因なんだ。

これはもう手遅れだと思うし、元に戻すのは無理だね。ブランドへの忠誠心やプラットフォームの慣性が人を引き留める部分もあるし。あと、指摘してるように、ソースコードがあるだけじゃ不十分なんだよね。プラットフォームを運営するのはそれ以上のことだから。でも、そのギャップは時間とともに狭まるだろうね。もっと広い問題として、AIが自分たちの仕事（や会社）を奪いに来てることに気づいてない技術者もいるってことだ。そういう立場の人が、他の人たちが自分たちの業界がAIによって「破壊される」ことを理解できるようになればいいなと思う。

ちゃんとしたクリーンルームのセットアップを作らなかったみたいだね。コードを書いてるエージェントが元のコードを見えてたんだ。質問だけど、もしAIチームを両方の「部屋」で使って、一方が仕様を書いて、もう一方が実装するようにしたら、それは大丈夫なのかな？仕様にソースコードが含まれてないことを確認する必要があるけど、それは簡単だよね。IBM時代の前例に従ってるみたいだけど、モデルが元のコードをトレーニングデータに含んでたら、どうかな？クローズドソースプロジェクトには有効かもしれないけど、オープンソースには当てはまらないのかな？面白い質問だね。

これが正しいと思う。LLMに元のコードの表現要素が全くない仕様を導出させて（クリーンルームの人間チームが慎重に確認できる）、その後別のLLMのインスタンスに（新しいコンテキストで）その仕様からコードを書かせたら、それは「クリーンルーム」の書き換えとどう違うの？新しいコードを書くエージェントは仕様しか見ないし、仮定として（すべてのクリーンルームの書き換えで前提とされる仮定）仕様は純粋に事実で、著作権で保護される表現はすべて取り除かれているはず。だけど「仕様を導出する（そしてそれができるだけクリーンであることを確認する）」のが重要で、これを飛ばすことはできないよね！

うん、Compaq / IBMの前例は表面的にしか適用できないと思う。まるで二つのチームがドキュメントでいっぱいの部屋でしか会わないみたいだけど、両方のチームが前日にソースコードを詰め込んでたらどうなるの？（その、逆コンパイルしてるソースコードはトレーニングデータに含まれてる。）意味がわからないよね。それに、LLMを教えるために海賊版の資料を使うのはOKみたいだけど、LLMが教えてくれたことを広めるのはダメってのも変だよね。

> ちゃんとしたクリーンルームのセットアップを作らなかったみたいだね。コードを書いてるエージェントが元のコードを見えてたんだ。エージェントの構造がどうであれ関係ないよ。chardetがLLMのトレーニングセットに含まれてるから、そのAIの実装がクリーンルームだとは主張できないよ。

答え：たぶん無理だね、APIのトポロジーも著作権の一部だから。編集：これ、間違ってる。

実装者のトレーニングにコードベースが含まれてたら、そうはならないよ。

わお、これはホットだね。元のLGPLコードに「汚染されてない」必要があるなんて知らなかった。これってつまり、AIが生成したコードはGPL/LGPLに汚染されてるってことかも。だって、LLMがそれで学習してる可能性があるから。

そう、それはLLMブームが始まってから、孤独な人たちが砂漠で叫んでたことだね。

完全に汚染されてないことは、多くの再実装が自分たちに設定している基準で、法的トラブルを完全に排除するためのものだよ。たとえば、ReactOSは、Windowsのコードを見たことがある人は貢献できないんだ。だって、見たことがなければ、コピーしたという主張はできないから。ただ、これは実際に法的に必要な基準よりも厳しいんだ。実際の法的基準は、通過したかどうかを判断するために裁判所の判決が必要になるから、みんなそれを避けたがる。だから、似たような事例の裁判もあまりないんだよね。

弁護士じゃないけど、これはいつも素朴に正しいと思ってた。ただ、著作権制度はアメリカの資本利益を守るための詐欺みたいなもんだから、これが実際に裁定されたり施行されたりしたら驚くよ。どちらにせよ、アメリカの立法者は法律を変えることができるからね。

「汚染」というのは、そのコードが*GPLライセンスの作品から明らかに派生している必要があるんだ。これって、実は思ってるよりも難しい基準なんだよ。アメリカのクリーンルームアプローチがあるのは、大企業が永遠に引き延ばす訴訟を短縮するのに役立つからなんだ。

LLMが業界を特許でIPを守る方向に押しやるのかな、他の工学分野みたいに。もしソフトウェアの動作の一般的なアイデアを特許化すれば、どんなリライトもその保護を解除できなくなるからね。

一般的な特許は認められていないよ。

へぇ、7e25bf4は大きなコミットだったんだね。2,305ファイルが変更されて、+0 -546871行が変更されたみたい。 https://github.com/chardet/chardet/commit/7e25bf40bb4ae68848...

本当の問題は、「chardet」に依存してるプロジェクトがたくさんあって、今やクソみたいな未検証のAIのゴミを引き込んでることじゃない？AIの偽造汚染だと思う。なんでこの新しいプロジェクトが、そんな不名誉な方法で元のものを置き換えなきゃいけなかったの？ちゃんとした新しいプロジェクトを作るのが正しい方法だったはずだよ。ちなみに、Pythonのpipもこれを依存関係として引き込んでるみたいだね（ちゃんとしたバージョンにしてくれるといいけど）。

これが本当の問題だね（AIの側面というより、全面的な置き換えの方が）。ライセンスの問題は確かにあるけど、個人的にはそれほど重要じゃないと思う。50万行のコードが4日間で削除されて、コミュニティのレビューやテストの機会もなく、直接メインブランチに置き換えられたんだ。（依存しているプロジェクトがメインブランチを使っているのか安定版を使っているのかは分からないけど、安定版はもうほぼ4年前のものだから、依存しているプロジェクトがそのバージョンを使っていることを願うけど、賭ける気にはなれない。）全体的にサプライチェーン攻撃の匂いがするし、たとえ善意であっても、確認するためにレビューしなきゃいけないコードが多すぎるよ。

コードベースに慣れているからリライトが著作権侵害だという主張は、完全に正しいわけじゃないよ。「内部知識」は著作権法には関係ないからね。それは著作権法よりも特許法の領域に近い。例えば、あるアーティストが空っぽの海の上に沈む夕日の写真を見たとしても、他の夕日を描くことができるのは、著作権侵害とはみなされない。著作権侵害とされるのは、コードを並べて、同じコードを言い換えただけで著作権法を回避しようとした場合だよ。だから、AIにコードベースへのアクセスを与えて、同じ（または似た）ものを作るように指示したら、ほぼ並行して書き換えたと見なされて著作権侵害になる可能性が高い。だけど、古いプロジェクトを見たり開いたりせずに、新しいライセンスのもとでプロジェクトをリライトすることはできるよ。ゼロから書き直すんだ。記憶を頼りに同じコードを書き直すんじゃなくて、全く新しいコードを書いて、同じような出力を出すようにすること。そうすること自体は違法ではないけど、法的には攻撃されやすいんだ。著作権の主張からそのリライトを守るのは難しいからね（ただし、全く異なるアルゴリズムやアーキテクチャを使って、違う方法で同じ結果を出すほどに違っていれば、著作権侵害の主張は避けられるかもしれない）。結局、技術的には「法的に守りにくい」ことは「違法」ではないけど、企業にとってはほとんどの場合、同じように扱うのがベストなんだ。

LLMにプログラムの完全なロジックとテストの詳細な説明を英語で書かせて、それを元に別のLLMにコードを生成させることができると思う。これって、クリーンルーム技術に似てるよね。

> 同じコードを記憶から書き直すんじゃなくて、同じような出力を出す全く新しいコードを書いてほしい。新しいコードは古いコードとどれくらい違わなきゃいけないの？それはどうやって測るの？

新しいメンテナがClaudeを「おしゃれなコード生成器」として使ってたなら（リポジトリにClaude.mdファイルがあるから、そうみたい）、ほぼ間違いなくchardetのソースコードでトレーニングされてるね。

これは良くない議論だね。人間やLLMによる書き直しを翻訳だと思ってみて。英語で書いた本を誰かがスペイン語に翻訳したら、それでも著作権の問題になるよね。翻訳と同じことだよ。作品のアイデアを持っていくのとは全然違う。だから、海賊がプリンセスを人質に取って、ヒーローが彼女を救うっていうアイデアを著作権で守ることはできない。それはあまりにも一般的すぎる。でも、ここにも限界がある。芸術作品があまりにも似ていることで訴訟が起きたこともあるし。ソフトウェアに戻ると、写真編集ソフトのアイデアを著作権で守ることはできないけど、そのソフトを作るソースコードは著作権で守れる。もしLLMに何とかして写真編集ソフトを作らせることができたら、あるいは誰かが自分で書いたら、それは一般的に「クリーンルーム」実装と呼ばれるもので、著作権フリーだよ（ただし特許の問題があるかもしれないけど、それはまた別の話）。でも、もしそうやってLLMを促したとして、LLMはどうやって必要なことを学んだの？他のプロジェクトのソースコードがそのトレーニングの入力になったの？これは今のところ法的なグレーゾーンだね。でも、問題になると思う。

ここでのピルグリムは著作権の仕組みをあまり理解していないと思う。>「完全なリライトだ」という主張は無関係だ。元のライセンスコードに十分に触れていたからだ。これは単純に真実じゃないよ。「クリーンルーム」コンセプトが存在する理由は、実際に法律が独立した実装が可能であることを認めているからなんだ。「クリーンルーム」の手法は訴訟を簡単にするためのトリックで、元のコードに触れていないことは求められていないんだ。例えば、リーナスや他の開発者がUnixの内部をよく知っていても、Linuxは実装されたんだ。法律が本当に求めているのは、新しいコードが元のコードの何かをコピーしているかどうかなんだ。クリーンルームのトリックは、似たようなものがあった場合、それは単なる偶然だと言いやすくするんだ。でも、それは必須条件じゃない。

その通りだね。自分が所有権を主張するメインのコードの作者は（多分みんなそうだよね！）、少なくとも著作権法の基本を勉強しておくべきだと思う。細かいところを間違えると、時間やお金、最終的にはビジネスにも影響が出るから、気をつけないとね。