Linux kernel code and the GPL - no peeking allowed
Since I frequently, in fact nearly every week, sometimes more than once a week, lecture folks about the Linux kernel, I often am asked to discuss my opinion about the ramifications of the GPL and their code for use in kernel space.
I won't rehash the usual static linking, loadable module, taining, EXPORT_SYMBOL_GPL stuff. One can read my article on that instead: "Are non-GPL loadable Linux drivers really not a problem?" http://www.linuxdevices.com/articles/AT5041108431.html
But, since I've talked and thought about this a lot of the last several years, the import has finally sunk in that perhaps no one writes a loadable module for Linux with out first looking at some GPL code. They look at examples or they look at the Linux device driver book from O'Reilly or something similar. Given that they have essentially "cut the code into their brain" they will of course, eventually "paste" that code into the module that they develop. How can they sensibly claim that the resulting module is not derived from GPL code?
I would think to be on the safe side that someone needs to *ONLY* see the API definition in order to be able to safely write code that is not derived. The problem is, there is no good API summary. Only example modules and reference material with code snippets that too are probably GPL. Can anyone argue with a straight face that they wrote a driver/module without seeing example code and only an API specification? I think not in this world.
So, I postulate that no one has written a complete module without deriving (some of)it from GPL code.
That brings up the notion of some developer writing some code, that is not a complete module, and only does stuff that did not require the developer to look at GPL code and linking this with other code to make up a module. Perhaps just some novel algorithm. This C file, then could rightly be considered as not derived from GPL code.
If I create a file with only a new subroutine for a new clever way, say, to calculate square root, and I link that file with other code to make a module, do I need to GPL my square root code? This approach, I believe is what some companies do. They don't, for a variety of reasons, GPL all of their module code, just some of it. They then link in their object-only portion when they build a module. Just what I'm talking about. Is this legitimate?
I say yes. For what I think are pragmatic reasons.
1) It allows organizations, that otherwise would/could not, to create drivers for Linux that can be rebuilt and have the important parts looked at and fixed for other kernel versions as one wishes. By my axiom the only code that is not GPL'd in this case is code that cannot be kernel dependent.
2) Linking code in link this is virtually equivalent to just linking in some data. I say it is equivalent because this code has nothing to do with the kernel interface and might just as well be data. This interpretation is an admitted stretch.
If this were not allowed one could, say, just implement an interpreter and have the square root function just be interpreted by this interpreter. Essentially the square root code could just be data in an array. One would not be obliged to GPL the code that produced that data. In fact the data could have been "translated to object code in one's head." Or really, never been in source code at all.
Perhaps I invent a object language : "x0 x1" (hex zero, hex one) means do square root (hex one means the value one), So "x0 x2" would mean do square root of two. Does the program 0x 1x have source code? I think not.
To take this further, what if I am assiduous enough to write a whole module in object code directly. There is no souce code. What must I GPL?
----
This whole argument could be construed to be some kind of reduction of GPL to absurdity. Since one could just write everything in object code one need not GPL anything. I think that would be a silly interpretation. The intent of the GPL is to provide users of software with the ability to modify it according to their own wishes. This should correlate to modify it in the same manner as could the author. If the author spews out the object code from his head - so be it that you must too.
I won't rehash the usual static linking, loadable module, taining, EXPORT_SYMBOL_GPL stuff. One can read my article on that instead: "Are non-GPL loadable Linux drivers really not a problem?" http://www.linuxdevices.com/articles/AT5041108431.html
But, since I've talked and thought about this a lot of the last several years, the import has finally sunk in that perhaps no one writes a loadable module for Linux with out first looking at some GPL code. They look at examples or they look at the Linux device driver book from O'Reilly or something similar. Given that they have essentially "cut the code into their brain" they will of course, eventually "paste" that code into the module that they develop. How can they sensibly claim that the resulting module is not derived from GPL code?
I would think to be on the safe side that someone needs to *ONLY* see the API definition in order to be able to safely write code that is not derived. The problem is, there is no good API summary. Only example modules and reference material with code snippets that too are probably GPL. Can anyone argue with a straight face that they wrote a driver/module without seeing example code and only an API specification? I think not in this world.
So, I postulate that no one has written a complete module without deriving (some of)it from GPL code.
That brings up the notion of some developer writing some code, that is not a complete module, and only does stuff that did not require the developer to look at GPL code and linking this with other code to make up a module. Perhaps just some novel algorithm. This C file, then could rightly be considered as not derived from GPL code.
If I create a file with only a new subroutine for a new clever way, say, to calculate square root, and I link that file with other code to make a module, do I need to GPL my square root code? This approach, I believe is what some companies do. They don't, for a variety of reasons, GPL all of their module code, just some of it. They then link in their object-only portion when they build a module. Just what I'm talking about. Is this legitimate?
I say yes. For what I think are pragmatic reasons.
1) It allows organizations, that otherwise would/could not, to create drivers for Linux that can be rebuilt and have the important parts looked at and fixed for other kernel versions as one wishes. By my axiom the only code that is not GPL'd in this case is code that cannot be kernel dependent.
2) Linking code in link this is virtually equivalent to just linking in some data. I say it is equivalent because this code has nothing to do with the kernel interface and might just as well be data. This interpretation is an admitted stretch.
If this were not allowed one could, say, just implement an interpreter and have the square root function just be interpreted by this interpreter. Essentially the square root code could just be data in an array. One would not be obliged to GPL the code that produced that data. In fact the data could have been "translated to object code in one's head." Or really, never been in source code at all.
Perhaps I invent a object language : "x0 x1" (hex zero, hex one) means do square root (hex one means the value one), So "x0 x2" would mean do square root of two. Does the program 0x 1x have source code? I think not.
To take this further, what if I am assiduous enough to write a whole module in object code directly. There is no souce code. What must I GPL?
----
This whole argument could be construed to be some kind of reduction of GPL to absurdity. Since one could just write everything in object code one need not GPL anything. I think that would be a silly interpretation. The intent of the GPL is to provide users of software with the ability to modify it according to their own wishes. This should correlate to modify it in the same manner as could the author. If the author spews out the object code from his head - so be it that you must too.
posted by Kevin Dankwardt | 4:33 PM
|
0 comments
