Re: How long is it acceptable to leave *undistributable* files in the kernel package?
@ 18/06/2004 09:56 : wrote Brian Thomas Sniffen :
>>Brian Thomas Sniffen <firstname.lastname@example.org> writes:
>>>Michael Poole <email@example.com> writes:
>>>>I expect that if a contributor has an uncommon interpretation of
>>>>the license requirements, he should check.
>>>I suspect that few people think a GPL'd installer of Microsoft
>>>Word would be compliant with the GPL. That's a reasonable
>>>analogy, right? A hardcoded string, copied to some device which
>>>runs it, and maybe with some additional setup.
>>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.
Yes, it is mere aggregation. It's not the fact that there are one or
two disk files that decide if the thing is aggregation or not...
it's the transformations (non-mechanical) that are needed to join
the stuff together (none!)
$ cat /windows/MSWord.MSI | to_cstring >> msword.c
is a mechanical process.
is a mechanical process.
You selecting MSWord, deciding how to dispose its files to be
installed, and aggregating it to your installer is an anthology
>>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. 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.
This is where you are wrong, you know. A derivative work does not
cease to be a derivative work when 'clipped out'. The definition of
a derivative work is related to *HOW* you got here, not *WHAT* it