On Mon, May 04, 2009 at 07:06:37PM +0200, Olivier Galibert wrote: > Because knowingly violating a patent triples the damages, among other > things. > > There's a persistent rumor that a valid microsoft US software patent > exists that covers the standard method of handling long file names on > FAT filesystems. It seems that such a patent is used by microsoft in > litigations, the latest being against tomtom. I think all of these > litigations have been settled, but I can easily be wrong. > > I have no idea whether such a patent actually exists, and even knowing > the reference (I don't) I am not competent to judge what it covers or > whether it would actually hold up in court. > > But knowingly violating a patent is consider way worse in US courts > than simple independant recreation. So I guess the knowingly part is > what the "you need a local lawyer" crowd tries to avoid. And now we get a patch that introduces a configure option above code dealing with longnames which disables a very specific piece of code. Because of that let us assume that IBM Corporate, Paul E. McKenney, Andrew Tridgell and other know what code exactly infridges that patent. IBM has worked around that code in the various embedded Linux offerings they ship and probably urge distributors to disable it. Why would we not remove that code unconditionally in that case and let other people infridge it? Or that patent is believed to be invalid and faught, and there was absolute no reason to remove it except for companies doing as part of a settlement and they could do it in their privat trees. Or both of the two above variants are wrong. That's why we do need a good description of what is actually happening, and I don't feel a signed-off-by is justified if adds an option that can disable known infringing code (if that actually is the case) but leaves it otherwise if fine. If it's not actually infringing we need an even better explanation. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html