summaryrefslogtreecommitdiff
path: root/talermerchantdemos/blog/articles/en/udi.html
diff options
context:
space:
mode:
Diffstat (limited to 'talermerchantdemos/blog/articles/en/udi.html')
-rw-r--r--talermerchantdemos/blog/articles/en/udi.html158
1 files changed, 158 insertions, 0 deletions
diff --git a/talermerchantdemos/blog/articles/en/udi.html b/talermerchantdemos/blog/articles/en/udi.html
new file mode 100644
index 0000000..5ebf873
--- /dev/null
+++ b/talermerchantdemos/blog/articles/en/udi.html
@@ -0,0 +1,158 @@
+<!--#include virtual="/server/header.html" -->
+<!-- Parent-Version: 1.77 -->
+
+<title>The Free Software Movement and UDI - GNU Project - Free Software Foundation</title>
+
+<!--#include virtual="/philosophy/po/udi.translist" -->
+<!--#include virtual="/server/banner.html" -->
+
+<h2>The Free Software Movement and UDI</h2>
+
+<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 &ldquo;look to the Linux community for help with
+UDI.&rdquo; 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&mdash;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><!-- for id="content", starts in the include above -->
+
+<!--#include virtual="/server/footer.html" -->
+
+<div id="footer">
+<div class="unprintable">
+
+<p>Please send general FSF &amp; GNU inquiries to <a
+href="mailto:gnu@gnu.org">&lt;gnu@gnu.org&gt;</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">&lt;webmasters@gnu.org&gt;</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">
+ &lt;web-translators@gnu.org&gt;</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>. -->
+Please see the <a
+href="/server/standards/README.translations.html">Translations README</a> for
+information on coordinating and submitting translations of this article.</p>
+</div>
+
+<p>Copyright &copy; 1998 Richard M. Stallman</p>
+
+<p>This page is licensed under a <a rel="license"
+href="http://creativecommons.org/licenses/by-nd/3.0/us/">Creative
+Commons Attribution-NoDerivs 3.0 United States License</a>.</p>
+
+<!--#include virtual="/server/bottom-notes.html" -->
+
+<p class="unprintable">Updated:
+<!-- timestamp start -->
+$Date: 2014/04/12 12:40:48 $
+<!-- timestamp end -->
+</p>
+</div>
+</div>
+</body>
+</html>