Re: CONFIG_VFAT_FS_DUALNAMES regressions

From: Bartlomiej Zolnierkiewicz
Date: Fri Jul 10 2009 - 16:35:10 EST


On Friday 10 July 2009 21:31:27 Jonathan Corbet wrote:

> I have a lot of sympathy for Alan's assertion that we can't muck up our
> upstream code with hackarounds for every bit of legal obnoxiousness we
> encounter. But outright refusal of things like patent workarounds does
> not help us either. Linux is a pragmatic system; somehow, I believe,
> we can find a way to minimize our patent hassles without messing up the
> system as a whole.

Alan, Pavel and other people are suggesting pragmatic *long-term* solutions,
like moving kernel.org outside problematic geopolitical area. Tainting *our*
code-base with (confusing for *our* users) workarounds doesn't belong in this
class of solutions.. actually no.. it is a PURE F*CKING IDIOCY..

Microsoft having patents on their *obsolete* filesystem should be *their*
problem, not *ours*. We keep said filesystem strictly for compatibility
reasons and not because we would like to encourage hardware/software vendors
or users to use it. Lets just update VFAT help text to mention potential
risks of using it, default it to N, rip it from defconfigs, pass it through
lawyers, remove CONFIG_VFAT_FS_DUALNAMES and move on..

When it comes to distributions if they really need they can easily deal with
the problem by simply allowing the 3-rd parties to host the repositories with
risky package (like they do with mp3 etc).

The end result is that end-users can still use full vfat, vendors are safe,
kernel developers don't waste their time on artificial problems and the blame
goes where it belong..

[ The validity of potentially bogus patents (or problems of hardware vendors
caused by *their* decisions to use *obsolete* and patent-risky filesystem in
their products) is an entirely different matter/discussion and it shouldn't
be mixed with technical solutions.. ]
--
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/