2023年 8月 19日 2023年 8月 21日

第7回 AGPLの勧め

実質的に他人が勝手に商売にできないオープンソースライセンス

ogochan

このブログは会社の広報のためのものですから、あまり政治的なことやセンシティブなことを書くつもりはありませんが(いつもの出だし)、ここ最近のAI関係の人達のライセンスに対する考え方はいかがなものかと思うことが増えて来ました。

そのことの是非をここで言うつもりはありません。言いたいことは山ほどあるのですが、弊社の業務的にはどうでもいいことです。ただ、その中にあった「商用利用禁止のオープンソース」という話から派生して、表題のような話を書いてみようかと思います。

弊社のオープンソース戦略(？)

特定の顧客がついた仕事の成果物は別として、社内用に作ったもの、あるいは自社サービス用に作ったものは、原則オープンソースライセンスで公開することにしています。

今のところ弊社名義のGitHubのピン止め公開リポジトリは3つしかないので、そんなにドヤれるものでもないですけどね。GitHubに置くのに必要なコードの整理やレビューが必要(公開していけないファイルがないかとか)があってそういった手間が取れないもので。直接金にならないことにかける余力はそんなにないので。追い追い追加して行きますけど。

ということはさておき、これはいろんな考えの結果です。基本的には以前のエントリ、

会計システム Hieronymus(3) 弊社オープンソースの考え方と展開

に書いているように「公開した方が得」という考えです。また、

IoT認証システムの特許について(2) 特許化しなかった理由

のような理由もあります。

いずれにしても、それらは自らの意思で選択したライセンスです。

個人(生越)的には「オープンソースで貢献しよう」的なことを考えているわけではなく、ただ単に

その方が扱いが楽だったり都合が良かったり
誰かが使ってくれたら嬉しいなという素朴な思い
あわよくばそれがビジネスにつながれば嬉しい

ということです。そしてもちろん最後のが一番強いわけです。

「商売にするならプロプライエタリにすれば？」という意見は当然のようにあると思います。ただ、これは弊社のようなソフト販売に軸足を置いてない零細企業ではあまり良い戦略ではありません。なぜなら、

「部品」のライセンス管理が厄介
単価がそう高くできそうにない商品を扱う工数が確保しづらい
金取れるレベルにする工数と収益の見通しが困難

ということで、ビジネス的に成立させるためには、いくつものハードルがあります。もちろんそれは戦略や体力次第なのですが。

つまり、弊社のビジネスの軸足がそこにないにも関わらず、プロプラな商用アプリを作ることよりは、オープンソースにしてしまって

他のビジネスの撒き餌

として機能してくれる方がいろいろバランスが取れているということです。つまりは商品と言うよりは「営業活動のツール」として使っているわけです。単価200万を超えたことは一度もないので、お気軽にどうぞ(だいたい120万くらい)。

ライセンス選択

ライセンス選択については明確な基準を持っています。それは、

商売に直接つながりそうなものはAGPL(3)
部品はMIT系(Apache)
アプリケーションはGPL(3)

です。個人的なリポジトリだとさらに色々あったりするのですが、会社としてはこれらを中心にして行こうと考えています。

と言うのも、弊社のようなスタンスの会社にとっては、この選択がいろいろ「ちょうどいい」感じだからです。

個々のライセンスについての解説は、表題に書いたAGPL以外は今回はしません。適当にネットを探してみて下さい。まとめとしては、

さまざまなライセンスとそれらについての解説

がまとまっていて良いですが、「Gnu目線」で書かれている点には注意が必要です。

AGPLという選択

AGPLとは

AGPLはGPLの上位版です。もう少し正確に言えば、GPLに「ネット越しで使わせた場合(13章)」をつけ加えたものです。「配布」を受けて使う人と「ネット越し」で使う人と同じ権利を持たせるということです。

AGPL及びその系統のライセンスとそれ以外の違いは、この「ネット越しでサービスを受ける人」と「配布を受けてプロプラ環境で使う人」とに同じ権利を与えるかどうかということです。つまり、ネット越しでサービスを受けた人であっても、ソフトウェアを手元にコピーして使う人でも同じように

ソースコードに対するアクセスができる
ソースコードを複製したり再配布したりする
他人に同等な権利を与えることができる

といったGPLにある権利があるということです。

これにはどういった効果があるかと言えば、AGPLで公開されたソフトウェアを使ったウェブサービスを使った場合、サービス提供者に対して「ソース下さい」と要求する権利があるということです。

よく誤解されるのですが、他のライセンスの場合はソース公開を求める権利があるのはソフトウェアの配布を受けた人だけということになっています。最近の家電製品等ではGPLなソフトウェアを組み込んだものが存在してるのですが、そのソースコードを要求する権利を持っているのは、ソフトウェアの配布を受けた人だけ、つまりその製品を購入した人だけです(それを第三者に再配布するのは自由です)。しばしば、「どこそこのルータはLinuxが入っているのにソース公開してないぞ」という祭りが起きたりしますが、そのルータのファームが一般公開されていない場合(普通はそうですね)は「ソース寄こせ」と正当に主張できるのは「どこそこのルータ」を購入した人だけです。

そんなわけで、「GPLなソフトウェアを使ったウェブサービスの利用者」にはソース入手の権利はありません。また、ウェブサービスの提供者は元々ソフトウェアを配布する予定でサービスしているわけではありませんから、そのソフトウェアが正規ルートで誰かの手に渡るわけでもありません。そうなるとそのソフトウェアをいくら改変しても実質的にソースの公開は免除されてしまいます。つまり、ウェブサービスの事業者は実質的にライセンス条項のうち第三者が絡むもの(再配布とか)の適用を免れてしまう、つまりプロプライエタリソフトウェアと実質的に同じということになってしまうわけです。

AGPLはこの状況を憂慮して作られたものです。

つまり、「配布を受けた人」だけに存在していた権利を「ネット越しで使っている人」にも拡大して適用させようということです。であれば、ウェブサービスの利用者であっても「ソース寄こせ」が主張できるわけです。

同じ目的で「BSL」というオープンソースをちょっといじったライセンスもありますが、これは目的は同じですがアプローチが異なります。利用者の資格を問うライセンスなのでオープンソースではありません。

AGPLを適用すると何が起きるか

自分の作ったソフトウェアにAGPLを適用した場合、そのソフトウェアを使ってウェブサービスを始める事業者がいた場合には、そのウェブサービスの利用者にもGPL的な権利が発生します。具体的には「ソース寄こせ」が主張できるようになるわけです。

誰か他人の作ったソフトウェアをそのまま使ってウェブサービスを行う人は普通いません。「いません」と言い切ることは無理ですが、仮にそれをやってもあまり良い商売にはなりません。なぜなら、他の事業者がそっくり同じことをすることが出来ますから、限りなく競争をすることになってしまいます。

そうならないためには、元のソフトウェアに手を加えて「より便利」にします。bug fixしたり、機能を増やしたりといったことをします。そうやって特色を作ってやれば、その特色の部分が嬉しい人達がもっと使ってくれるかも知れません。場合によってはオリジナルの作者がやっているウェブサービスよりも人気が出るかも知れません。

GPLの場合、オリジネーター(オリジナルの作者)と言えども「そのソース寄こせ」とは言えません。何しろそのソフトウェアの配布を受けているわけではないから、その権利が存在していないわけです。つまり、オリジナルよりも改良された部分は改良した事業者が独占できてしまいます。

オリジネーターは公開しているソフトウェアは改良も公開します。もちろんそれを公開しないという選択は可能ですし、そういったビジネスが存在しているのも事実ですが、結局いつかは公開します。公開されているものですから、公開していない「より便利に改良したサービスの事業者」はその改良部分を入手できてしまいます。つまり、オリジネーターは、

改良部分も受け取れない上に「肥やし」にされてしまう

わけです。オリジネーターとしては面白くありませんね。

AGPLの場合、そのサービスを使っていれば「そのソース寄こせ」と言えます。つまり、「より便利」になった部分について入手する権利があるわけです。

それは同時に「その他のサービス提供者」も同様に権利を持つことを可能にします。そのサービスを使っていれば、「より便利」の部分を手に入れることができます。

このことはつまり、「誰かが勝手にウェブサービスを公開してオイシイ思いをする」ということを難しくします。つまり、実質的に「商用タダノリ」を阻害することができるわけです。つまり、

勝手に商売する気を失せさせるライセンス

と言えます。それでもあえて使うのは自由です(だからオープンソースライセンス)。先に挙げたBSLは「勝手に商売するな」と禁止している(だからオープンソースライセンスではない)という点が異なります。

また、ライセンスを決めることは著作者人格権に属する権利です。なので、著作権者は自由に設定できます。そして、そのライセンスに自分が従うことは義務ではなくて、「じぶんのこころがきめる」ものです。これはどういうことかと言えば、オリジネーターに限り「より便利」な部分について公開するかどうかは、自分で勝手に決められるということです。これは「デュアルライセンス」として知られているものです。

ですから、たとえば公開されている版はAGPLにして、それとは別の版を誰か仁義を切って来た人には別のライセンスのものを渡す(コードは同じでいい)というようなことが可能です。つまり、「商用タダノリ」を阻害しつつ「ビジネス契約」をすることは可能になります。

AGPL適用の留意点

オープンソースで公開しつつ「商用タダノリ」を阻害できるAGPLは素晴らしいライセンスだからどんどん使いましょう... とはならない点に注意が必要です。もちろん前節で挙げたメリットは嘘ではないのですが、それ以外のところにデメリットがあったり留意点があったりします。

まず第一に挙げられるのは、GPL系ライセンスだということです。これを敬遠する人は結構います。

GPLは実質的に利用者にソース公開を義務づけます。実はこれ自体が義務そのものでないのは既に述べたとおりなのですが、それでも事実上の義務のようなものですからその手当は必要です。AGPLとなるとさらにそれが強化されるわけなので、さらに取り扱いが厄介になります。

ですから、群雄割拠みたいな世界に「商用タダノリ」が嫌だという理由だけでAGPLなものをリリースしても、「面倒だから他のもの使うわ」としかなりません。利用者からすれば、ライセンスは「軽い」方が好まれますから当然です。

ただこれは他に有力な競合ソフトウェアが存在している場合の話であって、他に適当なソフトウェアがない分野であれば問題にはなりません。導入で書いたような「国産LLM」のようなものは最初からプレイヤの少ない世界ですから、特には問題にはならないと思われます。

第二は外部からの貢献を受けるのに障害となるかも知れないということです。

AGPLはサービスとして提供を受けた人もソースを要求する権利があると言いました。これは正しいのですが、これが適用できるのはAGPLが適用されたソースだけです。

どういうことかと言えば、AGPLで公開したソースについては、AGPLに従ってソースコードを取得することは可能ですし、それを本家リポジトリに適用することは可能です。ここに問題はないのですが、問題はデュアルライセンスが絡む部分です。

ソースコードを改変した場合、規模にもよりますが、改変部分には改変者の権利が発生します。AGPLのコードを改変する人はAGPLが適用されることを期待して改変し、改変部分を譲渡します。ですが、そのコードを「他のライセンス」に適用するためには、別途改変者に許諾してもらう必要があります。ここで素直に「うん」と言ってくれれば良いですが、「改変部分もAGPLなんで」と主張されてしまった場合、他のライセンスの部分には適用できなくなってしまいます。実はこれは他のライセンスのデュアルライセンスでも同様の問題を孕むのですが、AGPLだとその性質上特に面倒になりかねません。

このようなことを避ける場合、「外部からのコードはそれはそれとして、同等な修正を自分で行う」という解決方法があります。これは「企業もの」のオープンソースにはよくあることですが、「プルリクをOKするだけ」の世界からすれば厄介なことです。まぁこれは「他のライセンス」を適用するべき相手がいる時の話なんですけどね。

第三はまだマイナーなライセンスであるということです。

GPLは多くの人に知られています。「重い」ライセンスではありますが、有名どころでも結構採用されていたりしているので、扱い方についての知見もあります。家電メーカあたりでも正しい理解が広まっています。

BSDと言うかMIT系のライセンスは「軽い」ライセンスです。かなりうっかりしていても、間違った扱いをしてしまうことはあまりありません。ある意味遵守しやすいライセンスです。

これに対してAGPLはマイナーです。「重い」ライセンスですが、扱い方の知見があまりありません。ここでメリットデメリット書きましたけど、私の知らない何かがあるかも知れません。うっかり違反してしまう危険性が0であると言い切ることは容易ではないように思えます。判例もあまりない(全くない？)ですし。

利用者もよくわかっていません。つまり、自分にどんな権利があるのか、十分理解できているとは言い難い上に、事実上「誰でも権利者」なので理解のないまま権利を主張するようなこともあるかも知れません。また、そういった人達に対処する方法についても、まだ知見はそんなにないように思われます。

おまけ

「GPL嫌いな人のために他にも同じ原理のライセンス(ABSDとかAApacheとか)が作れないか」ということを思う人もいると思います。

AGPLはGPLのようにソースの公開を半ば義務のように定めたライセンス(この表現は厳密ではありません)の時に意味があります。MIT系ライセンスのように「クレジットさえあればソースは公開しなくてもいいよ(この表現も厳密ではありません)」というライセンスの場合は、意味がありません。

ごく雑な言い方をすれば「GPLのような面倒臭いライセンスをより一層面倒臭くしてオリジネータの権利を実質的に強化した」のがAGPLと言えるので、「面倒臭いライセンスだなぁ」と思うところに意味があるのです。そういった意味でも

両刃の剣

です。「銀の弾丸」ではありません。

まとめ

以上のように、「銀の弾丸」と呼ぶにはまだ問題点はありますが、「商用タダノリ」を避けたいということに絞れば、効果のあるライセンスだと言えます。ですから、「商用タダノリ」を避けたいがために「オープンソースだけど商用利用禁止」というOSDに反するような主張をするくらいであれば、AGPLを採用して「実質的に商用タダノリは困難」という形にしてあった方が都合が良いですし、嘘がありません。

OSIに公認されているライセンスなので堂々とオープンソースを名乗れると共に、オープンソースにあるメリットを十分得ることもできます。「商用利用禁止」を謳うと、コンプラの厳しい企業だと「使うな」になってしまって、それはそれでもったいないことでしょう。

オープンソースにはしたいけど「商用タダノリ」が嫌であれば検討してみる価値があります。