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: Takashi Iwai summarized: Andrea again: Fernando Pablo Lopez-Lezcano: Actually, I tend to agree with this view. But it's not easily supported outside of programmers' circles, so I'd leave it alone.

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.

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.