Debian Project formally sets software patent policies

New policy rejects software patent licenses within Debian

By  

A new software policy from the Debian Project seeks to minimize its exposure to patent litigation. But could the new policies create friction with other projects within the community?

At first, you might think a statement from the Debian Project denouncing software patents was as obvious as "the sky is blue," or "Richard Stallman will make you write GNU/Linux 500 times if you call free software 'open source,'" but nonetheless, I thought the policy itself was rather interesting.

The policy is rather brief, which makes it very clear and concise. Consisting of only five clauses, the policy outlines how the Debian Project wants to handle patents associated with software: namely, it wants nothing to do with them. The meat of the policy is in the first three clauses:

Debian will not knowingly distribute software encumbered by patents; Debian contributors should not package or distribute software they know to infringe a patent.

Debian will not accept a patent license that is inconsistent with the Debian Social Contract or Debian Free Software Guidelines.

Unless communications related to patents are subject to attorney-client privilege, community members may be forced to produce them in a lawsuit. Also, patent concerns expressed publicly may turn out to be unfounded but create a good deal of fear, uncertainty, and doubt in the meantime. Therefore, please refrain from posting patent concerns publicly or discussing patents outside of communication with legal counsel, where they are subject to attorney-client privilege.

Clause One is curious to me, because it seems to be more of a washing of hands than any substantive statement. Not knowingly distributing patented software is all well and good, but one has to be careful here. Because of the wonderful complexities (read: inane stupidities) of U.S. patent law, if you are actually aware of a patent's existence on a certain invention you are using without license, then damages in any lawsuit aimed at you are going to be tripled if you are found at fault.

That's why developers like Linux kernel founder Linus Torvalds have often made public statements that they discourage any patent searches for software code.

"The fact is, technical people are better off not looking at patents. If you don't know what they cover and where they are, you won't be knowingly infringing on them. If somebody sues you, you change the algorithm or you just hire a hit-man to whack the stupid git," Torvalds wrote on the fa.linux.kernel newsgroup in 2002.

So, to me, Clause One sounds like the standard "I know nothing! Nothing!" line.

Clause Three is interesting, because it specifically requests that Debian Project members tone down the discussions of potential patent problems in public forums--and from talking about them at all outside of communications with attorneys. That is most definitely a move to lower the target profile for potential lawsuits. Clearly, the Debian Project wants to minimize the risk of a public discussion getting picked up by a troll looking to make some revenue through litigation (a la SCO, Microsoft, or Oracle) or getting subpoenaed later on down the line.

From a pragmatic standpoint, Clauses One and Three seem to be nothing more than common-sense legal practice: keep you head down and mouth closed. Clause Two, though, makes a definitive stance against software under patent licenses, and I have to wonder if this will cause some ripples in the community.

The statement that the Debian Project will not accept a patent license that is inconsistent with their existing policies is not the same as saying "we will never accept any patent license," but I am having trouble imagining that there would be any patent license the Debian Project would be cool with.

By making this statement, it raises a lot of questions about what software Debian developers will pull in from upstream or sidestream sources. I would imagine that any code coming out of SUSE Linux, for instance, would immediately be of concern under this new policy, since the patent license agreement originally made between Novell and Microsoft in 2006 is still in place for Attachmate and Microsoft. I am not sure what, if any, code is being shared between SUSE/openSUSE and Debian GNU/Linux, but this policy would seem to make any such sharing more problematic.

But one possible point of friction may lie between Debian and its famous downstream off-shoot: Canonical's Ubuntu distribution.

Neither the policy or the accompanying announcement from the Debian Project specifically mentioned Canonical or Ubuntu, but Ubuntu's patent policy (put forward in 2009) seems a bit more accepting of software patents.

Ubuntu's policy, for instance, puts forth similar disclaimer language to separate the overall project from potential patent infringement litigation, as well as establish policies on that to do if infringement is suspected (similar to the Debian Project's Clauses Four and Five), but makes no statements on accepting or rejecting software that is under any sort of patent license.

Given this difference, and Canonical's willingness to use software packages that are proprietary within Ubuntu distributions, there could arise situations where Debian's new patent policy could cause more strain on the relationship between the Debian and Ubuntu teams.

From a philosophical standpoint, Debian's new patent policy is a strong statement on the ills of software patents that, frankly, needs to be made. But like any stance made from the high moral ground, there could be logistical issues in how Debian GNU/Linux will relate to the rest of the Linux community.

Read more of Brian Proffitt's Zettatag and Open for Discussion blogs and follow the latest IT news at ITworld. Drop Brian a line or follow Brian on Twitter at @TheTechScribe. For the latest IT news, analysis and how-tos, follow ITworld on Twitter and Facebook.

Join us:
Facebook

Twitter

Pinterest

Tumblr

LinkedIn

Google+

Answers - Powered by ITworld

ITworld Answers helps you solve problems and share expertise. Ask a question or take a crack at answering the new questions below.

Ask a Question