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
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
|
<!--#set var="ENGLISH_PAGE" value="/philosophy/udi.en.html" -->
<!--#include virtual="/server/header.zh-cn.html" -->
<!-- Parent-Version: 1.96 -->
<!-- This page is derived from /server/standards/boilerplate.html -->
<!--#set var="TAGS" value="essays aboutfs free-nonfree" -->
<!--#set var="DISABLE_TOP_ADDENDUM" value="yes" -->
<!-- This file is automatically generated by GNUnited Nations! -->
<title>自由软件运动和 UDI - GNU 工程 - 自由软件基金会</title>
<!--#include virtual="/philosophy/po/udi.translist" -->
<!--#include virtual="/server/banner.zh-cn.html" -->
<!--#include virtual="/philosophy/ph-breadcrumb.zh-cn.html" -->
<!--GNUN: OUT-OF-DATE NOTICE-->
<!--#include virtual="/server/top-addendum.zh-cn.html" -->
<div class="article reduced-width">
<h2>自由软件运动和 UDI</h2>
<address class="byline"><a href="https://www.stallman.org/">Richard Stallman</a> 著</address>
<p>
一个名为 UDI（Uniform Driver
Interface，统一驱动程序接口）的项目旨在定义操作系统内核和设备驱动程序之间的单一接口。自由软件运动应该如何看待这个想法？</p>
<p>
如果我们想象一些操作系统和硬件开发人员，都在平等的基础上合作，UDI（如果技术上可行）将是一个非常好的主意。它允许我们为任何给定的硬件设备开发一个驱动程序，然后所有人共享它。这将促成更高水平的合作。</p>
<p>
当我们将这个想法应用到既有寻求合作的自由软件开发者，也有寻求统治的专有软件开发者的现实世界中时，结果是截然不同的。使用 UDI
的任何方式都无法使自由软件运动受益。如果它能做什么事情，那就是分裂和削弱我们。</p>
<p>
如果 Linux 支持 UDI，如果我们开始设计新的驱动程序使之通过 UDI 与 Linux 通信，那么会有什么后果？</p>
<ul>
<li> 人们可以在 Windows 系统上运行自由的、被 GPL 涵盖的 Linux 驱动程序。
<p>
这只有助于 Windows 用户；这对我们自由操作系统的用户没有任何帮助。它不会直接伤害我们；但是被 GPL
涵盖的自由驱动程序的开发人员可能会因为看到它们以这种方式被使用而气馁，那将是非常糟糕的。将驱动程序连接到专有内核也可能违反 GNU
GPL。增加这样做的诱惑是自找麻烦。</p></li>
<li> 人们可以在 <a href="/gnu/linux-and-gnu.html">GNU/Linux</a> 系统上运行非自由的 Windows
驱动程序。
<p>
这不会直接影响到自由软件支持的硬件范围。但它会间接地缩小这个范围，通过向数以百万计的、尚未学会为了自由而坚持自由的 GNU/Linux
用户提供诱惑。如果社区开始接受这种诱惑，我们将转而使用非自由驱动程序而不是编写自由驱动程序。</p>
<p>
UDI 本身不会阻碍自由驱动程序的开发。因此，如果我们中有足够多的人拒绝这种诱惑，尽管有 UDI，我们仍然可以开发自由驱动程序，就像我们没有 UDI
的时候一样。</p>
<p>
但是，为什么要鼓励社区变得比它想要成为的样子更脆弱呢？为什么要为自由软件的未来制造不必要的困难？因为 UDI 对我们没有好处，所以最好拒绝 UDI。</p></li>
</ul>
<p>
考虑到这些后果，作为 UDI 的支持者，Intel 开始“向 Linux 社区寻求 UDI
方面的帮助”就不足为奇了。一个富有和追求自我的公司如何接近一个合作社区？当然是要求施舍。他们问了也无所损失，而我们可能会仓促应声。</p>
<p>
与 UDI 的合作并非不可能。我们不应该给 UDI、Intel
或任何人贴上“大撒旦”的标签。但是在我们参与任何提出的交易之前，我们必须仔细判断，以确保它对自由软件社区有利，而不仅仅是对专有系统开发人员有利。在这个特定的问题上，这意味着要求合作使我们在通向自由内核和驱动程序之最终目标的道路上更进一步：用自由驱动程序支持所有重要的硬件。</p>
<p>
达成一笔好交易的方法之一可能是修改 UDI 项目本身。Eric Raymond 提出符合 UDI
规范可能要求驱动程序本身是自由软件。这很理想化，但其他替代选择也是可行的。只需要公布驱动程序的来源，而非将其作为商业秘密，就可以做到这一点——因为即使驱动程序是非自由的，它至少会告诉我们编写自由驱动程序需要知道的内容。</p>
<p>
Intel 也可以在 UDI 之外做一些事情来帮助自由软件社区解决这个问题。例如，硬件开发人员可能会寻求某种认证，Intel
可以在其间做出贡献。若果真如此，如果硬件规格是保密的，Intel 可能会同意使认证更加困难。这可能不是问题的完整解决方案，但它可以提供相当多的帮助。</p>
<p>
与 Intel 关于 UDI 的任何交易的一个困难之处是，我们将在一开始为 Intel 尽自己的一份力量，但 Intel
的回报将延后很长一段时间。实际上，（这相当于）我们要为 Intel 提供信贷。但 Intel
会继续偿还贷款吗？也许会，如果我们得到没有漏洞的书面承诺的话，否则，我们不能指望它。众所周知，企业是不值得信任的；我们正在与之打交道的人可能是正直的，但他们可能会被上级否决，甚至可能在任何时候被不同的人取代。即使是拥有大部分股票的
CEO 也可以通过收购来替换。与公司达成交易时，一定要得到有约束力的书面承诺。</p>
<p>
Intel 似乎不太可能提供满足我们需求的交易。事实上，UDI 的设计似乎是为了更易于对规范进行保密。</p>
<p>
尽管如此，不锁门也没什么坏处，只要我们慎于让谁进来。</p>
</div>
<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.zh-cn.html" -->
<div id="footer" role="contentinfo">
<div class="unprintable">
<p>请将有关自由软件基金会(FSF) & GNU的一般性问题发送到<a
href="mailto:gnu@gnu.org"><gnu@gnu.org></a>。也可以通过<a
href="/contact/">其他联系方法</a>联系自由软件基金会(FSF)。有关失效链接或其他错误和建议，请发送邮件到<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 contributing 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">《译者指南》</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 © 1998, 2021 Richard Stallman</p>
<p>本页面使用 <a rel="license"
href="http://creativecommons.org/licenses/by-nd/4.0/">Creative Commons
Attribution-NoDerivatives 4.0 International License</a> 授权。</p>
<!--#include virtual="/server/bottom-notes.zh-cn.html" -->
<div class="translators-credits">
<!--TRANSLATORS: Use space (SPC) as msgstr if you don't want credits.-->
<b>翻译团队</b>：<a rel="team"
href="https://savannah.gnu.org/projects/www-zh-cn/"><CTT></a>，2022。</div>
<p class="unprintable"><!-- timestamp start -->
最后更新：
$Date: 2022/09/12 11:00:04 $
<!-- timestamp end -->
</p>
</div>
</div>
<!-- for class="inner", starts in the banner include -->
</body>
</html>
|
