Re: CONFIG_VFAT_FS_DUALNAMES regressions

[Alan Cox]

> > 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/