[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: kernel firmware status

On Tue, Apr 05, 2005 at 06:06:34PM -0400, Andres Salomon wrote:
> I created a wiki page that contains a list of all drivers that are
> currently considered undistributable by Debian, the available license
> information we have for them, and various other comments:
> http://wiki.debian.net/?KernelFirmwareLicensing
> I would appreciate feedback from d-l about the various firmware blobs that
> *do* contain licensing.  Remember that the goal is to distribute the
> firmware in non-free, embedded in the drivers themselves; however,
> separate from the main kernel tree.

Also, as i got a response from broadcom about the tg3 driver, and it was noted
to me that the text i proposed :

  This program, except the firmware binary code,  is free software; you can
  redistribute it and/or modify it under the terms of the GNU General Public
  License as published by the Free Software Foundation, located in the file
  Distribution, either as is or modified syntactically to adapt to the
  layout of the surrounding GPLed code is allowed, provided this copyright 
  notice is acompanying it.

Which i put there only as an example and asked them to consult their legal
department, was not a good one, i am now asking the help of debian-legal to
word a nice licencing text which we can then propose to all copyright holders
of proprietary firmware, and even maybe propose to the kernel folk as sample
for future firmware licencing policy.

As i understand this, the firmware has to be distributable in binary format,
as part of an otherwise GPLed file. 

Additional requirement are that the binary blob content is not modifiable, but
the form it takes in the actual GPLed files source code should be (like adding
spaces or other syntactic modifications). As for distribution, it should be
distribuable by most things, not just inside the kernel tree, or inside the
manufacturers driver, as is the case for the keyspan usb driver, and should
allow us to move the module in question inside a separate package in non-free.

Notice that if we are pushing through with this, we should probably think
about a future splitting of our non-free area into a part which is non-free
because of not containing the sources, and a part which is non-free because it
has some distribution constraints, and draft a
non-free-but-distributable-guideline kind of document.

Thanks for your help, and i believe in the past few days this issue has been
making nice progres, and will hopefully be solved to everyone's satisfaction.


Sven Luther

Reply to: