AIがコードを読める時代に、OSSライセンスは何を守っているのか

昨日、Convergence Lab.のブログに興味深い記事が出た。Elastic、Redis、HashiCorpがライセンス変更を迫られた経緯を整理したもので、結論として「最初からAGPLを選んだ理由」が述べられている。

筋の通った判断だと思う。AGPLはネットワーク提供にもコピーレフトを及ぼす。クラウド事業者がSaaSとして提供するだけでソースを非公開にできる抜け穴を、構造的に塞ぐ。記事が整理した通り、Elastic、Redis、Grafanaが最終的にこのライセンスに辿り着いたのは偶然ではない。

ただ、読み終えてから一つの問いが残った。AGPLは、LLMがコードを読める時代にも同じように機能するのか、と。

コードをコピーしなければ、コピーレフトは届かない

競合が今日とれる行動を考えてみる。

AGPLで公開されているコードをLLMに読ませてアーキテクチャを理解する。「同じ機能を持つが一行も同じでないコード」を生成して、MITで公開する。著作権侵害はない。コードをコピーしていないからだ。AGPLのコピーレフト義務もない。ネットワーク提供しているのは新しく書いたコードだからだ。

これが合法かどうかは、現時点でグレーな部分もある。ただ、著作権法が保護するのは「表現」であって「意味・構造・アーキテクチャ」ではないという原則は変わっていない。コピーレフトは表現のコピーを捕捉する。意味のコピーには届かない。

最初はこの問題をライセンスの設計で解決できると思っていた。AGPLより強い条件にすればいい、と。

「もっと強いライセンス」の限界

実際、より強い制限を持つライセンスは存在する。

MongoDBが作ったSSPLは、サービスとして提供するなら運用基盤ごとソースを公開せよと求める。これに対してAWSはMongoDBのコードを使わず、互換APIを実装したAmazon DocumentDBを出した。ライセンスは著作権で保護されるコードの利用を制御できるが、アイデアやAPIの互換実装まで止めることはできない。

OSIは2024年にOpen Source AI Definitionを公開し、AIシステムへの「オープンソース」の定義拡張を試みている。ただし現状では、LlamaもGemmaも、この定義上はオープンソースではなく「オープンウェイト」に分類される。定義を作っても現実の大半のモデルが外れる。

米国では2026年1月にTRAIN Actが提出された。著作権者がAI学習データを検証できる権利を付与する法案だが、「使ったかどうかの検証権」であって「意味的迂回の禁止」ではない。

どの試みも、「意味的複製」を直接捕捉できていない。ライセンスは著作権法の上に乗っている以上、著作権法が変わらない限り、届かない場所がある。

コードの外側という考え方

Convergence Lab.の記事は「成功してからライセンスを考えるのでは遅い」という結論で終わっている。その通りだと思う。

ただ、「何をライセンスするか」と「ライセンスが届かない場所をどう守るか」は、別の問いかもしれない。

自分がParryを作りながら考えていることも、少しそこに関係している。コードを守るライセンスとは別に、コードの外側で何かを守れないか、という発想だ。

今はまだ、形にできていない部分がある。もう少し整理できたら続きを書く。