lkml.org 
[lkml]   [1998]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: UDI and Politics (was Re: Linux, UDI and SCO.)
    Hello All;

    One more time now, and may be just may be everyone will understand the
    copyright and GNU GPL arguments.

    Theodore, I totally agree that using UDI devices drivers which are
    available in binary-format only would be allowed under the current
    permissions that Linus gives. No argument at all there. As to whether
    this would be wise or not is another issue.

    The copyright and GNU GPL issue comes from Project UDI, SCO,
    and Intel's own press.

    Please see the below URL:

    IT Week: Intel looks to Linux communituy for help with UDI
    http://www.zdnet.co.uk/news/1998/37/ns-5501.html

    Specifically there are several paragraphs toward the end of this
    document that are of concern to the Linux Community.

    <Begin Quote>
    However, writing new drivers for the thousands of peripherals
    on the market is a daunting task. Hence, Project UDI is hoping
    the Linux community will help. Linux will be, said Quick, key
    to the adoption of the UDI initiative. A reference platform
    will be distibributed as freeware for Linux, and the Project
    UDI members will be counting on the Linux community to work
    on device drivers. "We have talked to Linus Torvalds (the
    creator of Linux) and he was very interested in the idea,"
    Intel's Demshki said.

    "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>

    It is clear from the above two paragraphs that Project UDI,
    Mr. Kevin Quick (InterPhase), SCO, and Intel want the Linux
    Community to undertake the "daunting" task of writing UDI
    device drivers for the clearly stated purpose that the
    commercial OS vendors would have a basis to work from.
    Assuming for a moment that the authors of the UDI device
    drivers release all drivers under GNU GPL, any derivative
    work made by the commercial OS vendors, peripheral vendors
    would have to be GNU GPL'ed. This however does not solve
    the problem that they cannot use a GNU GPL'ed UDI device
    driver in a commercial closed-source OS.

    It is on this point that copyright and GNU GPL come into play.
    There is no way, no how for a GNU GPL UDI device driver to
    be used in a closed-source commercial OS. particularly if that
    GNU GPL'ed UDI device driver is for the SCSI controller which
    the commercial OS needs to have in order to even boot.
    The same is true for a GNU GPL'ed UDI network driver since
    their are initially targeting Intel-Arch servers for Project
    UDI. Last time I checked a server tended to need at least
    network card. ;-)

    Based on the above is why I stated in previous postings that
    SCO, IBM, HP, Sun, Digital, etc need the Linux Community
    to take on the "daunting" task of writing all there UDI
    device drivers, and clear want to use them for their own
    commercial OSes have basically two choices:

    1. Abandon their close-source OSes and switch to Linux,
    build hardware only. SCO could switch to writing add-on
    software.

    2. Release all their source code under GNU GPL.

    Please refer to the linux-kernel mailing list archives
    for a complete copy of my original posting.

    It is also clear that Project UDI, SCO, and Intel, as stated
    by Mr. Kevin Quick (InterPhase) that Linux therefore the
    Linux Community is "key" to the adoption of UDI.

    The second point for concern for the Linux Community is what
    is the monetary unit of trade. While we are not in a totally
    similar situation that the Apache group found itself with IBM,
    I would suggest that payment be the same, source code.

    Theodore Y. Ts'o wrote:
    >
    > Date: Sat, 19 Sep 1998 15:12:55 -0500 (CDT)
    > From: "Edward S. Marshall" <emarshal@logic.net>
    >
    > I think this is something this discussion has been seriously missing;
    > input from some of those who really will be deciding this:
    >
    > - Linus Torvalds and other kernel developers (Alan's been involved a bit,
    > though).
    >
    > Well, not that anything I saw is official in any way, but I've been
    > keeping quite because I've been amazed how stupid most of the UDI
    > discussion has been.
    >
    > Let's back off and have a fresh perspective on things.
    >
    > First of all, from looking at the UDI spec, UDI drivers will likely not
    > be as performant as "native" drivers. So there will still be incentives
    > for people who want device drivers for Linux to actually go and write
    > them, and for those people to pester manufactuers for specifications.
    > (Or reverse-engineer or disassemble the UDI driver for programming
    > information. :-)
    >
    > Secondly, UDI drivers will almost certainly be loadable kernel modules,
    > using a fixed, and well defined interface. Linus (as the main copyright
    > holder of the Linux kernel) has already said that loadable kernel
    > modules which restrict themselves to the kernel interface as defined by
    > /proc/ksyms are considered separate entities, and are not covered by the
    > GPL copyright --- just as user programs which use the normal kernel
    > system calls are not considered part of the kernel, but using normal
    > kernel services. So all of the copyright arguments are also a red
    > herring.
    >
    > Furthermore, what do you think the APM code in the Linux kernel does?
    > It makes calls to the APM BIOS! Or the Linux Bootstrap code, which
    > makes calls to the system BIOS. The System BIOS and the APM BIOS are
    > not GPL'ed on most systems --- indeed, source code is usually not
    > available in any form. Why is this not a problem?
    >
    > Well, let's think about it. The System BIOS and APM BIOS have a
    > well-defined, and standardized interface. When you buy a computer, it
    > comes with BIOS installed on ROM's as a matter of course. So the fact
    > that the System BIOS and the APM BIOS are not free doesn't get people's
    > way, and they probably simply don't think about it.
    >
    > Similarly, suppose now that network cards start coming with UDI drivers
    > on a diskette as a matter of course. The UDI device driver uses a
    > standardized, well-defined interface --- the UDI interface. It really
    > isn't all that different from the Linux kernel calling system BIOS
    > routines, or the APM routines.
    >
    > So fundamentally, I don't have a problem with the UDI concept --- just
    > as I don't have a problem with purchasing commercial software to run on
    > my Linux box. I am not an Open Source fanatic. All other things being
    > equal, I prefer Open Source, of course, but if a Open Source product
    > doesn't exist, and there is a good propietary solution available, I will
    > use it.

    I do not have a problem with the UDI concept either, I do have a problem
    with Project UDI, SCO, and Intel making a very public statement that
    the Linux Community is the "key" to UDI adoption. As stated previously
    this puts the Linux Community is an awkward position. If the Linux
    Community
    decides not to support Project UDI, will we not run the risk, whether it
    is justified or not, that being labeled "unsupportive", "contrary", etc.

    As we all know sometimes hopes and expectation become confused, which is
    my concern here. While Project UDI, SCO, and Intel "hope" that the Linux
    Community will help, I suspect that they "expect" us to help.

    I can only state what my standpoint is when it comes to computers and
    networks for which I am responsible:

    Never trust software you do not have the source code for.

    >
    > The big question, though is the quality of the UDI reference
    > implementation which SCO is planning on writing. WIll it be clean
    > enough so that Linus is willing to include it in the mainline kernel?
    > That's the $64,000 question. If it's big, ugly, etc., then the answer
    > will be no. And of course, the UDI reference implementation which will
    > actually *allow* the Linux kernel to take advantage of UDI drivers will
    > have to be GPL'ed, since that *will* be linked with the kernel in a very
    > fundamental way. But as far as I can tell, SCO understands that.

    This is true, and again see quote below:

    <Begin Quote>
    Most failures on enterprise systems are due to driver problems,
    industry representatives heard at the Intel Developer Forum in
    Palm Springs Wednesday. "Driver reliability is the smoking gun
    keeping Unix on Intel servers out of the enterprise," said Intel's
    Justin Rattner during a server technology seminar where the Linux
    community was identified as a source of help for the mighty chip
    maker.

    Rattner was talking during the week that Intel announced its
    decision to support Project UDI (Uniform Driver Interface),
    a Unix industry initiative to develop a single device driver
    implementation that will work across different Unix operating
    systems running on Intel platforms. Project UDI is made up of
    representatives from Compaq, Hewlett-Packard, IBM, SCO and Sun
    as well as Adaptec, Bit3 and Interphase. Intel is to provide
    information on interfaces and initiatives as well as engineering
    resources to help complete a reference design. The complete
    specification is due to be delivered at the next Intel
    Developer Forum in February.
    <End Quote>

    The reference platform will not be released until February 1999.
    That is 5 months away. The Linux kernel developer community
    will be into Linux-2.3 development series at that time.
    It will not be a quick decision as to whether the UDI reference
    platform will go into the standard linux kernel source tree.
    (I realize that it ay be a quick decision if the UDI reference
    platform source code is ugly, poorly written, etc, I am at the
    moment giving Intel the benefit of the doubt.)


    >
    > - Ted
    >

    --
    Terry L. Ridder
    Blue Danube Software (Blaue Donau Software)
    "We do not write software, we compose it."

    entertaining angels
    by the light of my computer screen
    24-7 you wait for me
    entertaining angels
    while the night becomes history
    host of heaven, sing over me
    ==Entertaining Angels==Newsboys

    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 13:44    [W:0.035 / U:0.252 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site