| |||||||||||||
|
| |||||||||||||
Avoiding copyright violation with closed source modulesAvoiding copyright violation with closed source modulesPosted Jan 5, 2007 9:51 UTC (Fri) by kleptog (subscriber, #1183)In reply to: Avoiding copyright violation with closed source modules by giraffedata Parent article: Looking forward to 2007
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.
(Log in to post comments)
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).
|
|
||||||||||||