Re: CONFIG_VFAT_FS_DUALNAMES regressions

[James Bottomley]

On Wed, 2009-07-08 at 16:37 +0100, Alan Cox wrote:
> > > 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.
> > 
> > You have asserted such, but that's not proof.  If your assertion were
> > valid, vendors would already have removed all the msdos/vfat code, which
> > they haven't.
> 
> 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?

>  If
> they are going to disable stuff then they'll pull the lot (loss of risk
> for free).

I'd agree with that, the problem is the loss of functionality ... and
actually, the best outcome for this would be to come up with a true
light weight filesystem that could replace the rather crap DOS/FAT32 one
in embedded applications based on fully free source and no patent
encumbrances and have it adopted as a universal standard for flash/USB
stick/mmc interchange.

> Remember the GPL requires you provide the *sources* you used
> to create the binaries, not redacted ones so if you don't want to provide
> feature X for some reason you need to pull it out of your source tree
> before you build.

OK, so we disagree on whether providing source code constitutes
contributory infringement.

> > > 	- do we want to ship the feature because of patent concern
> > > 	> do not ship
> > > 	- is it less risk to remove the source from our build tree or
> > > 	  configure it out
> > > 	> remove from the tree
> > > 	- is there a functionality difference to the user between
> > > 	  removing or unconfiguring it
> > > 	> No
> > > 
> > > 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.
> > 
> > I think you might be confusing two sources of risk.  The risk of
> > actually infringing a real patent is what you're covering above.  The
> > source of risk in this case is the risk of being trolled with an invalid
> > patent but have to spend millions of dollars to demonstrate such if it
> > goes to trial.  The patch mitigates the latter risk by making it
> > demonstrable at a preliminary hearing that the invalid patent doesn't
> > read upon the kernel implementation.
> 
> At that point we get into legal advice I can't comment on in public.
> However based on previous discussions about source code and other patterns
> suffice to say I don't agree.

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?

James


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