Shaul Karl <[EMAIL PROTECTED]> writes: > What do you mean by `make sure that whatever your module does makes > sense out of the context of the Linux kernel'? > I guess that once I will get that sentence I will be able to understand > why it is difficult to satisfy in the case of hardware drivers.
The whole notion of a "derivative product" that is central to GPL is about (crudely speaking) "is this merely a feature/extension/fix/whatever of this GPLed program or is it a separate piece of software that has a right to exist and does/can do something non-trivial and useful outside of the context of this GPLed program." I would suggest you try to read GPL and what is written about it (search the archives - I posted on the subject before, including some URLs) to try to understand what this central notion of a derivative product is. If it still does not make sense, ask me nicely enough and I *might try* to dig up some notes I made and hopefully _they_ will make some sense. I'll try to illustrate this idea using the following example. AFAIK, (correct me if I am wrong - I just prefer to use something well-known for an example rather than describing the issues that I encountered in my own work, where a need arose to write proprietary kernel modules) CheckPoint's firewall - which is proprietary technology, of course - on Linux works as a kernel module. If you ask a purely legal question about whether or not this is permitted by GPL, one important consideration in determining whether or not this module is a "derivative" of Linux is whether or not CheckPoint's firewall "makes sense" outside of the context of Linux. The answer should be "yes" - the beast can be (and is) used with systems other than Linux, and the particular implementation as a kernel module (thus linked to the GPLed kernel) is just making this product work on Linux. This is not the whole argument, but it's one part of the whole argument why this is legal. Caveat emptor: IANAL, I just tried to understand the issues as well as I could and talked to lawyers at length in the process. Any misunderstandings and misinterpretations are mine, not the lawyers'. Also, please don't ask me to post the full transcripts of my communications with lawyers on the subject: it cost my employer a pretty penny and constitutes valuable intellectual property (in the sense of please do you own homework) - not mine, either. What I wrote above, including the specific example of CP-FW (I never checked myself whether it was indeed implemented as a kernel module, hence the "correct me" qualifier above - iptables/ipchains are modules, of course), is arguably general knowledge (or my interpretation of it) rather than a part of that intellectual property. Actually, come to think about it, contrary to what I wrote in the posting that puzzled you, one can argue that a device driver is a piece of software that makes a particular piece of software work, using knowledge of its specific characteristics that are outside of Linux scope. Thus a linux device driver is related to Linux only insofar as it enables the hardware to work with Linux, but the hardware spec it is based on is not Linux-specific, and thus the device driver is not a derivative product of the Linux kernel in this sense, so proprietary drivers are OK. I don't know if this or similar line of reasoning is used anywhere to justify proprietary device drivers, or nobody bothers. The cavaliere attitude along the lines of "Linus doesn't mind" (but are you sure Alan doesn't?) or "Rubbini says it's OK [in "Linux Device Drivers" - OG] so it's OK" (I really heard that given as a clinching argument) seems to prevail. It is shaky in the case of device drivers because, obviously, a driver just makes hardware work under Linux, so in this sense it does not have a right to exist outside of Linux. Which talmudic argument wins the day only a lawyer - or a rabbi, or Moshe Bar - both a talmudic scholar and a law student? - http://interviews.slashdot.org/article.pl?sid=02/06/02/1159242&mode=thread&tid=106 - can determine. I am neither, and maybe the more learned linux-il members (there are certainly quite a few religious ones; are there any lawyers lurking here?) will pity my feeble attempt to argue both sides. Firewall is a much cleaner case, IMHO, because the rules and the algorithms and the corresponding parts of _software_ are arguably broad and independent of Linux. For a device driver, the independent part is hardware, not software (and GPL does not deal with hardware or HW specs). My suggestion to use a "controlled interface layer" goes in the same direction. Keep the core of what you are doing proprietary if needed. If you need it to work inside (linked to) the kernel, do your best to separate whatever is needed to make it work in this particular context (I am not using this word in the software sense here) in a separate module, GPL the latter, and add the permissive clause from the FAQ to its license, so that your proprietary stuff can be legally linked to it. This, together with the hope that whatever you proprietary stuff does has a broader significance (back to the firewall example), probably covers your behind. Whether or not one without the other is enough, and whether your hope from the previous sentence is justified or not will be decided by the lawyers on a case-by-case basis whenever FUD is in the air. That's where you should do your own homework, spend money on a good, smart, technically savvy lawyer, and file the fruits of all that away as part of your company's IP. It is prudent - and considerate of the GPL-using part of the Open Source Community - to do that before lawsuits are filed and trials are conducted. Now, does this make any sense? ;-) -- Oleg Goldshmidt | [EMAIL PROTECTED] "A sense of the fundamental decencies is parceled out unequally at birth." ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
