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 <[EMAIL PROTECTED]> ALSA Developer - www.alsa-project.org