DH> Maybe I should have done a little more research before opening my
DH> mouth. I don't claim to be a UDI expert, a licensing expert, or
DH> anything of the sort. Terry has evidently done a lot more research into
DH> this whole thing than I have, which is great.
But Terry still wrong. There are is GPL and even more important there is
additional Linus clause about possibility of binary drivers for Linux.
So we have three choices for UDI drivers:
1. GNU GPL'ed UDI drivers or similar. Linux community are happy. [Some] Unix
vendors are unhappy. [Some] hardware manufacturers are unhappy.
2. GNU LGPL'ed UDI drivers or similar. Linux community are content. Unix
vendors are content. [Some] hardware manufacturers are unhappy.
3. Closed-Source UDI drivers. Linux community is unhappy. [Some] Unix
verndors are content, some are unhappy. Hardware manufacturers are
happy.
GPL and LGPL are different licensies. Main difference between GPL and LGPL is
that LGPL'ed work could be linked with closed-source code (like HP-UX or
SCO Unix source code). It's not clear for now that usage of drivers is
linking (in some systems (like Linux :-) you could load driver from module
and I'm not sure that it's could be classified as linking) but anyway:
"GPL problem" is not so big as Terry claims. UDI developers must be forced
to use LGPL and not GPL. But the biggest problem raised by UDI for Linux
community is Closed-Source drivers! Since Linux kernel API is in constant
change all existing closed-source drivers are in "unsupported" state (for
example change of kernel internals in 2.0.35 broke some Network Drivers)
and users are aware about this (even novices :-) and most of them avoid
closed-source drivers as much as they can (plus usually it's hard to find
that drivers -- you must search then on manufacturer web-site, you ubviously
could not find them on attached CD with drivers). UDI could change this and
manufacturers will produce it's own buggy UDI drivers and WILL NOT release
specs! Linux will be dependant from closed-source drivers (and often even
more buggy then Windows drivers since at least in this century *nix (includind
Linux) will be mandatory). That's point: UDI could help produce more buggy
Closed-Source drivers and will harm producing of Open-Source drivers (since
more and more manufacturers will not publish specs but instead will produce
Closed-Source UDI drivers and claims: "you already have drivers what else you
need???"). Even if UDI is NOT created with this scenario in mind it's HIGHLY
possible scenario and that's why Linux community just now is mostly against
UDI. [Most of] linux community is NOT against usage of UDI drivers tuned and
tested under Linux in HP-UX, SCO Unix, Solaris, etc. [Most of] linux community
is affraid of changing from their current Open-Source drivers to Closed-Source
UDI drivers.
DH> I'm in a somewhat awkward position anyway since I opened my big mouth.
DH> Kevin is my boss. Now, as far as I know, his feelings about Linux are
DH> the same as mine, we're both pro-Linux. What his other motivations
DH> regarding Linux and UDI are, I can only guess. I have nothing to do
DH> with UDI. I've seen bits of UDI code, but to be honest it never really
DH> interested me much (I'm busy enough already). I've only taken an
DH> interest in it now because it is obviously a major point of contention
DH> in the Linux community (which I feel I'm part of, even if a very small
DH> part).
Even if UDI initiative is created without bad minds in back it's still
HIGHLY possible then UDI will harm Linux in long terms (how -- see above).
And since this initiative has deep support from active I2O participants
(SCO & Intel) most Linuxoids (like me) are pretty sure that this is exactly
desirable scenario! I2O looks like it was specially created to give
closed-source players (Windows, SCO, HP-UX, Solaris, etc.) advantage oven
open-source players (Linux, *BSD, Hurd). JUST NOW UDI looks the same: force
Linux to use binary-only drivers, add check for OS in this drivers and make
drivers buggy under Linux (*BSD, Hurd) -- just few checks for OS type (a-la
Windows 3.1 beta) is enough -- and Ok under other OS'es; then clain that
Linux is buggy since it's crashed way to often. More subtle try then I2O but
still... You must coordinate a lot of manufacturers (not all of them -- only
few ones: one driver specially maked buggy is enough to crash Linux) but M$
has deep pockets...
DH> Anyway, enough rambling. I'm going to be in Dallas next week (I work in
DH> Arizona). I will take this email to Kevin and sit down with him and
DH> discuss it. I'll come back to you all with his comments later next week
DH> (I'm pretty sure I'm the only Interphaser reading this list)
DH> Terry L Ridder wrote:
>>
>> Hello;
>>
>> For background on my comments I would suggest reading the original
>> reports at:
>>
>> IT Week: Intel looks to Linux community for help with UDI
>> http://www.zdnet.co.uk/news/1998/37/ns-5501.html
>>
>> A Brief Quote from the above article is below
>>
>> <Begin Quote>
>> "The advantage of releasing to the Linux community is that their
>> work will give Unix OS vendors a basis to work from," Quick added,
>> though he stressed that the specification will still be tightly
>> controlled and standards based.
>> <End Quote>
>>
>> Uniform Driver Interface (UDI)
>> http://www.sco.com/udi/
>>
>> Below is a brief quote from the above Web Page:
>>
>> [rest of message snipped for brevity]
DH> --
DH> David Hollister Interphase Corporation dhollist@iphase.com
DH> Software Engineer Dallas, TX
DH> http://www.public.asu.edu/~dhollist
-
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/