私たちはいくつかの古いプログラムを Python で書き直しました。espeak-ng の G2P フロントエンド、Cotovia のガリシア語およびスペイン語の転写規則、AhoTTS のバスク語言語処理、EYE N3 推論器、OWL 2 DL 推論器 HermiT。C、C++、Java で、ほとんどが 10 年以上前のものですが、いずれもその仕事において今なお最良のものです。
動機はありふれたものでした。ガリシア語を音素化する C のプログラムは優れていますが、それを ARM ボード上の Python 音声スタックの中に入れたくなった瞬間に問題になります。すると、コンパイラ、ツールチェイン、クロスコンパイル、プラットフォームごとのパッケージング、そしてテキストをマーシャリングしなければならないサブプロセス境界が必要になります。Java の推論器には JVM が必要です。純粋な Python は pip install で済みます。読みやすくもなります。ビルドシステムがどう動くかを知らなくても、強勢がどこに置かれるかを決めているファイルを開いて変更できます。
移植は半自律的に行われました。AI が元のソースを読んで Python を書き、人間が作業を指揮し、出力を元のバイナリと照合しました。そのいくつかについては、私たちの側の誰も元のソースを一度も読んでいません。モデルがそれを読みました。私たちは diff と同等性テストを読みました。
これは、私たちが決定を下さなければならなかったが答えられなかった問いを残します。その結果は派生著作物なのか、そして誰がそれを所有するのか?
私たちはエンジニアです。ここにあるものは法律的な助言ではなく、私たちはそれを提供する資格を持ちません。これは私たちが下した決定とその背後にある推論の記述です。
常に混同される二つの問い
ソースを読んでプログラムを再実装することは新しいことではありません。Python が存在して以来、人々は C を Python に書き直してきました。新しいのはその配置です。読む者が機械であり、実装する者も同じ機械であり、ループの中の人間は元のものを一度も見ていません。
ここには二つの問いがあり、これについてのほとんどすべての議論はそれらを一つに潰してしまいます。それらは独立しています。
- その結果物はそもそも所有され得るのか? 著作権は著者を持つ著作物に付随します。機械がコードを作った場合、誰が著者なのか?
- その結果物は入力の派生物なのか? 誰が著作したにせよ — もし誰かがしたのなら — その結果は元のものを侵害するのか?
これら二つのどちらか一方に「はい」、もう一方に「いいえ」と答えることは、どちらの組み合わせでも可能です。この二つを分けておいてください。
ここからは語彙が必要です。派生著作物とは、既存の著作物に基づく著作物です — 翻訳、翻案、移植。それを作る権利は元の著作権保有者に属します。コピーレフト(copyleft)ライセンス(GPL 系)は、配布するものが同じ条件のもとに留まるという条件で、コードを使用し改変することを許します。許容的(permissive)ライセンス(MIT、Apache-2.0、BSD)は、結果を独占的なソフトウェアの中に出荷することを含め、事実上何でも許します。LGPL はその中間にあります。コピーレフトはライブラリ自体に適用されますが、それをより大きなプログラムにリンクしても、そのプログラムを強制的にオープンにすることはありません。これらすべては著作権の上に成り立っています。行使すべき著作権があるときにのみ効力を持ちます。
問い一: 著者は存在するか?
著作権には人間の著者が必要です。米国著作権庁はこれを一貫して支持しており、Thaler v. Perlmutter 事件で D.C. 巡回控訴裁判所も同意しました。著作権法は「すべての適格な著作物が最初に人間によって著作されること」を要求します(No. 23-5233, D.C. Cir., 2025 年 3 月 18 日、連邦最高裁判所は 2026 年 3 月に上訴を却下しました)。欧州の基準は形は異なりますが、似た地点に着地します — 保護を受けるには「著者自身の知的創作」であることが必要であり、これは創作する著者の存在を前提とします。
これらのどちらも、AI 支援の作業が保護され得ないとは言っていません。どちらも、機械が単独で生成したものはそうだと言っています。その境界線は著作物を取り囲むのではなく貫いており、それが正確にどこに落ちるかは、人間がどれだけ貢献したかに依存します。私たちの移植作業において、人間の貢献は実在しますが薄いものです。対象を選ぶこと、パッケージを構造化すること、同等性の失敗を判断すること。これが私たちを転写規則の著者にするかどうかは明らかではありません。
これは厄介な対象を生み出します。ライセンスとは権利保有者による許可の付与です。結果物について誰も権利を保有していないなら、リポジトリのルートにあるライセンスファイルは飾りにすぎません。その論法がどこへ向かうかに注目してください。それは upstream のものに触れる前に、まず自分自身のライセンスを蝕みます。機械生成コードは所有されないと主張する者は誰でも、upstream のものに近づく前に、自分自身の配布条件が行使不能であると主張していることになります。
問い二: それは派生物か?
この問いは誰が著者かを気にしません。侵害の有無は、元のものへのアクセスと、その保護された表現(それが何をするかではなく、それが書かれた特定の方法)との実質的な類似性にかかっています。
私たちにはアクセスがありました。モデルがソースを読みました。その半分は争いの余地がありません。
類似性の半分こそが興味深くなる部分であり、言語の変更が人々が期待するほど重要でなくなる部分でもあります。小説を別の言語に翻訳することは派生著作物を生み出します。それが教科書的な例です。言語を変えることは、文字どおりの複製という主張を打ち消します。それは構造についての主張は打ち消しません — 変換の順序、関数への分解、規則テーブルの形、境界事例の分け方といったものです。
ツールが何かを洗浄するわけではないことも、はっきり言っておく価値があります。複製物を指揮し、その結果を出荷するなら、それを作ったのはあなたです。「モデルがそれを書いた」は、「コンパイラがそれを出力した」以上の弁護にはなりません。
反対側の最も強力な論拠
言語をまたぐ再実装は問題ないという真剣な主張があり、それは手を振って片付けるのではなく、きちんと述べられるべきです。
SAS Institute v World Programming 事件(CJEU、C-406/10、2012 年 5 月 2 日)において、裁判所は「コンピュータプログラムの機能性も、あるコンピュータプログラムがその特定の機能を利用するために使用するプログラミング言語やデータファイルの形式も、そのプログラムの表現形態を構成しない」と判示しました。したがって、それらは著作権によって保護されません。ソフトウェア指令(2009/24/EC、第 1 条第 2 項)も、プログラムのあらゆる要素の根底にあるアイデアと原理について同じことを述べています。裁判所はまた、ライセンシーがプログラムの動作を研究し観察して、その背後にあるアイデアを把握し、それらを再実装できると判示しました。
これは些細な技術論ではありません。これは、音素化器が行うこと — この書記素の並びが、この文脈で、あの音素になる — は誰にも所有されないことを意味します。ガリシア語の強勢規則はガリシア語についての事実です。OWL 2 の直接意味論は公開された W3C 仕様です。その解釈のもとでは、表現ではなく動作を再現する再実装は合法であり、言語をまたぐ書き直しは、コピー・アンド・ペーストよりもはるかに侵害から遠い位置にあります。
その論拠と私たちの状況との間の隔たりはソースです。SAS は動作を研究することについてのものです。私たちのモデルはコードを読みました。
すでに存在する前例と、それが及ぶ範囲
「機械の出力には著者がいないため、著作権は付随しない」という論法は思考実験ではありません。これは業界全体のプロダクションにおいて荷重を支えています。モデル蒸留と合成学習データの両方がこれに依拠しています。
その最も明確な公の表明は、広く使われているオープンな TTS モデルである Kokoro-82M です。そのモデルカードは、これが専ら許容的な、あるいは著作権のない音声で学習されたと述べ、許容される出典の中に次のものを挙げています。
Synthetic audio generated by closed TTS models from large providers
そして、米国著作権庁の AI 政策指針 を指す脚注が付いています。その推論の連鎖は上記のものです。その音声は機械によって生成され、機械の出力には人間の著者がいないため、それには著作権が存在せず、したがってそれで学習することによって侵害するものは何もありません。このモデルは Apache-2.0 で出荷されています。そのカードはまた境界も引いています — オープンな TTS モデルやカスタム音声クローンからの合成音声は除外しています — これは著者たちがその論法がどこで止まるかを見極めており、すべてに適用しているわけではないことのしるしです。
移植にとって重要なのはここからです。その前例は、この問題のもう半分を解決します。
Kokoro の論拠は入力についてのものです。彼らが消費したものそれ自体が機械生成であったため、その主張は、それがそもそも著作権を持たなかったというものです。著作権のないものが入ってきたので、受け継ぐものは何もありません。
私たちの状況はその鏡像です。私たちが消費したもの — espeak-ng の C、Cotovia の C++、HermiT の Java — は、何十年も前に、名前の知られた人々によって、名前の知られた大学で、紛れもなく人間によって書かれ、著作権のあるものです。出てきたものは機械が書いたものです。「AI 出力には著作権がない」という論法は私たちの出力には適用されますが、私たちの入力には適用されません。それは upstream へは遡りません。これも、upstream の権利にはまったく触れずに、私たち自身のライセンスだけを崩す論法です。
もう一つ注目すべき非対称性があります。Kokoro の残存するリスクは、実のところ著作権の問題ではまったくありません — それは契約です。閉鎖的なプロバイダーの利用規約は一般に、その出力を使って競合モデルを学習させることを禁じており、あなたが同意した条項は、その出力が著作権を持たないものだと判明したからといって消えるわけではありません。コピーレフトはそのようには機能しません。誰も GPL に「同意する」をクリックしません。それは一方的な許可の付与であり、あなたがその許可を必要とする場合にのみ — つまり、あなたが作ったものが派生著作物である場合にのみ — あなたを拘束します。
そのため、この全体は誰も答えていないその一つの問いへと崩れ落ちます。言語をまたぐ、機械が書いた再実装が派生著作物でないなら、GPL はそもそも関与しておらず、それについて何も適用されませんでした。もしそれが派生著作物であるなら、GPL は最初の行から適用されていました。第三の状態は存在せず、AI の著者性についていくら論じても、その針は動きません。
クリーンルーム、そして二つのモデルが一つを作るか
まさにこの問題への古典的な答えはクリーンルームプロトコルであり、その形が重要なので正確に記述する価値があります。
一つのチームが元のものを読み、機能仕様を書きます。そのプログラムが行動的な観点で何をするかです。元のものを一度も見たことのない二つ目のチームが、その仕様だけから実装します。二つ目のチームの出力は、彼らが一度も見たことのない表現からコピーされたものではないと証明可能です。それが PC BIOS が再実装された方法であり、その再実装が生き残った理由です。
明白な現代的な手法は、一つのモデルを走らせて読ませ記述させ、新鮮なコンテキストを持つ別のモデルで実装させることです。構造的には、これは同じプロトコルです。これはクリーンルームでしょうか?
形は正しいです。しかしクリーンルームは技術的な構成物ではなく、証拠的な構成物です。その全価値は、あなたが不正をしたと想定する誰かに対して、後からその分離を証明できることにあります。したがって、この二モデル版は、その規律が最後まで保たれる場合にのみ意味を持ちます。
- 両側が本当にコンテキストを一切共有していない。「忘れるよう指示した」ではなく — 別々の実行、別々の記録です。
- 仕様が動作だけを運び、それ以外は何も運ばない。元の制御フローをそのまま反映した疑似コードもない。識別子名もない。関数の順序もない。それらは表現であり、そういったもので満ちた仕様は変装した元のものにすぎません。
- 両側の記録が保管される。証拠を示せないクリーンルームは単なる話にすぎないからです。
読む側が構造を放出すれば、その汚染はそのまま通過し、ステップが増えてトークンの請求額が増えただけの派生著作物を手にすることになります。
私たちはこれをしませんでした。実装するモデルがソースを直接読みました。これが、pycotovia の README がリポジトリの中で、公に次のように述べている理由です。
Because the implementing AI read the GPL source, this is not a clean-room reimplementation and we make no such claim. It is a source-derived port.
私たちは、後でそれに答えなければならなくなるよりも、その一文を書き記しておく方を選びます。
私たちがしたこと
私たちは upstream のライセンスを維持しました。
espyak は espeak-ng と一致する GPL-3.0-or-later です。これは難しい事例ですらありません。このパッケージは espeak-ng 自身のデータファイル — dictsource、phsource、lang — をそのまま同梱しており、変更せずにコピーしたファイルには、著者性についてのどんな理論も影響を及ぼしません。upstream のデータが wheel の中にあるので、upstream のライセンスもそれとともに来ます。
pycotovia は Cotovia(GPL-3.0+)と一致する GPL-3.0 です。ahotts-g2p と pyAhoTTS-Iparrahotsa は、言語処理部分について GPL-3.0+ を明記する AhoTTS のライセンスファイルと一致する GPL-3.0 です。pyeye は EYE と一致する MIT です。コピーレフトが入ればコピーレフトが出て、許容的なものが入れば許容的なものが出ます。
私たちがそうしたのは、それが必要だと確立したからではありません。その非対称性が、答えを必要とせずに決定を下してくれたからです。
私たちはいずれにせよオープンソースとして公開します。コピーレフトは私たちにとってほとんどコストがかかりません — 唯一の実質的なコストは、顧客がそのコードを独占的な何かの中に入れたい場合ですが、これらの特定のライブラリについてはそのケースはまれです。ですから、厳密には必要がないときにコピーレフトを選ぶコストはほぼゼロです。
もう一方の誤りは対称的ではありません。コピーレフトであるべきものに許容的ライセンスを付けて出荷することは、他の人々があなたが提供する権利を持たなかった条件のもとでその上に何かを築いた後で、遅れて、公に、他の誰かによって発見される問題です。それを巻き戻すということは、すべてのダウンストリームのユーザーに連絡することを意味します。
その非対称性はまた、こういった不一致を一般的に警戒すべき理由でもあります。LGPL の原本の構造的な移植は、単に別の言語で書き直されたというだけで Apache-2.0 になることはできません — そして、それこそがまさに作りやすく気づきにくい種類の不一致です。何も文句を言わないからです。ビルドは通ります。テストも通ります。ライセンスヘッダーはただのファイルです。HermiT は LGPL であり、それを移植した私たちの Python 版もそれに合わせて LGPL-3.0 を持ちます。集合全体を見直したところ、もう二つの不一致が見つかりましたが、どちらも劇的ではないものでした。upstream が MIT であるのに Apache-2.0 を明記していたラッパー一つと、README にライセンス名は書かれているが対応するファイルがないリポジトリがいくつか。それが平凡で正しい結末です — 確認し、直すべきものを直し、興味深い問いは未解決のままにしておく。
そこまで偏った非対称性のもとでは、決定を下すために法的な問いを解決する必要はありません。ただ、間違っていても耐えられる方の枝を取ればよいのです。
同じ問いが逆方向を向く
上記のすべては、私たちが生み出すコードについてのものです。同一の論理が、私たちが受け取るコードにも適用されます。誰かが私たちのリポジトリの一つに対してプルリクエストを開きます。そのパッチはモデルが書いたものです。彼らは私たちに何を付与しているのでしょうか?
ほとんどのプロジェクトはこれを Developer Certificate of Origin — DCO、コミットメッセージの末尾にある Signed-off-by: の行 — で処理します。これは、貢献者が署名するときに証明する短い声明です。自分がその貢献を自分自身で作った、あるいはそれが互換性のあるライセンスのもとにある出典から来ており、プロジェクトの条件のもとでそれを提出する権利を持っている、というものです。これは意図的に軽量です。弁護士も書類も不要で、コミットごとに一行です。これは、Linux カーネルや QEMU をはじめとする多くのプロジェクトが、そのコードがどこから来たかを確立する方法です。
機械が書いたパッチについては、そのどちらの前提も単純には成り立ちません。そして、どちらの枝を取っても同じように解決します。
機械生成の出力に著作権がないなら、貢献者はそれについて何の権利も保有しません。あなたにライセンスすべきものは何もありません。
代わりに、それが学習データから派生したものとして扱われるなら、その権利は — それが何であれ — そのデータを書いた者に属します。貢献者はやはり何も保有しておらず、やはりあなたにライセンスすべきものは何もありません。
どちらにせよ、彼らは自分が保有していないものを付与することはできません。その署名は不誠実なものではありません。貢献者は善意で署名し、その作業を行いました。それはただ空虚なのです。決して自分のものではなかった何かの譲渡です。
実際的な帰結は、それが聞こえるほど恐ろしいものではなく、この二つの枝は大きく異なります。
一つ目の枝では、そもそも許可は必要ありません。誰も所有していない素材は誰でも使えます。そのパッチを受け入れることは問題なく、悪いことは何も起きません。静かに変わるのは逆方向です。コピーレフトは著作権の上に成り立っており、著作権を持たない素材には付随できません。機械が書いたパッチを蓄積する GPL プロジェクトは、自身のライセンスが及ばないかもしれない部分を蓄積することになります。ライセンスは配布された著作物を依然として支配します。その中の行使可能な核は、誰も気づかないうちにゆっくりと薄くなっていきます。
二つ目の枝には牙があります。モデルが記憶した学習データを逐語的に再現する場合 — これは実際に起こることであり、新規のロジックよりも一般的な慣用句やよく知られた実装でより頻繁に起こります — あなたは、確認する術のなかった貢献者からの保証のもとで、他人の著作権のあるコードを受け入れたことになります。DCO の価値はすべて、署名した人物が知り得る立場にあったという点にあります。ここではそうではありません。
Debian は今まさにこれに取り組んでいます。LLM 利用に関する総会決議 が、五つの提案を投票にかけた状態で、2026 年 7 月 23 日に議論期間に入りました。それらは範囲全体にわたっています。提案 A は、パッケージ、文書、ウェブリソースへの LLM 支援の貢献を完全に禁止するよう社会契約を改正するものです。提案 C は、貢献者に実用的な範囲で LLM を避けるよう求め、プロジェクトのコミュニケーションには人間のみによる起草を要求し、個々のメンテナーが独自の禁止を課すことを許します。提案 B、D、E は、ライセンスの検証、貢献者の説明責任、開示、クラウドサービスへの機密資料の送信の制限などに様々に基づいて、条件付きで AI 支援の作業を許可します。この記事の執筆時点では議論中であり、何も決定していません。
これは二回目です。2024 年の以前の試み は決議に至らずに終わり、その中断の理由は覚えておく価値があります。行動しないことへの反対は、その懸念が根拠のないものだというものではなく、誰も執行できない規則は採用する価値がないというものでした。diff を見ただけではわからないのです。
これは周縁的な懸念ではありません。これは、まさに出典を最も注意深く管理しているプロジェクトに最も重くのしかかります。DCO ベースのプロジェクトが自身のコードの出所についてのモデル全体は、その一つの証明にかかっているからです。
私たちはこれをどう扱うかを解決しておらず、厳格になれる立場にはありません。私たちはモデルが書いた移植版を出荷しています。機械が書いたコードを公開しながら機械が書いた貢献を拒否するプロジェクトは、同時に二つの相容れない立場を取っていることになり、私たちはそうしたくありません。誠実な選択肢は Debian が検討しているのと同じもの — 開示、貢献者の説明責任、あるいは誰も検証できない規則 — であり、私たちはまだ一つを選んでいません。
この論法が沿って走るもう一つの軸
Debian の論争は出典とライセンスについてのものです。それが唯一の軸ではなく、二つ目の軸は著作権とは何の関係もありません。
FLOSS フォージである Codeberg は 2026 年 7 月に会員承認の二つの動議を採択し、ライセンスにはほとんど触れない言葉でその理由を説明しました。その反対はコストと労力についてのものです。全員に押し付けられるエネルギーとハードウェアの消費、小さなフォージを一般ユーザーまで妨げる防御策へと追い込むクローラートラフィック、公開されたが決して保守されない使い捨ての「バイブコーディング」プロジェクト、そしてレビューする人々にかかる負担です。
Maintainers are under an increased work-load due to people submitting (often well-meaning) low-effort, LLM-generated contributions that require substantial amounts of time to review.
彼らの利用規約は今や、そういったプロジェクトを一括削除ではなく、モデレーターがケースバイケースで適用する形で思いとどまらせています。
つまり、流通している独立した二つの問いがあり、プロジェクトはその格子上のどこにでも位置できます。機械が書いたコードにそもそもライセンスを付与できるのか、そしてエコシステムがその物量を吸収できるのか、です。Debian は一つ目について投票しており、まだ結論を出していません。Codeberg は二つ目について行動しました。どちらの結果も他方を解決せず、プロジェクトがそれぞれに与える答えは概ね無相関です。
解決済みだと装らない部分
私たちはそのどれも行う必要がなかったかもしれません。
この三つの論拠を合わせて考えてみてください。機能性は保護されない — CJEU が直接そう述べました。純粋に機械が生成した出力には人間の著者がいないかもしれず、心配すべき新しい著作権がなく、厄介なことに私たちのものもないかもしれません。そして、本当の規律をもって実行された二モデルプロトコルは、真のクリーンルームかもしれず、その場合、この移植は保護された表現に一切触れていません。
この三つすべてが成り立つなら、これらの移植のいくつかは、良心に恥じることなく許容的にライセンスできたかもしれません。どれも成り立たないなら、私たちの保守的な選択は単に正しかったのです。私たちはどちらなのか知りませんし、試してもいません。私たちはそれを解決する事例になることに興味はありません。
この問いは無視することでは消えません。この種の移植はますます普通のことになりつつあります — 今では安価であり、保守できる場所へ移す価値のある、保守されていない C コードが大量にあります。その移植の一つ一つが同じ二つの問いに直面することになり、そのほとんどは問わないことで答えるでしょう。自分が書いていないパッチをマージするすべてのプロジェクトも同様です。つまりすべてのプロジェクトがそうです。その問いは、あなたがコードを書いているか、それを受け入れているだけかにかかわらず、やって来ます。