[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How long is it acceptable to leave *undistributable* files in the kernel package?

Brian Thomas Sniffen writes:

> mdpoole@troilus.org 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


Reply to: