Subject: RE: Patent-based dual-licensing open source business model
From: "Lawrence Rosen" <>
Date: Fri, 15 Sep 2006 16:19:45 -0700

> 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."

> Brian Behlendorf responded:
> 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.

[LR:] We rely on patent law for that. It is patent misuse to use a patent to
try to control other, unrelated works. (In lay terms, see We could lose our patent if we
tried that. If our patent is not embodied in BBOSS, we have no standing to
control the use or publication of BBOSS.

> > 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.

[LR:] I don't understand how that is a risk with our Covenant. Software
either embodies the patent or it doesn't. Furthermore, we expressly promise
in our Covenant not to sue developers or distributors of open source
software for contributory or inducing infringement. Mozilla or Apache or
anyone else can do what you suggested in open source software with complete
confidence that we won't sue them. What other reassurance do you need about

> 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.

[LR:] It is enough different to be irrelevant. 

> >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.

[LR:] I didn't intend to suggest it is always easy to determine whether a
work infringes on a particular patent. But there are a few important reasons
why it isn't as bad as you suggest:

1. A patent claim is required to be precisely stated. If it isn't, it can be
invalidated. Community Patent Review, a process we support and have joined,
will help us make sure our patent claims aren't ambiguous. If you think our
patent is confusing after you read it, then we haven't done our jobs right.
Don't lump crappy patents in with ours just because we're all patents. (I
happen to think that my law partner, Michael Einschlag, writes high-quality

2. A patent claim is, by definition, limited in scope. There is no obvious
scope limitation for derivative works. Is Linux really a derivative work of
Unix? Ask SCO and IBM, although that's a bad example for other reasons. 

3. There are a limited number of patent claims. Remember how Dan Ravicher
was able to do a rough infringement analysis of Linux and found a discrete
set of possible problems to investigate more thoroughly? It is much more
bounded a problem than the one faced by Black Duck and Palomida when looking
for copyright infringement, although recognizing patent infringing
embodiments is more complicated than recognizing infringing copies.

4. A patent claim has been vetted, so you're not usually wasting your time
comparing your software to every cockamamie idea someone has. I know, this
will strike a sour note with realists who understand the current patent
examination system, but we're going with Community Patent Review for our
patents to make sure our patents are vetted by experts.

5. Patent claims are (sooner or later) published for all to see. In our
case, we promise to disclose in the same ways that other academic work is
disclosed, openly, for peer review and public comment. There need be no

6. Similarity of software to the claims is a legal issue that can be
evaluated by software experts upon whom judges and lay juries will rely.
Patent law addresses this. But you're right, sometimes equivalent methods
are also infringing, and so the analysis isn't trivial. Similarity in
copyright law derivative works analysis is also a complicated legal issue;
take a look at some of those cases!

7. Finally, don't think that a patent infringement lawsuit is always easy on
the patent owner. You see a relatively small (but unfortunately growing)
number of infringement lawsuits. What you don't see is the larger number of
"cease and desist" letters that are simply thrown in the trash and not
followed up because the cases are weak. :-) What you do see are the
complicated cases, the ones where there is a meaningful dispute worth
fighting about. 

> > 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.

[LR:] I didn't say "smallest possible portion." I said, if software X
infringes patent P, then publish X or get a license. You don't have any
requirement to publish anything that doesn't infringe P, including software
that surrounds X (links to X, exchanges data with X through an API, is a
separate part of a program that includes X, etc.), and you can remove X
(however small or large a piece it is) to avoid infringement. 

As long as you don't also infringe P2, P3, or P4....

This remains a question for analysis, but considering the list I gave you
above, you can at least have a bounded process for answering the question.