21
17

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

GPLのライブラリを動的リンクした作成物のライセンスはGPLか?

Last updated at Posted at 2018-07-17

普段からよく触るOSS。ライセンスについて理解しているつもりだったのですが、いざ自分がOSSとしてコードを公開しようとなったら滅茶苦茶不安になったので調べました。
(特にビルドオプションでリンクするlibevがGPLだったので。

調べた結論としては、**「静的リンクは利用だからアウト、動的リンクなら使用にあたるからセーフ」**な模様。100%の自信はないですが。

@tenmyoさんからのコメントより、GNU公式のQAで明確に「どちらもGPL適用範囲だ」と謳われていました。

いいえ。GPLの及ぶ作品に静的もしくは動的にほかのモジュールとリンクすることは、GPLの及ぶ作品をもとにして結合著作物を作成することです。ですから、全体としての結合には、GNU一般公衆ライセンスの条項が及びます。GPLソフトウェアにGPLと両立しないライブラリを用いた場合、どのような法的問題が発生するでしょうか?もご覧ください。

  • 大事なこと: まず公式見解を確認しよう!

以下はコメントもらう前の調査結果。一応残しておきます。

前提:私の作成物に関する状況

以下のライブラリを使用していました。

POSIX系(pthread, dl, rt), libevent, libev

特にこのlibevがGPLなので、リンクした時にGPLにしないといけない?と不安になったのがきっかけです。
(一応ビルドオプションでの選択式なので、その場合はFFmpegのようにオプションでライセンスを分けようとしていました。)

使用と利用の違い

OSSのライセンスを理解する(「使用」と「利用」の違い、知っていますか?)という記事を参考に使用と利用の違いについて考えましたが、結論出ず。
以前にも同記事は読んでいて理解したつもりでしたが、知っていますか?の問いはNoと言わざるを得ませんね(-_-;)

開発内で閉じた話ならスルーしてたかもですが、これらを使って自分のものを公開しようとなるとどうにも自信がありませんでした。
それに以前FFmpegがlibx264というGPLのライブラリをリンクした時にGPLになる仕組みになっているのを見かけたのも、不安に拍車をかけていました。(これは後で理由がわかります)

色々悩んでいても結論は出ないので、同じようなことをしている世の中のOSSや、ネット上の記事を漁ってみましょう。

OSSのライセンスを見てみる

今回のライブラリを使っている、もしくは私が気になっているOSSについて、ライセンスと使用ライブラリをざっと調べてみました。

OSS ライセンス ライセンスファイル 主な利用ライブラリ(わかる範囲で) 備考
openssl OpenSSL License && Original SSLeay License LICENSE pthread, dl SSLを利用する為の一般的なパッケージ
ffmpeg まっさらなビルドはLGPL v2.1+。ビルドオプションでGPL LICENSE.md, 各COPYING libx264等。オプション依存。 H.264で使われることの多いx264がGPLなのでGPLで使うことが多くなるかと。
x264 GPL v2.0 COPYING dl, m, pthread 静的ライブラリで提供
lighttpd revised BSD license COPYING libev, pcre, openssl, MySQL, etc HTTPサーバー
lldpd ISCライセンス LICENSE libevent 2条項BSDライセンスと機能上同等らしい(wikipedia), libeventを利用しているので記載
libevent 3-clause (or "modified") BSD COPYING pthread
libev GPL LICENSE pthread

どれを見ても、特に動的リンクしたライブラリのライセンス=自分のライセンスとはなっていないようです。
lighttpdを見てもlibevを使っているけどそのライセンスについて触れてはいないですし、その他lldpdは使っているlibeventより緩いライセンス形態になっていますし。

また、懸念していたFFmpegです。こちらはGPLになる原因の一例であるlibx264をビルドすると静的ライブラリファイルとなっていました。
プログラムに取り込んでるならそれは利用にあたりますね。

上記の例を見ると**静的リンクなら「利用」、動的リンクは「使用」**とみて良さそうかな。
確証を得たわけではありませんが。

その他情報を探してみる

こちらの記事の回答から抜粋させていただきます。

CPLライブラリのリンクについて

改変をしておらずとも静的リンクをしたソフトは開示範囲となります。
動的リンクの場合は開示範囲ではないという「見解があり」ます。
事実後述の企業はAndroidのソフト全体のソースコードを開示しているわけではなく、静的リンク範囲のみ公開しています。

この辺を見てても、動的リンクなら大丈夫な例が載せられています。

やっぱり動的リンクは利用にあたる。大丈夫!

。。。多分平気なはず。平気なんじゃないかな?まちょっと覚悟はしとけ

一応保険を打っておく

ソフトウェア開発と同じように100%平気です!と言えない気分なので、一応切り離しやすいよう保険を打っておきます。
といってもこれくらいですけど。

  • ビルドオプションでlibevやlibeventを選択可能にする。
  • ファイルを分けてインターフェイスクラスチックな実装にして削除しやすくする。

まあこういう構成にしたのはどちらかというとライブラリが無くても動作するようにってのが主な理由だったんですが、こういった時にもインターフェイス設計は便利ですね。

2018/07/18 追記
公式QAがある以上、これでは黒を水で薄めて黒くないと言い張っている状態ですね。
libevを利用するモジュールはGPLというのは避けられないので、うまく切り出すなり完全に消すなり考えましょう。

参考

OSSのライセンスを理解する(「使用」と「利用」の違い、知っていますか?)
GPLライブラリをリンクしたプログラムに対する対応方法
自作ソースコードに、MITライセンスを適用する3つのやり方

21
17
2

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
21
17

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?