linux-kernel - Re: CONFIG_VFAT_FS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1247147981.3898.15.camel@mulgrave.site>
Date:	Thu, 09 Jul 2009 08:59:41 -0500
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	tridge@...ba.org, Martin Steigerwald <Martin@...htvoll.de>,
	Jan Engelhardt <jengelh@...ozas.de>,
	Theodore Tso <tytso@....edu>,
	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, 2009-07-09 at 10:42 +0100, Alan Cox wrote:
> > no, when the vendors are given a clearly non-infringing way of
> > implementation then I think they will go for it. The proof is that
> 
> Even if they go for the non-infringing tweak they will still end up with
> patches to rip out the potentially infringing code paths.

You keep saying this and I keep pointing out to you it's not true.

Vendors would only rip the code out if they truly feared a suit for
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.

Even if I'm wrong on this, vendors still won't rip out the code in this
case principally because this is a weak set of patents they universally
regard as invalid.  The way to troll with a weak patent is to go after
the small fish (namely end users) who can't sustain a business shutdown
under TRO or ITU actions.

The point of this patch is to alter the code sufficiently to forestall
troll actions against small redistributors or end users, not to shield
vendors from contributory infringement suits which would never get filed
because the patents are too weak for such a large scale attack.

James

--
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/