|
Home > Archive > Debian Developers > March 2004 > Bug#239952: kernel-source-2.6.4: qla2xxx contains non-free firmware
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Bug#239952: kernel-source-2.6.4: qla2xxx contains non-free firmware
|
|
| Chris Cheney 2004-03-25, 6:45 pm |
| On Thu, Mar 25, 2004 at 07:29:49PM +1100, Herbert Xu wrote:
> On Thu, Mar 25, 2004 at 01:45:22AM +0100, Adrian Bunk wrote:
>
> I presume you're objecting to these firmware on the basis that they
> are being distributed as machine code.
>
> I personally find this attitude to be extreme. However, I have in
> the past removed a number of drivers for exactly this reason at the
> request of other developers.
>
> I would like the opinion of all Debian developers on the general issue
> of firmware in the kernel-source package.
>
> If we do decide to remove them, then we can remove quite a number of
> other drivers for the same reason, I can think of qlogicisp and tg3
> off the top of my head.
>
> I recall that when this issue was first raised with the keyspan drivers,
> some of the people advocating their removal promised to modify the
> drivers so that the firmware could be loaded from userspace (just like how
> the anti-non-free camp promised to host non-free packages), it appears
> that after three years this support still has not materialised.
>
> Perhaps the easiest solution is to move all kernel packages into non-free.
>
> PS I'm deliberately avoiding debian-legal as the inhabitants there tend
> to have views that are not necessarily representative of the project
> as a whole.
For this "binary firmware is not preferred form of source" issue to be
resolved coherently all sources that include binary firmware and all
drivers that include undocumented magic numbers and strings must be
removed since of course undocumented magic numbers and strings are not
preferred form of source either! Hence all or at a least a large amount
of reverse engineered drivers would need to be removed at minimum,
besides the drivers vendors provide with binary firmware. I know the
driver I wrote for the linux kernel uses magic strings which might be
firmware, I don't know, and so its certainly not the preferred form of
source. The company making the product never provided documentation on
the device at all nevermind the source for the supposed firmware.
Chris
| |
| Andrew Suffield 2004-03-25, 7:35 pm |
| On Thu, Mar 25, 2004 at 05:05:45PM -0600, Chris Cheney wrote:
> On Thu, Mar 25, 2004 at 07:29:49PM +1100, Herbert Xu wrote:
>
> For this "binary firmware is not preferred form of source" issue to be
> resolved coherently all sources that include binary firmware and all
> drivers that include undocumented magic numbers and strings must be
> removed since of course undocumented magic numbers and strings are not
> preferred form of source either! Hence all or at a least a large amount
> of reverse engineered drivers would need to be removed at minimum,
> besides the drivers vendors provide with binary firmware. I know the
> driver I wrote for the linux kernel uses magic strings which might be
> firmware, I don't know, and so its certainly not the preferred form of
> source.
Sophistry. It's clearly the form you "preferred" when you were writing
it. The GPL does not require that programs be well-written, it merely
requires a level playing field.
--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ |
`. `' |
`- -><- |
| |
| Chris Cheney 2004-03-25, 9:34 pm |
| On Fri, Mar 26, 2004 at 12:01:14AM +0000, Andrew Suffield wrote:
-snip-
> Sophistry. It's clearly the form you "preferred" when you were writing
> it. The GPL does not require that programs be well-written, it merely
> requires a level playing field.
So binary firmware is ok as long as it was not the vendor that wrote
the driver? Wow isn't that ingenious. :P
Chris
| |
| Chris Cheney 2004-03-25, 9:34 pm |
| On Thu, Mar 25, 2004 at 07:41:07PM -0600, Chris Cheney wrote:
> On Fri, Mar 26, 2004 at 12:01:14AM +0000, Andrew Suffield wrote:
> -snip-
>
> So binary firmware is ok as long as it was not the vendor that wrote
> the driver? Wow isn't that ingenious. :P
Actually a reverse engineered driver with blobs in it is probably
illegal since it is reproducing copyrighted code, I forgot to mention
that earlier. 
BTW - I know of at least one other driver in the linux kernels like
that, the one I wrote: kernel/drivers/usb/media/vicam.ko
Chris
| |
| Marco d'Itri 2004-03-26, 11:20 am |
| On Mar 26, Andrew Suffield <asuffield@debian.org> wrote:
> Sophistry. It's clearly the form you "preferred" when you were writing
> it. The GPL does not require that programs be well-written, it merely
> requires a level playing field.
So it's OK for you if the magic blob which the driver sends to the device
was sniffed from the USB bus?
--
ciao, |
Marco | [5366 vinzQJilUDWWc]
| |
| Nathanael Nerode 2004-03-26, 3:35 pm |
| Chris Cheney wrote:
> On Thu, Mar 25, 2004 at 07:29:49PM +1100, Herbert Xu wrote:
>
> For this "binary firmware is not preferred form of source" issue to be
> resolved coherently all sources that include binary firmware and all
> drivers that include undocumented magic numbers and strings must be
> removed since of course undocumented magic numbers and strings are not
> preferred form of source either! Hence all or at a least a large amount
> of reverse engineered drivers would need to be removed at minimum,
> besides the drivers vendors provide with binary firmware. I know the
> driver I wrote for the linux kernel uses magic strings which might be
> firmware, I don't know, and so its certainly not the preferred form of
> source. The company making the product never provided documentation on
> the device at all nevermind the source for the supposed firmware.
Not the issue in question....
There are several cases which have been discussed here.
(1) drivers/firmware released under GPL, with the same source used by the
copyright holders to make new releases (whether this is a binary blob, or
much more likely assembler or C code).
These are fine.
(1a) If the appropriate tools needed for compliation/assembly are not
free, they need to go in 'contrib';
(1b) if the tools are free, they can go in 'main'.
(2) drivers/firmware released only "under the GPL" as binary blobs, where
the copyright holders have secret source code hidden away somewhere.
These cannot legally be distributed, at all, because the terms of the GPL
cannot be satisfied.
(3) (This case apparently hasn't actually happened.) Drivers/firmware
released under a DFSG-free license which *doesn't* require source
distribution -- without source.
These can go in "non-free"; the absence of source means they aren't
DFSG-free, I think.
(4) drivers/firmware released only under non-DFSG-free licenses.
These must be removed from 'main'; if freely distributable, they can go in
'non-free'.
Distinguishing between (1) and (2) is best done by simply *asking* the
copyright holders if the firmware was written directly in machine code
(perhaps using some kind of specialized machine-code editor) or not. I
think it's fair to assume that most of the really large binary blobs
weren't, unless the copyright holders claim explicitly that they were,
because it just seems very, very unlikely that they were.
--
Make sure your vote will count.
http://www.verifiedvoting.org/
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Nathanael Nerode 2004-03-26, 3:35 pm |
| X-Original-Sender: news <news@sea.gmane.org>
X-Original-X-Complaints-To: usenet@sea.gmane.org
Xref: number1.nntp.ash.giganews.com linux.debian.devel:143902
Chris Cheney wrote:
> On Thu, Mar 25, 2004 at 07:41:07PM -0600, Chris Cheney wrote:
>
> Actually a reverse engineered driver with blobs in it is probably
Was it reverse-engineered using a "Chinese Wall" system, under which the
people writing the driver *never saw* the proprietary driver? :-) If so,
you're OK. Otherwise.....
> illegal since it is reproducing copyrighted code, I forgot to mention
> that earlier.
Yes, if the blobs are
(1) large and creative enough to be copyrightable
(2) not covered under 'fair use'
> BTW - I know of at least one other driver in the linux kernels like
> that, the one I wrote: kernel/drivers/usb/media/vicam.ko
If you actually extracted those setup4[] bytes from a proprietary binary
driver, then the vicam.c driver is probably completely undistributable,
yes. :-P
--
Make sure your vote will count.
http://www.verifiedvoting.org/
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Nathanael Nerode 2004-03-26, 3:35 pm |
| Marco d'Itri wrote:
> On Mar 26, Andrew Suffield <asuffield@debian.org> wrote:
>
> So it's OK for you if the magic blob which the driver sends to the device
> was sniffed from the USB bus?
Ugh.... provided it's not a copyright violation, which it might be if it was
not done with care to the legalities.
--
Make sure your vote will count.
http://www.verifiedvoting.org/
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Chris Cheney 2004-03-26, 5:36 pm |
| On Fri, Mar 26, 2004 at 03:21:31PM -0500, Nathanael Nerode wrote:
> Chris Cheney wrote:
>
> Was it reverse-engineered using a "Chinese Wall" system, under which the
> people writing the driver *never saw* the proprietary driver? :-) If so,
> you're OK. Otherwise.....
It was done via usb sniffing, not sure if that qualifies or not. No
decompilation of the driver itself was done by me (others may have
later).
> Yes, if the blobs are
> (1) large and creative enough to be copyrightable
> (2) not covered under 'fair use'
>
> If you actually extracted those setup4[] bytes from a proprietary binary
> driver, then the vicam.c driver is probably completely undistributable,
> yes. :-P
Regardless of where the blob came from it still wouldn't be the
preferred form, correct? ;)
Chris
| |
| Nathanael Nerode 2004-03-26, 5:36 pm |
| Chris Cheney wrote:
> On Fri, Mar 26, 2004 at 03:21:31PM -0500, Nathanael Nerode wrote:
>
> It was done via usb sniffing, not sure if that qualifies or not. No
If the sniffing was done *while* the proprietary driver was running, that
doesn't qualify. If it was done with no driver and was just sniffing the
signals the hardware put out, it does.
> decompilation of the driver itself was done by me (others may have
> later).
>
If it was sniffed on the wire and it was a sequence of packets being sent by
the proprietary driver, it's likely to be covered by the proprietary
driver's copyright, and not legally safe to distribute without
permission. :-(
[color=darkred]
> Regardless of where the blob came from it still wouldn't be the
> preferred form, correct? ;)
Have you tried editing it and seeing what results you get? Maybe it's fun
and easy. ;-)
--
Make sure your vote will count.
http://www.verifiedvoting.org/
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Andrew Suffield 2004-03-26, 6:36 pm |
| On Thu, Mar 25, 2004 at 08:03:13PM -0600, Chris Cheney wrote:
> On Thu, Mar 25, 2004 at 07:41:07PM -0600, Chris Cheney wrote:
>
> Actually a reverse engineered driver with blobs in it is probably
> illegal since it is reproducing copyrighted code, I forgot to mention
> that earlier.
Well, quite. If you didn't write it then you *can't* license it under
the GPL, because you don't own the copyright; if you did, then you
have to give us the stuff you were working with.
If it's not copyrightable (because it's too trivial) then obviously
there aren't any issues with the GPL.
--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ |
`. `' |
`- -><- |
| |
| Ryan Underwood 2004-03-29, 8:41 am |
| On Fri, Mar 26, 2004 at 03:16:08PM -0500, Nathanael Nerode wrote:
> (3) (This case apparently hasn't actually happened.) Drivers/firmware
> released under a DFSG-free license which *doesn't* require source
> distribution -- without source.
> These can go in "non-free"; the absence of source means they aren't
> DFSG-free, I think.
This has happened. Take a look at the microcodes for rendition and mga
drivers in XFree86.
--
Ryan Underwood, <nemesis@icequake.net>
| |
| John Goerzen 2004-03-29, 10:34 am |
| On Fri, Mar 26, 2004 at 10:43:32PM +0000, Andrew Suffield wrote:
> Well, quite. If you didn't write it then you *can't* license it under
> the GPL, because you don't own the copyright; if you did, then you
> have to give us the stuff you were working with.
>
> If it's not copyrightable (because it's too trivial) then obviously
> there aren't any issues with the GPL.
My reading of GPL section 2b does not seem to grant that exemption:
b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License.
The GPL is a license -- a contract -- that binds the user to certain
terms as a result of using the origina, copyrighted, GPL work. Where's
the exemption?
It is copyright law that forces the user to take the path of GPL
compliance in the event of redistribution or modification, as it is the
only legal one. Past there, the copyright law doesn't really enter into
it AFAICT.
-- John
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|
|
|
|