From alsa-devel-owner@alsa.jcu.cz  Mon Mar  8 20:22:50 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 UAA17254
	for <alsa-devel@alsa.jcu.cz>; Mon, 8 Mar 1999 20:22:37 +0100
Received: (qmail 15684 invoked from network); 8 Mar 1999 19:22:35 -0000
Received: from dialppp-7-142.rz.ruhr-uni-bochum.de (HELO localhost) (mail@134.147.7.142)
  by mailhost.rz.ruhr-uni-bochum.de with SMTP; 8 Mar 1999 19:22:35 -0000
Received: from brinkmds by localhost with local (Exim 2.11 #1 (Debian))
	id 10K5eY-0000Kc-00; Mon, 8 Mar 1999 20:25:26 +0100
Message-ID: <19990308202526.H391@ruhr-uni-bochum.de>
Date: Mon, 8 Mar 1999 20:25:26 +0100
From: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>
To: alsa-devel@alsa.jcu.cz
Subject: Re: ALSA Soundcard Vendor Information
References: <19990307224419.B24079@ruhr-uni-bochum.de> <m10Jrb0-000sLNC@lbscissors.kek.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <m10Jrb0-000sLNC@lbscissors.kek.jp>; from sharkey@ale.physics.sunysb.edu on Mon, Mar 08, 1999 at 01:24:50PM +0900
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

Hi,

On Mon, Mar 08, 1999 at 01:24:50PM +0900, sharkey@ale.physics.sunysb.edu wrote:
> > 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".
> 
> That's true.  However, if the firmware is patched to resolve some
> incompatibility, does that make it a derived work?

Definitely yes. How could it be something else?

And, I have yet to see a proprietary license which allows patching binaries
and distributing/copying the result. Most copyright licenses explicitely
forbid ANY modification, disassembling etc. The usual stuff.
 
> I mean, if Creative Balls shipped Sound Bleater 2000's last year with buggy
> firmware, and ALSA only works with this year's Sound Bleater, or older
> Sound Bleaters that have been flashed with new firmware, I don't think
> you could call the new firmware a derived work.

It is. And depending on the license of the firmware, you would violate
Creative's copyright if you'd distribute the modified firmware. Ususally it
is already in vioaltion to copy and distribute it unmodified (or to modify
it at all, or to dissassemble it etc).

> Nor would ALSA be a derived
> work of the firmware if it refused to work with the buggy version.

This is something I can agree with. 
 
> > 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.
> 
> ALSA drivers also don't work without hardware.  Is the hardware also included
> in the work?

No, because the copyright only applies to software. (yeah, I know you didn't
mean it serious :)

> :)  Seriously, the designs for nearly all hardware are closed, at
> the most detailed levels.  You can't just etch a new batch of chips for a card
> yourself even if you had the facilities because chip masks are generally not
> published.  If the code is is set in PROM or ROM, then it's not really all
> that different from any of the other chips on the card necessary for its
> function.  If the code is on EEPROM, then it is modifiable, but the basic
> function of the component is the same whether it's on ROM or EEPROM.  The
> legality should change by changing the chip type.

I think you meant "shoud not change", and I think I can agree with this
interpretation.
 
> Most cards have binary firmware installed on EEPROM  or ROM chips, whether or
> not ALSA ships with it.  The code on these chips allow the cards to function
> and at that level ALSA must interact with them, but declaring ALSA non-free
> because can use non-free firmware is like saying Mozilla is non-free because
> you can use it with a IIs web server. 

Nono, please don't misunderstand me. I agree. However, if you ship a special
firmware with Alsa that is not the original one, the situation is somewhat
different. (although I don't want to discuss this hypothetical situation
right now, so we can stay focussed).

> > But if the driver calls parts of the firmware directly, I think this is
> > similar to linking.
> 
> I don't think ALSA can "call" the firmware.  It can pass data to the card,
> and tell the card to execute some function on that data (e.g. "mix audio
> streams") and the firmware could take care of the details of how this card
> does this mixing, but I don't think that could be called a "call".

Ok.

> I think, for practical reasons, the interaction of ALSA with non-free firmware
> must be allowed, because prohibiting that would make nearly all hardware
> incompatible.  If we accept that ALSA can interact with non-free firmware,
> then the only question is if ALSA can also distribute non-free firmware.

Correct. I happen to agree.

[...]
> 
> He goes off on a tangent which is not really relevant to this discussion,
> but his basic point is that the GPL does not prohibit the distribution of
> non-GPL'd data along with GPL'd source.

... as long as both are seperated entities.
 
> Whether ALSA would want to bulk up its distribution with this kind of data
> or not is another question.  I'm not advocating that point one way or the
> other, but I'm pretty sure that it would be legal to do so if it were desired.

Yes. My suggestion is the following:

Consider firmware to be free enough to be distributed along Alsa, if the
following conditions are met.

* The firmware can be copied and distributed unmodified without restriction
(that means, everybody must be able to copy it ((not only card holders)),
and one may take a fee for it - which is important for Linux distributions,
which are often selled for money). [if it is non-commmercial only, it should
be distributed from the ftp site, but not in Alsa tar file, as this will make
life unhappy for a lot of ftp-archive snapshot makers etc]
* The firmware may be disassembled.
* The firmware may be patched with a binary patch, thus forming a derived
  work, which can be distributed under the very terms described here.

These are three simple criterions. If these are inacceptable, Alsa probably
can't make much use of the firmware anyway (if you must not distribute
patched versions, you may still want to make unmoidified version available
on your ftp site). If you must not disassemble it, you can't patch it,
right?

I want to say again that I have no say in this, because I am hardly doing
Alsa development. I am just offering you my advice and discussion.

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

