Fedora Freedom and linux-libre

Les Mikesell lesmikesell at gmail.com
Mon Jun 16 00:26:22 UTC 2008

David Woodhouse wrote:
> On Sun, 2008-06-15 at 17:13 -0500, Les Mikesell wrote:
>> Do do have an exact definition of what is not permitted? 
> I pasted a precise definition of 'collective work' already, didn't I?

That is unrelated to the question.

> It is a work in which a number of separate and independent works are
> assembled into one work.
> The very definition of 'collective work' is that it is an aggregation of
> other independent and separate works.

And aggregations are explicitly permitted which makes that discussion 

> In order to create a collective work, you need the permission of the
> copyright-holders of each of the constituent parts. If any _one_ of them
> denies you that permission, then you may not distribute that collective
> work.

And this part applies equally to every line of code and data.  Having 
source or not doesn't change the requirement for permission to 
distribute - or give anyone more or less reason to question whether that 
permission has been given.

> As you know, the GPL makes an exception for 'mere aggregation on a
> volume of a storage or distribution medium'. There is some scope for
> debate on precisely what is covered by that exception, but not a huge
> amount.

So the relevant discussion should be about whether there is a person 
that can identify the separate parts.

> I've been talking generically so far. Getting back to the particular
> case of firmware and kernel drivers... these are claimed by the network
> driver maintainer to be "intimately tied" "pieces of a coherent whole".
> I really cannot see how that claim by an expert in the field can be
> reconciled with a claim that the presence of the firmware is 'mere
> aggregation on a volume of a storage medium'.

You could resolve that question by finding someone who can identify the 
separate parts.

> But it's not particularly well-phrased, so there is a grey area, and no
> definitive 'right' answer until/unless it's been heard in court. There
> are only 'likely' answers.

And at least in the US, copyright is a matter of civil law so it won't 
go to court unless the holder of the copyright that is violated takes it 

> When you distribute the firmware blobs as separate works, of _course_
> the GPL doesn't apply to them.
> But when you distribute those same blobs as part of a whole which is a
> work based on the GPL'd Program, the distribution of the whole must be
> on the terms of the GPL, whose permissions for other licensees extend to
> the entire whole, and thus to each and every part, regardless of who
> wrote it.

Unless they consist of separate parts that have been aggregated together...

But, I think you are the one missing the point at least from the 
perspective of the FSF or anyone likely to take legal action on behalf 
of the GPL.  They claim that it doesn't matter if the components are 
distributed separately or not.  For example, you can't modify a GPL'd 
component so that it needs a library under different terms even if the 
parts are never distributed together.

> Thus, it is not the intent of the GPL to claim rights or contest
> your rights to work written entirely by you; rather, the intent is to
> exercise the right to control the distribution of derivative or
> collective works based on the Program.

Whether it is a derivative or 'work as a whole' depends on the 
relationship of the parts, not temporary physical proximity.  If the 
compiler keeps the parts separate so the downloading code can identify 
them to download the correct separate data to the correct separate 
device they are rather clearly separate things aggregated temporarily 
within a file.  This might be more obvious if it were easier for a human 
to identify the parts, but that's a mechanical detail.  The question of 
whether the relationship of the runtime code makes it a derived work 
might still remain, but it is unrelated to the bits of code and data 
having been aggregated as permitted.

   Les Mikesell
    lesmikesell at gmail.com

More information about the devel mailing list