Re: broadcom proposed firmware licence, please comment ...
On 5/26/05, Sven Luther <sven.luther@wanadoo.fr> wrote:
> On Wed, May 25, 2005 at 08:53:44PM -0700, Don Armstrong wrote:
> > Would we actually be distributing the hexadecimal format, or would we
> > be distributing the packed binary[1] representation of the hexadecimal
> > format?
>
> I guess that if there is a 1-1 mapping between the two representations, then
> it falls under the "equivalent" format thingy.
Presumably we'll be distributing both (as source code and embedded in
a compiled module, and potentially separately from the rest of the
module), inside various compressed archive formats. None of that is
likely to present a problem given the "equivalent format" fudge (I
think; IANAL). Disassembling and distributing the result would be
conduct outside the license, as would burning it into FLASH or PROM
and distributing that. Constraints like these are enforceable as
"media limitations on the scope of license" in the US and similar
legal systems.
> > While it's probably ok the way it is written, if they're going to go
> > through the trouble of drafting a change, they should make it clear
> > that it's also ok to distribute the firmware data in the packed binary
> > form, assuming that's actually what will be distributed.
>
> What good is this packed binary for ? Also, the way we are going to distribute
> it apart from under hexadecimal format, is by distributing the compiled binary
> driver, which is not clear in the above maybe ?
I think that the "equivalent format" language is just fine. Reciting
a laundry list of acceptable formats can have unfortunate
consequences, as may be seen from the history of lawsuits about
videocassette distribution rights in the Ninth Circuit. Media not
contemplated at the time of drafting are probably best left to a
reasonable interpretation of the purpose of the license.
> I feel that it could be better, apart from the proposed clarification in the
> other subthread, to ask them to allow :
>
> 1) distribution of the firmware data in hexadecimal or equivalent format,
> provided the copyright notice accompanies it.
>
> 2) distribution as part of a binary module, without necessarily any
> copyright notice attached, which would be a pain. Since the GPL gives access
> to the source of the driver when the binary module is available, it also
> gives access by transition to the copyright notice in question under 1).
The "provided this copyright notice is accompanying it" bit is not too
worrisome, especially since under current law notice is not required
for the sake of retaining copyright. There is recent case law in the
US Court of Federal Claims, cited in the latest update to Nimmer,
saying that inadvertent omission of credit is not material breach even
if it's the only benefit offered to the licensor under the contract.
(See RT Computer Graphics v. US,
http://www.uscfc.uscourts.gov/Opinions/Horn/99/RTCOMP.htm ). Not that
we should wink at such an omission; but it's far from instant death.
I think it would perhaps be smart for Linus to include a file under
Documentation that recites the license terms on non-GPL works that
happen to be embedded in the Linux kernel's code base, such as
firmware blobs and perhaps some of the documentation files. That
would make it clear where to find the boundaries of the kernel per se
-- the "literary or artistic work" on which Linus Torvalds is the
author, offered by him as "the Program" under the terms of the GPL.
Note that even though drivers, netfilter, and other substantial
subsystems contain copyright notices with other people's names on
them, "authorship" on a work is (both in US copyright law and under
droits morals) a special status over and above "having contributed
copyrightable material". For many of the purposes we worry about,
only someone who is an "author" can raise difficulties, and IMHO Linus
Torvalds is the only person who can claim to be an "author" of the
kernel. See, for instance, Aalmuhammed v. Lee (
http://laws.findlaw.com/circs/9th/9955224.html ).
In any case, if it comes to exist, that particular
"license-on-bundled-bits.txt" file should be copied into each binary
deb's directory under /usr/share/doc. This would be comfortably
within the meaning of "accompanying" the firmware blob, because it's
inside the end-user packaging "shrink-wrap". No one cares whether
that file winds up inside, say, the initrd image. IANAL, IANADD, etc.
Cheers,
- Michael
Reply to: