Fedora Freedom and linux-libre

Alexandre Oliva aoliva at redhat.com
Sat Jun 14 00:09:02 UTC 2008


On Jun  9, 2008, Les Mikesell <lesmikesell at gmail.com> 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}




More information about the fedora-devel-list mailing list