Alexandre Oliva wrote:
If it's silly, then you shouldn't have any problem showing where it is
executed as part of "the Program",
Execution is irrelevant, because copyright law doesn't apply to this
act.
Does that mean you disagree with the FSF claim that it is not
permitted to distribute non-GPL'd software that dynamically links to
unique libraries only available under the GPL?
I agree that the GPL doesn't grant permission for the distribution of
such derived works under terms others than those specified in the GPL.
OK, then the relevant question becomes whether the kernel or the
firmware is a derived work, not whether they are distributed together or
not.
And the GPL's 'work as a whole' concept
I don't know what you're talking about. "work as a whole" appears
only once in the license, and there 'work' is not a verb, but rather
part of the "modified work" phrase.
Once is enough - and it is the definitive requirement:
"These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program, and
can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works."
The question is, does taking some code and an opaque binary blob and
sticking them in the same file make a 'work as a whole' or is it
identifiable sections of code and separate data that are not derived
from the Program?
It is *distributed* as part of the program, and that's what copyright
law restricts by default.
Which is irrelevant if you have permission to distribute all parts.
If they form a coherent whole to the point of being regarded by a
court, according to copyright law, as a derived/collective work, then
it is relevant. And then, this is not the case we're talking about
here.
How is it different? The question is whether firmware and microcode are
part of the kernel 'work as a whole', which, I don't think depends on
how they are distributed at all.
We're talking of a case in which one part became an integral,
essential and inseparable part from the other, so the distinction is
definitely no longer irrelevant, because it's a different case.
Are you sure that the opaque blob of firmware can't be replaced by any
other opaque blob of bits without affecting the other part? In which
case it's just aggregated and along for the ride.
I don't see how you can say it is inseparable when the firmware
downloader understands the separation perfectly
You got your facts wrong, I'm afraid. The code in question doesn't
even use the firmware downloader. It absolutely requires the code to
be part of the source code.
Would the code continue to work if you replace those bits with something
else that would work in the hardware it loads?
it's a part of the program since it gets
installed on different hardware - except maybe for the CPU microcode.
So, when you use say Google Docs, just because some part of the
program is shipped to your computer while another keeps on running on
Google's servers, they're not part of the same program named "Google
Docs"?
I wouldn't assume that. But why not stick to the CPU microcode example?
I think it is the purest form of the issue in question.
Just because a program uses Java RMI to transfer classes from one
process to another (that may be running on a different machine), the
classes are not part of that program?
Unless it is covered by the GPL with the 'work as a whole' restriction,
the question doesn't make much sense, since a program can otherwise have
any number of components under different licenses running together. And
in the GPL case, I haven't seen even the FSF try to claim that things
running on other machines or connected via pipes or sockets are covered
parts of a 'work as a whole'.
Do you even have an argument here, or are you just saying it, to fill
in the void? :-)
I would like to see a definitive answer to delimit the 'work as a whole'
where the GPL restrictions of any component apply, particularly in cases
like microcode downloads and how shared libs would differ from code in
ROM or firmware in flash. I think your interpretation is wrong, and
mine might be - but I suppose we aren't going to get one.
--
Les Mikesell
lesmikesell@xxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
