Re: How long is it acceptable to leave *undistributable* files in the kernel package?
@ 18/06/2004 09:56 : wrote Brian Thomas Sniffen :
>mdpoole@troilus.org writes:
>
>>Brian Thomas Sniffen <bts@alum.mit.edu> writes:
>>
>>>Michael Poole <mdpoole@troilus.org> 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.
$ debuild
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
work.
>>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
is.
--
br,M
Reply to: