Messages in this thread | | | Date | Mon, 6 Oct 2003 16:08:08 -0400 (EDT) | From | "Richard B. Johnson" <> | Subject | Re: 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.
Cheers, 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |