[sorry, I messed the headers in the previous message, so I repost after
cancelling the pending messages to [EMAIL PROTECTED] and linux-audio-dev]
[after exchanging a few personal messages with Andrea, we decided I
should post here, although I already raised my points in the discussion
that led to this draft. Now I notice a "reply-to" set to users@ in the
original message, so I might have lost most discussion. I keep all the
Cc: list as Andrea suggested]
[while writing this message, I found another, bigger, issue. It is
about being able to distribute the package at all; I didn't talk with Andrea
about this since just found it today]
> To make a long story short, the final position I'm proposing is that
> AGNULA *should* distribute such firmware, but should carefully explain
> why it's doing it and how it thinks that this is not the optimal
> solution.
I agree wholeheartedly with this. Unfortunately I disagree with the
actual reasoning (and mine is not the optimal solution, either).
> (2) The second question is whether such firmware is "software" (i.e. a
> computer program) or "data". The distinction between the two is
> very, very blurry. The position of AGNULA is that the firmware we
> are discussing about can be actually considered software (i.e. a
> computer program) in the sense that it is interpreted by a piece
> of hardware to execute some operations.
However, such a piece of hardware is not a general-purpose computer.
More importantly, it is not the target of the AGNULA distribution (or
any distribution as we intend it). Therefore, while agreeing that
there no sharp line between code and data, I think firmware is rather
data than code.
Simply stated, the host computer (the scope of the distribution)
treats it as "rw-" not "rwx". Or I could note that the files that are
unchanged when the distribution is ported to another platform are
data, not code.
Now, I am well aware that _in_another_context_ such data my be
executable. But our focus is a distribution of free software for the
PowerPC (or Sparc or ARM or, possibly, the awful IA32 legacy). It's not
a distribution of free software for audio DSP's or microcontrollers.
> (3) The third question is, given that we consider firmware as
> software, what is the "preferred form for modification" of such
> firmware. The wording we use is not random: it's the way the GNU
> GPL license defines the "source code" of a program.
I didn't understand the question here. I would rather ask whether such
stuff is free software, first. So I got the package [1] and
checked. Actually, every README in the data directories of
alsa-firmware-1.0.4 states:
This directory contains the firmware data files for ***
Copyright (c) ***
Distributable under GPL.
[So, if you trust the upstream, this is data]
I think your position statement should state that the GPL is attached
to each firmware file, otherwise point (3) above is puzzling -- I
personally wouldn't have expected the individual files to be GPL'd,
just the package as a whole.
So, the issue of the "preferred form of modification" applies, just
like it applies to a PDF document released according to the GNU GPL.
> Now, if the "preferred form for modification" of said firmware is
> editing the hex codes themselves, then we are actually distributing
> the source together with the program.
>
> Unfortunately, we are quite convinced (based on our personal
> experience, and on us being overly cautious) that the "preferred form
> for modification" of such firmware is not hacking on hexadecimal
> values; we think the firmware is the result of some higher-level
> language being compiled into the resulting "blob" (no more and no less
> than what happens with "ordinary" computer programs).
Yes, most likely. Even if there was no assembler for such DSP's,
binary data in source form is thoroughly commented. As an example, see
the "jmpi" instruction in AS86 code found in
linux-2.2/arch/i386/boot/setup.S, line 670 or so: 11 lines of source
for 8 bytes of binary code.
> Given (1), (2) and (3) we conclude that the firmware we are discussing
> about can't actually be considered Free Software.
I disagree. The issue here is worse. Such stuff is most likely not
distributable at all. That's because the only license applied to the
files is the GPL, but the original distributor didn't satisfy the
conditions. If the license is invalid, there is no license at all.
This is the new thing I found today, and I think it can only be solved
by the ALSA team talking with the hardware companies. So I'll ignore
it by now and will turn back to the other reasoning, based on the
assumption the binary blobs are distributable with a "do whatever you
want" license, or even just a "verbatim copying" one.
> (4) without such firmware, most professional-grade sound cards won't
> work;
That's a typical problem.
> (5) the Free Software community, and AGNULA specifically, has not
> gained enough momentum in the audio field to be able to convince
> any major sound card manufacturer that it should release the
> source code of its firmware (supposing (3) is true, of course)
> lest AGNULA won't distribute such firmware inside A/DeMuDi,
This is typical too. Actually, I can't find really convincing reasons
why they should really GPL the firmware, or realease sorce in any
form. They are usually very unwilling to release anything related to
the inner workings of the hardware.
> (6) the unwillingness by AGNULA to distribute such firmware would
> actually *damage* Free Software
This is typical too.
> (7) we feel that providing a downloader for such firmware would be a
> hypocritical stance - "we don't give you X, but we give you an
> easy way to get X". We don't see the point in acting this way.
Agreed.
> the AGNULA project has decided that it *will* distribute the
> alsa-firmware package in the next releases of its AGNULA/DeMuDi
> distribution.
Unfortunately, points (4), (5), (6) and (7) above are so oh so common
nowadays. If you make an exception like this, you are opening yourself
to arbitrarily choose to include other non-free packages in the core
distribution, according to whether or not the weight of these points
is strong enough. While I appreciate you are not applying them to
Java _today_, I can foresee the same points applied to a CAD package,
to VHDL compilers, to audio/video CODECs and so on.
I think this one is a slippery slope, and I'd better not enter it.
But if we start by separating code from data, and we consider that
firmware is data (again, let's ignore the explicit-GPL issue), the path
to accept alsa-firmware in the distribution is less dangerous:
- without such data most professional-grade sound cards won't work;
- the right to change such data is not really important as it most
likely will make the hardware unuseful. Also, the data is not useful
other than on the sound card it comes with;
- accepting non-free data has been done in the past without great
damage to the freedom of the distribution as a whole (e.g., RFC
documents and some icons including the debian swirl).
Now, this is as suboptimal as it can be (we all would like to get
source and associated rights on those files), but it doesn't open the
path to accept non-free packages that execute on the host processor.
------------------------------------
More details about my initial interpretation of the issue.
Let's assume the firmware binary blob is included in a GPL package,
without an explicit license attached to the firmware file. Sometimes
it is within a C source file, in hex; sometimes in a separate file.
In this case, I think the reasoning is more straightforward: the GPL
applies to the package as a whole: the blob in that specific context
is just opaque data, even if _in_another_context_ it may be code.
This is no different with icons: an icon may have a vector drawing
source somewhere in the world, but in the context of the program
distributing it it is just opaque data, without a GPL violation. This
because the GPL applies to "the Program" (its own words) and not to
each and every file in isolation.
In my drivers I sometimes have binary blobs; I never wrote drivers for
microprogrammed stuff, so such blobs are just initialization values
for the register arrays of the harware. But, in the context of the
program, there is no difference.
As another example: some computers have the UART designed in FPGA, and
only the flash and ram are accessible when power is applied.
Therefore, the boot loader must first program the FPGA and then
interact through the console. I don't see a big problem with the
boot-loader being GPL, even if it carries inside the binary blob. The
blob in that context is just data; it would be a little overkill to
require the VHDL source code in order to distribute the boot loader at
all.
To put it differently, the work GPL-licensed is the boot loader (or
the driver). The binary blob is a _different_ work, to which the GPL
is not automatically applied because it is brought around by the GPL
work. I'm not going as far as claiming it is "mere aggregation", but
it's not much different than that.
Another example: the MD5 algorithm uses a table derived from the sine
function, but textutils-2.0/lib/md5.c includes a binary blob for that
table, not the source for it. Is that a GPL violation? No, becuase
the GPL covers the "program", not each and every binary blob
[actually the instructions to build the table are included in a
comment, but let's delete that comment for the sake of this reasoning]
Hope my point is clear enough. While acknowledging that it'd be better
to have source for the firmware (and the icons, and the VHDL, and the
sine table), I'd like AGNULA to take the "data and different work"
path rather than the "it's just like other software but we beed it"
one.
The GPL applied specifically to the firmware files is another,
serious, issue.
/alessandro
--
Alessandro Rubini -- Gnu Project, Free Software Foundation Europe
1024/210D0374 AD0A BCC7 31BE AE01 9FD9 38FF E857 F9F7 210D 0374
