Re: Proposal: The DFSG do not require source code for data, including firmware

[Sven Luther <sven.luther@wanadoo.fr>]

On Wed, Aug 23, 2006 at 12:27:07PM +0200, Florian Weimer wrote:
> * Steve Langasek:
> 
> >   - The author's preferred form for modification may require non-free tools
> >     in order to be converted into its final "binary" form; e.g., some
> >     device firmware, videos, and graphics.
> 
> I would prefer if the term "firmware" would be defined or at least
> explained in the GR.  Something like:
> 
>   firmware (data which is sent to attached devices for processing and
>   which is not, directly or indirectly, executed on the host CPU)

Notice that the bios or other firmware used on most machines today is also
refered as firmware. The original definition is, i believe, any kind of code
provided by the vendor of said device, and on which he has full control, so
firmware was non-free by definition originally.

> I'd actually see some restriction with regard to interoperability
> (i.e. some reasonably documented interface between the firmware and
> the driver code), but getting this right is likely not worth the
> effort.

This is a moot point, since the communication protocol between the firmware
and the actual kernel driver is well established, or more precisely, the
driver never speaks with the firmware, but with the device it is uploaded to,
and there is no difference between a driver for a non-firmware peripheral and
a firmware peripheral in this sense.

> It seems the present language also covers CA certificates, which is
> fine.
> 
> A completely different issue is whether we take upstream's word for
> GPL compability, or if we claim that something is not redistributable
> because it contains a firmware blob *and* is licensed under the GPL as
> a whole.

Well, there are two issues here :

  1) we should always ask for a relicencing in a not-GPL like licence for
  firmware lacking source. It is almost always the case that there is indeed
  such a upper source (even a banal C code or shell script which transforms
  the register dump in hexdump), and in any case we should thus suppose by
  default that the firmware is not the prefered form of modification.

  2) given that the copyright holder is the one distributing the files under a
  messed up licencing, and that he is the only one who could sue us over it,
  the risk that he actually does so is pretty much limited, as is the risk
  that he actually wins in court if he where to do it. Other linux copyright
  holder have no right to sue, because the firmware in question consitutes a
  distinct agregated work just being transported inside the kernel, not a
  derivative work.

Friendly,

Sven Luther