Re: CONFIG_VFAT_FS_DUALNAMES regressions

[Alan Cox]

> > 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). If
they are going to disable stuff then they'll pull the lot (loss of risk
for free). 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.

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

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