blob: f3986868abe7dbe838f3886de0aadc64997d1087 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
|
#use wml::debian::template title="ソフトウェアライセンスの比較"
#use wml::debian::translation-check translation="2bd18a67682540fb7c79d49a858ca9bcfaa704ed"
<p><strong>******This document is under development*******</strong>
<p>オープンなソフトウェアに対して活動している人は、
ライセンスについて非常に強い意見を展開する傾向があります。
初心者はそれよりも目の前にある作業を完了させることに関心があり、
長期的な視点に立った意味合いを理解しないので、
あまり深く考えずに、特定のライセンスを持つソフトウェアを
選択します
(ライセンスする意味合いを理解する多くの人が
これについて強い意見を持っていないというのは疑問です)。</p>
<p>数年の間に、ソフトウェアの作者にその作成に関する制御権を与える、
ほとんどの開発者が要求する種類の多くのライセンスが顕著になって来ました。
著作権表示が全くないものや、
作者独自のライセンスが含まれるソフトウェアもまだ多く見つかります。
後者については、こういったライセンスの多くに<a href="#mistakes"
>よくやる間違い</a>が含まれるためにソフトウェア配布がしづらくなり、
(オンライン、CD を作成する人の両方の) ソフトウェア配布者にとって
実にやっかいなものとなります。</p>
<p>以下は主なフリーの (オープンな) ソフトウェアライセンスと、
それぞれの良い点や悪い点を挙げたものです。
ここで述べていることに関連する点だけを示します。
また、多くの項目が「良い / 悪い」の見出しに挙げられます。
これは視点によって良い点にも悪い点にもなるということです。</p>
<ul>
<li><a href="https://www.gnu.org/">GNU General Public License (GPL)</a>
<br>
<b>要点:</b> ソースコードは入手可能にされなければなりません。
ソフトウェアは販売することができます。
派生物は同じライセンスを使用しなければなりません。
<br>
<b>良い:</b>
フリーの (オープンな) ソフトウェアに対してもっとも多く採用されている、
というのが良い理由です。ソフトウェア開発者の権利と、
ソースコードの入手可能性を保護することで、
ユーザが将来のサポートを失うことを心配する必要がなくなるという面で
大きな役割を果たします。
<br>
<b>良い/悪い:</b>
GPL 下にリリースされたソフトウェアを商用のソフトウェアに
組み込むことはできません。
これが実際悪いものであるかどうかは観点に依存します。
入手可能な解決法があるのにライセンスの矛盾によってそれが使えない、
という場合に、商用のソフトウェアを開発している人はもどかしい思いをしています。
もちろん、異なるライセンスを使用したバージョンを購入できるか
作者に連絡して確認するのを妨げるものでは全くありません。
GPL を使用したソフトウェアをリリースするほとんどの人は、
それが彼らの重労働の結果を許可なく利用して他者が金儲けするのを防止していても、
他者に使用と改善を可能にしているので、これらの制限を悪いと考えません。</li>
<li>Artistic License
<a href="http://language.perl.com/misc/Artistic.html">http://language.perl.com/misc/Artistic.html</a>
<br>
<b>要点:</b>
<br>
<b>良い:</b>
<br>
<b>悪い:</b></li>
<li><a href="https://opensource.org/licenses/BSD-3-Clause">BSD style license</a>
<br>
<b>要点:</b>
バイナリ及びソースコードにはライセンスを含めなければなりません。
宣伝する場合はライセンスに挙げられた開発者の承認を受けなければなりません。<br>
<br>
<b>良い / 悪い:</b>
ソースコードを公表することなく実行可能ファイルを一般に
(可能であればフリーで) 入手可能にしたい企業はこのライセンスを好みます。
良い例として、グラフィックカードのドライバをリリースしたい会社があります。
オープンソース支持者は、
とにかく企業がハードウェア仕様を公表することを好みます。
XFree86 のドライバ開発が暗示しているとすれば、
最良のドライバは入手可能なソースによって書かれたものです。
企業がやっていることは、所有権を主張した、
遅くてバグだらけのドライバをリリースすることで、
自らの製品に対して悪いものであるという印象を与えているだけです。
ドライバを他者に開発させることで開発費の節約にもなるのですが。
<br>
<b>良い / 悪い:</b>
誰でも、ソースを取得してそれを修正し、
その変更点を発表せずにできあがったものを発表することができます。
これがよいと思うか、悪いと思うかは個人的な嗜好によります。</li>
</ul>
<hr>
<p><a name="mistakes">自前のライセンスでよくある過ち</a>:</p>
<ul>
<li>ソフトウェアの営利販売を許可しない、あるいは制限する。
これにより、ソフトウェアを CD で配布するのが難しくなります。
<q>reasonable cost</q> (妥当な費用)
などの明確でない用語を使用するという誤りを犯すことがよくあります。
同じことを述べるのであれば、こういった言い回しに頼らずに、
単に上に挙げたライセンスの一つを使用する方が好ましいことになります。
例えば、ソフトウェアの配布を誰もに許可することで、
GPL は通常の市場動向によって費用を抑制します。
誰かが高い利幅を取って CD を販売した場合、
競争相手が市場に参入し、もっと安く売るまでに長くはかからないでしょう。
<br>注意: Artistic License は <q>Reasonable copying fee</q>
(妥当なコピー料金) という用語を使っていますが、
用語を制限して、あまり漠然とならないように努めています。</li>
<li>ソフトウェアの修正されたバージョンの配布を許可しない。
これは特定のグループによるソフトウェアの配布を妨げることになります。
例えば、Debian はコンパイル済みのソフトウェアを配布するので、
コンパイル、あるいは <a
href="ftp://tsx-11.mit.edu/pub/linux/docs/linux-standards/fsstnd/">FSSTND</a>
に合わせるようにソースの修正が必要になることはよくあります。
しかし、これを行うと私たちはその配布を許可されません。</li>
<li>作者にソフトウェアへのすべての変更を報告することを要求する。
変更や改良を作者に報告することで、
より広く配布することができるのはよいアイデアなのですが、
これを要件にすると問題が発生することがあります。
どれだけの人が、作者が五年後どこにいるか知っているでしょうか?
これは単純に
'Any changes to the software should be reported to the author'
というように (要件としないように) 書き換えてください。
ほとんどの人は報告するでしょう。<br>
この条項は通常、枝プロジェクトの発展を防止するために含められます。
オリジナルコードの開発が行き詰まらない限り、
枝が成功するのはその分割に他の力が働いた場合だけであることを歴史は示しています</li>
<li>ソフトウェアがパブリックドメインであることを述べた上で何らかの制限を加える
(営利販売を許可しない等)。
パブリックドメインであるか、あるいはそうでないか -
その中間は存在しません。そういったライセンスは無意味で、
付加した条件は法廷においては支持されないでしょう。</li>
</ul>
|
