OSSの利用・改変・再配布の条件を定めたライセンスの分類。
OSSライセンスとは、そのOSSを利用・改変・再配布するときに守るべき条件を定めた取り決めのことです。「自由に使ってよい」とはいえ、まったく無条件ではなく、必ず何らかの決まりがあります。
身近な例で考えると、レンタルスペースの利用規約に似ています。誰でも借りられますが「ゴミは持ち帰る」「火気厳禁」などのルールがあり、それを守る前提で自由に使えます。OSSも同じで、ライセンスという規約を守ることが利用の条件です。
OSSライセンスは、上の図解のように「派生物の公開をどこまで強制するか」で大きく3つに分類できます。制約が強い順に、コピーレフト型・準コピーレフト型・非コピーレフト型です。
代表的なOSSライセンスは次のとおりです。制約の強さに着目すると整理しやすくなります。
・GPL:コピーレフト型。派生物も同じライセンスで公開させる
・LGPL:ライブラリ(部品プログラム)向けの緩いコピーレフト
・BSD / MIT:制約が少なく、改変・組み込みが自由(著作権表示のみ)
・Apache 2.0:MIT系に近く、さらに特許に関する条項を持つ
| ライセンス | 分類 | 派生物の公開義務 | 主な用途 |
|---|---|---|---|
| GPL | コピーレフト型 | あり(全体に伝播) | 自由を継承させたいとき |
| LGPL | 準コピーレフト型 | ライブラリ部分のみ | ライブラリ提供 |
| BSD / MIT | 非コピーレフト型 | なし(表示のみ) | 商用組み込み |
| Apache 2.0 | 非コピーレフト型 | なし(表示+特許) | 商用・特許対策 |
ライブラリとは他のプログラムから部品として呼び出して使う、まとまった機能のプログラムのことです。LGPLは、ライブラリ自体を改変したら公開させるが、それを呼び出すだけのプログラムには公開義務を及ぼさない、という中間的な性質を持ちます。
ライセンスを選ぶときの判断軸は、「自分のコードを公開したいか、させたいか」です。
・公開したくない商用利用:制約の少ない MIT / BSD / Apache 2.0 系を選ぶ
・改変を必ず共有させたい:派生物にも公開を義務づける GPL 系を選ぶ
逆に「他人のOSSを使う側」として見ると、GPLのコードを自社製品に組み込むと、その製品全体のソース公開を求められる恐れがあります。ソースを秘密にしたい製品では、非コピーレフト型のOSSを選ぶのが安全です。
どのライセンスでも共通するのは「条件を守れば自由に使える」という点です。利用前にライセンスの種類を確認し、自分の用途に合うかを必ずチェックしましょう。
コピーレフト(Copyleft)という仕組みは、「OSSの自由を次の人にも継続させる」ために生まれました。
なぜ必要かというと、コピーレフトがないと次のことが起こりえます。A社がOSSを改変して製品を作り、ソースコードを秘密にして販売する──すると元のOSSの「自由」が消えてしまいます。
コピーレフト型ライセンス(代表がGPL)は、「改変・再配布するなら、派生物も同じライセンスでソースを公開しなければならない」というルールを課します。
・コピーレフトの効果:自由が連鎖する。使った人が改良したら、その改良版も公開される
・著作権(コピーライト)と逆:「守る」ではなく「広げる」ための仕組みだから「レフト」
コピーレフトの名は、著作権を意味する英語 copyright(コピーライト) をもじった造語です。「right(右)」ではなく「left(左)」とすることで、「規制」ではなく「自由の拡大」に使う逆転の発想を表しています。
OSSは「自由に使える」とはいえ、ライセンスの条件を守らないと違反になります。OSSを使う側として押さえておきたい代表的なルールを整理します。
違反になりやすいケース
・GPLのコードを自社製品に組み込み、ソースを公開しない:コピーレフト違反。製品全体の公開義務が生じる
・著作権表示(作者の名前や元のライセンス文)を消す:MIT・BSD系でも必ず表示を残す必要がある
・「無償だから自由に使える」と思い込んでライセンスを確認しない:無償でも利用条件は必ず存在する
守るための3つのポイント
・使う前にライセンスを確認する:GPL・MIT・Apacheなど種類によって義務が異なる
・著作権表示を必ず残す:どのライセンスでも元の作者の表示を消してはいけない
・GPLのコードを使う場合はソースを公開する:コピーレフトのルールに従う
「条件さえ守れば自由」──これがOSSの基本姿勢です。使う前に1分でもライセンスを確認する習慣が、トラブルを防ぐ一番の近道です。