著作権やライセンスの大分類。
大分類
| 大分類 | 概要 | 方法 |
|---|---|---|
| copyright(proprietary) | 金銭の支払いを強制する | 利用者はコードの再配布や改変などが一切できない |
| non-commercial | 非営利 | 営利目的の利用を禁止する |
| copyleft | ソースコードの自由を強制する | 利用者はコードを改変したら公開すること |
| copycenter(permissive) | 非copyleftなOSL | 利用者は改変コードをクローズドにすることさえ可。詳細は各ライセンス参照 |
| public-domain相当 | 公有 | 法の許す限り権利を放棄する |
最初はproprietaryしかなかった。しかし利用者にとって不利益が大きく支配的であったため不満が出た。そこでcopyleftの概念が生まれた。しかしcopyleftは営利目的として使いにくい。その余地を残したpermissiveがある。利権自体を放棄したのがpublic-domain相当。権利の期限が切れたものがpublic-domain。非営利は定義が微妙らしい。普通はコピーレフトで事足りると思う。
自由
それぞれを「自由」で捉えると以下のような解釈になる。
| 種別 | 誰が自由か | 誰から自由か | どんな自由か |
|---|---|---|---|
| proprietary | 著者 | 著者以外の人 | 著者が独占・支配する自由。著者が利用者に対して対価を求める自由。自分の開発したソフトを自分だけが自由にする自由 |
| non-commercial | 成果物 | すべての人 | 成果物はカネから自由になる。たぶん利用者が著者に無断でパクって金儲けするのを防ぐ狙いもある？ |
| copyleft | ソースコード | すべての人 | ソースコードを人の都合(立場,権利,欲)から解放する自由 |
| permissive | 利用者 | 著者 | 利用者が改変したコードをクローズドにできる自由 |
| public-domain | 人 | 支配体制(国など) | 権利を放棄する自由。（権利を持つことを義務付けられる不自由からの解放）実際はその国の法が許す限りである |
どう選ぶ？
ライセンスは他者への許可を与えるもの。自分のソフトウェアに対して自分の意志を表明するのがライセンスのはず。それだけなら、以下のように判断できる。
| 種別 | 選択基準 |
|---|---|
proprietary |
（そもそもコード公開すべきでない） |
public-domain |
著作権放棄。著者は権利主張しない。ただし法的効果は不明 |
copyleft or permissive |
コードを公開する |
copyleft / permissive
copyleft と permissiveはどちらもコードを公開するもの。それはプロプライエタリの対になる。だがcopyleft と permissiveでは、コードを公開する目的が違うと思われる。
| 種別 | 違い |
|---|---|
copyleft |
ソースコードを人の都合(権利,欲)から解放し自由にする |
permissive |
公開するのは手段や結果にすぎない。目的ではない。ソースコードを非公開closedにしようが営利使用しようが利用者の自由 |
権利と義務で表現すると以下。法律に詳しくないので責任持てん。
| 種別 | 誰に | 何を与えるか |
|---|---|---|
copyleft |
利用者 | ソースコードを公開openする義務 |
permissive |
利用者 | ソースコードを非公開closedにする権利 |
さらにpermissiveなライセンスは多数あるが、それぞれ何を重んじているかが違う。以下例。
permissiveライセンス |
重視 |
|---|---|
MIT |
自由。著者責任放棄（利用者自己責任）の元に自由利用許可 |
Apache-2.0 |
営利利用可能なオープンソース。コントリビュータは著者を訴えないこと（コントリビュータが提供するコードもApache-2.0であること） |
permissiveは利用の仕方が利用者の自由である。それは営利目的を視野に入れている場合がある。その上でできるだけ利権絡みのトラブルを解消しようとしているのがApache-2.0と思われる。
MITの場合、世間で広まりカネになるとわかったとたん、著作権を振りかざしてくる可能性を孕んでいると思われる。おそらくそのような事態もApache-2.0なら回避できるのかもしれない。わからん。
permissiveは著者の法的態度・目的意識が不明瞭に思える。何も考えていないのかもしれないし、将来変わるかもしれないため意図的に明言を避けている場合も含まれているかもしれない。実際に裁判になったときにどうなるかはともかく、著者の意図がわからないのは罠になるかもしれないリスクに感じてしまう。
大雑把な選択基準は以下。
| 種別 | 選択基準 |
|---|---|
proprietary |
（そもそもコード公開すべきでない） |
public-domain |
著作権放棄。著者は権利主張しない。ただし法的効果は不明 |
copyleft |
コードを公開する。利用者にも公開を強いる |
permissive |
コードを公開する。利用者は非公開にしてもいい場合がある。詳細は各ライセンス参照 |
細かい所は法律も絡むし、ライセンスも読み込んでないため、よくわからない。ただ、ざっくりとした意図は以下のような感じだろう。
| 種別 | 意図 |
|---|---|
proprietary |
自分だけが独占し儲けたい |
public-domain |
公益に貢献したい（ただし利用者は私益のために利用できる） |
copyleft |
コードは常に公開し誰でも自由に使えるようにしたい（利用者にも公開を強いる） |
permissive |
コードを公開するがそれは手段。目的やその結果責任は利用者次第
|
私的認識
GitHubでコード公開するなら以下のような感じになるか？
| グループ | ライセンス | 対象 | 狙い | 法 |
|---|---|---|---|---|
| public-domain | CC0 |
練習用コード等 | 法的に争うつもりがないことを主張することで利用者に無用な負担をかけない。これにより開発時間を増やして公益に貢献する。私益のために使うことも利用者の自由 | 法的効果は不明 |
| copyleft | AGPL-3.0-only |
差別化された一定の価値がありそうなコード | コードを自由にする | 知らん |
| permissive | MIT,Apache-2.0 |
差別化された一定の価値がありそうなコード | 利用者を自由にする | 知らん |
参考
- https://exygy.com/blog/which-license-should-i-use-mit-vs-apache-vs-gpl/
- https://qiita.com/lovee/items/484ae3fc038314a64ee2
対象環境
- Raspbierry pi 4 Model B
- Raspbian buster 10.0 2019-09-26 ※
- bash 5.0.3(1)-release
$ uname -a Linux raspberrypi 4.19.75-v7l+ #1270 SMP Tue Sep 24 18:51:41 BST 2019 armv7l GNU/Linux
