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
aggregation.
--
Les Mikesell
lesmikesell@xxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
