Fedora Freedom and linux-libre

Les Mikesell lesmikesell at gmail.com
Mon Jun 9 16:36:59 UTC 2008


David Woodhouse wrote:
> On Sun, 2008-06-08 at 17:29 -0500, Les Mikesell wrote:
>> Do you mean the part about identifiable sections that are not derived 
>> from the program and can be reasonably considered independent and 
>> separate works?  That would seem the only possible interpretation for 
>> firmware blobs.
> 
> Exactly that part, yes. Where it says that the GPL applies to them
> anyway.

Can you quote that?  My copies all say it doesn't.

> Specifically, the bit where where it says that the GPL (obviously)
> doesn't "apply to those sections when you distribute them as separate
> works. But when you distribute those _same_ sections as part of a whole
> which is a work based on the Program, the distribution of the whole must
> be on the terms of this License, whose permissions to other licensees
> extend to the entire whole, and thus to each and every part regardless
> of who wrote it."

Firmware that happens to be aggregated for convenient delivery and 
installation is no more a part of the GPL'd work than firmware that is 
already in your machine or than it would be if someone sent you a 
handful of new ROMs to plug in, or if you had a separate pre-run 
initialization program that downloaded all these separate components and 
registry initializers.

> I agree with you that that seems to be the only possible interpretation
> for firmware blobs.

Aggregation is the only possible interpretation since it is just a 
delivery mechanism for something no more related than ROM contents would 
be.

> And when we take them and include them in the
> bzImage and distribute that, the only possible interpretation is that
> they are 'part of a whole which is a work based on the Program'.

No, _how_ you aggregate something is irrelevant.  You are talking about 
file formats and containers here.

> You do get an exception for 'mere aggregation on a volume of a storage
> or distribution medium', which covers stuff like shareware/freeware CDs
> on the covers of magazines -- so unrelated stuff which happens to be
> shipped together in _that_ form doesn't get infected by the GPL.

Form has nothing to do with it - the terms apply to the content, not the 
intermediate storage.

> But it's extremely hard to argue that combining non-GPL'd firmware into
> the kernel image is 'mere aggregation on a volume of a storage or
> distribution medium'.

It is exactly as much a part of the kernel as firmware that is already 
in ROM is - that is, not at all.

> I know some people like to conveniently abbreviate that to 'mere
> aggregation' -- since "mere" doesn't really mean much, so then they like
> to claim it actually excuses _all_ forms of aggregation, effectively
> cancelling out the previous two paragraphs of the GPL in their entirety.

No, the GPL applies to components that actually are parts of a work as 
whole or derivatives.  Firmware is something separate, just carried 
along for the ride.  It could clearly be already present in ROM or 
pre-loaded by something other than the kernel.

> I don't find that interpretation particularly realistic, though --
> although nobody is right or wrong about it until/unless a court rules on
> it, of course.

Exactly - until a court says that the file format used to carry a 
separate component is relevant, it is just as much a separate entity as 
equivalent ROM contents.

> To claim that there is no _legal_ basis for such a restriction is also
> incorrect. Nothing but the GPL gives you the right to distribute the
> Linux kernel. If the GPL has conditions with which you fail to comply,
> then you may not distribute the Linux kernel.

I'm not sure why you'd consider being unable to distribute the Linux 
kernel to be a desirable thing, but the point here is that the GPL 
explicitly allows aggregation and nothing in copyright law or any court 
decisions that I've heard of have excluded bzImage or any other specific 
file formats as delivery containers for such aggregation.

-- 
   Les Mikesell
    lesmikesell at gmail.com




More information about the devel mailing list