linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Adam J. Richter" <adam@yggdrasil.com>
To: simon@thekelleys.org.uk
Cc: linux-kernel@vger.kernel.org
Subject: Re: Binary firmware in the kernel - licensing issues.
Date: Wed, 7 May 2003 10:14:09 -0700	[thread overview]
Message-ID: <200305071714.h47HE9u00434@freya.yggdrasil.com> (raw)

	I am not a lawyer, so please don't rely on this as legal advice.
I'm only explaining my layman's understanding.

Simon Kelley wrote:
>If many copyright holders don't agree then clearly firmware blobs
>shouldn't go into the kernel. It is difficult to argue that just one is
>enough for a veto [...]

	I don't think that should be difficult to argue.  Let's see.

	One objecting developer is enough for a lawsuit.  If a court
find copyright infringement and that developer registered the
copyright (a form TX from the copyright office and a $35 registration
fee, if memory serves), then I believe statutory damages would be
something like $750-30k per copy (see
http://www4.law.cornell.edu/uscode/17/504.html).  Theoretically,
there might be the potential for criminal prosecution of
for-profit distributors (see
http://www4.law.cornell.edu/uscode/18/2319.html).

	See how easy that was easy to argue?

>, especially since at least one driver (Advansys) has
>been there, complete with its "bucket of bits" since 1.3.x days at 
>least.

	This is the first I've heard of it.  In this case,
it appears that the copyright is GPL compatible, but it does
not appear that the GPL's requirement for the "preferred form of
the work for making modifications to it" has been satisfied
with respect to this binary blob of firmware.  If the source is
not included in the kernel, I think that binary blob should be
removed and replaced with some user level facility for loading that
array.  I wonder if it really is necessary to load the microcode
at all, as I would assume that there would have to be some
initial firmware loaded for the control to act as a boot
device (or can't it do that?).

>Any contributor to the kernel since then who cared could have 
>been aware of that as evidence of a de-facto interpretation of the GPL
>source clause as not applying to firmware in Linux.

	There are all sorts of obscure facts that one "could have
been aware" of, but that doesn't show that one _was_ aware of them
if you're trying to argue that one implicitly agreed to something.

>The technical advantages you give are not compelling for the Atmel 
>driver. The driver has international roaming support built-in and the
>firmware size is than 20k. In general though they may be good points.

>I suggest that having a driver which "just works" without needing
>extra files and configuration steps would trump minmizing legal
>exposure to the Linux copyright holders, for most people in the real
>world.

	It's not just the copyright holders who have the legal
exposure.  It would be anyone who distributes your driver.

	Again, I want to emphasize that I'm not a lawyer, and I
wouldn't want anyone to rely on my incomplete and potentially
quite incorrect layman's understanding as legal advice.

Adam J. Richter     __     ______________   575 Oroville Road
adam@yggdrasil.com     \ /                  Miplitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."

             reply	other threads:[~2003-05-07 17:03 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-07 17:14 Adam J. Richter [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-05-08 23:36 Binary firmware in the kernel - licensing issues Adam J. Richter
2003-05-08 16:51 Adam J. Richter
2003-05-08 16:35 Adam J. Richter
2003-05-08 18:26 ` root
2003-05-08 22:19   ` Alan Cox
2003-05-08 15:59 Adam J. Richter
2003-05-08 16:09 ` Jörn Engel
2003-05-08 13:20 Downing, Thomas
2003-05-07 11:59 Adam J. Richter
2003-05-07 14:08 ` Simon Kelley
2003-05-06 15:04 Adam J. Richter
2003-05-06 12:54 Downing, Thomas
2003-05-06 12:46 ` Alan Cox
2003-05-06 11:38 Simon Kelley
2003-05-06 11:15 ` Alan Cox
2003-05-06 13:28   ` Simon Kelley
2003-05-06 12:44     ` Alan Cox
2003-05-06 13:42   ` Simon Kelley
2003-05-06 12:19 ` Matti Aarnio
2003-05-06 15:16   ` J. Bruce Fields
2003-05-06 15:42     ` Simon Kelley
2003-05-06 15:21       ` Alan Cox
2003-05-07  6:52         ` Simon Kelley
2003-05-07  9:07           ` Filip Van Raemdonck
2003-05-07  9:54             ` Simon Kelley
2003-05-08  8:01               ` Filip Van Raemdonck
2003-05-08  9:44                 ` Simon Kelley
2003-05-08 10:56                   ` Alan Cox
2003-05-06 15:48     ` Richard B. Johnson
2003-05-06 15:19       ` Alan Cox
2003-05-08 10:20 ` Jörn Engel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200305071714.h47HE9u00434@freya.yggdrasil.com \
    --to=adam@yggdrasil.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=simon@thekelleys.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).