Brian Thomas Sniffen writes:
> [EMAIL PROTECTED] writes:
>>
>> The installer can be GPLed, sure. Why shouldn't it be? You will
>> likely run into other copyright issues because you do not have
>> permission to redistribute Microsoft Word like that, but it is
>> irrelevant to the GPLness of the installer.
>
> But why do I have permission to distribute the GPL'd installer that
> way (let's say it incorporates Emacs for some reason)? This isn't
> mere aggregation -- it would be if the files were next to each other
> on a CD and otherwise unrelated, but it's clear that there are
> dependencies between them.
Reference, please? It may be clear to you, but it is only clear to me
that the two works are in a compilation. See also the various
commercial games for Linux that use a GPL'ed installer.
>> It is not his interpretation of copyright law, but his interpretation
>> of the license, that is incorrect.
>
> It's a unilateral license. It can't mean anything but what he intends
> it to mean.
Reference, please? That is Alice in Wonderland logic ("Words mean
exactly what I want them to mean, neither more nor less."). I hope
that a license means what is written.
>> Telling him that may not be nice, but nobody suggested the right way
>> to deal with SCO was being nice to them, either. If someone insists
>> that his copyright is being infringed, we should stop distributing
>> *his* code. It is not fair to other parties that his complaints
>> should cause the removal of their code.
>
> I think the UW is the right comparison, not SCO -- who are incorrect
> in their understanding of the law. But I, and others here, are
> persuaded by the arguments that non-free firmware in the kernel is
> unacceptable.
It is unacceptable to Debian; while I disagree with Debian's policy,
that is not the issue here. Linus and other kernel maintainers have a
different policy on what is appropriate, and I am defending the
legality of that choice.
> I'm further persuaded by the arguments that
> GPL-incompatible firmware in the kernel is unacceptable, and a
> violation of the license under which Debian distributes most of the
> kernel source. I see code written to load that firmware specifically,
> with curlicues and features designed to work with that
> GPL-incompatible code. That says to be pretty strongly that the
> kernel containing the firmware is a derivative work of the firmware.
> Sure, you can clip the firmware out and use it separately, and that's
> not derivative of the kernel -- but I don't think that's important.
How does that work? If the firmware is shipped separately from the
kernel, the kernel still depends on the features and behavior of the
firmware. I do not think that is sufficient to establish the kernel
as a derivative work of the firmware. Why is there a difference in
derivative work status with respect to how the firmware is
distributed? There is an obvious difference in compilation or
collective work status, but I do not see how the legal definition of
derivative work[1] is affected by distribution method.
[1]- http://www4.law.cornell.edu/uscode/17/101.html
Michael
