12 May
2004
12 May
'04
2:50 p.m.
At Wed, 12 May 2004 12:16:37 +0200,
Alessandro Rubini - FSFE wrote:
Sorry for the delay; we, as FSFE, as currently involved in the patent
issue and other ones, and time is always too little.
I write as FSFE member, after checking with other members, although we
don't have an official position about the firmware issue, yet.
Andrea Glorioso originally wrote:
IMO, the only concern about saying "it's a part of hardware" is that
you can redistribute the firmware while you cannot do the hardware.
this is the basic difference between hardware and software.
My personal position is one of being a bit
more pragmatic. A large
part of the hardware we use actually has firmware embedded into it,
the only difference being that we don't see it and we don't need to
upload it
Takashi Iwai summarized:
1. is the firmware binary is a program or a
data?
2. can we force the h/w vendor to show the source code under GPL (if
exists) in practice?
3. if not, shouldn't we change the license to the non-restrictive one?
which license would be feasible?
so far, alsa-firmware package is released from the understanding of 1
as "data". but if someone insists it as program, yes, it can be a
problem.
Andrea again:
I might be wrong, but my guess is that if a piece
of data is
absolutely necessary for a GNU GPL program to work, then that data
should be distributed together with the program at the same
conditions of the GNU GPL (otherwise the GNU GPL itself could be
very easily bypassed).
Fernando Pablo Lopez-Lezcano:
I tend to look at it (very conveniently, of
course) as neither. I view
it as part of the hardware device we're dealing with. Without it the
device does not work. It is distributed as a separate file (inside the
driver disk that actually comes with the device) because it is
convenient for the manufacturer for updates, avoiding a flash rom in the
device, and so on and so forth.
Most probably very few people will agree with this viewpoint :-)
Actually, I tend to agree with this view. But it's not easily supported
outside of programmers' circles, so I'd leave it alone. In my opinion we should treat firmware as data as far
as the driver is
concerned. That's similar to how emacs-lisp is data when loaded into OOo,
and my own software is just data for the routers that bring it to my
clients. [no example matches perfectly, they are exemplifications not
demonstrations]
Actually, a number of my drivers include plain binary arrays in the
source files, and those arrays are just stored into register sets to
bring the device up in a known and default state. The binary firmware
is no different in the context of the GPL'd code.
I don't buy the objection that "such binary blurb is software in
another context", since in the context of the GPL driver it is not.
Sure it is a work subject to copyright, but it is a different work;
saying that we need source to that in order to fulfill the GPL doesn't
look sensible to me [sure it would be _great_ to have that source, but
it's another issue altogether].
In my opinion, what is relevant as far as the GPL is concerned, is
that the author of such binary blurb allows it to be modified at will
in the form relevant to our free driver (i.e., data). I can change
such data, so the GPL is satisfied (and my hardware won't work any
more). It is the same with register default values: you can change
them if you want your hardware to not work, and you don't ask for
their source. The preferred form of modification for binary data is a
binary editor or a text editor over the hex representation, no problem
here.
fully agreed.
This isn't a loophole of the GPL: if someone
writes a GPL'd kernel
module that executes its own data, then _that_ module is not compliant
to its own license, since such data is actually code in disguise, and
is integral to the driver according to copyright law (they are one
work, acting as a driver).
But with firmware, the GPL'd work is the driver, not the internals of
the hardware. So binary or hex is the preferred form of modification
for such data. What's important is being able to duplicate, study and
port the driver to other operating systems, not being able to study
the firmware to port it to other audio cards.
yes, the execution of the given data is a key point.
imagine that you give an example MIDI file to your application
released under GPL.
MIDI is a data, but it's also a kind of program, too -- it's the list
of pattern sequences to drive the MIDI devices with the programmed
timing. then, must the source of this MIDI file be provided as human
readable?
--
Takashi Iwai <tiwai(a)suse.de> ALSA Developer - www.alsa-project.org