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

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

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

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

https://www.gnu.org/licenses/gpl-faq.ja.html#GPLStaticVsDynamic

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

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

--------------------------------------------

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

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

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

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

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

## **使用と利用の違い**

[OSSのライセンスを理解する（「使用」と「利用」の違い、知っていますか？）](https://qiita.com/bremen/items/c5aa9446e73aa4bc1de0)という記事を参考に使用と利用の違いについて考えましたが、結論出ず。
以前にも同記事は読んでいて理解したつもりでしたが、知っていますか？の問いは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をビルドすると静的ライブラリファイルとなっていました。
プログラムに取り込んでるならそれは利用にあたりますね。

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

## **その他情報を探してみる**


[こちらの記事の回答](https://ja.stackoverflow.com/questions/33857/gpl%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA%E3%82%92%E3%83%AA%E3%83%B3%E3%82%AF%E3%81%97%E3%81%9F%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%A0%E3%81%AB%E5%AF%BE%E3%81%99%E3%82%8B%E5%AF%BE%E5%BF%9C%E6%96%B9%E6%B3%95)から抜粋させていただきます。

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

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

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

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

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

## **一応保険を打っておく**

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

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

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

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

## **参考**

[OSSのライセンスを理解する（「使用」と「利用」の違い、知っていますか？）](https://qiita.com/bremen/items/c5aa9446e73aa4bc1de0)
[GPLライブラリをリンクしたプログラムに対する対応方法](https://ja.stackoverflow.com/questions/33857/gpl%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA%E3%82%92%E3%83%AA%E3%83%B3%E3%82%AF%E3%81%97%E3%81%9F%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%A0%E3%81%AB%E5%AF%BE%E3%81%99%E3%82%8B%E5%AF%BE%E5%BF%9C%E6%96%B9%E6%B3%95)
[自作ソースコードに、MITライセンスを適用する３つのやり方](https://www.catch.jp/oss-license/2013/09/27/mit_license/)