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

  • 167
    いいね
  • 1
    コメント
この記事は最終更新日から1年以上が経過しています。

はじめに

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

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

よくある例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等と簡単に交換出来ますね。
 静的リンクした実行ファイルのライブラリの部分だけを修正可能な状態にするにはコンパイル中の中間ファイルを配布する必要があり、知識が無いと何のファイルを配れば良いのか分からないですし色々面倒なので、コード公開するか、動的リンクにする人が多いと思います。
 
 しかしながら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とは今後関わらないみたいに逆ギレした?など、揉めたり揉めなかったりします。

実際どんな感じ?

 マルチメディア系のライブラリを適当に調べてみた結果。
勘違いがあったら御免なさい。(と言いつつ、ブーメランを投げる)

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

検索したらライセンスのやりとりっぽいのが
If is it possible to change the licence from LGPL to BSD or MIT?

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

SFML/license
 SFML自体はpng/zlibだが下の方にBSDスタイルのライブラリやLGPLのライブラリを使ってると書いてある、分かりやすい方だとは思う。

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

Qt/license
 無料版は本体がLGPL、気付かなかったって事にはなりにくそう?
Qtのライセンスについて

DXライブラリ/license
 Topからライセンスのページを見つけにくい?ような気もするが、独自ライセンスだけど複雑ではないし日本語で説明があるので、違反はしにくそう。
 ただ、最近までlibtiffの表記が間違ってたようです。

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

まとめ

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

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

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

参考にしました

wikipedia/著作権侵害

第9講 著作権等の侵害

モバイルアプリ(Android/iOS)はオープンソースライセンス違反が多い‘初期の西部開拓地'か

Top 20 Open Source Licenses

FSF、(LGPLの)及ぶ作品に対し、静的 vs 動的にリンクされたモジュールについて、LGPLには異なる要求がありますか?

FSF、GNUライセンスに対する違反

ライセンスの選択を恐れる必要はありません

解釈が分かれている例
Qtのライセンス

LGPLとAndroid

(L)GPLとApp StoreとVLC for iOS

Android アプリに LGPL ライブラリを組み込むとソースコード開示義務が発生するらしい