On Thu, Jul 09, 2009 at 03:10:09PM +0100, Alan Cox wrote: > > 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. Look, even if what you say is valid (despite the advice of lawyers), it is still useful for us to apply the patch (with the CONFIG option) in the upstream sources. It means that support for the workaround stays in the mainstream sources, so we don't have to worry about separate patch going no longer applying as time goes by and the upstream sources change over time. *If* a vendor really wants to strip out the source code, they can do that easily enough using unifdef to strip out the one specific CONFIG option. However, I don't think they will think it's necessary, and I'll tell you why. Regardless of whether or not source code with an #ifdef'ed out (but still present) source code might be considered "contributory infringment" (and we have legal advice saying that this would not be the case), either way, the *binary*, which is to say the **product** does not contain any of the infringing functionality or code. Hence, the patent troll won't be able to use an ITC action to stop the product at the border, thus putting the potentially weak company out of business. Suing for contributory infringment takes time; potentially years, so there is plenty of time for (a) the patent troll, if it is a company like Microsoft, to suffer all sorts of public relations damange, thus revealing the claims of people like Sam Ramji as empty and cynical, and (b) for the community to rally around said company and provide defense. In addition, healing a cliam of contributory infringment is easy enough; simply releasing a version of the source code with unifdef applied won't changing the resulting binary. In any case, the fact that the patent troll won't be able to put a company out of business, but instead might have to wage a long legal war (consider how long the SCO lawsuits have dragged on), will tend to dissuade the rational troll from pursuing such a path; and even if we do have an irrational actor, (a) I don't really think Microsoft is irrational, and (b) in the U.S. you can get a lawyer to sue a ham sandwich, so there's no real proactive steps you can take to protect yourself against an irrational actor who is bound and determined to abuse the legal system; and most companies and lawyers (as opposed to people who like to play lawyers on mailing lists and TV) understand that. But in any case, even for a very risk-averse company, getting this proposed patch into mainline is useful, since at any point in time the company can get a version of the code without any code that might be claimable as being infringing by using unifdef. So it's still a net win. And if people are worried about the very small chances of problems (which perhaps we can improve), we can fix that as future patches against the mainline --- which is the right way to do OSS development. Given that Hirofumi-san has already decided to take this patch, so unless Linus decides to override his decision, this discussion is rapidly becoming moot in any case. Regards, - Ted -- 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
