Fedora Freedom and linux-libre

Alexandre Oliva aoliva at redhat.com
Sat Jun 14 19:13:56 UTC 2008


On Jun 14, 2008, Les Mikesell <lesmikesell at gmail.com> wrote:

> Alexandre Oliva wrote:

>>>> The other is, is the kernel separate from the device's firmware?

>>> That's a different question, unrelated to how that firmware got into
>>> the device.

>> I know.  I don't understand why you insist on this irrelevant point.

> Because I think it is the only relevent point. It is only if the
> combined works form a derivative work that restrictions can apply to
> the combination differently than the components and whether a
> derivative work is formed does not depend on how the components were
> distribtuted.

There are various possibilities here, let me summarize the ones that
occur to me, in no particular order:

a. one work is a derivative from the other, and they are distributed
   together

b. one work is a derivative from the other, and they are distributed
   separately

c. two unrelated works are distributed separately

d. two works are combined into a single coherent work, undoubtedly a
   derivative from both, regardless of whether the two works were
   originally related, and then the derivative work is distributed

e. two unrelated works are distributed together by mere aggregation in
   a single volume of storage or distribution medium

If I understood your argument correctly, you appear to be proposing
that, because cases such as (a-c) exist, the case at hand can't be
(d), so it must be (e).  I don't see how this conclusion can follow
from the premises.  Please clue me in?

>> Execution is not what this is about.  The GPL says running the program
>> is not restricted, and by this it acknowledges that copyright does not
>> restrict that.  I'm talking about distribution.

> It's about a derived work - which the FSF says is the same regardless
> of the way the parts are distributed.

Err...  I thought you didn't agree it was a derived work.  If you
agree that it is, then the terms of the GPL are clear, and there's no
reason for us to be holding this discussion.

>> 1. The GPL doesn't establish restrictions.

> If the GPL didn't establish restrictions, it would only be a grant to
> use, copy, and redistribute.

And that's pretty much what it is.  And I say pretty much, rather than
exactly, because 'use' needs no grant, and it also grants permissions
to modify and distribute the modified versions.

But the permissions are not unconstrained.  It's like, if you come to
my (hypothetical) house, the bathroom downstairs is being used by
another guest and you need to use a bathroom.  So I tell you: "yo may
go upstairs and use the bathroom to your right".  That I permitted you
to go upstairs to use the bathroom doesn't grant you permission to go
wandering into my bedroom.  Now if there is a law that says "you can't
go into a person's bedroom without her permission", you broke the law.
What the GPL states are not prohibitions, they're merely describing in
detail the granted permissions.

This may be easier to explain and understand under Brazilian copyright
law, where 'distribution' and 'publishing' require separate
permissions.  So a license could easily grant permission for the one
without granting permission for the other without any traces of
conditions: it would just say "I grant you permission to publish this
work".  Now, under other jurisdictions, the license would have to say
"I grant you permission to distribute this work, but only if it is
exposed in public places and offered under non-discriminatory pricing
to any interested party" (or whatever the precise distinction between
distribution and publication under Brazilian law is).

So, if there was a word used in copyright law that stood for
"distributing without denying others the permissions your were
granted", let's say "freestribute", then the GPL could just say
"you're granted permission to freestribute this program".  You'd still
be subject to all the restrictions of copyright law as to (other forms
of) distribution, and there wouldn't be any such mislabeled
restriction in the license.

Wherever the GPL says "you may not" rather than "you may", it's
clarifying provisions of copyright law, rather than imposing
restrictions of its own.  Go figure.

> But it is not about how it is distributed.  It is whether it becomes a
> derived work.

Indeed.  It may be a derived work even it's distributed separately.  I
wouldn't argue against that.  But since it's distributed together,
discussing the case of its being distributed separately is irrelevant,
isn't it?

> But they included the head files which were verbatim copies of the
> original values.  How do you establish that one set of values are OK
> but others aren't?

I don't.  Copyright law and court law do, AFAIK.  And the rules don't
always make sense when they're presented under a certain light.  For
example, numbers aren't copyrightable, right?  But anything stored in
digital form is ultimately a number.  Can we conclude from this that
nothing digital is copyrightable, and go about copying CDs, DVDs and
software without any regard to copyright law?

Likewise, the firmwares slipped into the kernel are "just numbers".
But it's not the numbers per se that are copyrighted.  It's the
meaning, the expression.  Now, if you can't understand them, are they
still subject to copyright?  If the fact that you can't understand
them means they're not a form that enables one to make modifications
to it (let alone the preferred form for making modifications to it),
could it be redistributed under the GPL?

>>> We know the GPL imposes restrictions.

>> We don't.  You think you do, but you're mistaken.  Go read the GPL
>> again.

> I'm not mistaken. Everything in there except the conditional grant to
> use, modify, distribute is a restriction.

Like what?  Tell me *anything* you could do in the absence of the GPL,
that, by accepting the GPL, you can no longer do.  That's what
'restriction' means, no?  If the GPL lets you do something, but you
cannot do other things because you're subject to other restrictions
stemming from say copyright law, that's not a restriction from the
GPL, it's a restriction from the law.

> Go read a less restricted license to see the difference.

You mean more permissive licenses, I suppose.  Yup, they do exist.
They grant you more permissions, removing more of the restrictions
imposed by copyright law.  How does this related with the claim that
there's any restriction in the GPL?

> divisive nature of the GPL.

Another fallacy.  "You can redistribute under the same license"
doesn't divide, it has quite the opposite effect.  It's permitting
redistribution under any licenses that may lead to forks, including
ones that don't permit further modifications.

> If the combination is interpreted as a derived work, it doesn't matter
> if they are distributed together or not.

Agreed.

> You still wouldn't be able to distribute them separately with the
> intent to recombine them.

Hopefully a court would see it that way, yes.

> If you could, you would be able to add a component to a GPL'd work
> that links to a commercial library that the end user is expected to
> obtain separately.

But you can do that already, as long as the commercial library is
licensed under a GPL-compatible license.  Or did you mean to imply
that I'm not going to get my next pay check, and that the ones that
preceded it are just a figment of my imagination? :-)

Make that s/commercial/proprietary/, pretty please.  Don't feed the
FUD machine.

>> And then, we're not talking about mere aggregation.  We're talking
>> about a combination in which at least one of the works had to be
>> modified to make room for the other, and that, if you take out the
>> other, it goes kaboom.

> Yes, this part is the same even if the firmware is loaded by something
> else or already exists in ROM.

This would sound like a reasonable argument, if the kernel were
modified in such a way that it was indeed indifferent to it.  And
then, it might be the case that it's still found to be a derived work,
and so that it can't be distributed under the GPL.  Well, too bad.
But the law is the law.

>> For modification, copyright law requires
>> permission.  So, yes, copyright law does restrict acts of aggregation
>> that are not mere aggregation.  (And the distribution of the result,
>> be it mere aggregation or any other form of collective or derivative
>> work.)

> But whether it is aggregation or not doesn't depend on the container
> or packaging for distribution - it is a separate concept.

Now you lost me.  Can you try to rephrase the point you're trying to
make here in relation with my paragraph above, perhaps using other
words and more sentences?  As in, what is this separate concept of
'aggregation' you're talking about, and how does it compare with 'mere
aggregation in a volume of storage or distribution media'?

-- 
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