snip.....
>
> 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.
I fail to see it doing anything but strengthening the Linux architecture.
If we have UDI support in the kernel, it does not necessarily require
us to develop UDI modules, and it will potentially give Linux the
access to the latest hardware available, assuming that the various
vendors release UDI drivers for their hardware. If the various vendors
find that they have a problem providing the detailed support for their
board, it should encourage them to provide source code, or detailed
information for their hardware. In either case, I believe Linux wins.
>
> If Linux supported UDI, and if we started designing new drivers to
> communicate with Linux through UDI, what would the consequences be?
>
> * People could run free GPL-covered Linux drivers with
> Windows systems.
>
> 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.
>
> * People could run non-free Windows drivers on GNU/Linux systems.
It is highly unlikely that a large number of Windows users would ever
use GNU/Linux drivers for their NT system, for most will only run the
drivers supplied with their hardware, and never search out this type.
>
> 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 move to using
> non-free drivers instead of writing free ones.
Linux, regardless of the pressure being put on hardware vendors, always
lags behind in availability of detailed information for the hardware.
Beyond that, if the linux community really had an interest in using non-free
drivers, we would have moved back over to M$, and just accepted the low
performance, low reliability that Redmond provides.
>
> 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.
>
snip....
>
> Cooperation with Intel is not out of the question. We should not
> label 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 *all* important
> hardware with free drivers.
Ideally, the hardware vendors will come around. But I wouldn't hold
my breath.
>
> 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 if that driver is not free, it would at least tell us
> what we need to know to write a free driver.
It should be encouraged, but not required. like taxes :)
>
> Intel could also do something else, 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.
I believe that putting Intel in that place of power is a *bad* move.
>
> One difficulty with any deal involving 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. When making a deal
> with a corporation, always get a binding commitment in writing.
>
> Given Intel's involvement in I2O, a broad plan to keep hardware
> specifications secret, it is not likely that they will accept a deal
> that gives us what we need. In fact, UDI seems like a plan to make it
> easier to keep specifications secret.
As UDI moves forward, and as Intel works with the linux world, there
should be pressure to release the I2O specifications to the freeware
community.
>
> Still, there is no harm in keeping the door unlocked, as long as we
> are careful whether we let Intel in.
>
>
> Copyright 1998 Richard Stallman
> Verbatim copying and distribution is permitted in any medium
> provided this notice is preserved.
>
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/