Re: Draft position statement of AGNULA on ALSA firmware

[Alessandro Rubini - FSFE <rubini@fsfeurope.org>]

[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