大根's ITブログ

ITとか開発ツールとかビジネスとか色々

Ruby on RailsのGPL汚染まとめ(mimemagicの件)

("汚染"という言葉をあまり良く思わない方もいると後から知りました。たしかにその通りだと思います。次から気を付けようと思いますが、とりあえず本記事ではそのまま"汚染"の表現を使います。ご了承ください。)

2021年の3月、突如としてRailsGPL汚染の話題がネット上を駆け巡りました。

リチャードストールマンがFSFへの復帰を発表した途端にこんなことが起きるなんて…。 偶然にしてはすごいタイミングですね。

GitHub Enterpriseのコードが公開されるの?と盛り上がっておりますが、果たしてどうなりますでしょうか。

さて今回は本件についてまとめていきます。技術者だけでなく法務や知財の目線でも分かるように書いていこうかと思います。

★私は法律の専門家ではありません。この記事に法的根拠はありませんので何かあっても責任は取れません。ご理解ください。

概要(経緯)

概要はこのissueのやりとりを見ると良いでしょうか。

github.com

RailsではmimemagicというOSSgemパッケージ)が使われているんですが、本gemにGPLのコードが混ざっていたというのが今回の話になります。 ※正確には、Railsactivestoragemimemagicの順で依存しているようです。

mimemagicはMIME Typeを識別するライブラリ(MITライセンス)なんですが、MIME Typeの定義情報(xml)を持っており、これがshared-mime-infoという別OSSxml(ライセンスがGPL)だったようです。

mimemagicの開発者はissueでこの指摘を受け、ライセンスをMIT→GPLに変更(バージョンアップ)し、その後rubygems.org(gemを公開しているところ)で過去バージョンをyanked(公開停止)した上で、最新版を公開した模様。

これにより、mimemagicに依存していたプロジェクトのCI(要はビルド)が軒並み崩壊&さまざまなプロジェクトで影響が出た、というのが今回の件の大まかな流れです。

で、影響を受けたプロジェクトの一つがRailsで「え、RailsってGPLになるの?」「Rails使ってるGitHub Enterpriseどうなるの?」といった話が各所で出ることになりました。

ただし最新状況(3/25の夜の時点)としては、mimemagicの開発者は該当のxmlを取り除いてMITライセンスに戻した最新版を公開しているようです。

【追記】さらに最新状況(3/27時点)としては、Railsの新しいバージョン5.2.5/6.0.3.6/6.1.3.1ではmimemagicに依存しなくなりました

事実確認

念のため実物を見ていきます。元ネタであるshared-mime-infoの該当ファイル(と思われるファイル)がこちら。たしかにGPLで間違いなさそうです。 https://gitlab.freedesktop.org/xdg/shared-mime-info/-/blob/master/data/freedesktop.org.xml.in#L63-79

次に、これが本当にmimemagicで使われているか、mimemagicのリポジトリを見てみます。最新版ではfreedesktopのファイルが削除されたようなので、過去の履歴から確認してみます。script/freedesktop.org.xml が該当ファイルのようで、たしかに思いっきりGPLと書かれています。 https://github.com/mimemagicrb/mimemagic/blob/40dd02bb6b442535f97c35326c0383bc67146ac4/script/freedesktop.org.xml#L63-L79

あと、このxmlが本当にgemパッケージ(ビルド成果物として実際使われるモジュール)で使われるのか確認してみます。

40dd02bb6bをパッと見た感じ、

  1. script/freedesktop.org.xmlを基にlib/mimemagic/tables.rbを生成する

  2. tables.rbを含めてlib配下をgem化する(testディレクトリ&scriptディレクトリは含まれない)

という流れになっているように見える。xml自体はgemには含まれないようですね。(たぶん合ってるけど間違ってたら指摘してください)

念のためrubygems.orgを見てみるかーと思ったけど過去ver.は公開されていないため実物は確認できず。wayback machineでもgem取れないので諦め。まぁいいか。

とりあえず結論としては、「GPLxmlそのものはgemに含まれないっぽい」「xmlを基に生成したrubyファイルがgemに含まれる」ような形であることが分かった。

GPL汚染かどうか

ネット上を見ていると「RailsGPLになっちゃうのか」「RailsGPLのライブラリを読み込んでいるだけだから影響ないでしょ?」といった意見が散見されます。 これらについて少し補足します。

まず、Railsのコード自体はMITライセンスのままで問題ありません。ですが、「Railsおよびその依存関係コードを含む作品全体」はGPLでライセンスしなければいけない可能性があります。

この作品にはmimemagic(GPL)が含まれていて、GPLには「作品全体にGPLを適用すること」という条件があるからです。

なので、Railsとしては自身のMITライセンスを変える必要はないが、Railsを使って何か作っているプロジェクトに影響が出てしまう=Railsメンテナ側としても放置できない という状態です。

また「そもそもRailsには影響ないでしょ?」の意見についてですが、これは「作品」の定義次第となります。

一般的に作品の定義としては「リンクしたものを一つの作品とする」のが定説になっているかと思います。

これに対して、今回は「Railsがgemパッケージを読み込んでいる」状態であり、これをGPLがどう捉えるか?が問題になります。

まぁおそらくRailsを使って作ったWEBアプリケーションは一つの作品として扱われるのだと思いますが、こればかりは何とも言えません。

また、今回少し特殊なのが、対象がGPLxmlであること。また、頒布されるのがxmlから出力したrubyのコードであることです。

この感じだとかなり詳しい人に判断を委ねることになると思います。

企業だと通常は安全側に倒すので、この類のものもGPL汚染として考えるのが普通ではないかなと思います。あくまで思うだけですが。

なお、GPL汚染かどうかの判断にはGPLのFAQが使えるので参照ください。ただ今回のパターンについては良い例はない気はします。

【追記】そもそも論としてxmlの著作物性に関する議論もありました。 freedesktop.org.xmlの著作物性 - 西尾泰和のScrapbox

じゃあ、うちのRailsアプリもGPL汚染なの?

これについては、「もしそのRailsアプリを外部に提供するなら」GPLを適用する必要が出てきます。

例えば、Railsを使って作ったサーバ製品(mimemagicを含む製品)を販売するような場合が該当します。

典型的な例としては、GitHub Enterprise(オンプレ版)が該当すると思われます(だからみんな騒いでる)。

逆に、クラウドサービスのように自社にサーバをホストしてサービスとして使う分には基本的にこのような問題はありません。

GPLはライブラリの再頒布(利用)の際の条件なので、再頒布せずに自社のサーバ上で動かすだけなら問題ないです。

ただしAGPLなど、サーバ側で動かすだけでも影響が出てくるライセンスもありますので、ライセンスのチェックはどんなプロジェクトにおいてもちゃんと実施する必要はあります。

でもmimemagicの最新版は完全にMITライセンスなんだよね?

そうです。なので、Railsがmimemagicの最新版を読み込むようになれば、「Railsの最新版は」使っても特に問題なしとなります。

ただ問題なのは、これまでRailsがmimemagic(GPL含む)に依存してしまっていたことです。つまり、これまでRailsを使ってWEBアプリ製品を作って売ってきた企業には影響が出ます。

例えばGitHub Enterpriseであれば、過去にオンプレミス版を売ってきた顧客にはこれまでのGitHub Enterpriseのバージョンに対応するソースコードは開示の義務が発生します。

実質的にGHEのオープンソース化と言えてしまうかもしれません。

ミスってGPL混入させたのはmimemagicなのに、GitHub可哀そうでは?

そうでもないと思います。

これも最終的には専門家が判断することですけど、基本的にOSSは何の責任も保証もなく公開されています。

あらゆる責任はOSSを使う側にありますから、今回の件でOSS側が悪いというのは無理があります。

OSSの中身をちゃんと調べなかった、利用側の責任です。

こういった責任があるので、世の中にはOSSのライセンスをチェックするツールがたくさんあります。

GitHubだってlicensedっていうOSSのライセンスをチェックするツールを公開しています。自分たちでも使っているようなので、その辺はしっかり対策していたはずです。

ただ今回の場合はgemの中身までライセンスチェックしないといけないので、licensedなどの単純なライセンスチェックツールでは把握は難しかったろうと思います。

おそらくFOSSAのようなクラウドサービスを使ってコードレベルのライセンスチェックをしておく必要があったのだろうと思います。

対応策

以上が今回の件についての話になります。

とりあえずはRailsコミュニティやGitHub社の動きを待ってから対応を考えるべきと思いますが、仮にGPL汚染だという判断になった場合に、やった方が良さそうなことを書いておきます。

まず、GPLを使うのがダメなプロジェクト/会社/組織である場合には、mimemagicがどこで使われているか把握する必要があるかと思います。

mimemagicに依存するのはRailsだけではないので「mimemagicに依存するライブラリに依存するプロジェクト」も要把握となります。

mimemagicの被依存性に関する確認はrubygems.orgのreverse_dependenciesを見たり、libraries.ioを見たりすれば良いと思います。

(でも特定バージョンの被依存性の確認はできないっぽい…すんません…)

どうにかして把握したら、まずそれらについてはmimemagicの最新版が適用されるようにします。Railsも早いうちに対応版がリリースされると思いますので、そしたら最新にすべきでしょう。

で、問題はすでにリリースされてしまっているものですね。これについては… どうなるんでしょうね。本当にGPL適用なのかなww やばい企業相当出てくると思うんだけど…。

やるとなったら、まぁ、製品はGPL適用&必要に応じてソースコード提供、ということになるのでしょうね。

まぁでもこれはやはり今後の動きを見てからの判断になるかと思います。

短期的な対応としてはこんなもんでしょうか。

長期的にはやはりCI/CDの流れでFOSSAなどを使って、常時ライセンスをチェックする仕組みを構築すべきと思われます。

また事後対応でも良いという場合にはSourceGraphなどの導入して、いつでも社内のソースコードを検索できるようにしておくと良いかもしれません。

まとめ

途中から法務や知財の目線を忘れて書いてしまいました。すみません。

とりあえず自分の理解を書かせていただきましたが、おかしい点は指摘ください。

また再度言いますが、私は法律の専門家ではないので、何の責任も取れませんのでよろしくお願いします。