もしあなたが書いたプログラム／ソースコードを、「オープンソース」または「フリーソフトウェア」として他者から 自由に 使ってもらうことを意図してるなら、やるべきではない。
注意
この記事を書いてるひとは法律の専門家じゃないよ。詳しいことはべんごし・べんりしなどのせんせいに相談してね。
そもそもライセンスとは
許可とか免許とかそんな感じの意味ですが、オープンソースライセンスを「利用許諾契約書」として解釈するには不可解な点があります。
実際には配布元(作者)から受け取った人への「お約束」だと解釈するべきです。つまり、ライセンスによって提示する条件を守る限りは複製権・頒布権・同一性保持権・公衆送信権の侵害について刑事告訴および利用差し止め、損害賠償請求などの提訴を行ふことはない、といふ約束です。
現行(2016年4月)の日本の法律において、著作権法違反は親告罪——つまり権利者の告訴がなければ刑事裁判になることはありません。このあたりの解釈と説明は怪しいので、法的な判断は専門家に相談してください（@sugitkさんのコメントを参考） これは一種の著作権法を逆用したハックですが、既に広く受け入れられてゐます。官公庁でのオープンソースライセンスの利用などは、まったく珍しいことではありません。
たとへば、首相官邸ホームページですらjQueryを利用、つまりオープンソースライセンスに則った再配布を行ってます。 http://www.kantei.go.jp/jp/n3-common/js/jquery-1.7.1.min.js
オープンソースってなんだ
Open Source Initiativeが掲げる「オープンソースの定義 (The Open Source Definition)」は以下の通りです。
- 自由な再頒布ができること
- ソースコードを入手できること
- 派生物が存在でき、派生物に同じライセンスを適用できること
- 差分情報の配布を認める場合には、同一性の保持を要求してもかまわない
- 個人やグループを差別しないこと
- 適用領域に基づいた差別をしないこと
- 再配布において追加ライセンスを必要としないこと
- 特定製品に依存しないこと
- 同じ媒体で配布される他のソフトウェアを制限しないこと
- 技術的な中立を保っていること
オープンソース - Wikipedia(2016-01-14 23:50:36の版)より引用
「フリーソフトウェア」と呼ばれる概念も、およそ同一の条件を持ちます。
7がわかりにくいのですが、「このライセンス以外に機密保持契約書にサインして提出しないと使っちゃだめだよ」みたいな感じです。直接の確認/承認/許諾を経ずに自由に複写・再配布して良いといふ要素も重要で、たとへばLinuxの1コピーごとに作者のリーナスに一通づつ契約書を送らなければならないとしたら、リーナスの家には倉庫がいくつあっても足りないでせう（ご存じの通りLinuxは産業分野でのサーバー用途にはもちろん、Androidにも採用されてますね）。
10の技術的中立は「このボタンをクリックすることで成立する」とか「ICカードリーダーが必要」とか「ソースコードはCD-Rでのみ再配布を許可する」みたいな条件をつけるとマウスとか専用のハードウェアがないと条件を満たせないので、そういった条件も付けちゃだめだよ、ってことです。
よく知られたライセンスとは
俗に「オープンソース」「フリーソフトウェア」と呼ばれるライセンスは、いくつかの組織団体が一覧管理してゐます。自分で作ったソフトウェアに適用すべきライセンスを選ぶのならば、これらで紹介／推奨されてるものを選ぶのが良いです。
- 自由ソフトウェアのライセンス一覧 (GNUプロジェクト/Free Software Foundation)
- Licenses & Standards (Open Source Initiative)
- SPDX License List) (Software Package Data Exchange/Linux Foundation)
よく知られたライセンスを利用するメリット
あなたが既存のソフトウェア／ライブラリを組合せて再利用して新しい何かを作りたいときに、ひとつひとつ条件を確認していく作業はとても煩しいものです。最低でも有名なライセンスを覚えておくことで、守らなければいけない条件が明確になります。
また、ライセンスの組合せには、後述するように相性の問題があります。よく知られたライセンス同士であれば組合せが可能かどうかよく考察されてゐます。また最新バージョンにおいては組合せの問題が解消されてるかもしれません。
ところで、いはゆる「ライセンス」は、基本的に著作権の概念の上に成り立ちます（一部、特許権などに言及するものもある）。主権国家は独自に著作権についての法律を持ちますが、現在は多くの国家が文学的及び美術的著作物の保護に関するベルヌ条約を批准してるので、これと矛盾する条項が受け入られることはないでせう1。
オープンソースじゃないライセンス
法律やオープンソースについて理解のないひとが書いたライセンスには、とんでもない条項が紛れることがあります。著作権の概念が怪しいソフトウェアをあなたの作品／製品にうっかり取り込んでしまうと、あなたのソフトウェアの著作権の扱いまで不明瞭になるおそれがあります。
「オープンソースっぽいけどオープンソースじゃないライセンス」にありがちなのが、先のオープンソースの定義5 と 6 の違反です。5「個人やグループを差別しないこと」について。たとへば企業として公開したときに「競合他社の利用を禁ずる」のような条件です。「競合他社」は一見明確な条件のように見えて、解釈や判定が非常に困難です。6「適用領域に基づいた差別をしないこと」について。「業務利用を禁ずる」「企業内での利用を禁ずる」のような条項です。これもやはり明瞭なようで判断がとても難しい問題で、一円でも収益を得たら利用を終了しなければいけないのか。
私見ですが「このソフトウェアを使って得られたデータを利用して論文を公刊してはならない」のように著作権の範囲から著しく逸脱した理不尽な要求も、オープンソースライセンスとして受け入れられないのではないかと感じます。
勝手な条件を付け足してはいけない
ありがちなのが、既存のライセンスに奇妙な条件を付加することです。
あへて過去のことを掘り返すのですが、Qiitaもライセンスが問題になった事例がありました。要約すると「基本はGPLで、GitHubでリポジトリにスターをつけてくれたらMIT」といふライセンス設定でした。さて、このライブラリには、誰がいくつ☆を付ければならないのでせうか。
あるいは、「個人」「教育/研究」「商用利用」などを単純に分けると奇妙なことになります。
個人使用 無償です。BSDライセンスによります。
教育機関、研究機関 無償です。BSDライセンスによります。
商用利用 1ライセンスにつき8万円です。好きい夢 <メール> にご連絡ください。
(http://homepage1.nifty.com/~skz/Scheme/normal.html より引用、2016年5月1日閲覧。 メールアドレスは引用者が置換した。)
さて、この表記ではライセンスの解釈が困難です。単に字面だけを見れば個人が再配布すれば商用利用者でもBSDライセンスとして再利用可能なように見えます。しかし先に述べた通りライセンスとは作者の側から利用者への（訴訟などを通じて権利を行使しないといふ）約束なので、そのような曖昧さのあるライセンスでは恐しくて利用することはできません。
善行を為そうと何気なく書いた一文が厄介なことを招くのは、やはりよくあることです。
何が正義で何が悪か、といった懊悩は昔からさまざまの思惟が巡らされ文学・特撮・アニメ作品のテーマにもなってきましたが、そんなものをソフトウェアライセンスに持ち込まれても困ります。環境保護団体のみなさまに「ITソフトウェア業界はすべて資源を搾取しエネルギーを浪費する地球環境破壊主義者だ！」とか主張されたら私はどうすればいいんですか。夜も眠れなくなります。
ちなみにJSONライセンスは現在(2016年4月)においても是正されてません。
そのほかにも、むかし「世界人権宣言とGPLを統合した」と称する謎ライセンスがありましたが、やはり意味はよくわかりません。
複数ライセンスの組合せ
「勝手な条件を付け足してはいけない」と前項に書いたのですが、よく知られたライセンス同士で、それぞれに矛盾がないことが確認できれば任意に組合せることは可能です。
たとへばMITライセンスで公開されたソフトウェア「A」をApache Licenseで公開するアプリケーション「B」の一部として同梱する、のようなことは大概において問題にならないでせう（ただしAが特許権について明確な問題がある場合を除く）。
ライセンスの相性
さて、実はApache LicenseとGNU General Public License 2.0は条件が両立しないので組合せることができません。また、古いMozilla Public LicenseとGNU General Public Licenseは組合せることができません。
これらのライセンス間の相性問題はApache License 2.0、Mozilla Public License 2.0、GNU General Public License 3.0などで改善されてます。そのほかのライセンスについての考察はさまざまなライセンスとそれらについての解説 - GNUプロジェクトを読まれると良いでせう。
デュアルライセンス
ライセンスには相性があり組合せが厄介であることは前に述べた通りですが、自分が著作権を持つ作品を複数のライセンスについては、複数のライセンスの「どちらかまたは両方 (and/or)」を満たすことで利用を許諾する方法があります。
たとへば俗にRuby's Licenseと呼ばれるRubyのライセンスは、独自ライセンスとBSD Licenseのどちらかを選択することができます。
また、フリーソフトウェアと私有ライセンス2を組合せてリリースする手法もあります。詳しくはnippondanjiさんの漢(オトコ)のコンピュータ道: デュアルライセンスとGPLをお読みください。
で、なんでライセンスを改造しちゃいけないんだっけ?
まとめます。
- よく知られたライセンスは著作権などの法的権利との整合性がある
- よく知られたライセンス同士は組合せの問題について既に誰かが考察済み
- よく知られたライセンスを採用することでに法的調査の余計な付加がかからない
- よく知られたライセンスを改造することで、法的な整合性が崩れることがある
- 独自のライセンスについては法的な妥当性について新たに検討の必要があるので導入コストが跳ね上がる
- 法的な整合性がないソフトウェアを自分の作品に取り込むことで、全体の法的権利が危うくなる
「コップ一杯の水に泥水を一滴垂らすと、コップ一杯の泥水ができあがる」ってやつですね。
おまけ
ちょっとユニークなオープンソースライセンス・まとめ - Qiitaはおもしろい記事ですが、いくつかはオープンソースライセンスの要件を満たしません。なぜでせう？