From alsa-devel-owner@alsa.jcu.cz  Sun Mar  7 23:50:52 1999
Received: from sunu450.rz.ruhr-uni-bochum.de (sunu450.rz.ruhr-uni-bochum.de [134.147.222.33])
	by marvin.jcu.cz (8.9.1a/8.9.1) with SMTP id XAA21505
	for <alsa-devel@alsa.jcu.cz>; Sun, 7 Mar 1999 23:50:03 +0100
Received: (qmail 27061 invoked from network); 7 Mar 1999 22:50:01 -0000
Received: from dialppp-1-166.rz.ruhr-uni-bochum.de (HELO localhost) (mail@134.147.1.166)
  by mailhost.rz.ruhr-uni-bochum.de with SMTP; 7 Mar 1999 22:50:01 -0000
Received: from brinkmds by localhost with local (Exim 2.11 #1 (Debian))
	id 10JlLP-0006Hm-00; Sun, 7 Mar 1999 22:44:19 +0100
Message-ID: <19990307224419.B24079@ruhr-uni-bochum.de>
Date: Sun, 7 Mar 1999 22:44:19 +0100
From: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>
To: alsa-devel@alsa.jcu.cz
Cc: rms@gnu.org
Subject: Re: ALSA Soundcard Vendor Information
References: <19990307202853.G22312@ruhr-uni-bochum.de> <m10JjtA-000TL6C@nurock.kek.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <m10JjtA-000TL6C@nurock.kek.jp>; from sharkey@ale.physics.sunysb.edu on Mon, Mar 08, 1999 at 05:11:04AM +0900
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

Hi,

RMS: What is your position about firmware and hardware drivers?

On Mon, Mar 08, 1999 at 05:11:04AM +0900, sharkey@ale.physics.sunysb.edu wrote:
> > Note that if you include Firmware in the Alsa distribution, it will be
> > difficult for me to comply to the GPL when distributing ALsa, because I
> > can't copy the source of the firmware, as the GPL requests. So non-free
> > Firmware should probably be distributed and made available outside of Alsa.
> > 
> > (I have experienced with such issue, as I'm a distribution builder. In
> > Debian, this was the very reason why KDE couldn't be shipped, for example).
> 
> I don't think this is a fair comparison.  KDE links to QT.  That's pretty
> different than ALSA distributing firmware, IMO.

Before we continue, we should probably note two things. First, the GPL does
not make any difference between the type and purpose of the software. It
speaks in general terms of "derived work", and "software as a whole". If an
Alsa driver does not work at all without the Firmware, isn't it reasonable
to call both together a work as a whole? Maybe, maybe not. I am no lawyer.
But if the driver calls parts of the firmware directly, I think this is
similar to linking. You write:
 
> When you link a library to an application, the code for that library becomes
> part of that application.  You can trace through the code of KDE with a
> debugger and say at any point in the execution that the code being executed
> is either in the KDE part or in the QT part but the execution will flip back
> and forth repeatedly.  The execution of KDE is inextricably intertwined with
> QT.
>
> But firmware is quite different.  It isn't linked in with ALSA.  ALSA runs
> on the system CPU(s) and is completely independent from any firmware.  The
> firmware runs only on the sound card not the system.  I've always felt that
> firmware is more like hardware than software.  But I guess that's why they
> call it firmware, it isn't really either.

Maybe I don't know enough about hardware and firmware. If you have a
general firmware loader, and the firmware as a seperate data file, I agree
that the firmware loader itself is free software. I would still not bundle
the firmware data together with Alsa, but your mileage may vary.
It gives me a headache to think about it if the driver and the firmware are
completely independent works. :)

Maybe you can explain how firmware is working exactly?

> So I don't see why there should be a conflict.  If all the code in ALSA is
> GPL, but we include a separately licensed binary file which could be used to
> flash some eeprom on the card or something like that, then there's no conflict
> of licenses the way there was with KDE, because there's no linking involved.

It is certainly a grey zone. I would still prefer if only DFSG free Firmware
is distributed along Alsa (in the same tar file), but I have no vote in this
issue. But I could never say "take Alsa, it's completely free", because I
had always to add: "except the firmware, which is unfortunately in the same
file".

> As a whole, ALSA might then fail to meet the DFSG.  I don't think that would
> stop the inclusion of ALSA into Debian, though.  It should be a trivial job
> to separtate ALSA into to packages.  The main component, alsa.deb, and the
> optional non-free component, alsa-nonfree.deb.

Sure, this can be done. It will be a bit harder to do it, and the drivers
which depend on the firmware would have to be in the contrib section of
Debian, but it is certainly possible.

Practically, there is little problem. But you have a choice in this issue,
because you can send a message. If you say, "non-free Firmware stays outside
of the distribution", you send the message that you prefer open specs and
open firmware. Otherwise, you accept that parts of the hardware details are
just closed.

I don't want to judge this. Firmware is better then ROM chips which can't be
updated at all, and as long as the hardware specs needed for a good driver
are open, I have no moral problems using firmware (I still use a non-free
BIOS, too).

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org   finger brinkmd@ 
Marcus Brinkmann              GNU    http://www.gnu.org     master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de                        for public  PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/       PGP Key ID 36E7CD09

