[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090708171848.21633768@lxorguk.ukuu.org.uk>
Date: Wed, 8 Jul 2009 17:18:48 +0100
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: James Bottomley <James.Bottomley@...senPartnership.com>
Cc: tridge@...ba.org, Martin Steigerwald <Martin@...htvoll.de>,
Jan Engelhardt <jengelh@...ozas.de>,
OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>,
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
> > That represents loss of functionality for loss of risk (a trade off).
>
> Precisely ... that's what this whole thread is about. Accepting the
> lawyer's argument that this patch eliminates the risk of suit under the
> FAT32 patents, does the loss of functionality it comes with represent an
> adequate reward?
You are missing the point still.
Ship with problem feature enabled risk high features high
Ship with problem off but in source risk lower features low
Ship with it ripped out risk lowest features low
So the only two logical positions to operate are low feature/lowest risk
and high feature/high risk. So if you decide not to ship the feature it'll
get ripped out entirely.
> OK, so we disagree on whether providing source code constitutes
> contributory infringement.
We disagree whether there is zero risk involved. If there is any risk
then the logical position if you've decided not to enable the feature is
not to ship source for it.
> OK, so rather than get into a what my lawyer says versus what your
> lawyer says argument, can we get back to the technical aspects of this
> and leave the lawyers retained by the vendors to sort out what they
> actually do?
Sure and I'd say the technical issues are simple
- Tridge's patch breaks stuff
- Tridge's patch masquerades as vfat but isn't.
We can fix those by only creating short names (but honouring existing
long ones) and by not claiming its vfat.
Alan
--
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