Subject: RE: Patent-based dual-licensing open source business model
From: Brian Behlendorf <>
Date: Fri, 15 Sep 2006 09:43:49 -0700 (PDT)

On Thu, 14 Sep 2006, Lawrence Rosen wrote:
> If one of our patent claims reads only on a little open source module
> ("LOSM") in a big blob of open source stuff ("BBOSS"), then our covenant
> doesn't assert rights over that bigger blob. Only modifications to LOSM need
> be disclosed. This is consistent with one of our philosophical goals, namely
> that improvements to patented technology should be shared and published. It
> is also similar, in some respects, to Mozilla, except I use the words
> "module" and "blob" instead of "file."

The license you proposed doesn't make this clear at all, at least on my 
read of it.  A clear statement that "only the modified software that 
embodies the patent inventions need be published publicly" need be made.

> On the other hand, if we have other patent claims in our portfolio that read
> on BBOSS directly, or on different modules in BBOSS, or on combinations of
> LOSM with other software, then we can also require *that* software be
> disclosed.

Totally reasonable, though this does point out that there might be a much 
greater degree of dispute over scope.  If Mozilla were to be designed in a 
way to support IC's method of transcoding, but actually left the software 
that implements the specific technique to a separate plug-in that had to 
be downloaded separately by the end-user, even that built-in "support" 
might be seen as embodying the patent, totally aside from concerns about 
inducement to infringe.

As an imperfect comparison, before Apache httpd forked from NCSA, there 
was experimental support for PEM, a cryptography precursor to SSL.  To 
actually use it you had to set some compile options and link with a PEM 
library which was not a part of the httpd source code and which the httpd 
developers did not distribute.  One day, before open source crypto export 
was legalized, the U.S. National Security Agency asked NCSA to remove 
their PEM "hooks" from their older httpd.  NCSA passed this information 
along to us with a strong hint that it would be a good idea to do the same 
thing, and since no one was using PEM and SSL was on its way and the 
crypto regs looked likely to fall anyways, we agreed.  While this is 
different from talking about whether any sort of "patent" read on Apache 
httpd even while we weren't redistributing PEM, it suggests that one might 
argue for a broader interpretation.

From a layman's perspective, there appear to be a significant number of 
patent cases that question your claim that it's a simple matter to 
determine whether a work infringes on a particular patent.  With patents 
being often defined so broadly and so confusingly, and the final judgement 
resting upon a lay judge, it would appear to be at least as difficult to 
judge whether a work really reads on the patent, and what the smallest 
portion of work does, as it is to answer the "what is a derivative work" 
question in copyright law.  Not to even consider what will probably be the 
earliest toughest case, those who've created very similar but not exactly 
equivalent approaches to transcoding as IC.

> I want to avoid any impression that linking, or exchanging data over an API,
> or any other way of making software work with other software, is what
> matters. All you have to do is lay the patent claim and the software on the
> table for review; whatever software the claim reads on must be open source.

More importantly, it sounds like it's the *smallest possible portion* of 
one's software system that implements the patent.  But you, the patent 
holder, to maximize licensing revenue, will be incented to argue in the 
other direction - for a broader interpretation of what reads on the 
patent.  So better clarity on the scope feels necessary.