9月20日、セキュリティ研究者のChester Wisniewskiが「AI and the Destruction of the Creative Commons」と題した記事を公開した。
コードや知識を公開すること——かつてそれはコミュニティへの貢献だった。しかし今、AIの登場によって「共有する」という行為そのものが、クリエイターにとってのリスクに変わりつつある。Wisniewskiは法廷の外側にある構造的な問題を問う。法的な争いが決着する以前に、共有文化そのものが静かに崩れていく——という警告だ。
WisniewskiはSophosのグローバルCISOを務めるセキュリティの第一人者で、オープンソース文化とインターネットのセキュリティ基盤の両方を長年にわたり見てきた立場にある。だからこそ彼の視点は、著作権侵害を「法的に問えるか」という議論にとどまらない。法的グレーゾーンを利用した構造的な収奪が、共有文化そのものを消滅させるという、より根深い問題に向けられている。
35年かけて築いた均衡が崩れた
ソフトウェアの著作権をめぐる議論は長い歴史を持つ。シェアウェア・フリーウェアの時代を経て、GPL・MPL・CC-SAといった「コピーレフト」ライセンスが生まれた。コピーレフトとは著作権(copyright)を逆手に取り、「この成果物を利用する者は、派生物にも同じ自由を引き継がせなければならない」と義務づける仕組みだ。
この仕組みがあったからこそ、現代のインターネットとクラウドは成立した。Wisniewskiは「すべてのクラウドサービスと、インターネットの根幹そのものが、前の世代の巨人たちの肩の上に立つ派生物だ」と述べている。この開放性がなければ、オンライン体験はAOLやCompuServeのような閉じた世界に近く、コストも現在の何百倍にもなっていたと指摘する。
AIが「共有すること」をリスクに変えた
Wisniewskiが最も核心的に問題視するのは、「共有」という行為そのものがクリエイターにとって不利に働くようになったという逆転現象だ。具体的なリスクとして、以下が挙げられている。
- LLMはライセンスや著作権を無視して、ネット上のあらゆるコンテンツを学習データとして消費している。その派生物がオリジナルのライセンスを引き継ぐかどうかは不透明で、法的な執行を求める動きも現時点では乏しい。
- コードをGitHubなどの公開サービスに置くと、AIが自動生成した大量のPull Request(いわゆる「AIスパムPR」)が届く。そのほとんどは有用でなく、トリアージだけで時間が奪われる。
- コードを公開すれば、AIによって脆弱性の発見が容易になり悪用リスクが上がる。逆に非公開にすれば同じミスは見つかりにくくなる——つまり「開けば損、閉じれば安全」という構造になってしまっている。
- 共有したコードが、誰かの盗用コードを含んだ「スロップ(slop)」——AIが大量生成した粗悪なコードを指すスラング——や悪意あるライブラリで汚染されている可能性があり、それを利用した側も責任を問われかねない。
こうした状況を踏まえ、Wisniewskiはこう断言する。
_The social contract has been broken._(社会契約は破られた)
オープンソースメンテナが置かれている状況への共感は、エンジニアの間で特に広がりやすいテーマでもある。AIが生成したスパム的なPRを手作業でさばき、ライセンスの不安に怯えながら、それでもコードを公開し続けることに意義があるのか——という問いは、すでに多くの開発者が実感として抱えているはずだ。
なぜ今これが重要か
AIによる著作権侵害やライセンス違反については、New York Times対OpenAIの訴訟やGitHubのCopilot訴訟など、法的な争いがすでに始まっている。しかしWisniewskiの視点が際立つのは、法廷の外側にある問題——法的解決を待つ間にも、共有文化そのものが静かに崩れていく——を問うている点だ。
AIは知識の共有を「世界への贈り物」から「作者にとっての負債」に変えてしまった。その結果、開放性によって生まれるはずだった富や力は、創造した者への敬意や対価なしに、一部の巨大プレイヤーへ集中していくとWisniewskiは警告する。過去35年間のオープン化が現在の私たちがオンラインで享受しているほぼすべてを生み出してきたとすれば、この流れが止まった先にあるのは何か——記事はレイ・ブラッドベリの『華氏451度』を引き合いに出し、「コード・技術者・アーティストが一体となって新しいデジタル・ルネサンスを起こさなければ、奇妙に歪んだ形のディストピアに行き着くだろう」と締めくくっている。
詳細はAI and the Destruction of the Creative Commonsを参照していただきたい。