Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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
Reply to: