@ 18/06/2004 09:56 : wrote Brian Thomas Sniffen : >[EMAIL PROTECTED] writes: > >>Brian Thomas Sniffen <[EMAIL PROTECTED]> writes: >> >>>Michael Poole <[EMAIL PROTECTED]> 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
