Fedora Freedom and linux-libre

Les Mikesell lesmikesell at gmail.com
Tue Jun 10 16:31:36 UTC 2008

David Woodhouse wrote:
>> Yes I know that. I'm curious why you think the two independent works are
>> somehow a collective work.
> Because they have been assembled into a collective whole; the bzImage
> file which is distributed and used as a single entity,

They are aggregated together.

>  and which makes
> use of both the firmware and the GPL'd kernel code.

Separately.  The firmware is downloaded to respective devices and is no 
more a part of the kernel than the content of a music file is part of 
the code that plays it.

> Also, in the case of the source code, because they are integrated into
> the kernel source and into its build system, and distributed as
> complementary parts of a coherent whole.

You aggregate something for distribution.  It's not a whole unless the 
components are combined.  And while this may be a fuzzy area for things 
covered by the stock GPL, the version that covers Linux specifically says

>> I can't find a rational way to interpret it otherwise. 
> I do not find it rational to assert that the above-quoted exception
> exempts _all_ collective work from the preceding conditions, purely on
> the basis that it happens to be stored on a 'storage medium'. Such a
> wide-sweeping exemption would effectively render the preceding two
> paragraphs entirely redundant.

No, what exempts it is the fact that they are separate things both in 
their origin and destination.

> When it speaks of 'mere aggregation on a volume of a storage or
> distribution medium', I take that to mean things like free and shareware
> software CDs on the cover of a magazine.

When that was written and for a long time after, there was no GPL'd OS, 
so among other things it meant that commercial unix distributors 
(without which there wouldn't have been any way to run the GPL'd 
code...) could include GPL'd items in their distribution or along with 
other add-on packages.

 >  Not a blanket exemption for
> _any_ work which happens to get stored on something we can call a
> 'storage medium', which would even cover examples like GPL'd programs
> using proprietary libraries.

Not _any_ work - just separate works.

> You effectively seem to be saying "you can do what you like as long as
> you store it on disk", which is not a reasonable interpretation of the
> intent of those sections of the GPL.

No, you can take separate works and put them together as long as they 
remain separate works - as the stuff loaded into a device's firmware is 
separate from the kernel.

>> We get into the world of 'f the program is GPL then the icons are GPL
>> because they are connected with it. Or games where you'd argue the
>> music files magically become GPL
> Again, it would depend on whether the icons, or music files, are
> distributed as part of a collective whole which is a work based on the
> Program. There is no fundamental problem here.

Temporarily aggregating two separate items into one storage container 
doesn't change the fact that they are separate items.

> And nothing "magically becomes GPL". Either it _is_ available under a
> GPL-compatible licence and you are permitted to incorporate it into a
> collective work under the terms of the GPL, or not, and you may not do
> so. There's no magic involved.

Permission to make a collective work is irrelevant to aggregating 
separate things.

>> Take the cases you think are a collective/derivative and the cases you think are
>> not and define a test by which this can be ascertained, then perhaps I can
>> see what you are trying to argue.. 
> As I said, it is a grey area. There is no easy test. We understand what
> a collective work is, of course, and we can see that the GPL explicitly
> spells out its intention to extend to collective works based on the
> Program, and explicitly speaks of its permissions extending to sections
> of a collective work which are independent and separate works in
> themselves, but distributed as part of a collective work.
> The only part which is really subject to interpretation is the part you
> quoted above, where it grants an exception for "mere aggregation on a
> volume of a storage or distribution medium".

Which is, of course, the relevant part.

> You seem to believe that
> this exception applies to _anything_ you can store on a hard drive or in
> memory 

Straw man..  No one said any such thing.

> -- which I don't consider to be at all reasonable because it
> would effectively render the preceding paragraphs of the §2 entirely
> pointless, and is obviously not consistent with the stated intent.

And an irrelevant argument, since this is covered by the copyright 
concepts of derived works.

> I believe that exception is intended for things such as magazine cover
> CDs, carrying a bunch of mostly unrelated software.

Please... try to imagine the time when that was written and think about 
tapes full of commercial software instead.

 > It _might_ even (and
> I suspect we should hope that it does) cover Linux distributions with
> many programs collected together for convenient installation. But when
> it comes to such things as a bzImage file which contains both a driver
> for some hardware _and_ the firmware which drives it, and which will not
> operate on that hardware unless both of those fundamentally intertwined
> parts are present, I do not believe that is covered by the exception.

Where does it say that one file format or another is not a reasonable 
way to aggregate for distribution?

> The test, if a single such test were possible, would probably be
> something along the lines of whether the works in question were really
> just bundled together on a hard drive or CD as if by coincidence, or
> whether they're really interdependent.

Now you are getting somewhere but the answer to any such test won't 
depend on _how_ that firmware got installed.  That is, if the kernel is 
prohibited from being distributed because it depends on firmware, then 
it won't matter whether it carries that content along, or it is already 
there in ROM or preloaded flash.

> It would actually make more sense for me to ask the same question of
> _you_, since your interpretation would seem to be rendering that part of
> the GPL entirely void. Can you tell us under what circumstances you
> believe the GPL _would_ extend to something which is reasonably
> considered an 'independent and separate work in itself', and what _your_
> 'test' would be?

In the past the FSF has claimed that something should be considered a 
derived work and covered by the GPL if it needed a GPL'd library to 
function, even if it was not distributed together.  Since the firmware 
contents are specific to the device and typically function with other 
OS's, I'd think that makes them independent and separate.

>> Now I'd like to get to that state anyway so that firmware is nicely seperate
>> from the kernel sources and it is clearer about licenses and what is what. I'm
>> unconvinced it is neccessary, but I am not a lawyer.
> As I said, there's no real answer to the question of whether it's "mere
> aggregation on a volume of a storage or distribution medium"
> until/unless a court has ruled on it -- and we each seem to think that
> the other's position is irrational.
> But I think we can agree that _until_ there's a ruling, including the
> firmware in the kernel is just a gratuitous risk.

The same risk goes with any GPL covered work.  There's always the chance 
that you'll find some part of it had restrictions that make it 
impossible to distribute the whole.  Being able to read the source 
doesn't make a difference in that respect.

> At least, I'm
> _working_ on making it gratuitous, by removing the _technical_ obstacles
> which have historically made it suboptimal to remove the firmware from
> the kernel -- and when that's done, it'll just be silly for us to
> continue to include it. With the CONFIG_BUILTIN_FIRMWARE config option,
> you _can_ still include arbitrary firmware into your kernel, if you want
> to take that legal risk. But it'll no longer be the default.

It would make the fact that the firmware images are separate items more 
obvious if they were bundled separately from the code that installs 
them, but there's really no difference except in the technique used for 

  Les Mikesell
    lesmikesell at gmail.com

More information about the devel mailing list