GPLed firmware flasher ...
Hello all,
Let's paste dissension lie in the paste, i promise to be reasonable in any
further dealying with the people on this list, and apologize for the rudeness
i may have shown in the past, be it justified or not.
I am in the process of writing a new firmware flasher for the pegasos powerpc
motherboard (http://www.pegasosppc.com).
I am also considering putting this tool under the GPL, which would be best and
easy, but there are a certain amount of problems with this approach. But first
a few detailed explanations.
The tool will flash the firmware (like the x86 bios) of the motherboard, and
said firmware contains everything needed to bring the box up and more. The
firmware in question is (still but i am working on it) non-free, as not only
do we not own the original copyright (original code bought from codegen), but
many people have contributed to it and not all would like to open source it,
not counting the NDA problems linked to the programing specs of certain low
level devices, but i guess this is the case for most hardware we all use.
Now, the pegasos is a CHRP machine, and thus uses OpenFirmware, which knows
how to execute an ELF file. My original plan was to produce a project which
could be put in an ELF file together with the firmware in question, and then
simply booted from the OpenFirmware console.
My understanding of this is that neither the firmware constitute a derived
work from the flasher, nor the flasher constitute a derived work of the
firmware. The fact that they are individually packaged in the same elf binary
does not constitute a linking act, nor a derivation/modification act, but mere
aggregation, and is thus not a problem for the GPL.
Is this analysis true ? The GPL says :
0. This License applies to any program or other work which contains
a notice placed by the copyright holder saying it may be distributed
under the terms of this General Public License. The "Program", below,
refers to any such program or work, and a "work based on the Program"
means either the Program or any derivative work under copyright law:
that is to say, a work containing the Program or a portion of it,
either verbatim or with modifications and/or translated into another
language. (Hereinafter, translation is included without limitation in
the term "modification".) Each licensee is addressed as "you".
which seems to me to be saying that to be a derivative work, one of them must
contain code from the other (or use it in the library case), but the firmware
is independent from the flasher and vice-versa.
Is this analysis true and correct ?
That said, the flasher program is itself using the OF methods of the existing
firmware but since it is using the installed version and not the one it is
flashing, one can consider that the OF methods are indeed covered by the GPL
clause 3) exception for stuff normally included in the system, altough one
wonders what happens when running the flasher two times in a row, since then
it will be making calls to the binary firmware it is using. Also having this
flasher with embedded firmware on a CD which is distributed with each board
or machine sold may break the exception to the exception, right ?
The GPL says :
However, as a
special exception, the source code distributed need not include
anything that is normally distributed (in either source or binary
form) with the major components (compiler, kernel, and so on) of the
operating system on which the executable runs, unless that component
itself accompanies the executable.
The FSF GPL FAQ says :
http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLInProprietarySystem
However, in many cases you can distribute the GPL-covered software
alongside your proprietary system. To do this validly, you must make sure that
the free and non-free programs communicate at arms length, that they are not
combined in a way that would make them effectively a single program.
The difference between this and "incorporating" the GPL-covered software
is partly a matter of substance and partly form. The substantive part is this:
if the two programs are combined so that they become effectively two parts of
one program, then you can't treat them as two separate programs. So the GPL
has to cover the whole thing.
If the two programs remain well separated, like the compiler and the
kernel, or like an editor and a shell, then you can treat them as two separate
programs--but you have to do it properly. The issue is simply one of form: how
you describe what you are doing. Why do we care about this? Because we want to
make sure the users clearly understand the free status of the GPL-covered
software in the collection.
If people were to distribute GPL-covered software calling it "part of" a
system that users know is partly proprietary, users might be uncertain of
their rights regarding the GPL-covered software. But if they know that what
they have received is a free program plus another program, side by side, their
rights will be clear.
and :
http://www.fsf.org/licensing/licenses/gpl-faq.html#MereAggregation
Mere aggregation of two programs means putting them side by side on the same
CD-ROM or hard disk. We use this term in the case where they are separate
programs, not parts of a single program. In this case, if one of the
programs is covered by the GPL, it has no effect on the other program.
Combining two modules means connecting them together so that they form a
single larger program. If either part is covered by the GPL, the whole
combination must also be released under the GPL--if you can't, or won't, do
that, you may not combine them.
What constitutes combining two parts into one program? This is a legal
question, which ultimately judges will decide. We believe that a proper
criterion depends both on the mechanism of communication (exec, pipes, rpc,
function calls within a shared address space, etc.) and the semantics of the
communication (what kinds of information are interchanged).
If the modules are included in the same executable file, they are definitely
combined in one program. If modules are designed to run linked together in a
shared address space, that almost surely means combining them into one
program.
By contrast, pipes, sockets and command-line arguments are communication
mechanisms normally used between two separate programs. So when they are
used for communication, the modules normally are separate programs. But if
the semantics of the communication are intimate enough, exchanging complex
internal data structures, that too could be a basis to consider the two
parts as combined into a larger program.
One wonders about the definition of modules, and one can consider that in this
case there is no communication altogether between the the two parts, at least
not when the code is run, and later once the firmware is installed, the
communication method between the two being the IEEE 1275 standard, so there is
no surprises.
Additionally, the flasher program, or rather the flasher .o, which can be
linked with a firmware object and produce a flasheable ELF file can easily
enough be distributed in debian/main, and if it contains the firmware, it
could be distributed in non-free if the licence on the firmware allowed it.
Not that it would really make sense, since distribution is better done on the
manufacturers web server, but still.
Friendly,
Sven Luther
Reply to: