Re: broadcom proposed firmware licence, please comment ...
Sven Luther wrote:
> The text of the new licence proposal is as follows :
>
> > +/* xxx.h: Broadcom tg3 network driver.
> > + *
> > + * Copyright (c) 2004, 2005 Broadcom Corporation
> > + *
> > + * This program 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, except as noted below.
> > + *
> > + * This file contains firmware data derived from proprietary unpublished
> > + * source code, Copyright (c) 2004, 2005 Broadcom Corporation.
> > + *
> > + * Permission is hereby granted for the distribution of this firmware
data
> > + * in hexadecimal or equivalent format, provided this copyright notice is
> > + * accompanying it.
> > + */
>
> I would have liked a clear identification of the firmware blob, but i guess
> that to anyone familiar with C, it is immediately evident what is the
firmware
> blob and what is normal code.
>
> So, before i reply to them, i would like to have feedback from debian-legal,
> and we can then move ahead and upload this driver to the non-free part of
our
> archive, including a working .udeb.
Great! This license is totally distributable. I'm not sure, unfortunately,
what counts as "equivalent" to hexadecimal. I think that's the only problem.
If it was just "permission to distribute, unmodified, in any form", it would
be clear.
Before you move the whole driver to non-free, you should know that I have made
a version of the driver which loads the firmware from files if it is
available (many tg3 users don't *need* the firmware), and I believe that is
the one currently in Debian's kernel tree. I have also designed a package
containing appropriate firmware files for this version of the driver. The
only reason I have not published the package yet is that it was under this
legal cloud.
The package generates the firmware files as arch-independent binary files
(with a specified endianness) by writing out the hex in a really
simple-minded way. (Each lump of hex has a length and a lump in the C file,
and I just write the the length and the lump out binary, in a defined order.)
If this binary form counts as "equivalent", then I have a package for you :-),
and I just have to fix it up to generate a udeb (and get a sponsor). If the
binary form doesn't, we can rewrite the kernel driver to actually parse hex,
but that seems a bit silly to me. They seem equivalent to me. I suspect
they're meant to be equivalent, because the compiled version of the stock
kernel contains binary rather than hex, and they want it to be possible to
distribute that. Do we need clarification here?
In any case, I believe we do not need to move the whole driver to non-free in
this case, just the firmware. Remember that this one works for many cards
without the firmware, so people will certainly appreciate that.
--Nathanael Nerode
Reply to: