[lkml]   [2003]   [Oct]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: freed_symbols [Re: People, not GPL [was: Re: Driver Model]]
    On Mon, 6 Oct 2003, Pascal Schmidt wrote:

    > On Mon, 06 Oct 2003 20:50:12 +0200, you wrote in linux.kernel:
    > > That has no bearing on the legalities. A version of the kernel can't
    > > force the GPL on a driver that works with that version of the kernel
    > > because you can pull that driver out and drop in another.
    > Okay, I can see the boundary. We still have the problem that drivers
    > writers have to be very careful to not copy kernel code by accident
    > because the kernel changes often, which creates a temptation to look
    > closely at in-tree drivers to see how they do things. And if a
    > drivers writer then produces code that is essentialy the same as is
    > found in the kernel, only with changed indentation and variable names,
    > I think we both a agree that such a driver would be a derived work.
    > Another problem is the fact that Linux kernel headers can contain code
    > in the form of macros. If a driver uses such a header, it links kernel
    > code with itself which can easily make it a derived work.
    > --
    > Ciao,
    > Pascal

    Statement of the problem:

    A company makes a new device that could run under Linux.
    This device uses some standard gate-arrays. Because of
    this, some gate-array bits need to be loaded upon startup.

    The company knows that if the competition learns that a
    gate-array was used, instead of an ASIC, the competition
    could clone the whole device in a few weeks, thereby
    stealing a few million dollars of development effort.
    In fact, the thieves don't even need to buy an initial
    board to copy. They just need the GPL source-code of
    the driver.

    The thieves need only to get a copy of the bits and
    the device type of the gate-array. They then have
    the entire design at-hand without ever doing any
    Engineering at all. This will give the thieves an
    unfair marketing advantage, allowing them to sell
    the device at a cheaper amount and still make money.

    For Linux to be more widely accepted by the hardware
    community, there needs to be some way of protecting
    the investment that the hardware companies have made.
    They need to be able to hide the implementation details
    from the competition. For this, they currently need to
    link their GPL module-code against some secret code
    that is not released to the general public.

    Unfortunately, any code that can execute in the kernel
    can throughly corrupt other kernel code. This has led
    some to create the "Tainted" advice, etc. It may be
    possible to work around the bug-reporting problem if
    the module is not a disk-interface module or a screen-
    interface module. Just remove the module, verify the
    bug still exists, then submit a report. However, many
    modules can't be removed and still have a running
    system. Therefore the "Tainted" fix doesn't work.

    So, instead of arguing, forever, about what's GPL
    and what's not GPL, it would be real nice if the same
    amount of effort was expended towards fixing the
    basic problem.

    The basic problem is that, in many cases, a hardware
    vendor cannot divulge the inner workings of his hardware.
    Even if the hardware vendor wanted to be a "nice guy"
    and let everybody know how his board worked, if the
    company was being publically-traded, the stock-holders
    could (read would) sue and whomever released the information
    could (read would) be found guilty of stealing or
    divulging trade-secrets.

    So, let's figure out how to protect the inner workings
    of the kernel while, at the same time, protecting a
    hardware vendor's engineering investment.

    Dick Johnson
    Penguin : Linux version 2.4.22 on an i686 machine (797.90 BogoMips).
    Note 96.31% of all statistics are fiction.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

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