[Agnula-Developers] Re: [linux-audio-dev] Request to audio

[Takashi Iwai]

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:
> > 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.

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.


> 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 at suse.de>		ALSA Developer - www.alsa-project.org