そのコードはまだLGPLだよ。GitHubのリリースノートにリリースエンジニアが何を書こうが関係ない。元の著作者や著作権者が明示的に別のライセンスに再ライセンスすることに同意しない限り、そのコードはLGPLのままだ。あと、言及されているSCOTUSの決定は生成AI製品の著作権に関するもので、今回のケースとは全然違う。ここでは、ソースコードを変換して、なんか魔法みたいに著作権が消えたって話をしてるの？もしそれが本当に可能だったら、アメリカの著作権産業にどんな影響があるか想像してみて。

もし何かあるとすれば、SCOTUSの決定は、生成AIの変換が追加の創造的貢献を生まないことを示唆しているように思える。だから、元の著作権者が派生したAI作品に対するすべての権利を持つことになる。（私は法律の専門家ではないけど）

AIを使って完全にクリーンルームで書き直したなら、実質的には公共のものだね（でも多分そうじゃないだろうけど）。完全に新しい実装で内部が全く異なるなら、深い知識を持った人が作ってもLGPLにはならない可能性もある。著作権は「何かをコピーしたかどうか」だけを気にするから、「知識があるか」や「同じように振る舞うか」は関係ない。だから、十分に異なっていれば法的には問題ないかも。クリーンルームの要件は「裁判で通用することが保証されているか」についてであって、「法的リスクがあるが非派生的として通るかもしれないこと」ではないよ。

法律の世界には「LGPLなコード」なんてものは存在しないよ。それはコードに付随するxattrじゃないから。コピー行為があって、そのコピーが著作権法の下で許可されていたかどうかが問題なんだ。もしコードの作者がコピーしていいと言ったら、コピーできる。元の作者が許可していなかったのに、派生作品の作者がコピーしていいと言ったら、これは複雑になるね。

> 所有権の空白: もしそのコードが本当に機械によって作られた「新しい」作品なら、生成された瞬間に公有財産になる可能性があるから、MITライセンスは意味がなくなるかも。どうなるんだろう？AIモデルが生成したコードが合法かどうか、まだ法的な結論は出てないよね。私は法律の専門家じゃないけど、個人的には全く違法だと思う。モデルが訓練されたソースコードの著作者から許可を取ってないからね。だから、機械が作ったコードを公有財産としてリリースすることはできないと思う。モデルがどのようにインスパイアされて生成コードを作り出したのかもわからないし。これは「リバースエンジニアリング」の範疇に入るだろうし、それは人間だけの話じゃない。機械にも当てはまるよ。追記: モデルが訓練された最も制限のあるライセンスを、すべてのモデル生成コードに適用すべきだと思う。そして、元の著作者（コードに何らかの形で貢献したすべてのGitHubユーザー）とのライセンスモデルを設定して、AI企業から報酬を受け取るべきだ。つまり、コード関連のトークンが生成されるたびに、利益の一部がコミュニティ全体に還元されるべきなんだ。たとえみんながほんの少ししかもらえなくても、それは公平だと思う。アートのトレーニングに使われたアーティストにも同じことが適用されるべきだね。

それは実現不可能すぎて、これを願うくらいならUBIや世界平和を願った方がマシだね。

テクノロジーが進化して、AIがディズニーの利益を脅かすようになるまで待たなきゃね。

> モデルが訓練された最も制限のあるライセンスを、すべてのモデル生成コードに適用すべきだと思う。そのライセンスは「全ての権利を留保」と呼ばれていて、その場合、出力を何かに合法的に使うことはできない。許可されたライセンスのデータだけで訓練された研究モデルもあるけど（つまり「全ての権利を留保」データは使ってない）、それは最新技術と比べると、俗に言う「バカみたいな」ものだよね。でも、「モデルの出力は訓練データの派生作品である」というのが面白い結果をもたらすとしたら、それは実質的に、AI生成やAI支援のコードを含む可能性のあるすべてのオープンソースプロジェクトを消し去るか、少なくともAI以前のコミットに戻すことを強いることになるだろう。今やほぼすべての主要なオープンソースプロジェクトがそれに該当するからね。そして、厳密にAI以前の訓練データを持たない新しいモデルを合法的に訓練することも不可能になるだろう。なぜなら、訓練データが汚染されているかどうかわからなくなるから。

> AIモデルが生成したコードが、すべての公開されているソース（ライセンスの種類に関係なく）で訓練された場合、合法かどうかについての法的結論はまだ出ていない。もう手遅れだね。誰もAIコードがどこにあるか知らないし、AI生成コードを使えないという判決に従うことも不可能になってしまった。何とか可能にするための精神的・法的な体操があるかもしれないけど、今はもう手遅れだから合法にされるだろうね。

「AIモデルが生成したコードが、すべての公開されているソース（ライセンスの種類に関係なく）を基に訓練された場合、それが合法かどうかについてはまだ法的な結論が出ていません。」AIが新しいコードにたどり着いた方法によると思う。もし元のソースコードを使っていたら、たぶん共犯的な罪になるだろうけど、理論的にはAIモデルがそのプロジェクトに基づかない中間データを使ってリライトを生成することもできる。

> それはどういうこと？AIは所有権を主張できないし、人間もそれを生み出してないから主張できないよね。誰も所有権を主張できないなら、それは公共のものと見なされることが多い。一般的に、AIのトレーニングデータの著作権は関係ないよ。少なくともアメリカでは、裁判官たちがその点についてはっきりしてるからね。（ただし、AIが入力データをほぼそのまま再現した場合は別だけど。_でも一般的には、AIがコードベースでトレーニングされているわけじゃなくて、AIがそれを使ったり書き直したりしている話だよね_。）(1): これは、誰が所有権を持っているのか誰も知らないというのとは違うよ。誰も著作権の許可を与えられないという意味で、誰も所有していない可能性もある（つまり公共のものの逆だけど）、でも誰も訴えることもできない（事実上公共のもの）。

LLMが生成したすべてのコードをGPL v3の下にあると考えるのは全然問題ないよ。ただし、モデルの作者がそれがGPL v3のコードでトレーニングされていないことを疑いなく証明できる場合を除いてね。ウイルスライセンスの極みだね。 ;-)

> 所有権の空白: もしそのコードが本当に機械によって作られた「新しい」作品なら、生成された瞬間に公有財産になる可能性があるから、MITライセンスは意味がなくなるかも。どこからこの結論が出てきたのか、ちょっと理解できないな。私には、AIが書いた作品は著作権がないってことのように聞こえるし、元のコードをコピー＆ペーストしてるだけみたい。元のコードをコピー＆ペーストしたからって、それが公有財産になるわけじゃないよね。AIが生成したコードは著作権がないし、公有財産にもならないし、元のコードのライセンス外で使うこともできない。ここにどんなパラドックスがあるんだろう？

「もし」それが新しい作品なら、著作権がないかもしれないって言ってるんだろうね。あなたはそれがまだ元の作品だから、著作権があるって考えてるんだと思う。彼らはあなたの立場が正しいかどうかを修辞的に問いかけているんじゃないかな。

> 私には、AIが書いた作品は著作権がないように聞こえる。私たちはこのことのすべての影響を考え始めたばかりだと思うし、誰かが生成された画像の著作権を持てなかったという一つのケースに飛びついているけど、コードに関してはそんなに簡単じゃないよね。これが解決したと言えるようになるまでには、もっと多くの訴訟が必要だと思う。「生成された」コードが著作権を持たないなら、何が「生成された」と見なされるのか線引きはどこにあるの？マクロはどうなる？他のコードを生成するコードは？Protobufは？コードを生成するツールがあるなら、また線引きはどこにあるの？単にサードパーティのツールを使うだけなの？自分で訓練したらどうなる？「ランダム」なコード生成と当選者を選ぶ（どんな手段であれ）は？全ての空間をブルートフォースする（バカな例だけど、今はバカな話をしてるから）ことは？単に著作権がない「AI」隣接のものだけなの？そうだとしたら、AIをどう定義するの？オートコンプリートは？インテリセンスは？もっと賢いインテリセンスは？LLMと電源プラグの間でバカな比較をする弁護士がいるような裁判になるのかな？それとも、そろばん（そろばん？）を数えることになるのかな…「でも、あなたの名誉、これはただのランダムな数字や行列の掛け算です…」

要するに、リベラルライセンスやパブリックドメインの素材だけで訓練されたAIが書いた作品には著作権がないってことなんだ。法的には「作品」とは言えないから、誰もそれにライセンスを付けたり権利を主張したりできない。もし僕がプロジェクト・グーテンベルクの内容でリメリック生成器を訓練したとしても、その出力がどんなにクリエイティブでも、この解釈の下では著作権が認められない。これは法律の意図や文言から見ても、最も合理的な解釈だよ。法的人格でない存在は著作権を持てないし、法的人格も非人間が作ったものの著作権を主張できない。ただし、その作品の「創造的な力」がある場合は別だけどね。

AIが書いたものは絶対に著作権があるよ。どこに線を引くか、そして人間がどれだけどんな形で関与する必要があるかについては、まだ解決されていない緊張関係がある。

FYI: 概念は「著作権」であって「コピーライト」じゃないよ。「コピーライト」と形容詞にはならないからね。形容詞は「著作権がある」だよ。

これに関連するかもね：「このプロジェクトを再ライセンスする権利はない (github.com/chardet)」 https://news.ycombinator.com/item?id=47259177

それは別のプロジェクトだよね？この場合は違うと思う。だって、そのプロジェクトは明らかに盗まれた感じがするから。裁判所もそれを確認できると思う。主な問題は、AIによるリライトがクリーンなリライトなのかどうかだと思う。クリーンなリライトなら、どんなライセンスでも選べるはず。

設計上、リライトを行うLLMが元のコードベースに触れていたかどうかはわからないよね。AI企業が訓練素材を開示しない限り、彼らは法律を破ったことを認めたくないから、そんなことはしないだろうし。

LLMがLGPLライセンスのコードを読むのは法律に反するのかな？これはまだ解決されていない複雑な問題だよ。明らかに、LGPLコードをそのまま大量に再現するのは違法だろうね。でも、どのくらいの量がLGPL違反を引き起こすかはあまり明確じゃない。1行？2行？関数？それが些細なものであれば？それに、LGPLコードを入力として受け取ったシステムの出力は必ず派生物なのか？もし僕がLGPLコードを読んでPythonのコーディングを学んで、新しいものを書いたとしても、既存の法律の下では著作権違反にはならないことは明らかだよ。たとえ人間としてはLGPLコードから理解したトークンを並べ替えて新しい結果を得ているだけでもね。ソフトウェアと法制度にとって厳しい時代だね。答えは持ってないけど、好き嫌いに関わらず、こういったシステムはこれからも存在し続けるから、どうやって共存していくかを学ぶ必要があるよ。

リライトするためにそのものを見せたときに露呈したんだ。

LLMが訓練中に触れていたかどうかは関係ないよ。クリーンルームリライトは、1つのLLMがターゲットの詳細な分析を行い（バイナリ形式ならリバースエンジニアリング）、その分析を別のLLMに提供して実装の基にすることでできるんだ。

プロジェクトのソースを見ることが、同じようなプロジェクトを作るのを妨げるわけじゃないよ。コードを見たからってね。細部にこそ悪魔が潜んでいるんだ。

> 設計上、リライトを行うLLMが元のコードベースに触れていたかどうかはわからない。理論的には同意するけど、実際には裁判所が意思決定プロセスを公開するよう要求するだろう。「わからない」という言い訳は通用しない。実際の人間も裁判で真実を話さなきゃいけないからね。LLMは裁判所に嘘をついたり、チューバッカ弁護を使ったりしちゃいけない。あと、AIモデルが意思決定プロセスの起源を説明できることも確かだし、有効なコードも生成できるから、理論的には何でも自動生成できる。

現在の混合ライセンスデータで訓練されたLLMを使って、より制限の少ないライセンスにリライトするのは難しいと思う。でも、GPLのコードを出力するのには使えるかもしれないね。

この話は「クリーンルーム」実装の意味を誤解している前提に基づいていると思う。「元のコードを一度も読まなければ、書いたものは全部自分のもの」ってわけじゃないからね。もし完全に密閉されたコードベースがあって、それがたまたまGCCのコードベースと行ごとに一致していたとしても、それはコピーになる。従来の人間主導のクリーンルーム実装は、元のコードベースと十分に一致する可能性が極めて低い。LLMの場合、その可能性はずっと高い（実際には全然「クリーンルーム」じゃないから）。クリーンルーム実装の実際の意味は、APIから派生していて、実装からではない（少し簡略化してるけど）。再実装が実際に「新しい実装」かどうかは、主観的だけど経験的な質問で、新しいコードベースが古いものとどれだけ似ているかにかかっている。もし似すぎていたら、それはコピーだ。ここでchardetのメンテナがやったことは、法的に非常に無責任だ。彼らのコードが本当にMITであって、LGPLでないことを保証する簡単な方法はない。ライブラリの下流ユーザーは、ライセンスがいつの間にか切り替わるリスクがある。理想的には、これが彼らの責任あるメンテナとしての評判を損なわせ、誰かがそのプロジェクトを引き継ぐことになるだろう。でも実際には、たぶん数年はMITのままで、その後突然「サプライチェーンの問題」が起きるだろうね。数年前のmimemagicみたいに。

著者は、文法的には完全に異なるが、意味的には同じコードについて話している。つまり、再実装はまだ派生作品と見なされる可能性がある。著作権侵害を隠すだけのものとして。新しい作品としても、AIがAPI、APIドキュメント、APIの使用/ファジングに基づいて仕様を生成し、その後AIをリセットしてその仕様を使ってリライトを行うことは何も妨げない。「同じことをする」ことは著作権保護にはならない。特許法が必要だ。特許法でも、イノベーションや概念が必要で、正確な実装の詳細は必要ない。つまり、ソフトウェア特許があっても（理論的には）、ソフトウェアで行われるほとんどのことは特許を取得できない（実装の詳細に過ぎないから、発明ではない）。（1）：理論的には、実際には決して与えられるべきではない多くの特許が付与されている長い記録がある。これが特許無効化の高コストと相まって、経済的な損害を引き起こしている。

> LLMの場合、確率はかなり高いよ（実際には全然「クリーンルーム」じゃないからね）。それには反論したいな。最近の自分のGitHubのコードベースを見てみてよ（同じユーザー名）；自分はpar2（par2z）、bzip2（bzip2z）、rar（rarz）、7zip（z7z）をクリーンルームで再実装したから、これがいいテストケースかも（今までどこにも発表してなかったから、ここで初めて言うけど…） https://github.com/pmarreck?tab=repositories&type=source 7zipの再実装には特に気を使ったよ。これは最も議論を呼ぶ可能性が高いからね。ここに「ダーティチーム」が作成した完全な仕様があるリポジトリがあって、LLMが元のソースにアクセスせずに作業したものだよ： https://github.com/pmarreck/7z-cleanroom-spec 完全に異なる言語で書き直されているだけでなく、仕様に従わなければならない部分を除いて、意味的にも完全に異なると思う。元のソースと比較して、明らかな類似点を見つけてみてほしい。これらすべてにおいて、仕様との互換性を確保するために、元のツールとの双方向の相互運用テストも含めているよ。

> 「元のコードを一度も読まなければ、あなたが書いたものはすべてあなたのもの」という意味ではないよ。これを正確に示す前例があると思うよ。例えば、Phoenixのような人たちがIBM PCのBIOSを書き直した例がある。LLMに、可能な限りアセンブラでレジスタCを使用するように指示するのは簡単で、その結果、異なるコードになるよ。

「クリーンルーム実装」の実際の意味は、実装からではなくAPIから派生していることだよ。簡略化しているのはわかるけど、あなたの広い視点を損なうつもりはないよ。でも、APIから派生した実装でも問題が起こる可能性があるんだ。Google対Oracleのケースみたいにね。[1] 最高裁は「フェアユース」の観点からGoogleに有利な判決を下したけど、APIの著作権性についての前例を設定することは回避したんだ。今後のケースが前例を設定したかどうかは知らないけど、ふと思い出したよ。[1]: https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_....

> もしあなたがGCCのコードベースと行ごとに一致するような完全に密閉されたコードベースを持っていたら、それでもコピーになるよ。法律はそう言ってるからね。[1] もし二人が独立して同じものを作ったら、それぞれに著作権があるんだ。もし二つの作品が独立している可能性が非常に低い（例えば、gccのコードベース）なら、最初の著者はコピーを主張して裁判に行くかもしれないけど、二番目の著者が自分の作品が独立していることを示せれば、そのケースは失敗するよ。たとえそれがどんなにあり得ないことであってもね。[1] https://lawhandbook.sa.gov.au/ch11s13.php?lscsa_prod%5Bpage%...

君の著作権法の解釈には同意できないな。著作権はコピーを禁止してるよ：オリジナルからコピーへの情報の流れがなきゃ「コピー」にはならない。自発的に同じコンテンツが生成されるのは、裁判所では純粋に機能的で、数学的な法則による要求から派生したものと見なされることが多い。特許法は違って、同じように情報の流れに依存してないんだ。

「クリーンルーム」実装の概念が完全に馬鹿げてると思う。みんなで集まって、オリジナルのソースコードを見ないって約束しながら何かを書き直すって、基本的にその前提が不可能だってことを保証してるようなもんだし、既存の著作権法を笑い飛ばすための法的な道化師の踊りみたいに聞こえる。

>「クリーンルーム実装」の実際の意味は、APIから派生したものであり、実装からではない。これは間違いで、こう考えると訴えられる可能性があるよ。

> 完全に密閉されたコードベースがたまたまGCCのコードベースと行ごとに一致したとしても、それはコピーだよ。もし何らかの方法で参照なしに同じコードをランダムに生成したら、それはコピーじゃないし、著作権を侵害してない。訴えられて負けるかもしれないけど、プラトニックには問題ないよ。もし単に少し似ているだけなら、実際には問題ないことが多い。似ている部分が機能の著作権がない部分の構造的結果だと主張するのはすごく簡単になるから。 >「クリーンルーム実装」の実際の意味は、APIから派生したものであり、実装からではない（少し簡略化してるけど）。これはほぼ正反対のことだよ。クリーンルーム実装のダーティフェーズでは、著作権がない実装の詳細を含むことが許可されている仕様が生成される。APIを生成することとして定義されているわけではなく、もし元のものにあまりにも近いAPI仕様を生成したら、著作権のある部分を含めてしまってプロセスが汚れてしまうかもしれない。Google対Oracleの件で、これが以前より面倒になったよね。 > 再実装が実際に「新しい実装」であるかどうかは主観的だけど、実証的な質問で、基本的には新しいコードベースが古いものとどれだけ似ているかにかかってる。もし似すぎていたら、それはコピーだよ。CRREに従っていれば、それはコピーじゃない、たとえ1:1で同じでも。コピーとして判断されることになるから、非自明な量のコードの実質的な類似性は、ほぼ確実にクリーンルームプロセスを逸脱したことを意味して、防御として機能しなくなるけど、もしCRREに従っていたら、プラトニックにはコピーじゃない。 > chardetのメンテナがやったことは、法的には非常に無責任だよね。これには同意するけど、思っているほどドラマチックではないかも。10年か20年前に、商業的な日本のフォントのアウトラインを機械的に（手動ではなく）コピーしたとされる無料の日本のフォント/タイプフェイスの問題があった。フォントのアウトラインはアメリカや日本では著作権がないけど、ヨーロッパの一部ではあるし、特定のフォントの正確な構造はどこでも著作権がある（例えば、デジタルフォントのベクターデータやビットマップフィールド、形状のアイデアとは対照的に）。この問題の結果はどうなったの？ ディストリビューションはそのフォントの提供をやめて、何かおおよそ互換性のあるものに置き換えた。実際にそのフォントは侵害してたの？ おそらくそうではないけど、安全策を取るのが一番だよね。

生成AIが状況を大きく変えたせいで、今の著作権法は完全に時代遅れになっちゃったよね。機械学習に関する条項があったとしても、それはランキングアルゴリズムや特定のタスク用モデルのトレーニングみたいな、元の素材と直接競争しないようなことを想定して書かれてたから。コードに関しても、人間が提供する価値の位置が完全に変わっちゃった。著作権はアイデアの特定の表現を保護するけど、今はその表現を自動生成できるからね（LLMの間接的な影響で「派生作品」の意味も混乱してるし）。生成プロセスを導いたアイデアを保護するのはもっと難しい問題だよ（それには特許があって、これもややこしい）。GNUにとっても戦略的な問題になってる。GNUの目的はライセンスそのものじゃなくて、ユーザーが自分のソフトウェアを自由にコントロールできることだから。ライセンスはGNUが望む自由を法的に実現するための巧妙な手段だったんだ。でも、今はコードのライセンスを洗浄するのが簡単すぎて、効果的な手段じゃなくなっちゃった。GNUのライセンス戦略も、コードの希少性に依存してたんだよね（GCCに貢献するのは、ゼロからコンパイラを書くのは難しすぎるから）。でも、許可されたOSSのおかげで希少性が減ってきてるし、生成AIはその最後の一撃になっちゃった。

それは問題じゃないよ。AIに作品を渡して「これを書き直して」と言えば、派生作品を作ったことになる。AIに作品を渡さずに「（元のコードがすることを）するプログラムを書いて」と言ったら、派生作品にはならない。発見の過程で、元の作者は書き直しをした人のClaudeログを見て、どれがどれか確認できる。もし書き直しをした人が訴訟中にClaudeログを削除したら、刑務所行きだよ。訴訟前に削除した場合は、裁判所が証拠に基づいてどちらが可能性が高いかを解釈することになる。

法を大胆に破って「状況を変える」ってことだね。

> GNUの目的はライセンスそのものじゃなくて、ユーザーが自分のソフトウェアを自由にコントロールできることだ。これ、ちょっと誤解してるかも。GNUはみんなが自分の目的でコンピュータを使えるようにしたいんだ。ソフトウェアが焦点なのは、ソフトウェアがボトルネックだったから。誰でも自由にソフトウェアを作れる世界がGNUのユートピアであって、問題じゃないよ。明らかにGNUにとっての大きな問題はソフトウェアじゃなくて、すでに20年前のFOSSでかなり商品化されてるからね。むしろ制限されたハードウェアが問題で、AIはそれにはまだ触れてないかも。

じゃあ、どうやって書き直したの？もし二段階でやったら、問題ないんじゃない？フェーズ1：元の製品から要件を抽出する（理想的にはコードではなく）。フェーズ2：元の製品やコードを参照せずに実装する。俺はシンプルな「クリーンルーム」LLMパイプラインを書いたけど、要件が結局コードの正確な説明になっちゃって、目的を達成できなかった。無駄を減らすつもりだったのに、逆に無駄が増えちゃった！偶然の要素を全部再現しちゃって、さらに「企業向け」な要素が追加されちゃった。プロンプトで解決できるかどうかはわからないけど、コードから機能を導き出すように指示するのはどうだろう？それは試してないし、どれくらい効果があるかもわからない。要件のフェーズは、たぶん自動化するのは難しいと思う。

LLMが元のソースコードで訓練されている場合、フェーズ2をどうやって進めるの？ これは、元の本でプロットを説明することでLLMに「ハリー・ポッター」を「書き直す」ことと同じじゃない？

一番の問題は、LLMが訓練されたコードをそのままコピーするだけでなく、そのコメントまでコピーする可能性があることだよね。コードが一対一のコピーだと主張するのは分かるけど、コメントまで同じだったら、明らかにコピーじゃない？

実際に、ドキュメンテーションコメントの重要な部分をそのままコピーしてたよ。