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
|
<!--#set var="ENGLISH_PAGE" value="/philosophy/when-free-software-isnt-practically-superior.en.html" -->
<!--#include virtual="/server/header.ja.html" -->
<!-- Parent-Version: 1.79 -->
<!-- This file is automatically generated by GNUnited Nations! -->
<title> 自由ソフトウェアが(実際問題として)優れていないとき - GNUプロジェクト - フリーソフトウェアファウンデーション</title>
<!--#include virtual="/philosophy/po/when-free-software-isnt-practically-superior.translist" -->
<!--#include virtual="/server/banner.ja.html" -->
<h2> 自由ソフトウェアが(実際問題として)優れていないとき</h2>
<p>
<a href="https://mako.cc/writing/"><strong>ベンジャミン・メイコ・ヒル</strong></a>著</p>
<p>オープンソース・イニシアティブ(OSI)のミッション・ステートメントは、こう述べます。「オープンソースは分散ピア・レビューとプロセスの透明性の力を活用したソフトウェアの開発方法です。オープンソースは、高品質、高信頼性、高い柔軟性、コスト削減、独裁的なベンダーのロックインの終末を約束します。」</p>
<p>これまで10年以上、フリーソフトウェアファウンデーションは、この「オープンソース」による自由ソフトウェア運動の特徴付けに異を唱えてきました。自由ソフトウェアの擁護者は、主に、この枠に対して議論しています。なぜなら、「オープンソース」は、わたしたちの中心的なメッセージである自由を抑制し、わたしたちが作り上げたソフトウェアの成功におけるわたしたちの運動の役割を覆い隠そうとする、明白な活動だからです。わたしたちは、「オープンソース」は基本的に悪い、と言ってきました。なぜなら、人々がソフトウェアの自由について語ることから遠ざけるようにする、からです。しかし、ここで、オープンソースの枠組みについて、わたしたちが油断してはいけないもう一つの理由があります。基本的なオープンソースの議論は、上記の引用されたミッションステートメントとして論じられますが、しばしば正しくありません。</p>
<p>オープンソース・イニシアティブは「オープンソースは高品質、高信頼性、高い柔軟性を約束する」と示唆しますが、この約束はいつも現実となるわけではありません。わたしたちはしばしば事実を宣伝するわけではありませんが、自由ソフトウェアプロジェクトの初期段階のどんなユーザも、純粋に実用性の面で、プロプライエタリの競争相手として自由ソフトウェアは常に便利とは限らない、と説明できるでしょう。自由ソフトウェアは時々、低品質です。時々、低信頼性です。時々、柔軟性を備えていません。オープンソースを好む議論を真剣にするならば、なぜ、オープンソースは、その「約束」を守らないのか説明し、プロプライエタリなツールが良い選択かもしれないと結論づけなければならないのではないでしょうか。そうしなければいけない理由はなにもありません。</p>
<p>リチャード・ストールマンはこの小論、<a
href="/philosophy/open-source-misses-the-point.html">なぜオープンソースは的を外すのか</a>、でこの点を論じています。そこでは、こう説明されています。「オープンソースの考えは、利用者にソフトウェアの変更と再配布を許すことで、ソフトウェアをよりパワフルに信頼性の高いものにする、ということです。しかし、これは保証されていません。プロプライエタリなソフトウェアの開発者は無能というわけではありません。ときに、かれらもパワフルで信頼性の高いものを作り出します。それが、利用者の自由を尊重するものではないといえども。」</p>
<p>オープンソースにとっては、低品質のソフトウェアは、言い逃れるべき問題だったり、そのソフトウェアをまるごと避ける理由となります。自由ソフトウェアにとっては、それは解決するべき問題です。自由ソフトウェアの擁護者にとって、不具合と欠落した機能は決して恥のもとではありません。ユーザの自由を尊重する自由ソフトウェアのどんな部分も、ユーザの自由を尊重しないプロプライエタリの競争相手に対し、強力で本質的な優位があります。たとえほかの問題があったとしても、自由ソフトウェアには常に自由があります。</p>
<p>もちろん、すべての自由ソフトウェアはどこからか始めなければなりません。たとえば、始まったばかりの新しいソフトウェアは、プロプライエタリの確立されたツールよりも機能がたくさん有る、とはなりにくいでしょう。たくさんのバグでプロジェクトは始まり、時とともに改善します。オープンソースの擁護者はプロジェクトは時とともに運とともに有用性を増す、と論じるでしょうが自由ソフトウェアのプロジェクトは最初の一日から自由ソフトウェア擁護者に重要な貢献を表現しているのです。技術でユーザにコントロールを与えるどんなソフトウェアも前進です。プロジェクトの成熟とともに品質が改善されるのは、それに色を添えるものに過ぎません。</p>
<p>第二のおそらくもっとののしるべき事実は、オープンソースの定義の中心にある協調分散のピアレビューの開発プロセスは、自由(もしくは「オープンソース」)ライセンスのもとにあるプロジェクトの大半のソフトウェア開発の慣習とまったく似ていない、ということです。</p>
<p><a href="/software/repo-criteria.html">自由ソフトウェアのホスティングサイト</a>SourceForgeと<a
href="http://sv.gnu.org">Savannah</a>のいくつかのアカデミックな研究は、コードベースをオンラインにしている多くの自由ソフトウェア開発者が既に最初の一歩の段階から知っていることを、明かにしています。自由ソフトウェア・プロジェクトの大勢は特に協調的ではありません。SourceForgeの自由ソフトウェア・プロジェクトの貢献者の数のメディアンは?
1です。たった一人の開発者です。SourceForgeプロジェクトの参加者の数で見た際の95パーセンタイルは5人の貢献者です。半数以上の自由ソフトウェア・プロジェクトは(いくつもの成功したリリースを行い、頻繁にダウンロードされる多くのプロジェクトさえも)、外部からの援助は少なく、単一の開発者の仕事なのです。</p>
<p>協調開発の力と「分散ピアレビュー」を強調することにより、オープンソースのアプローチは、なぜ、人は、自由ソフトウェアのプロジェクトの大半を使用し貢献するべきなのか、についてほとんどなにも言ってないように思えます。なぜなら、協調の主張されている利益は強調がないときには実現しえませんし、自由な開発プロジェクトの大半は、プロプライエタリの競争相手に対して何の技術的優位性もないからです。</p>
<p>自由ソフトウェアの擁護者にとって、こう言った同じプロジェクトは同じように重要な成功に見えます。なぜなら、それぞれの自由ソフトウェアはユーザの自由を尊重し、ソフトウェアの自由の擁護者は、それぞれの自由ソフトウェアの部分がプロプライエタリの競争相手よりも本質的な倫理的な優位があるとして始まっていると論じるからです。実用上の有意性よりも自由を強調することによって、自由ソフトウェアの擁護者は、オープンソースがしばしばそうではない、技術の現実を根とするのです。自由ソフトウェアがより良いとき、わたしたちはその事実を祝すことができます。そうではないとき、自由ソフトウェアの擁護に対する批判やその問題のソフトウェアの使用を有無を言わさずに禁止するような議論として、みなす必要はありません。</p>
<p>オープンソースの擁護者は、自由に開発されたソフトウェアはプロプライエタリなソフトウェアよりも良いものであるべき(もしくは時とともにそうなる)とその主張を防御せねばならないでしょう。自由ソフトウェアの支持者は、代わりに、「どうしたら自由ソフトウェアをよくできるでしょうか?」と問うことができます。自由ソフトウェアの枠組みでは、高品質なソフトウェアは目的への手段として存在します。目的そのものではなく。自由ソフトウェアの開発者は、そのユーザに役立つ、機能する、柔軟なソフトウェアを作り出すことに励むべきです。しかし、そうすることだけが、わかりやすくてかつ深遠で重要な目標へと進む一歩一歩の唯一の方策というわけではありません。つまり、ユーザの自由を尊重し守る目標です。</p>
<p>もちろん、高品質なソフトウェアを作り出すのに協働が重要な役割を担うという議論を拒否する必要はありません。もっとも成功している自由ソフトウェアのプロジェクトの多くでは、まさに明らかにそれがなされているのです。協働の利点は、理解、支持、協力されるべきものです。イデオロギーに適合しない確とした事実を前にして、与えられて当然とするものではありません。</p>
<div class="translators-notes">
<!--TRANSLATORS: Use space (SPC) as msgstr if you don't have notes.-->
</div>
</div>
<!-- for id="content", starts in the include above -->
<!--#include virtual="/server/footer.ja.html" -->
<div id="footer">
<div class="unprintable">
<p>FSFおよびGNUに関する問い合わせは<a
href="mailto:gnu@gnu.org"><gnu@gnu.org></a>までお願いします(英語)。FSFへの連絡は<a
href="/contact/">他の方法</a>もあります。リンク切れや他の修正、提案は<a
href="mailto:webmasters@gnu.org"><webmasters@gnu.org></a>までお送りください。</p>
<p>
<!-- TRANSLATORS: Ignore the original text in this paragraph,
replace it with the translation of these two:
We work hard and do our best to provide accurate, good quality
translations. However, we are not exempt from imperfection.
Please send your comments and general suggestions in this regard
to <a href="mailto:web-translators@gnu.org">
<web-translators@gnu.org></a>.</p>
<p>For information on coordinating and submitting translations of
our web pages, see <a
href="/server/standards/README.translations.html">Translations
README</a>. -->
正確で良い品質の翻訳を提供するよう努力していますが、不完全な場合もあるかと思います。翻訳に関するコメントと提案は、<a
href="mailto:web-translators@gnu.org"><web-translators@gnu.org></a>におねがいします。</p><p>わたしたちのウェブページの翻訳の調整と提出については、<a
href="/server/standards/README.translations.html">翻訳 README</a>をご覧ください。</p>
</div>
<!-- Regarding copyright, in general, standalone pages (as opposed to
files generated as part of manuals) on the GNU web server should
be under CC BY-ND 4.0. Please do NOT change or remove this
without talking with the webmasters or licensing team first.
Please make sure the copyright date is consistent with the
document. For web pages, it is ok to list just the latest year the
document was modified, or published.
If you wish to list earlier years, that is ok too.
Either "2001, 2002, 2003" or "2001-2003" are ok for specifying
years, as long as each year in the range is in fact a copyrightable
year, i.e., a year in which the document was published (including
being publicly visible on the web or in a revision control system).
There is more detail about copyright years in the GNU Maintainers
Information document, www.gnu.org/prep/maintain. -->
<p>Copyright © 1999-2011 Benjamin Mako Hill</p>
<p>このページは<a rel="license"
href="http://creativecommons.org/licenses/by-sa/3.0/us/">Creative Commons
Attribution-Share Alike 3.0 United States License</a>の条件で許諾されます。</p>
<!--#include virtual="/server/bottom-notes.ja.html" -->
<div class="translators-credits">
<!--TRANSLATORS: Use space (SPC) as msgstr if you don't want credits.-->
</div>
<p class="unprintable"><!-- timestamp start -->
最終更新:
$Date: 2016/11/18 07:32:51 $
<!-- timestamp end -->
</p>
</div>
</div>
</body>
</html>
|
