Message-ID: <19028.31088.400461.939917@samba.org>
Date:	Wed, 8 Jul 2009 20:48:16 +1000
From:	tridge@...ba.org
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	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, James.Bottomley@...senpartnership.com
Subject: Re: CONFIG_VFAT_FS_DUALNAMES regressions

Hi Alan,

 > There are lots of Win98 systems still alive out there. The "last few" in
 > the Win98 world is rather a lot due to the original enormous user base.

I find it rather ironic that you are advocating leaving the Linux
kernel open to further legal attacks by Microsoft because if we didn't
then we might lose compatibility with an operating system which
Microsoft themselves abandoned a long time ago.

 > I think we already proved it had no use upstream. Vendors will remove
 > the code from their source tree if worried about patents so including it
 > in the base tree is really irrelevant. So I find your argument about this
 > less than convincing.

we've been round this loop before. See my previous emails where I
explained why I think having it upstream is an advantage. See also the
reply from James.

 > I also note you keep talking about vendors. This is an open list yet I
 > don't hear a word from the vendors you claim to represent in support of
 > this patch set, and saying they would enable it. Not one voice seems to
 > have appeared.

I never claimed to represent any vendors. I said that it was my
opinion that many vendors will want to apply this patch, and you seem
to support that opinion as you've several times stated that you think
that vendors will apply it in an unconditional form.

 > At that point nobody managing risk is going to do anything but remove the
 > code that worries them. It's additional risk with no return.

Some vendors may well do that. Some may decide to keep it as a compile
time option. The legal advice that I've seen is that keeping it as a
compile time option is fine. 

If it's pulled out of kernel.org trees then:

 - each vendor may end up with slightly different varients. That means
   we could have Linux devices behaving inconsistently.

 - the testing and discussion may end up happening in a less open
   manner. I think the testing and discussion on lkml has been very
   valuable. As you've noted, vendors have not been actively
   participating in these discussions. Do you think they'll suddenly
   decide to start discussing things openly if we move it out of a
   kernel.org tree? You must know how reluctant vendors are to draw
   attention to themselves when it comes to patents.

 - some vendors may decide not to use Linux, and switch to embedded
   windows instead if we don't have a clearly supported way of
   avoiding these patents in the Linux kernels.

 - we'd be setting up the kernel to have a deliberate long term
   difference between what a large part of the user base runs and what
   is tested for kernel.org kernels. As I said previously, I think
   that is poor software engineering practice. I know you disagree,
   but I also know that some other people do agree. I suspect you
   would be more inclined to agree if this patch had nothing to do
   with patents.

I suspect you are right that many vendors would apply it anyway if it
wasn't in a kernel.org kernel. Is that sufficient to stop a new round
of lawsuits? Maybe. If that is what is decided then I guess we'll find
out over the next year or two.

Cheers, Tridge
--
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