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
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
|
<!--#include virtual="/server/header.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" -->
<title>The Free Software Movement and UDI - GNU Project - Free Software Foundation</title>
<!--#include virtual="/philosophy/po/udi.translist" -->
<!--#include virtual="/server/banner.html" -->
<!--#include virtual="/philosophy/ph-breadcrumb.html" -->
<!--GNUN: OUT-OF-DATE NOTICE-->
<!--#include virtual="/server/top-addendum.html" -->
<div class="article reduced-width">
<h2>The Free Software Movement and UDI</h2>
<address class="byline">by Richard Stallman</address>
<p>
A project called UDI (Uniform Driver Interface) aims to define a
single interface between operating system kernels and device drivers.
What should the free software movement make of this idea?</p>
<p>
If we imagine a number of operating systems and hardware developers,
all cooperating on an equal footing, UDI (if technically feasible)
would be a very good idea. It would permit us to develop just one
driver for any given hardware device, and then all share it. It would
enable a higher level of cooperation.</p>
<p>
When we apply the idea to the actual world, which contains both free
software developers seeking cooperation, and proprietary software
developers seeking domination, the consequences are very different.
No way of using UDI can benefit the free software movement. If it
does anything, it will divide and weaken us.</p>
<p>
If Linux supported UDI, and if we started designing new drivers to
communicate with Linux through UDI, what would the consequences be?</p>
<ul>
<li> People could run free GPL-covered Linux drivers with Windows systems.
<p>
This would help only Windows users; it would do nothing for us users
of free operating systems. It would not directly hurt us, either; but
the developers of GPL-covered free drivers could be discouraged to see
them used in this way, and that would be very bad. It can also be a
violation of the GNU GPL to link the drivers into a proprietary
kernel. To increase the temptation to do so is asking for trouble.</p></li>
<li> People could run nonfree Windows drivers
on <a href="/gnu/linux-and-gnu.html">GNU/Linux</a> systems.
<p>
This would not directly affect the range of hardware supported by free
software. But indirectly it would tend to decrease the range, by
offering a temptation to the millions of GNU/Linux users who have not
learned to insist on freedom for its own sake. To the extent that the
community began to accept the temptation, we would be moving to using
nonfree drivers instead of writing free ones.</p>
<p>
UDI would not in itself obstruct development of free drivers. So if
enough of us rejected the temptation, we could still develop free
drivers despite UDI, just as we do without UDI.</p>
<p>
But why encourage the community to be weaker than it needs to be? Why
make unnecessary difficulties for the future of free software? Since
UDI does no good for us, it is better to reject UDI.</p></li>
</ul>
<p>
Given these consequences, it is no surprise that Intel, a supporter of
UDI, has started to “look to the Linux community for help with
UDI.” How does a rich and self-seeking company approach a
cooperating community? By asking for a handout, of course. They have
nothing to lose by asking, and we might be caught off guard and say
yes.</p>
<p>
Cooperation with UDI is not out of the question. We should not label
UDI, Intel, or anyone, as a Great Satan. But before we participate in
any proposed deal, we must judge it carefully, to make sure it is
advantageous for the free software community, not just for proprietary
system developers. On this particular issue, that means requiring
that cooperation take us a step further along a path that leads to the
ultimate goal for free kernels and drivers: supporting <em>all</em>
important hardware with free drivers.</p>
<p>
One way to make a deal a good one could be by modifying the UDI
project itself. Eric Raymond has proposed that UDI compliance could
require that the driver be free software. That would be ideal, but
other alternatives could also work. Just requiring source for the
driver to be published, and not a trade secret, could do the
job—because even if that driver is not free, it would at least
tell us what we need to know to write a free driver.</p>
<p>
Intel could also do something outside of UDI to help the free software
community solve this problem. For example, there may be some sort of
certification that hardware developers seek, that Intel plays a role
in granting. If so, Intel could agree to make certification more
difficult if the hardware specs are secret. That might not be a
complete solution to the problem, but it could help quite a bit.</p>
<p>
One difficulty with any deal with Intel about UDI is that we would do
our part for Intel at the beginning, but Intel's payback would extend
over a long time. In effect, we would be extending credit to Intel.
But would Intel continue to repay its loan? Probably yes, if we get
it in writing and there are no loopholes; otherwise, we can't count on
it. Corporations are notoriously untrustworthy; the people we are
dealing with may have integrity, but they could be overruled from
above, or even replaced at any time with different people. Even a CEO
who owns most of the stock can be replaced through a buy-out. When
making a deal with a corporation, always get a binding commitment in
writing.</p>
<p>
It does not seem likely that Intel would offer a deal that gives us
what we need. In fact, UDI seems designed to make it easier to keep
specifications secret.</p>
<p>
Still, there is no harm in keeping the door unlocked, as long as we
are careful about who we let in.</p>
</div>
</div><!-- for id="content", starts in the include above -->
<!--#include virtual="/server/footer.html" -->
<div id="footer" role="contentinfo">
<div class="unprintable">
<p>Please send general FSF & GNU inquiries to <a
href="mailto:gnu@gnu.org"><gnu@gnu.org></a>. There are also <a
href="/contact/">other ways to contact</a> the FSF. Broken links and other
corrections or suggestions can be sent to <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>. -->
Please see the <a
href="/server/standards/README.translations.html">Translations README</a> for
information on coordinating and contributing translations of this article.</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>This page is licensed under a <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.html" -->
<p class="unprintable">Updated:
<!-- timestamp start -->
$Date: 2021/10/01 17:02:54 $
<!-- timestamp end -->
</p>
</div>
</div><!-- for class="inner", starts in the banner include -->
</body>
</html>
|
