diff options
Diffstat (limited to 'talermerchantdemos/blog/articles/en/udi.html')
-rw-r--r-- | talermerchantdemos/blog/articles/en/udi.html | 158 |
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 “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><!-- for id="content", starts in the include above --> + +<!--#include virtual="/server/footer.html" --> + +<div id="footer"> +<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 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 © 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> |