【後編】MIT、GPL、BSL?何をしたら違反になる?ケースから学ぶ OSSライセンス講座 #DeepDive

【前編はこちら】

Offers」では、エンジニア・PM・デザイナー向けにキャリア、スキル、働き方についての役立つイベントを開催しています。無料登録・ログインで、人気のイベント動画は今すぐアーカイブ視聴可能です。動画を視聴して、最新の技術トレンドや実践的なノウハウを手に入れましょう!

【限定配信】アーカイブ動画を今すぐ視聴する!

ディスカッション・質疑応答

大谷:テーマは運営からいくつか用意させていただいています。

質問はXやzoomでもいくつかきているので、それをいくつかピックアップしています。

【OSSを出す側】今からOSSを開発して出すとしたら・・?

大谷:今からOSSを出す場合のライセンス選択の部分です。

紅月さん、OSSを開発・公開・コミュニティを形成・運用していくとなった場合、ライセンス選択時にどのような考慮点があるのか重要性について改めて聞かせてください。

まず考慮点は「個人として出すとき」、「特定のグループを代表して出すとき」、「企業として出すとき」など運営形態で考えることは変わりますでしょうか?

紅月氏:はい。考えることは違うと思っています。

先ほどスライドの中でも話しましたが、なぜオープンソースにしているのかという目的が大切なんです。

例えば個人だとし、趣味や何かしらのライフミッションなどいろいろな目的で公開されると思います。

企業としても、直接的な利益を追求するだけでなく、間接的なメリットを享受したいと考えています。たとえ自社がECサービスやゲームといった異なる領域でマネタイズしている場合でも、基盤となる部分の開発をむしろ競合他社と共同で開発してでも良い道具や基盤を整えた方が、各社が本業の差分で戦えると考える部分が大きいと思います。

そこでやるのならば、BSD / Apach系のライセンスを採用しておくと、非常に使いやすいと思います。反対に自分たちの商品をオープンソースで公開したい場合は、いろいろ考えないといけないと思います。

大谷:個人とグループは特に商用的な部分で考えなければBSDやMITを選ぶところで、企業としてOSSを公開する場合はどのような考慮点で考えるべきでしょうか?

紅月氏:マネタイズが直接ではない場合は分かりやすいのでいいとしますが、マネタイズしたい場合は競合他社との差分化だと思います。

どのようなビジネスモデルを作るのか、例えばサポートを完全に売るモデルであればGPLでもBSDでもあまり関係ないかもしれません。逆にフリーミアムモデルで、オープンソース(コミュニティ)版とエンタープライズ版を作るような場合は、相手が同じようなことができないようにGPLとして公開するのが一つの手です。

GPLをそのように使って良いのかは別問題として、そのようにしておくと修正バージョンなどを他の人が世の中に出すことがクローズな形では不可となります。でもその代わり自分たちのコードベースを完全に分けないといけません。エンタープライズ版とオープンソース版でソースコードリポジトリを別々にします。GPLを混ぜないように運営しなければならないので複雑だったり、それをBSDで公開するとしたら別のマネタイズの方法を考えたりしないといけません。

そうなると、今ならFair sourceを使うのもありかなと個人的には思っています。

Fair sourceであれば最初からソースコードの公開もできますし、相手に競合ビジネスをしないように制限も入れられますし、最初からやれば反発などもないと思うので、ひとつのコミュニティの形態としてはいいのかもしれません。

大谷:後で変更するのではなく、企業として最初からFair sourceで出していくことがいい選択かもしれませんね。

分かりました。ありがとうございます。

今後のテーマに関わるところで質問が来ていますので、それもピックアップしながら聞いていければと思っています。

Q:企業がOSSプロジェクトを始める際、最初からBSLのようなライセンスを選択することのメリット・デメリットは何でしょうか?

大谷:繰り返しになってしまうかもしれませんが、いかがでしょうか?

紅月氏:メリットとして一番大きいのは、最初から自分たちのソースコードを公開しつつ、競合相手のビジネスを制限できることです。

自分たちのビジネスモデルを守りつつ、コミュニティを作りやすいことが大きなメリットだと思います。

デメリットは特に今時点では結構あり、BSLやFair sourceと言われても「よく分からない」ですよね。認知度が低いです。

特にBSLやSSPLはFair sourceならいいかなとは思いますが、オープンソースのようにキャッチ―な名前も付いていないので、ブランディングとしては大きなデメリットになるのかもしれません。

あと、実際に利用しようと思ったときにどんな制限があるのかが分からないですよね。オープンソースならわかりやすいですが、分からないと使う側からすると不安です。BSLのライセンスは自分が使っても問題ないのかがよく分からなくて「じゃ、やめておこう」となるかもしれないので、そこに対する啓蒙は必要で、「うちはこのような観点です」と一緒に伝えていかなければなりませんね。

大谷:権利侵害などはこの後のテーマでも用意しているので、そちらでまた詳しく聞いていきたいと思います。

Q:特許でも権利侵害があることを証明するのになかなか苦労している(製品に組み込まれてしまったらわからない)ようですが、ライセンスで禁止した特定用途で使用されたことを検知するための工夫は何かありますか?ユーザー1000人以上とかってどうやって検出するのでしょうか?

大谷:この辺りについて、実際の部分をご存じですか?

紅月氏:特に詳しい訳ではないと言う前振りですが、人数で絞る系のライセンスは商用ライセンスでも結構あります。

どうしているかと言うと、ひとつは「きちんとカウントしている」ケースです。ライセンス管理サーバのようなものがあり、そちらで管理するパターンもあります。おそらくそれはFair sourceには似合わないでしょうね。

いちばん多いのは1000人くらいになったらきちんと支払いましょうという「紳士協定」です。

大谷:なるほどですね。

紅月氏:「あの会社は」と後ろ指刺されたらビジネスとしてしんどいので紳士協定もバカにならないです。

大手になればなるほど、訴えられたら困りますしそのようなレピュテーションリスクは大きくなってきます。

なので大手には有効なので紳士協定もダメではないと思っています。

大谷:いったんディスカッションテーマに戻ります。

まとめとしては、運営形態よりもオープンソースをどのように商用利用・提供するのかによってライセンスの選択方法を変えていくところで、商用利用としてはFair sourceライセンスのようなものを選択肢としてあげることが有用ではないかというお話を聞きました。

この辺りで全般的なまとめはありますか?

紅月氏:特にないので次にいきましょう。

【OSS利用者側】ウェブアプリケーションを使う場合、どこからが問題になる?事例などもあれば

大谷:オープンソースライブラリを使う側の視点に立ったテーマになります。

特にWEBアプリケーションに限定したテーマにしています。WEBアプリケーションでOSSを使う場合はどのような問題が生じることがあるのかを、具体的な事例を交えてお話ください。

紅月氏:先ほどのデスクトップで使うことを想定してというお話に絡みますが、ほとんどのオープンソースのライセンスはバイナリを配布したときにソースコードを利用可能な状態にしなければならないという規定になっているんです。そのためバイナリが触れるユーザーはソースコードが利用可能でないといけないので、結果としてGitHubなどにソースコードを公開しています。

私はその時代は知りませんが、昔はフロッピーを送ったりしていたみたいです。

ソースコードを公開にしなくても、フロッピーを郵送してソースコードを渡しても別にいいのです。

バイナリの配布がキーワードなんです。

WEBアプリケーションの場合は、ユーザーにバイナリを配布しません。

基本的にはWEB画面で生成されたHTMLやJavaScriptを見せているだけなので、WEBアプリケーションはオープンソースが使い放題です。

BSDライセンスでもGPLでもあまり気にせず使って良いです。ただし、AGPLライセンスも存在していて、これはWEBアプリケーションとして提供してもソースコードを公開してくださいというライセンスになっています。

WEBアプリケーションは問題ない使い方ですが、まさにフリーライドのようになってしまいます。それが「自由の考え方からすると反している」と考える人も一定数いるので、AGPLで「WEBアプリケーションでも制限をきちんとしましょう」という形になっています。

ただ、SSPLのように関連したものを全部公開するのではなく、あくまで「自分たちのWEBアプリケーションを公開してください」というライセンスです。

大谷:自分たちのWEBアプリケーションを公開するのはソースコードを公開するということですか?

紅月氏:ソースコードです。コピーレフト系なのでそのライブラリを使った時点で、動的リンクでもAGPLを気にしないといけません。

実際に私も開発をしていたときに、BSDライセンスだったのにバージョンが上がったらAGPLになったことがありました。その時は(気が付いてよかった)と言う気持ちになりました。そのまま出していたら危なかったです。

大谷:その辺は急に変わる場合もあり、変わった後に以前のモノを使っていたら対象内に入ってしまうということでしょうか?

紅月氏:変わった後は大丈夫です。

基本的にオープンソースのライセンス変更は新しく「ここからライセンスを変えます」という考え方なので、過去のバージョンが問題になることはありません。

脱オープンソースをしたElasticsearchに対して、SSPLになる前のElasticsearchから交付したオープンサーチをAmazonが作ったりしました。SSPLになる前なら問題ないので、そちらをずっと使い続けていることに問題は無いのです。

大谷:そういうことですか。

WEBアプリケーションの部分で課題になる・注意すべきところはAGPLですが、紅月さんの先ほどの事例もそうですが、AGPLで侵害が起きた事例はありますでしょうか?

紅月氏:問題が起きた事例はあると思いますが、裁判事例などは確認していません。比較的有名なライブラリでAGPLがあるので、そこは注意かなというくらいです。

大谷:そういうことなんですね。分かりました。

ワードプレスはGPLライセンスだと思いますが、クライアントから依頼を受けてワードプレスを魔改造して納品する場合は配布になりますか?それともGPLの対象外になりますか?

どのように判定するかなどの基準はありますか?

紅月氏:私の理解では、今の話は少なくともクライアントにはソースコードを渡す必要があると思います。

なぜならば、クライアントはそのバイナリを受け取っているからです。

ただ、一般公開をする必要があるかと言うと、バイナリを受け取った人がソースコードにアクセスできることが本来のルールなので、一般公開はいらない気がします。

大谷:そこまでシビアに考えなくても大丈夫ということでしょうか?

紅月氏:WEBアプリケーションは、AGPL以外は気を付けなくてもいいですが、気を付けるべきはスマートフォンアプリです。

大谷:スマートフォンアプリはAGPL以外にも他のライセンスの形態を気にしなければいけませんか?

紅月氏:全部気にしないといけません。

デスクトップアプリケーションの人は昔から慣れているので気にしなかったと思いますが、黎明期のスマートフォンアプリはWEB屋さんがある日「うちもスマホアプリ出すぞ!」と出したことが多かったと思います。WEBアプリケーションのノリでライセンスを考えるのでなく、バイナリを配布しているので全部必要と考えなければなりません。

大谷:危ないですね。

紅月氏:後気を付けるべきは、BSD系です。GPLはさすがに皆さん気を付けると思いますが、BSD系は「このライブラリを使っています」など広告条項があり、1度ニュースで話題になり各社やることになったと思います。

スマホアプリには「このスマホアプリはこのライブラリを使用しています」ページが付いています。皆さんめったに見ることはないと思いますが、どのアプリケーションにもついていると思います。

大谷:そうですね。ありますね。

そういう観点で必要となっているんですね。

WEBアプリケーションはAGPLだけ気にすればよく、スマートフォンアプリはより注意が必要だと言うことを聞けたと思います。

紅月氏:補足をしておくと、オープンソースはいいですが、Fair sourceやSSPLのようなノットオープンソースなSource-available Licenseはそうでないので気を付けてください。

大谷:そうではないので、それぞれのライセンスを確認していく必要がありますね。

このテーマに関する質問も来ています。

Q:terraformを実務で使っているのですが、なにをしたら違反になるのでしょうか?ローカルで実行する分には無問題ですかね? 逆に例えばWEB上でterraformの機能を持ったサービスを作ろうとしたらどんなところに気を付けるべきなのでしょうか?

大谷:こちらは問題ないですか?

紅月氏:はい。問題ないです。terraformを実務で使っていても全く問題ないです。WEBでterraformのサービスをマネージドサービスとして提供する場合はライセンスに引っ掛かる可能性があるという感じです。

大谷:公開・配布の仕方によっては引っかかる可能性は出てくるけれど、実行する分には問題ないということですね。

紅月氏:利用は問題ないです。

【OSS利用者側】規約違反になりかけたことはありますか? (モバイルを入れるのもあり)

大谷:先ほど紅月さんがAGPLに変わって規約違反になりかけたと言われていましたが、一般的に規約違反が起こりやすい状況に関してお伺いしたいです。

複数のOSSを組み合わせて使用する場合、どのような所に注意が必要なのかと、ライセンスの検知はどのようにしたらいいかのアドバイスはありますか?

紅月氏:組み合わせた時で言うと、基本的に一番厳しいものに引っ張られるので、GPLが入っていると例えばcopyleftで引っかかります。

GPL、LGPL、AGPL、Apache系など、厳しい側に引っ掛かるので厳しい側のライブラリがあるかどうかを注視した方がいいです。

検知の方法は、ツールがあったような気もしますが、私や私の所属している組織は「レビューアーが頑張る」です。

大谷:先ほどQAに『ライセンスファインダー』があると書いてありました。

紅月氏:そのようなツールはありますね。使ったことはありませんが……。

大谷:レビューアーも頑張る必要があるということですね。

ライブラリを追加するタイミングが日に何件も発生することは、そうは無いと思いますので。

紅月氏:それは組織にもよると思います。

大谷:実際規約違反になりかけたことはあるかというところから、規約違反になったときの処罰についても聞いていければと思います。

規約違反が発生した場合に法的な処罰は一般的に決まっていますでしょうか?それともライセンスごとに何かあるのでしょうか?

どのような処罰や罰則を受けるのでしょうか?

紅月氏:法務の専門家ではないのでと言い訳を先にしますが、私の理解だと基本的にオープンソースライセンスは著作権をベースに制約を作っているので「著作権法違反」になると思います。

著作権法違反なので、日本では親告罪です。訴えられたら負けます。

ソースコードを公開する義務に反しているので、ソースコードの公開が要求されるはずで、たしか実際に要求されて公開した事例もあったはずです。

大谷:ありがとうございます。

ライセンスの違反に関しては後ほどQAでもお願いします。

【OSS利用者側】AIのオープンモデルを使うにあたって気をつけるべきところは?

大谷:資料でも解説いただいていましたが、生成AI系のモデルを使用する際に気を付ける点を改めて聞かせてください。

紅月氏:成果物が著作権に違反していないかを見ることです。デベロッパーとして、そもそもそれがオープンなモデルだからと言って本当にオープンなのかを気にしたほうがいいと思います。

生成物を気にすることはしなければなりませんが、それとは別に蔑ろにされる「そもそもその利用用途はライセンス違反ではないのか」という部分があります。

今のAIのモデルのほとんどはオープンソースではないんです。

なので用途に制限がかけられています。ほとんどの用途は「社会一般通念として納得するような犯罪に使わない」などのレベルなので問題ないと思いますが、「同意なく裁判や会計など専門知識を使わない」ということもあるので、会計アプリを使う時には気を付けないといけません。

アダルトコンテンツも駄目ですが、これは日本の基準ではなくアメリカの基準なので、エンターテイメント系のゲームなどを作っている方は気にしないといけないかもしれません。

何にしても不明瞭です。オープンソースなら勝手に使えばいいですが、ルールがあるので気を付けてということです。

大谷:ありがとうございます。

Q&Aで紹介しきれていないものに移っていこうと思います。

Q:素人すぎる質問ですみません。ライセンスに引っかかってしまったら、何か罰則があるのか?引っかかってヤバい状況になるとは、具体的にどのようなことになるのでしょうか?

紅月氏:ソースコードの開示要求をされる場合が多いです。それをされると自分たちが外に出したくなかったものを出さなくてはいけなくなるので、いろいろな影響がありますよね。

大谷:そうですね。

紅月氏:もしくはデュアルライセンスで、商用ライセンスとオープンソース両方公開しているような企業だと、本来は商用ライセンスを使わないといけなかった分の罰金を払うことになるなど、プロダクトによってどのような訴え方をするかで違ってくると思いますが、少なくともソースコードの開示要求はされます。

大谷:それを防ぐためにもライセンスの要綱はしっかり調べて確認する必要がありますね。

Q:ElasticsearchがまたOSSになったりとか、その辺どうなっているのだろうか…。

紅月氏:Elasticsearchは先日オープンソースに戻った宣言をした不思議な子です。

戻ったと言っても元々のBSDライセンスではなくて、AGPLになっています。AGPLは先ほども言いましたが、厳しめのサービスで、マネージドサービスをすごくしづらいライセンスなんです。かつ既存のSSPLあたりに脱オープンソースにしたときに使ったライセンスは残しているのです。

そのため本質的にはあまり変わっていません。ただ、オープンソースというキーワードが無いと、コミュニティ運営がしづらかったのかなと、横から邪推しています。

大谷:その辺もあり、現状はAGPLでコミュニティ運用もしているんですね。

紅月氏:SSPLなどでは不透明すぎて嫌な感じになったのかもしれません。表向きは「私たちはオープンソースに戻したかった」と言っていますが、そこはよく分かりません。

大谷:最後の質問です。

Q:ユーザーとして、絶対競合認定されないと思ったら、BSLのOSSは自由に使って問題ないということでしょうか?

紅月氏:まず前提としてほとんどの場合利用は問題ありません。

組み込んだサービスをマネージドサービスとして提供する場合は、競合しないと思っているなら選択なのでいいと思いますということです。

ただ、相手がいつ新しいビジネスを始めるか分からないので、そこの不安が私自身もモヤモヤしているところです。

どうしたら絶対に大丈夫と言えるのか……。

大谷:使用は問題ないということなんですね。

紅月氏:使用は問題ありませんし、相手の目につくぐらい大きくなったらその時に考えてもいいかもしれませんね。

大谷:そうですね。

その点は大きくなったら法務部と確認しながら進めていくことが重要ではありますね。

みなさん、たくさんのご質問ありがとうございました。

最後に

最後に一言お願いします。

紅月氏:ライセンスは難しいので皆さん気をつけましょう。

毎週日曜日に20時くらいからWeekly ITニュース配信をしています。ニコニコ動画でリアルタイム、youtubeにアーカイブ上げていますのでチャンネル登録・高評価をよろしくお願いします。


Offersエージェント」では、業界で活躍するプロフェッショナルがあなたの転職を徹底サポート。CxO経験者を含む現役エンジニア・デザイナー・プロダクトマネージャーが在籍し、職種に特化した専門的なアドバイスをご提供・非公開求人の紹介も可能です


この記事をシェア

関連記事


副業・フリーランス

プログラミング

インタビュー

デザイン

お金

採用・組織

イベントレポート

転職