Re: CONFIG_VFAT_FS_DUALNAMES regressions

[Alan Cox]

> > Even if they go for the non-infringing tweak they will still end up with
> > patches to rip out the potentially infringing code paths.
> 
> You keep saying this and I keep pointing out to you it's not true.

You keep saying this is not true and you keep ignoring the fact that a)
it is true and b) you can look at lots of existing RPM packages and see
that today. The evidence is out there - no hearsay, no question marks, go
look.

> contributory infringement based on shipping the code.  I don't actually
> believe that a compile time option they turn on in the binary kernel to
> make it non infringing coupled with shipping code where the user could
> recompile with it off is sufficient to rise to the tests under the
> contributory infringement doctrine.

Its a simple risk test. Anything which reduces risk but does not change
functionality is something you do. Its basically a zero cost way to
reduce the chances of being shot at.

The decision they have to make is full vfat v tridgefat v fat. Once you
make that decision and any part of that decision involves not enabling a
feature because of a theoretical concern about a dubious patent you rip
the code out of your tree as well. So if a vendor picked tridgefat they'd
rip out the source bits outside of the ifdefs that switched tridgefat v
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/