Glenn Maynard wrote:
>On Thu, Apr 14, 2005 at 09:18:46AM -0300, Humberto Massa >wrote: > >>> Then all the people who think that creating a binary >>>kernel module requires creating a derivative work and hence >>>can be restricted by the GPL are wrong. Take that argument >>>up with them. >> >>I took. Google my name on lkml and you'll see. They ARE >>wrong. Linus himself studied carefully the situation and >>came to the conclusion they are wrong, > > >"Linus himself" is, as far as I understand, a programmer, not >a lawyer.
So am I (altough I *am* a para, after all). This does not preclude him from being right, does it?
>His opinion and study of this topic has no more weight on >this issue than any other "armchair lawyer", and far less >than Eben Moglen, for instance. > >(I'm not claiming he's right or wrong--just that it's not >useful to cite "Linus himself" as a source about legal issues >just because he's a well- known programmer.)
I wasn't. I was simply stating that me -- as a programmer, too, but mainly as a paralegal, after doing some research on the subject -- shared his views on this.
>The FSF FAQ says that *all* software linking against GPL >libraries must GPL-compatible[1]. [2] contradicts the above >even more directly.
Yeah, but the GPL does not. And that is the problem. If the GPL specifically stated "any works that does link, either dynamically or not, to the Program are to be considered a work based on the Program for the effects of this license", this would be substantiated. but it's not.
>Now, it's possible that they're wrong;
I'm glad you admit that. I admit I can be wrong, too, but I sincerely don't think so.
>there's the obvious theory, for example, that they've long >since realized this, but have no way of fixing it without >admitting to a "loophole" in the GPL.
I think the latest "GPLv2 or later" debates, started by rumors of the contents of the GPLv3, mostly proves that they can't fix it at all :-) At least, not without creating (a) a license that is incompatible with the GPLv2 or (b) a license that is substitutable by the GPLv2, and hence, that adds no additional restriction, so it can't add restrictions about linking.
>I've seen lots of these "derivative work" arguments (and >others, such as whether the GPL is a contract), and have >never seen a reply from the FSF addressing them; given their >potential severity, that at least raises an eyebrow.
The "at least raises an eyebrow", in my personal opinion, is translated by "yeah, they are agreeing that this is a loophole, and the best they can do is shut up about it."
>Of course, I've never raised these with them personally, >since I'm not even qualified to tell which arguments have >enough grounding in reality to avoid wasting their time, and >I don't know whether anyone else has; so I don't place too >much weight in that particular theory. (I don't believe >they're unaware of the arguments, though, and dispelling >misconceptions about the GPL is entirely in their interest, >so I'd expect to see responses to these things.)
The most relevant "response" to this theory IMHO is the lack of response, that occurred when Linus (as "project manager" of sorts IRT the kernel) made his statement almost two years ago that he did not consider kernel modules as derivative works *in* *principle*. It's reasonable to assume that if someone (especially EM) tought he was completely off his marker, this someone would have called attention to the subject.
>>If you make a kernel module that only uses something >>EXPORT_SYMBOL()'d from the kernel, you are NOT in principle >>writing a derivative work. If you use EXPORT_SYMBOL_GPL()'d >>symbols, then you are incurring in (b) above and your kernel >>module is most certainly a derivative work. > > >The notion that what is a derivative work changes based on >whether a symbol was declared with EXPORT_SYMBOL or >EXPORT_SYMBOL_GPL seems fundamentally absurd to me.
But not to me. I consider EXPORT_SYMBOL vs. EXPORT_SYMBOL_GPL as specific permissions to use symbols respectively in *any* module, or in *GPL-only* modules. The existence, purpose, and even the implementation of those two macros construe each use of them as a special documentation about the "intimacy" of the kernel modules with the *implementation* of the kernel internals, in a way that would help determine (by filtration, abstraction, comparison) if a kernel module is a derivative work of the kernel (and hence subject to GPL terms).
>(If somebody is reimplementing the Linux kernel API, he might >just as easily reimplement the "EXPORT_SYMBOL_GPL" symbols, >for compatibility with drivers that need them, for example.)
This is not really true. To reimplment GPL'd symbols without (potentially) infringing on the kernel copyright, you would have to "clean-room" such implementation, which is not really easy when everybody that touched a kernel-x.y.z.tar.gz is 'dirty' :-)
HTH, Massa
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]