| |||||||||||||
|
| |||||||||||||
Looking forward to 2007Looking forward to 2007Posted Jan 5, 2007 4:18 UTC (Fri) by iabervon (subscriber, #722)In reply to: Looking forward to 2007 by giraffedata Parent article: Looking forward to 2007
The "purpose" of a work is not relevant to copyright law at all. The aspect of a work as being useful at all only matters to trade secrets and patents. From the point of view of copyright law, the module is a product of creativity which may be have been created using the information in the kernel (i.e., if you're calling functions from the kernel, your choice of code is due to looking at the kernel). If the module only calls functions from some API that the vendor made up from scratch, it's not a derived work of the kernel, even if the only way the module could be made to run with code that has been written is by using the kernel, because the fact that it runs at all is merely incidental.
The reason to use FreeBSD's driver API would be that the module would then clearly not be a derived work of the Linux kernel, in that it would be completely intuitive to have written the module having never seen the Linux kernel, since the choices could clearly be motivated by the FreeBSD kernel.
(Log in to post comments)
Avoiding copyright violation with closed source modules Posted Jan 5, 2007 8:27 UTC (Fri) by giraffedata (subscriber, #1954) [Link] The definition of derivative work, in the US at least, is quite hazy and as applied to computer code is basically up for grabs. But one of the arguments I see applying it to Linux modules makes usefulness quite relevant. It says a module is a derivative work of Linux because it is based on Linux in that its entire reason for existing is to be part of Linux -- it's an integral part of an expanded Linux. People with this view say the code being useful in multiple environments is therefore a litmus test.But looking at your definition, where seeing and getting information from the Linux source code is the key, I don't see the distinction between the Linux-specific isolation module and the FreeBSD interface. In fact, you don't even need the isolation module; you can just have someone describe the Linux interface in prose and write your closed source driver without ever having seen Linux source code. And one other thing about the isolation module: Don't the smart closed source drivers already do that? There's a better reason than legal for it: it lets people adapt your driver to myriad variations of Linux base kernel that you couldn't practically keep up with yourself.
Avoiding copyright violation with closed source modules Posted Jan 5, 2007 9:48 UTC (Fri) by jschrod (subscriber, #1646) [Link] It has been reported several times, the "smart closed source device drivers" like Nvidia's use isolation modules (shims) because their proprietary binary part is not Linux-specific but is designed to work on other x86 operating systems (most important, Windows) as well. The open source part maps the Linux API to the proprietary Nvidia API. (See, e.g, http://lwn.net/Articles/206435/)
If that's true, the legality of Nvidia's kernel module is not a settled thing, as it can be argued with good reasons that it's not derived code. Therefore, I would not hold my breath that someone sues Nvidia, it would be hard to make that a good case law.
Joachim
Avoiding copyright violation with closed source modules Posted Jan 5, 2007 9:51 UTC (Fri) by kleptog (subscriber, #1183) [Link] The other argument I've heard relates not to the source, but to the compiled binary. The point being that you compile the module, you need the kernel source. And the resulting binary object is a derived work of both the original source and linux kernel headers.
It's at least true that strings that only appear in the kernel headers end up in the final binary object, but is that enough to make it a derived work? If the Linux kernel headers are GPL, is the resulting module distributable?
That's why shim modules are safe, because the actual module no longer needs the linux kernel source, but the shim module which does can be under a licence compatable with both the linux kernel and the actual module.
Avoiding copyright violation with closed source modules Posted Jan 5, 2007 19:31 UTC (Fri) by giraffedata (subscriber, #1954) [Link] Yeah, the header argument is another one, but not as interesting because it is so easily circumvented: just don't use the distributed header files. Write your own that effect the same interface. One thing that is clear in derived works of software is that when you compile from source, the object code is a derived work of the source. It was decided long ago that this is the same as translating from English to French, which is classic derived work. But insofar as that's a pretty shaky analogy (because of the fact that software is much more than an exposition of ideas -- it's more like a device), I suppose a judge looking further might find that mere declarations (as from a header file) aren't really present in the object code, so the object code isn't a derived work of the header files. And it might be a fair use exception, like how quoting a book is.
Avoiding copyright violation with closed source modules Posted Jan 6, 2007 6:56 UTC (Sat) by roelofs (subscriber, #2599) [Link] I suppose a judge looking further might find that mere declarations (as from a header file) aren't really present in the object code, so the object code isn't a derived work of the header files.Or he/she might simply find that the header files aren't copyrightable in the first place, to the extent that what they embody can be expressed in only one way. (I seem to recall a statement, if not a ruling, to that effect in the SCO mess w.r.t. some AT&T errnos or something.) I freely admit that's not very firm ground on which to stand once you include struct definitions in there--although I vaguely recall some further exceptions if said structs (and function interfaces) implement a public API? Anyway, IANAL, so don't mind me... Greg
Avoiding copyright violation with closed source modules Posted Jan 6, 2007 14:02 UTC (Sat) by kleptog (subscriber, #1183) [Link] If a header file only consisted of declarations, maybe. But the linux kernel header files are stacked with inline functions and macros, whose code will be copied to the final object. These functions and macros may contain references to strings, which will also be copied verbatim to the final object. There are also inline assembly blocks.
Now, if someone went through the header files and removed all but the parts that are just declarations or trivial macros that could only be written one way, you'd probably be fine.
But I think a blanket statement that all header files are uncopyrightable is I think going a bit far. It's trivial to disprove (move all your code to the header file, and include it). As far as the C compiler is concerned, there are no header files, that's the preprocessors job.
Avoiding copyright violation with closed source modules Posted Jan 7, 2007 21:14 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link] one interesting tidbit from the SCO/IBM lawsuit that I noticed recently
Moreover, the term "derivative work" is defined by federal copyright law, and one work must be "substantially similar" to a preexisting work properly to be considered a "derivative work". (Ex. 181 ΒΆ12.) The mere fact that a product contains some licensed source code from another product does not make the product a "derivative work" of the other.
http://www.groklaw.net/article.php?story=20061222212643457
if this is correct mearly including some code may not be enough
Avoiding copyright violation with closed source modules Posted Jan 8, 2007 1:16 UTC (Mon) by giraffedata (subscriber, #1954) [Link] Well, the header file argument isn't that including the header files makes the binary device driver a derivative work of the kernel. It's that the binary device driver contains within it a derivative work of the header files, in the sense that object code is a derivative work of source code. So if you distribute the entire binary driver, you're distributing the header file object code and the copyright owner of the header files gets to control it. But the header file argument isn't what most people use anyway; they use the derivative work argument from the top of this thread which doesn't involve use of any literal Linux code at all. SCO's derivative work claim is even more tenuous than the Linux device driver one. It's a William's Axe argument that SCO owns parts of Linux that never had any relation to SCO-owned code. (A museum somewhere in England has in its collection the actual axe used by William The Conqueror in battle, and by many of his successors. It is so old that between the time of William's death and the time it was preserved in the museum, the handle had been replaced 3 times and head 4 times).
|
|
||||||||||||