On Jun 9, 2008, Les Mikesell <lesmikesell@xxxxxxxxx> wrote: > What I don't understand is why you think there is some requirement in > terms of page boundaries or storage mechanism involved in copyright > separation. I've never seen any such thing. Mainly because typesetting, line- and page-breaking for a specific rendering might very well be regarded as modifications for some kinds of works. Heck, even changing the fonts and their relative sizes may amount to a modification. Similarly, if you remove the firmware from the middle of the sources of a C file where they appear, you have to make further adjustments such that it as much as compiles again. > No, it screams common storage, particularly when you know that it runs > on separate hardware elements and can't possibly be a single work when > it executes. The fact that it runs on something is completely irrelevant. That's what makes it software, but it doesn't change in any way how copyright applies to it (except here in Brazil, as it turns out, because there's a separate copyright-like law for software) >> To be separate works, you'd have to start out by being able to >> point at and obtain both/all the works separately. > Where is that requirement stated? Why should it have to be? Since when does separate mean something other than separate? How could inseparable works be separate independent works? > I believe there there wouldn't be any difference if the identical > content were already in ROM There would. You'd have to modify the GPLed code to cope with this. And you'd need copyright permission to do that. > This might be made more clear if the loader is generalized and the > contents separated so that it is obvious that changes in firmware > contents do not need modifications in the GPL'd mechanism Aha, *now* we're getting somewhere. Yes, the problem is not that the firmware is not a separate work. The problem is that the GPLed code at some point became a derived work from these originally-separate works. And, per the GPL, the whole could only be distributed together under the GPL, but one of the originally-separate works can't be distributed like that. Oops. > It is an aggregation, explicitly permitted by the GPL, It is an aggregation, no doubt. But we disagree as to whether it's the kind of mere aggregation that would make it elligible for the additional permission granted by the GPL for this case. > I don't think that's a sufficient reason for me to want to remove > something, but OK. >> So you remove the firwmare and notice that the kernel won't compile >> any more. What now? > Ignore it, consider it a feature in case you get one of the devices in > question, or ask someone with permission to modify to make the change > for you. Oh, so you do need permission in what you claim to be a separate and independent work, to cope with the absence of another unarguably-separate independent work. Can you see the inconsistency in your position yet? >> Do you get permission to modify the kernel >> (creating a derived work thereof) just because it won't compile after >> you rip off a "separate work"? > If it mattered that much, I'd try to figure out why the removal > affected compilation and supply a compiler-satisfying substitute. Wouldn't that be modification of the source file for which you need permission? Say, you have: # Copyright 2006 Evil Empire, Inc, all rights reserved, # except for the portion between quotes in the assignment to "fw" # below. You have permission to remove that portion, but no other # permission is granted as far as modifying this program goes. # This firmware is Copyright 2004 SFS # It is licensed under the terms of the GUN GLP version 3.14, or any # newer version published by the SFS. # Please see fw.asm for the sources and the complete licensing terms. fw="0xde 0xad 0xbe 0xef 0xe7 0xc0" if test -z "$fw"; then echo you loser, you have just made this completely useless fi ... lots of otherwise-useful code ... What do you make of this? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ¡Sé Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
