freed_symbols [Re: People, not GPL [was: Re: Driver Model]]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
On Mon, 06 Oct 2003 20:50:12 +0200, you wrote in linux.kernel:
Quoted 3 lines
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.
Signature · 2 lines
Ciao, Pascal
Correct, this is why most device drivers ARE derived from the kernel and must be GPL'd.
however it is possible to write a device driver independantly and then interface it with the kernel without making it a derived work.
David Lang
Quoted 33 lines · Pascal Schmidt
Date: Mon, 6 Oct 2003 20:56:25 +0200
From: Pascal Schmidt <[email protected]>
To: Larry McVoy <[email protected]>
Cc: [email protected]
Subject: Re:freed_symbols[Re: People, not GPL [was: Re: Driver Model]]On Mon, 06 Oct 2003 20:50:12 +0200, you wrote in linux.kernel:
Quoted 3 lines
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Signature · 3 lines
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan
Quoted 14 lines · Pascal Schmidt
On Mon, 06 Oct 2003 20:50:12 +0200, you wrote in linux.kernel:
Quoted 3 lines
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.
Quoted 7 lines
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.
Hi!
Quoted 8 lines
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.
Since when is creating compatible hw called stealing?! If this was such a big problem, nothing prevents you from putting ROM with those magic bits... How much is that? _5?
Signature · 2 lines
Pavel Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...
Quoted 6 lines · Pavel Machek
Hi!
Quoted 4 lines
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.
Quoted 7 lines
Quoted 4 lines
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.
Since when is creating compatible hw called stealing?!
When the "compatible" device is a copy.
Quoted 3 lines
If this was such a big problem, nothing prevents you from putting ROM with those magic bits... How much is that? _5?
Yes it does. Market pressure. The ROM may cost US$0.50. During the lifetime of the product, that may mean over a million dollars in lost profit. And, if you were a stockholder, you would not like that. Or, if you were an employee who lost his job because the company couldn't quite make up the cost of your salary. Every dime saved in the production cost of a high-volume product means several jobs saved.
Quoted 4 lines
--
Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...
Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.
Richard, I asked the list TWICE nicely to stop this thread.
THIS MEANS YOU TOO!
If you post one more time in this thread, I am going to remove you.
Quoted 3 lines · Richard B. Johnson
Quoted 1 line
Since when is creating compatible hw called stealing?!
When the "compatible" device is a copy.
The gate-array or other binary-only firmware that is distributed alongside an open source driver is not covered by an open source license.
(We may argue about the merits of that, but it is the de facto situation).
So you, as the owner of the firmware, have _strong_ copyright protection against that firmware being used inappropriately. That's the legal protection.
As for technical protection, if a clone product could make "a million dollars", the cost of extracting firmware from a closed source driver is trivial in comparison. It takes a skilled coder minutes or hours; nothing compared to the difficulty of making a clone board.
Contrarily, if you and the cloner are doing it all closed source, you are not likely to know your firmware has been copied. OTOH if it's the norm to produce open source drivers, you can inspect your competition's code to see if they ripped your firmware. (They have to release open source too, if it's the norm, because that's what's demanded).
The real issue is that when generic chips being used, some h/w manufacturers aren't really making hardware. They're putting a few widely available chips together, and offering a design. In effect they are becoming software companies, and we already see how the economics of that are changing world-wide.
Quoted 4 lines
Quoted 3 lines
If this was such a big problem, nothing prevents you from putting ROM with those magic bits... How much is that? _5?
Quoted 8 lines
Yes it does. Market pressure. The ROM may cost US$0.50. During the lifetime of the product, that may mean over a million dollars in lost profit. And, if you were a stockholder, you would not like that. Or, if you were an employee who lost his job because the company couldn't quite make up the cost of your salary. Every dime saved in the production cost of a high-volume product means several jobs saved.
It is relative; the million isn't important, if you made a billion from the product. It's far more important to asses how the $0.50 affects your margin. On a device costing $15 to manufacture, it depends on whether you are selling the device to the reseller for $16 or $50.
-- Jamie
Quoted 9 lines · Pavel Machek
Quoted 8 lines
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.
Quoted 4 lines
Since when is creating compatible hw called stealing?! If this was such a big problem, nothing prevents you from putting ROM with those magic bits... How much is that? _5?
Large modern gate arrays use encrypted bitstreams, and even when not encrypted are very hard to reverse engineer, so that's not the problem. It's possible, but very expensive.
Small gate arrays use non-volatile programming anyway.
The problem is blatant copying of the bitstream.
This is trivial whether it's in ROM or not, for anyone capable of making a device, so gate-array firmware is *no excuse* for keeping the driver code obscured, not even a _5 excuse.
-- Jamie
Jamie, you're on the shit list too, stop posting in this thread or you'll be removed from the lists.
Thank you.
Quoted 2 lines · David S. Miller
Jamie, you're on the shit list too, stop posting in this thread or you'll be removed from the lists.
Sorry Dave, I didn't see your warning about this thread.
-- Jamie
Quoted 6 lines · Pascal Schmidt
On Mon, 06 Oct 2003 20:50:12 +0200, you wrote in linux.kernel:
Quoted 3 lines
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.
Quoted 7 lines
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.
You can look all you want, just can not touch.
Simiar to the red light district in Holland, it costs alot to do more than look throught the glass.
Quoted 3 lines
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.
No it can not, by only using the headers as the functional API for that snapshot verson of the kernel release, it is the standard means for functionality. If the macro is require for any driver and or one in the kernel to function, and is listed in the headers, it is generally deemed to part of the unportected API.
Again it is very simple declare, all modules which are not GPL and reject loading, and we can watch the death of linux as nobody will use it. Again who cares, because it started out as fun for a Finn in 1991, and should never be of use or value outside of academics.
All of the code monkeys here need to be equally exploited by all. Some of the best marketing pitchs to date for some of the big companies who claim to be linux friends, their slogans translated:
Use our hardware with Linux, there are a lot of suckers out there with talnet who will gladly help you with your support issues. This reduces our support costs because we cans send you to join the rest of the monkeys, Pinocchio.
Harsh and reality suck, but I could not believe this is what is being pitched at trade shows.
Later ...
Andre
Quoted 7 lines · Andre Hedrick
Use our hardware with Linux, there are a lot of suckers out there with talnet who will gladly help you with your support issues. This reduces our support costs because we cans send you to join the rest of the monkeys, Pinocchio.
Harsh and reality suck, but I could not believe this is what is being pitched at trade shows.
It is hardly surprising as plenty of Linux advocates have drawn attention to the availability of community support. That's one of the purposes of Free Software. It's considered a feature! (Even if we are suckers ;)
-- Jamie
Quoted 3 lines · Andre Hedrick
No it can not, by only using the headers as the functional API for that snapshot verson of the kernel release, it is the standard means for functionality.
Well, I don't see "standard means for functionality" mentioned anywhere in the GPL or copyright law (though I'm no expert on that).
If a header contains a macro that expands to real code and a module has to use that, it means that it absolutely needs that part of kernel source code to function and then it is a derived work because it includes GPL'ed code and would not work without it.
Quoted 3 lines
If the macro is require for any driver and or one in the kernel to function, and is listed in the headers, it is generally deemed to part of the unportected API.
Says who? Who defines what is unprotected API and what is not?
Quoted 4 lines
Again it is very simple declare, all modules which are not GPL and reject loading, and we can watch the death of linux as nobody will use it. Again who cares, because it started out as fun for a Finn in 1991, and should never be of use or value outside of academics.
Well, silly me, I only buy hardware with open source drivers available. I wouldn't agree that something is good and has to be done just because it would improve Linux' "success" (I wouldn't define that to be commercial success, either).
Signature · 2 lines
Ciao, Pascal
Quoted 8 lines · Pascal Schmidt
Quoted 3 lines · Andre Hedrick
No it can not, by only using the headers as the functional API for that snapshot verson of the kernel release, it is the standard means for functionality.
Well, I don't see "standard means for functionality" mentioned anywhere in the GPL or copyright law (though I'm no expert on that).
You should pay a lawyer and learn something then.
Quoted 4 lines
If a header contains a macro that expands to real code and a module has to use that, it means that it absolutely needs that part of kernel source code to function and then it is a derived work because it includes GPL'ed code and would not work without it.
Sorry but usage of headers the functional api is an unprotectable work. To follow up on the point of boundaries, it is abstract interface to properly work as a driver in the given space.
Alternative view, using the MS DDK and the associated headers for running in MicroSoft. Because a driver uses MicroSoft Headers, does it make it a derived work belonging to MicroSoft?
Quoted 5 lines
Quoted 3 lines
If the macro is require for any driver and or one in the kernel to function, and is listed in the headers, it is generally deemed to part of the unportected API.
Says who? Who defines what is unprotected API and what is not?
US Copyright and courts the rest of the pathetic world is lame and brain dead and even follows our stupidity with DMCA laws also.
<see flame bait, above>
Lawyers who make up the meaning of the laws. You should really decide to spend some money to get an expensive education. $10,000 USD or Euro should be enough to rudely open your eyes to how the courts operate. Copyright law is so strange and painful.
I know it was an expensive lesson for me to start writing checks to lawyers, but less costly than making mistakes based on ignorance.
Quoted 9 lines
Quoted 4 lines
Again it is very simple declare, all modules which are not GPL and reject loading, and we can watch the death of linux as nobody will use it. Again who cares, because it started out as fun for a Finn in 1991, and should never be of use or value outside of academics.
Well, silly me, I only buy hardware with open source drivers available. I wouldn't agree that something is good and has to be done just because it would improve Linux' "success" (I wouldn't define that to be commercial success, either).
Does tongue in cheek mean anything?
Cheers,
Andre
PS one day I will figure out how to enable the spell check in pine, sigh.