Message-ID: <20090709152541.GA6334@mit.edu>
Date:	Thu, 9 Jul 2009 11:25:41 -0400
From:	Theodore Tso <tytso@....edu>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	James Bottomley <James.Bottomley@...senPartnership.com>,
	tridge@...ba.org, Martin Steigerwald <Martin@...htvoll.de>,
	Jan Engelhardt <jengelh@...ozas.de>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Pavel Machek <pavel@....cz>, john.lanza@...ux.com,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-fsdevel@...r.kernel.org,
	Dave Kleikamp <shaggy@...ux.vnet.ibm.com>, corbet@....net,
	jcm@...masters.org
Subject: Re: CONFIG_VFAT_FS_DUALNAMES regressions

On Thu, Jul 09, 2009 at 03:10:09PM +0100, Alan Cox wrote:
> > contributory infringement based on shipping the code.  I don't actually
> > believe that a compile time option they turn on in the binary kernel to
> > make it non infringing coupled with shipping code where the user could
> > recompile with it off is sufficient to rise to the tests under the
> > contributory infringement doctrine.
> 
> Its a simple risk test. Anything which reduces risk but does not change
> functionality is something you do. Its basically a zero cost way to
> reduce the chances of being shot at.

Look, even if what you say is valid (despite the advice of lawyers),
it is still useful for us to apply the patch (with the CONFIG option)
in the upstream sources.  It means that support for the workaround
stays in the mainstream sources, so we don't have to worry about
separate patch going no longer applying as time goes by and the
upstream sources change over time.  *If* a vendor really wants to
strip out the source code, they can do that easily enough using
unifdef to strip out the one specific CONFIG option.

However, I don't think they will think it's necessary, and I'll tell
you why.  Regardless of whether or not source code with an #ifdef'ed
out (but still present) source code might be considered "contributory
infringment" (and we have legal advice saying that this would not be
the case), either way, the *binary*, which is to say the **product**
does not contain any of the infringing functionality or code.  Hence,
the patent troll won't be able to use an ITC action to stop the
product at the border, thus putting the potentially weak company out
of business.  Suing for contributory infringment takes time;
potentially years, so there is plenty of time for (a) the patent
troll, if it is a company like Microsoft, to suffer all sorts of
public relations damange, thus revealing the claims of people like Sam
Ramji as empty and cynical, and (b) for the community to rally around
said company and provide defense.  In addition, healing a cliam of
contributory infringment is easy enough; simply releasing a version of
the source code with unifdef applied won't changing the resulting
binary.   

In any case, the fact that the patent troll won't be able to put a
company out of business, but instead might have to wage a long legal
war (consider how long the SCO lawsuits have dragged on), will tend to
dissuade the rational troll from pursuing such a path; and even if we
do have an irrational actor, (a) I don't really think Microsoft is
irrational, and (b) in the U.S. you can get a lawyer to sue a ham
sandwich, so there's no real proactive steps you can take to protect
yourself against an irrational actor who is bound and determined to
abuse the legal system; and most companies and lawyers (as opposed to
people who like to play lawyers on mailing lists and TV) understand
that.

But in any case, even for a very risk-averse company, getting this
proposed patch into mainline is useful, since at any point in time the
company can get a version of the code without any code that might be
claimable as being infringing by using unifdef.  So it's still a net
win.  And if people are worried about the very small chances of
problems (which perhaps we can improve), we can fix that as future
patches against the mainline --- which is the right way to do OSS
development.  Given that Hirofumi-san has already decided to take this
patch, so unless Linus decides to override his decision, this
discussion is rapidly becoming moot in any case.

Regards,

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists