| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
Avoiding copyright violation with closed source modules
Avoiding copyright violation with closed source modules
Posted Jan 6, 2007 14:02 UTC (Sat) by kleptog (subscriber, #1183)In reply to: Avoiding copyright violation with closed source modules by roelofs
Parent article: Looking forward to 2007
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.
(Log in to post comments)
Avoiding copyright violation with closed source modules
Posted Jan 7, 2007 21:14 UTC (Sun) by dlang (subscriber, #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).