TG3 firmware report...
Daniel Freedman
I'm writing regarding the issue of inclusion of TG3 binary firmware in
the Debian-distributed Linux post-2.6.5 kernels. I understand this
has been a contentious topic, and I've read most of the mailing list
archives on it, so I'm not trying to restart the debate, but merely
adding some additional information, which might not be widely know.
Clearly, the TG3 firmware is still distributed with the upstream Linux
kernel tarballs, yet removed (post-2.6.5) from Debian distributed
kernels for reasons of DFSG guidelines.
Much of the debate of this removal has surfaced around the fact that
most Broadcom chipsets work fine without the firmware inclusion, and,
at worst, possibly simply lose some of their more advanced features.
Unfortunately, I believe that my server board contains one of the rare
on-board Broadcom chipsets that is completely unable to function (best
as I can tell), without downloading this firmware, or without at least
disabling the download of it... In other words, it works perfectly
with 2.4.26, but not at all with 2.6.8. It's recognized fine, get's
IP address fine, has kernel modules loaded etc., but simply drops
packets off the stack...
My chipset is the Broadcom 5705 (not nearly as popular as the 5704,
etc.), but included onboard in the only motherboard that offers a
single Opteron processor---namely the Tyan Tomcat K8S---which I think
is a wonderful board for certain economical uses where dual processor
Opteron capability is overkill.
Anyway, just thought I'd see what people think of this, and how the
Debian community wants to proceed. Is there some way to enable
compability with this without downloading the firmware and violating
the DFSG?
Thanks,
Daniel
PS Please cc: me on replies. Also, unfortunately, for various
reasons, I don't currently have access to my Tomcat K8S board to test
any options with the Broadcom 5705 chipset... :(
--
Daniel A. Freedman <free...@physics.cornell.edu>, Graduate Fellow
Electronic Structure Calculations, LASSP, Cornell University
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Roland Stigge
Daniel Freedman wrote:
> Anyway, just thought I'd see what people think of this, and how the
> Debian community wants to proceed. Is there some way to enable
> compability with this without downloading the firmware and violating
> the DFSG?
Since the tg3 driver doesn't work with my BCM5702 interface anyway
(#240812), I'm using the bcm5700-source driver from non-free. I guess
people running servers and using the advanced features of this driver
are doing the same.
Feel free to write a personal email to Broadcom asking for the source of
their GPLed driver.
bye,
Roland
Paul Hampson
> Unfortunately, I believe that my server board contains one of the rare
> on-board Broadcom chipsets that is completely unable to function (best
> as I can tell), without downloading this firmware, or without at least
> disabling the download of it... In other words, it works perfectly
> with 2.4.26, but not at all with 2.6.8. It's recognized fine, get's
> IP address fine, has kernel modules loaded etc., but simply drops
> packets off the stack...
> Anyway, just thought I'd see what people think of this, and how the
> Debian community wants to proceed. Is there some way to enable
> compability with this without downloading the firmware and violating
> the DFSG?
Surely you can grab the firmware yourself, dump it into the appropriate
place in /lib/firmware (the boot message from the tg3 driver tells you)
and then it'll work on next boot?
This won't break the DFSG as far as I know, 'cause you're not
distributing the firmware and Broadcom presumably are happy for you to
download it yourself for use.
Unless of course the firmware itself is GPL'd, and therefore no one
can legally give it out without offering the source as well.
I'm not sure this is the right list for this topic, anyway...
--
-----------------------------------------------------------
Paul "TBBle" Hampson, MCSE
7th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
Paul.H...@Anu.edu.au
"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"
This email is licensed to the recipient for non-commercial
use, duplication and distribution.
-----------------------------------------------------------
Nico Golde
* Roland Stigge <sti...@antcom.de> [2004-10-10 15:46]:
> Daniel Freedman wrote:
> > Anyway, just thought I'd see what people think of this, and how the
> > Debian community wants to proceed. Is there some way to enable
> > compability with this without downloading the firmware and violating
> > the DFSG?
>
> Since the tg3 driver doesn't work with my BCM5702 interface anyway
> (#240812), I'm using the bcm5700-source driver from non-free. I guess
> people running servers and using the advanced features of this driver
> are doing the same.
>
> Feel free to write a personal email to Broadcom asking for the source of
> their GPLed driver.
the source is included in the kernel sources :)
regards nico
--
Nico Golde - 310777820@ICQ
ni...@ngolde.de | ni...@gmx.net | http://www.ngolde.de
GPG: FF46 E565 5CC1 E2E5 3F69 C739 1D87 E549 7364 7CFF
Is there life after /sbin/halt -p?
Nathanael Nerode
Paul Hampson wrote:
> On Sat, Oct 09, 2004 at 07:10:33PM -0400, Daniel Freedman wrote:
>> Unfortunately, I believe that my server board contains one of the rare
>> on-board Broadcom chipsets that is completely unable to function (best
>> as I can tell), without downloading this firmware, or without at least
>> disabling the download of it... In other words, it works perfectly
>> with 2.4.26, but not at all with 2.6.8. It's recognized fine, get's
>> IP address fine, has kernel modules loaded etc., but simply drops
>> packets off the stack...
>
>> Anyway, just thought I'd see what people think of this, and how the
>> Debian community wants to proceed. Is there some way to enable
>> compability with this without downloading the firmware and violating
>> the DFSG?
>
> Surely you can grab the firmware yourself, dump it into the appropriate
> place in /lib/firmware (the boot message from the tg3 driver tells you)
> and then it'll work on next boot?
>
> This won't break the DFSG as far as I know, 'cause you're not
> distributing the firmware and Broadcom presumably are happy for you to
> download it yourself for use.
>
> Unless of course the firmware itself is GPL'd, and therefore no one
> can legally give it out without offering the source as well.
It is GPLed. This is why it hasn't been put in non-free. :-P
Contact Broadcom and ask them to do one of the following things:
(1) Release source for the firmware
(2) Release the firmware under a license which allows distribution without
source
Until they do one of these two things, the firmware is not safe to
distribute. I don't know why upstream is distributing it; I believe they
are simply being sloppy about licensing.
> I'm not sure this is the right list for this topic, anyway...
>
--
This space intentionally left blank.
Nathanael Nerode
Nico Golde wrote:
> hi
> * Roland Stigge <sti...@antcom.de> [2004-10-10 15:46]:
>> Daniel Freedman wrote:
>> > Anyway, just thought I'd see what people think of this, and how the
>> > Debian community wants to proceed. Is there some way to enable
>> > compability with this without downloading the firmware and violating
>> > the DFSG?
>>
>> Since the tg3 driver doesn't work with my BCM5702 interface anyway
>> (#240812), I'm using the bcm5700-source driver from non-free. I guess
>> people running servers and using the advanced features of this driver
>> are doing the same.
>>
>> Feel free to write a personal email to Broadcom asking for the source of
>> their GPLed driver.
>
> the source is included in the kernel sources :)
> regards nico
Um, no, the firmware source isn't. There's just a hunk of hex.
--
This space intentionally left blank.
Marco d'Itri
> Until they do one of these two things, the firmware is not safe to
> distribute. I don't know why upstream is distributing it; I believe they
> are simply being sloppy about licensing.
You know well that upstream is not "being sloppy", but disagrees with
your interpretation of licensing.
--
ciao, |
Marco | [8468 qu1ZFFjpdB01A]
Florian Weimer
>> Unless of course the firmware itself is GPL'd, and therefore no one
>> can legally give it out without offering the source as well.
>
> It is GPLed. This is why it hasn't been put in non-free. :-P
> Until they do one of these two things, the firmware is not safe to
> distribute.
Of course it is safe to distribute. What do you fear? That Broadcom
might sue you for distributing something that they have written and
released under the GPL, and actually have a case? They might as well
sue Debian because the toolchain supports the SB-1 architecture.
Of course, Debian is free to refrain from distribution for other
reasons, but citing legal problems to cover up political decisions is
dishonest.
Matthew Garrett
> * Nathanael Nerode:
>> Until they do one of these two things, the firmware is not safe to
>> distribute.
>
> Of course it is safe to distribute. What do you fear? That Broadcom
> might sue you for distributing something that they have written and
> released under the GPL, and actually have a case? They might as well
> sue Debian because the toolchain supports the SB-1 architecture.
Indeed. It's obviously the intention of the licensor to provide code
that can be distributed. There are potentially issues with derived works
containing a combination of the firmware and other GPLed code, but
that's why we'd consider non-free rather than anywhere else.
--
Matthew Garrett | mjg59-chiark.ma...@srcf.ucam.org
sean finney
> Of course it is safe to distribute. What do you fear? That Broadcom
> might sue you for distributing something that they have written and
> released under the GPL, and actually have a case? They might as well
> sue Debian because the toolchain supports the SB-1 architecture.
they may have released it under the GPL, but there's a strong case for
arguing that they're in violation of their own licensing terms for not
providing the source code to the firmware blobs. if they were in fact
in violation of said terms, debian could not legally distribute the
code. or so the argument goes.
sean
--
Scott James Remnant
You can't violate your own licensing terms. A licence is what an author
gives to somebody to adjust the rights they have on a work. The
licensee is bound by the licence, not the author.
(Note that this arguably doesn't apply where the author has taken back
patches under their own licence because they are in fact the licensee
not the author.)
Scott
--
Have you ever, ever felt like this?
Had strange things happen? Are you going round the twist?
John Hasler
> they may have released it under the GPL, but there's a strong case for
> arguing that they're in violation of their own licensing terms for not
> providing the source code to the firmware blobs. if they were in fact in
> violation of said terms, debian could not legally distribute the code.
What do you mean by "legally"? Copyright infringement is a tort, and there
is no way they could win an infringement lawsuit against a distributor for
failing to redistribute the source for the blobs when they did not supply
it themselves and yet asserted that the work was under the GPL.
The real risk (if any) is of being sued by a kernel author.
--
John Hasler
Henning Makholm
> they may have released it under the GPL, but there's a strong case for
> arguing that they're in violation of their own licensing terms for not
> providing the source code to the firmware blobs.
The copyright holder cannot logically be in violation of his own
licensing terms. He does not need a license at all to distribute his
own work, thus there is nothing for *him* to violate.
--
Henning Makholm "Jeg køber intet af Sulla, og selv om uordenen griber
planmæssigt om sig, så er vi endnu ikke nået dertil hvor
ordentlige mennesker kan tillade sig at stjæle slaver fra
hinanden. Så er det ligegyldigt, hvor stærke, politiske modstandere vi er."
Thomas Bushnell BSG
> Scripsit sean finney <sea...@seanius.net>
>
> > they may have released it under the GPL, but there's a strong case for
> > arguing that they're in violation of their own licensing terms for not
> > providing the source code to the firmware blobs.
>
> The copyright holder cannot logically be in violation of his own
> licensing terms. He does not need a license at all to distribute his
> own work, thus there is nothing for *him* to violate.
Right. In cases like this one, what has happened is that the
copyright holder has simply failed to make legal distribution
possible, by saying "you must distribute complete source" and then
failing to provide it. So the only way to comply with the license in
such a case is simply to do no distribution at all.
Thomas
Nathanael Nerode
> Florian Weimer <f...@deneb.enyo.de> wrote:
>> * Nathanael Nerode:
>>> Until they do one of these two things, the firmware is not safe to
>>> distribute.
>>
>> Of course it is safe to distribute. What do you fear? That Broadcom
>> might sue you for distributing something that they have written and
>> released under the GPL, and actually have a case?
Yes. They would have an excellent case. They didn't grant explicit
permission to distribute without source. I don't have source, so I'd
better not distribute. If I were defending myself, I'd have to claim that
they'd granted implicit permission, and I don't think I'd have better than
a 50-50 chance of winning; see below.
>> They might as well
>> sue Debian because the toolchain supports the SB-1 architecture.
>
> Indeed. It's obviously the intention of the licensor to provide code
> that can be distributed.
Maybe it's obvious to you. It's certainly not obvious to me.
In actual fact, Broadcom released the firmware code under a license which
does not grant permission to redistribute. (It requires source but the
source is not provided; see Thomas Bushnell's message which summarizes the
situation at http://lists.debian.org/debian-devel/2004/10/msg00705.html .)
To me, this means that Broadcom didn't know what the hell it was doing. I
cannot divine Broadcom's actual intentions from that, and Broadcom can
easily and convincingly claim that it intended something different from
what you assume.
If Broadcom (or some irresponsible successor company; think SCO) decided to
sue for copyright infringement, they could claim that they had never
intended to allow people in general to redistribute the firmware without
source -- that it was just for them to distribute, and perhaps for
kernel.org as well -- that any further distribution was inadvertent -- and
they would actually have a pretty good case, as far as I can tell.
(Of course, if you get an actual legal opinion from a copyright lawyer
saying differently, I will of course concede, since IANAL.)
Now, if Broadcom could be contacted, and they said, "Oh, we meant to allow
anyone to redistribute the hex/binary blobs without further source code,"
that would be different. Then it would be safe to distribute with a copy
of that statement.
I have not been able to get such a clarification from Broadcom, and I have
tried. If you can get such a clarification, more power to you.
--
This space intentionally left blank.
--
John Hasler
> In cases like this one, what has happened is that the copyright holder
> has simply failed to make legal distribution possible, by saying "you
> must distribute complete source" and then failing to provide it.
He has provided what he claims is source. If he sues me for redistributing
all of what I got from him after he told me it included source he will be
laughed out of court.
> So the only way to comply with the license in such a case is simply to do
> no distribution at all.
You just have to refrain from distributing derivatives that are
combinations of such bungled works and ones that are properly GPL'd (or get
permission of the authors of the properly GPL'd works).
--
John Hasler
Matthew Garrett
> What do you mean by "legally"? Copyright infringement is a tort, and there
> is no way they could win an infringement lawsuit against a distributor for
> failing to redistribute the source for the blobs when they did not supply
> it themselves and yet asserted that the work was under the GPL.
>
> The real risk (if any) is of being sued by a kernel author.
That's only a risk if we ship it linked with the kernel. Shipping a
single blob of hex in non-free shouldn't be a problem in that respect.
--
Matthew Garrett | mjg59-chiark.ma...@srcf.ucam.org
John Hasler
> To me, this means that Broadcom didn't know what the hell it was doing.
> I cannot divine Broadcom's actual intentions from that, and Broadcom can
> easily and convincingly claim that it intended something different from
> what you assume.
The intent implied by publically releasing a work under the GPL is well
understood and widely known. I don't believe that they would stand any
chance of getting an injunction, let alone damages.
The fact that they have already permitted redistribution would count
heavily against them.
--
John Hasler
Thomas Bushnell BSG
> Thomas writes:
> > In cases like this one, what has happened is that the copyright holder
> > has simply failed to make legal distribution possible, by saying "you
> > must distribute complete source" and then failing to provide it.
>
> He has provided what he claims is source. If he sues me for redistributing
> all of what I got from him after he told me it included source he will be
> laughed out of court.
In this case, one would be well advised to obtain an explicit waiver
on the point, rather than to rely on such.
Regardless, the question is irrelevant to Debian, because we require
source.
Thomas Bushnell BSG
> The intent implied by publically releasing a work under the GPL is well
> understood and widely known. I don't believe that they would stand any
> chance of getting an injunction, let alone damages.
You cannot infer person A's intent in doing something merely by
assuming that it must be the same as persons B, C, and D.
sean finney
> What do you mean by "legally"? Copyright infringement is a tort, and there
> is no way they could win an infringement lawsuit against a distributor for
> failing to redistribute the source for the blobs when they did not supply
> it themselves and yet asserted that the work was under the GPL.
the terms of the gpl quite explicitly state that software must
be distributed with its source code, where source code is
defined as "the preferred form of the work for making modifications to
it" (and i somehow doubt that a binary blob is their preferred form,
but if they could successfully argue this point this is all m00t).
unless we have the author's permission to use an alternate license,
wherein the bulk of the code went into contrib and the binary blob went
into non-free, or unless the author opened up the firmware, we're
unable to legally redistribute it, period.
On Mon, Oct 11, 2004 at 06:53:05PM +0100, Matthew Garrett wrote:
> That's only a risk if we ship it linked with the kernel. Shipping a
> single blob of hex in non-free shouldn't be a problem in that respect.
i do not believe that a piece of gpl'd code could legally link against
this blob. if this were to be put under some system for loading
firmware in userland, i think it'd be up for debate; but
the lack of a usable Free alternative would make me think the
driver would still need to go in contrib at the least.
On Mon, Oct 11, 2004 at 04:53:10PM +0100, Scott James Remnant wrote:
> You can't violate your own licensing terms. A licence is what an author
> gives to somebody to adjust the rights they have on a work. The
> licensee is bound by the licence, not the author.
you're arguing my point. debian is a licensee, and is not able to meet
with the terms of the license.
On Mon, Oct 11, 2004 at 05:26:38PM +0100, Henning Makholm wrote:
> The copyright holder cannot logically be in violation of his own
> licensing terms. He does not need a license at all to distribute his
> own work, thus there is nothing for *him* to violate.
this is true, but there is something for *us*...
On Mon, Oct 11, 2004 at 01:19:54PM -0500, John Hasler wrote:
> The intent implied by publically releasing a work under the GPL is well
> understood and widely known. I don't believe that they would stand any
> chance of getting an injunction, let alone damages.
have you missed everything going on with SCO? granted, their case was
a load of crap from the beginning, but it goes to show that this
is not something to be taken lightly. and anyway, i don't think you'll
get very far trying to argue "implied intent" against the holder of a
copyright in a courtroom...
sean
--
Matthew Garrett
> In this case, one would be well advised to obtain an explicit waiver
> on the point, rather than to rely on such.
>
> Regardless, the question is irrelevant to Debian, because we require
> source.
Debian does not require source for non-free. The distribution that we
ship under the name "Debian" requires source, but that's not the only
software we provide.
--
Matthew Garrett | mjg59-chiark.ma...@srcf.ucam.org
Florian Weimer
> John Hasler <jha...@debian.org> writes:
>
>> The intent implied by publically releasing a work under the GPL is well
>> understood and widely known. I don't believe that they would stand any
>> chance of getting an injunction, let alone damages.
>
> You cannot infer person A's intent in doing something merely by
> assuming that it must be the same as persons B, C, and D.
Well, of course you can. A lot of contracts are made this way (for
example, if you buy something in a shop).
Is U.S. law really *that* different?
John Hasler
> Is U.S. law really *that* different?
No. It is commonplace to introduce evidence about established industry
practice in lawsuits.
--
John Hasler
Thomas Bushnell BSG
> > You cannot infer person A's intent in doing something merely by
> > assuming that it must be the same as persons B, C, and D.
>
> Well, of course you can. A lot of contracts are made this way (for
> example, if you buy something in a shop).
Actually, no. First, buying something in a shop doesn't necessarily
involve any contract at all; it's a sale, which can proceed other than
by contract.
Second, the Uniform Commercial Code explicitly says things about
following customary practices, and does say that commercial contracts
are presumed to be following normal customary practices, so that such
imputation of intent works there.
But no, the UCC does not apply to copyright licensing.
And finally, it might be evidence for A's intent that they were
probably wanting what B, C, and D, wanted. I said that you can't get
there *merely* from that assumption, but there must be some additional
something to help it along. Otherwise, the inference doesn't go.
Moreover, companies are allowed to have deceptive copyright
statements; in fact, they do it all the time. Nearly every book or CD
you get has a deceptive copyright statement on it.
Thomas
Nathanael Nerode
> On Oct 10, Nathanael Nerode <ner...@twcny.rr.com> wrote:
>
>> Until they do one of these two things, the firmware is not safe to
>> distribute. I don't know why upstream is distributing it; I believe they
>> are simply being sloppy about licensing.
> You know well that upstream is not "being sloppy", but disagrees with
> your interpretation of licensing.
On the contrary. The upstream maintainer stated that "nobody" from Broadcom
"complained", and apparently felt that that was sufficient, and that it was
unimportant to get a valid explicit license. Or indeed to include
Broadcom's copyright statement at all, until I complained about its
absence. That, to me, seems sloppy.
Copyright infrignment is strict liability, IIRC. This is not safe to mess
around with.
Nathanael Nerode
> Nathanael Nerode writes:
>> To me, this means that Broadcom didn't know what the hell it was doing.
>> I cannot divine Broadcom's actual intentions from that, and Broadcom can
>> easily and convincingly claim that it intended something different from
>> what you assume.
>
> The intent implied by publically releasing a work under the GPL is well
> understood and widely known.
The intent implied by publically releasing a work "under the GPL" but
without source code, however, is not well understood or widely known. If
indeed anyone understands it.
> I don't believe that they would stand any
> chance of getting an injunction, let alone damages.
Have you got a legal opinion to back that up? :-P
> The fact that they have already permitted redistribution would count
> heavily against them.
Well, if you feel safe distributing the tg3 microcode files in non-free, you
may. I don't, which is why I have not submitted such a package to Debian.
I will be happy to tell you how to take the files from Broadcom's driver and
convert them to the form which is loaded by the driver currently in Debian,
and to give you my tools for doing so. (Or anyone else who is interested
in this.)
Perhaps I should construct a package for non-free which instructs users to
download Broadcom's driver; then unpacks it, and converts and installs the
firmware files appropriately? (I *am* sure that Broadcom permits
distribution from their own website directly to end-users, since they
pretty much advertise that.) That I would feel safe doing.
--
This space intentionally left blank.
Thomas Bushnell BSG
> No. It is commonplace to introduce evidence about established industry
> practice in lawsuits.
Right, but this is not imputation of intent, and it's generally done
under the UCC which worked a sea change in US commercial contracts law
for this purpose, but does not apply to non-contractual things like
copyright licenses.
Nathanael Nerode
> John Hasler <jha...@debian.org> writes:
>
>> Thomas writes:
>> > In cases like this one, what has happened is that the copyright holder
>> > has simply failed to make legal distribution possible, by saying "you
>> > must distribute complete source" and then failing to provide it.
>>
>> He has provided what he claims is source.
If there was an explicit statement saying "Broadcom claims that this is
source code for the purposes of the GPL," that would be the case. I have
not been able to get such a statement from Broadcom, either.
If someone has better lines of communication with Broadcom, they can clear
this up really easily: making the statement above; releasing the source
code; licensing under 2-clause BSD or MIT/X11; or stating "We intend to
allow anyone to redistribute these hex files in any form": *any one* of
these options would make the firmware safe to distribute in non-free.
However, since I have not yet been able to talk to anyone at Broadcom who
appears to know anything about this, I do not feel safe making any
assumptions about their intent.
>> If he sues me for
>> redistributing all of what I got from him after he told me it included
>> source he will be laughed out of court.
>
> In this case, one would be well advised to obtain an explicit waiver
> on the point, rather than to rely on such.
Which is exactly what I hoped to get. Unfortunately, I have had a hard time
getting feedback from Broadcom.
If you fancy your luck, please try!
--
This space intentionally left blank.
Paul Hampson
> Perhaps I should construct a package for non-free which instructs users to
> download Broadcom's driver; then unpacks it, and converts and installs the
> firmware files appropriately? (I *am* sure that Broadcom permits
> distribution from their own website directly to end-users, since they
> pretty much advertise that.) That I would feel safe doing.
Yeah, that'd be good... Is a lot of conversion required for the firmware
in the Windows driver archive?
--
-----------------------------------------------------------
Paul "TBBle" Hampson, MCSE
7th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
Paul.H...@Anu.edu.au
"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"
This email is licensed to the recipient for non-commercial
use, duplication and distribution.
-----------------------------------------------------------