そのライブラリは、本当にその著作権表記だけで良いのか？

#はじめに
　自分が使っているライブラリが内部で別のライブラリを使っているかをきちんと調べなかった結果、ライセンス表記とライセンス文を入れ忘れ、ライセンス違反している状態になっていた事があります。
　気になって他のライブラリも調べたら、そういう所がいい加減だったりドキュメントで説明していない事例は結構あったので色んな所でライセンス違反者が続出してそうと言うアレな話です。

　ライセンスの話は専門家でも解釈が分かれたり国によって法律が違う事があるので、細かい法的な内容や個別の事例ついては良く分からないです。あきらかにあかんでしょみたいな事を中心に書いてます。
　また違反と一口に言っても、表記の間違いやライセンス文のコピーの入れ忘れなどから、コード公開義務違反や商用禁止ライブラリを商用で使うまで色々ありますし、故意なのか過失によるものなのかでも全然違いますし、著作権者も寛大だったりパテントトロールだったり様々です、違反した場合どういう対応するのが良くて結果どうなるかみたいなのは分かりません。

#よくある例1
　MITライセンスで配布されているライブラリAが、内部でMITライセンスで配布されているライブラリBを使用しています。この時ライブラリAを利用しているあなたの作ったソフトウェアを配布する場合どのようなライセンス表記が必要でしょうか？

1.ライセンス表記はしてもしなくてもよい

2.ライブラリAの著作権表示とMITライセンスの許諾表示をすればよい

3.ライブラリAとライブラリBの著作権表示とMITライセンスの許諾表示が必要

　Aを使っている時点でBも利用しているため、当然3になりますね。
　ライブラリが内部で別のライブラリを使用している事をはっきりと書いていない事が結構あるので、気付かずにライセンス違反してる人がいそうです。
　場合によってはライブラリBがさらにライブラリCを明示せずに使っていてみたいな事もあったりするので、ライブラリBを調べたと思っても違反している事もあると思います。

　ただ故意でない限り刑事上の責任は普通ないのでそれで逮捕とかはないですし、著作権者の表記を改めれば民事的な面でもセーフになる可能性は高そうです。

　BSD系のライセンスはどれも似たような感じですが、商標の制限があったりなかったり、勝手に著作者の名前を宣伝に使ってはいけない等の細かい違いがあるので一応気をつけたいですね。

#よくある例2
　libpngLicenseで配布されているライブラリAが、パブリックドメインのライブラリPとzlibLicenseのライブラリZを使用しています。この時ライブラリAを無改変で利用しているあなたの作ったソフトウェアを配布する場合どのようなライセンス表記が必要でしょうか？

1.ライセンス表記はしてもしなくてもよい

2.ライブラリAの著作権表示とlibpngライセンスの許諾表示をすればよい

3.ライブラリAとライブラリZ,Pの著作権表示とライセンスの許諾表示が必要

　この場合、2でも3でもライセンス違反ではありませんが、1でOKですね。

　この辺りのライセンスは著作者名を変えて表記するとか自分で書きましたとか捏造するみたいなあからさまにあかん事をしない限り違反しない様になっています。
　なのでライセンスを一切調べずにライブラリを使ったり、内部でどんなライブラリを使っているか書いていないライブラリを使ってもライセンスによっては何の問題も無い事もあります。
　ただしソースコードを公開する場合はライセンス表記が必要な場合がある物とソースコードの最初に書かれているライセンス表記を残して置くだけで良い物があったりするので気をつけましょう

#よくある例3
　MITライセンスで配布されているライブラリAが、LGPL2.1のライブラリBを利用しています。
この時ライブラリAと静的リンクしている、あなたの作ったソフトウェアはどういう事が求められるでしょうか？(複数選択)

1.ライブラリAの著作権表示とMITライセンスの許諾表示

2.ライブラリBの著作権表示とLGPL2.1のライセンス文の写しをソフトと一緒に配布する

3.ソフトウェアのライセンスにリバースエンジニアリングを禁止する条項を入れてはいけない

4.ソフトを所持している人に、ソースコードかオブジェクトコード(ソースがコンパイル中に機械語に変換された中間形式等)を請求された場合、どちらかを渡す必要がある。

5.ソフトウェアで利用している、あなたが権利を持っている特許がGPL又はLGPLのソフトウェアで利用されていても、特許について訴訟したり請求出来ない。

6.ソフトウェアに技術的保護手段を組み込んでも良いが、法律上は技術的保護手段とは見なされなくなる。

　静的リンクしているなら1～4を守る必要があります。
5や6のような条項はLGPL3.0にも2.1にも含まれていません。

　4がよくわかんないですね
　ようするに少なくともLGPLの部分は修正する事が可能になっている必要があると言う事です。LGPLの部分がdllやスクリプトの場合は修正したdll等と簡単に交換出来ますね。
　静的リンクした実行ファイルのライブラリの部分だけを修正可能な状態にするにはコンパイル中の中間ファイルを配布する必要があり、知識が無いと何のファイルを配れば良いのか分からないですし色々面倒なので、コード公開するか、動的リンクにする人が多いと思います。
　動的リンクの場合は、ソースコードかDLLとのリンク方法のどちらかを公開すれば良いです。
　
　しかしながらiOSやAndroidだと基本的に静的リンクする事になるので動的リンクあるいはコード公開を選べない場合があり、オブジェクトコードを配布するしかない事があり問題になることがあります。

　LGPLと静的リンクする場合、LGPLにしてソースコードを公開する必要があるみたいな誤解をしてる人は多そうですね、自分も勘違いしてたし。

　やはり内部でLGPLのライブラリを利用していることがはっきり書かれていない事も結構あり、そういった場合｢知らずにLGPLに違反していた｣みたいな事になりそうです。

#よくある例4
　MITライセンスで配布されているライブラリAが、GPL ver2のライブラリBを利用しています。
この時ライブラリAを利用している、あなたの作ったソフトウェアはソースコードを公開して、ライセンス文を一緒に配布したり、互換性のあるライセンスにしたり、再配布を認めたり、著作権表示を正しく行って下さい。
　後はLGPL ver3やGPL ver3あるいはGPL ver2とかだと(LGPL ver2.1もそうかも？)、一部配信プラットフォームの規約と両立しないとか言う話や、GPL ver3とGPL ver2のコードを組み合わせるとアウトとか、その辺りも注意が必要です。

　GPL以外でも条件によってはライセンス料の支払いが必要なライブラリとか著作権表記以外の事を求めるライブラリを知らずに使うと困った事になるかもしれません。
　例1のような違反で何か大きな問題になった話とかは私の知る範囲では聞いた事ありませんが、こういう例だと再配布出来ると商業的に困る事があるためコード公開を拒否し配信停止して有耶無耶になったパターンや、コードを公開して過去の違反は無かった事にして許諾されたパターン、コード公開を拒否したり違反を繰り返した結果裁判になって賠償金を払ったパターン、違反に対して適切な対応を取ったので寧ろ賞賛されたパターンや、某OSとは今後関わらないみたいに逆ギレした？など、揉めたり揉めなかったりします。

#ソースコード以外のあれこれ
　GPL3 でコードが公開されているゲームソフトAを改変したソフトB配布する際、問題が発生する可能性があるのはどれか？
１．ゲームソフトAのゲーム名を元にソフトBに似た名前を付けて公開する
２．ゲームソフトAに同梱されている画像や音声ファイルをソフトBと一緒に配布する
３．素材としての再配布が禁止されている音声ファイルを購入しBGMとしてソフトBと一緒に配布する
４．ゲームBの処理を一部スクリプト化してスクリプト部分は二次利用不可にする
５．ソフトAのソースコードを改変せずに画像や音声ファイル等を全て差し替えて配布する

　１と２は条件により問題が発生します。３と４と５は基本的に問題ありません。
　１．GPLや他OSSのライセンスとは別に商標を取っていたり商標に関する制限を課す事があり、制限がかかっていれば問題になります
ただし制限を掛けていない場合もあるので問題にならない場合もあります

　２．ソフトウェアと一緒に配布されている、画像、音声、スクリプト、フォント等のファイルはソフトウェアのライセンスとは別のライセンスを適用出来るので、コードがGPLでも画像や音声ファイルは二次利用不可になっている事もあります
これもクリエイティブ・コモンズの制限がゆるい奴とかでライセンスされている等で問題ない場合もあります

　３．２の理由で問題ありません

　４．動的リンクしてお互いにファンクションコールでデータ構造を共有しているようなスクリプトだとダメです
普通のスクリプトだとそんな事してないと思うので別のプログラム扱いになってメインプログラムのGPLライセンスは何の条件も課さないよね？
あんまり自信がない・・・

　５．再配布が自由なので問題がありません
全て差し替えれば問題ありませんが、一部差し替えてないファイルがあれば２の理由でNGになる可能性があります

#LGPLとGPLとアプリストア
GPLライセンスを作成したFSFの見解によるとアプリストアに登録する時にストア管理者が何かアプリに埋め込む系の配布方法はソースコードからコンパイル可能なファイルと配布されるファイルが本質的に違う物になるためライセンス違反となるとされています
　そういった配布サイトへの登録はソースコードを公開していてもGPLやLGPL違反になるしフリーソフトウェアの理念にも反するとかで囲碁のアプリが配布が停止されたりとかもあったそうです
有名所だとAppStoreなんかがそうなので注意が必要だとか(あとはコンシューマ系のストアとかsteamとか)

　自分が作ったアプリをAppStoreやsteam等で公開して、ソースコードをGPLで配布している人はいてそれは問題ありません
ただし、そのソースコードを元に第三者がアプリを作ってAppStore等で公開するのは違反になります

#実際どんな感じ？
　色んなライブラリを複合してる事が多いマルチメディア系のライブラリを適当に調べてみた結果
勘違いがあったら御免なさい。(と言いつつ、ブーメランを投げる)

[cocos2d-x/license]
(https://github.com/cocos2d/cocos2d-x/tree/v3/licenses)
　公式ページでは全てのコードがMITライセンスみたいな事が書いてあり何のライブラリを使っているかが不明瞭、git-hubを見るとBSD系ライセンスのライブラリを結構使ってる様子？？LibwebsocketsはLGPLに見えて、無修正で静的リンクする場合は出所明示だけで良い別のライセンスになる感じなのかな？
　例1のパターンでライセンス違反してる人が多いかも？

検索したらライセンスのやりとりっぽいのが
[If is it possible to change the licence from LGPL to BSD or MIT?]
(http://ml.libwebsockets.org/pipermail/libwebsockets/2013-February/000148.html)

以下のpdfの50P辺りによると、昔はライセンス的にまずかったが安心になったらしい？
http://connect.jp.square-enix.com/wp-content/uploads/2014/10/SQEX_DevCon_hata.pdf

[SFML/license]
(http://www.sfml-dev.org/license.php)
　SFML自体はpng/zlibだが下の方にBSDスタイルのライブラリやLGPLのライブラリを使ってると書いてある、分かりやすい方だとは思う。

[SDL2.0/license]
(https://www.libsdl.org/license.php)
　本体はzlib、必要なdllと一緒に各dllのライセンス文も配られているがHPの記載が分かりにくいので、全部zlibだと思っているとライセンスに違反する。

[Qt/license]
(http://doc.qt.io/qt-5/licensing.html)
　無料版は本体がLGPL、気付かなかったって事にはなりにくそう？
[Qtのライセンスについて]
(http://qiita.com/ynuma/items/e8749233677821a81fcc)

[DXライブラリ/license]
(http://homepage2.nifty.com/natupaji/DxLib/dxlicense.html)
　Topからライセンスのページを見つけにくい？ような気もするが、独自ライセンスだけど複雑ではないし日本語で説明があるので、違反はしにくそう。
　ただ、最近までlibtiffの表記が間違ってたようです。

[openFrameworks/license]
(http://ja.wikipedia.org/wiki/OpenFrameworks)
　本体はMITライセンスで、選択的に利用可能なライブラリのライセンスは色々。
　ライブラリ名だけで各ライブラリが何のライセンスか公式ページに書いておらず、自分で調べる必要がある模様、FreeImageのマルチライセンスなんかは読むの大変そう。

色々あるけど、利用者がほぼ違反しないようなライセンス選択をしているライブラリは少ない
ライブラリ作者のミスで利用者が１００％違反するようなライブラリも別に珍しくない

#まとめ
　一節によると公開されているアプリの８割がライセンス違反（多分大半はMITライセンスの表記漏れ等の重大では無いやつ）しているなんて話もありますが、ライブラリAがB使って、BがC使って～以下略みたいな感じで誰か一人でも適当な人がいると連鎖的に違反者が出まくる関係でさもありなんって感じではありますね

　オープンソースなり自由なライブラリやソフトウェアのライセンス条項は鵜呑みにせずに調査した方が安心だと思います、機能が多かったりdllやらlibをたくさん使っているのにライセンス条項がやたらシンプルな場合は特に注意した方が良さそう。結構なお値段だけど、そういうのをチェックする商用ツールとかもあるらしいっすよ。

　違反者が｢そのライセンスだと知らなかった｣とか何故か被害者ぶる事もあるのだけど、著作権者からすると｢知らなかったとか知らんがな｣な感じなので、その辺りは故意で無いのを示すのはともかく責任転嫁せずに対応した方が良いと思いました。

　ライセンス違反したりライセンス表記が分かりにくいライブラリやソフトウェアがあると、芋づる式にライセンス違反者が生まれかねないので、コードを公開する時は特にちゃんとした方が良いですね。

#参考にしました
[wikipedia/著作権侵害]
(https://ja.wikipedia.org/wiki/%E8%91%97%E4%BD%9C%E6%A8%A9%E4%BE%B5%E5%AE%B3#.E8.91.97.E4.BD.9C.E6.A8.A9.E3.81.AE.E5.8A.B9.E5.8A.9B)

[第９講　著作権等の侵害]
(http://www.sekidou.com/law/lives/urhrecht/urhr-09.shtml)

[モバイルアプリ(Android/iOS)はオープンソースライセンス違反が多い‘初期の西部開拓地'か]
(http://jp.techcrunch.com/2011/03/09/20110308potential-open-source-license-violations-in-android-and-ios-apps/)

[Top 20 Open Source Licenses]
(https://www.blackducksoftware.com/resources/data/top-20-open-source-licenses)

[FSF、(LGPLの)及ぶ作品に対し、静的 vs 動的にリンクされたモジュールについて、LGPLには異なる要求がありますか?]
(http://www.gnu.org/licenses/gpl-faq.ja.html#LGPLStaticVsDynamic)

[FSF、GNUライセンスに対する違反]
(https://www.gnu.org/copyleft/gpl-violation.html)

[ライセンスの選択を恐れる必要はありません]
(http://qiita.com/tadsan/items/99d816e78ca429093b75)

[100% GPLとは？]
(https://ja.wordpress.org/about/license/100-percent-gpl/)

解釈が分かれている例
[Qtのライセンス]
(http://blog.hermit4.info/2012/07/qt.html)

[LGPLとAndroid]
(http://d.hatena.ne.jp/pekeq/20110126/p1)

[(L)GPLとApp StoreとVLC for iOS]
(http://blog.tai2.net/lgpl_and_appstore.html)

[Android アプリに LGPL ライブラリを組み込むとソースコード開示義務が発生するらしい]
(http://fnya.cocolog-nifty.com/blog/2012/01/android-lgpl-26.html)

趣味でゲーム作ってます
ゲーム制作Blog