On Thu, Apr 14, 2005 at 11:02:36AM -0300, Humberto Massa wrote: > So am I (altough I *am* a para, after all). This does not > preclude him from being right, does it?
Nope, as I mentioned. You just seemed to put special weight on his opinion on the topic. > >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. I hold the FSF's legal competence in much higher regard than my own, of course, but I don't put them on a pedestal as an organization. :) > 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. The "GPLv2 or later" debates are a different issue. Changing the license in GPLv3 might be able to fix some problems, to adjust the license due to changed circumstances. However, even if it's completely usable and valid, it doesn't help close *loopholes* in v2, since v2 is still available for all "GPLv2 or later" works, since upgrading to "later" is not mandatory. > 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." Well, I'm a bit slow to take that opinion, just because of its implications: the FSF continues to claim that the GPL applies in these ways, and continues to convince more people to put more code under the GPL based on these claims. Claiming that they know it's false is accusing them of lying, tricking people into using the GPL by deliberately giving them a false understanding of its effects. (My opinion of the FSF dropped significantly during the GFDL debacle, but it's not so low that I'm yet ready to make such claims.) > 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). By your argumentation, it doesn't seem that this is a decision the author of the library (or kernel, or whatever) gets to make, but rather something which is inherent in what's been created; they can offer their own opinion on what constitutes an application's use of the library being "intimate" enough to create a derived work, but have no special authority on the subject. In other words, nothing binding would change if they were to s/EXPORT_SYMBOL/EXPORT_SYMBOL_GPL/. They simply don't have any say in whether my use of their work is a derivative work or not, and these "EXPORT_SYMBOL_GPL" seem like documentation that says "we believe use of these symbols probably means you're creating a derivative work"--the derivative-work-ness is not actually a result of these tags (and the tags might be wrong). -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]