Subject: RE: Patent-based dual-licensing open source business model
From: "Lawrence Rosen" <lrosen@rosenlaw.com>
Date: Thu, 14 Sep 2006 21:56:36 -0700

Brian Behlendorf wrote:
> ... I was still confused even
> after the discussion of the term "use" about a couple of things:
> 
> a) Open source copyright licenses care almost exclusively about 
> redistribution - this license cares about use.  Only the APSL, as far 
> as I can recall, places requirements upon actions that don't involve 
> redistributing a copy of the code to someone else - if you modify it 
> and deploy it to someone over the net, you have to give that someone 
> your modifications plus the original source.  Here, it sounds like 
> even if I modify it for my company's internal use exclusively, I still 
> have to either license or redistribute publicly - something not even 
> the GPL requires.  Discussion here seems to echo this point.  Is this the
case?

[LR:] Yes, this is the case. This covenant cares about use because its
subject is patents and its goal is to drive revenue from commercial uses.

> b) If given a), does that mean that the only circumstance in which I 
> can use the software internally, without being compelled to release 
> something publicly or pay licensing fees, is if I use it without 
> modifications (aside from "fixes", as you describe)?

[LR:] Yes. Or for experimentation, research or teaching.

> c) What's the boundary of "modifications"?  Let's say I take your code 
> and integrate it one of ten different ways with other proprietary 
> software.  I could do anything from link it statically to make calls 
> over a web services API.  Given the nature of IC's technology, it's 
> likely to be something very tightly linked into an I/O pipeline, 
> probably as part of the same process space as an app server or even
internet protocol server.
> Ideally we'd get a definition close to something like Mozilla's.

[LR:] I don't want to adopt your characterization of "the nature of IC's
technology." We have claims that have potential application at various
levels of the hardware/software stack. Anyway, if our model works, it ought
to work for patents involving lots of different kinds of software
technology. So perhaps it is best to keep this discussion general as to
technology and focus on principles. 

Remember also that this relates to *internal modifications of open source
software*, not the different issue of making new products and distributing
or selling them in commerce.

The scope of the internal modifications we care about relates to the scope
of the patent claims we own. We start by asking, "Does this software
infringe any of our patent claims?" If so, we can assert our rights and
demand publication of that software, or a license.

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

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. This is very different from determining whether BBOSS, or LOSM,
or that other software is a derivative work under copyright law. Instead, we
look at the scope of the patent claim, and the software itself, and
determine whether the software infringes. If it does, it must be disclosed
or licensed.

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. 

By the way, this has two important consequences:

1) Commercial companies can avoid infringing by taking LOSM out of BBOSS.
Replace it or design around it. That also encourages innovation, even if it
doesn't increase our licensing revenue.

2) The value of a patent claim is directly related to the scope of what it
covers. By way of contrast, a sliver of GPL-licensed code is believed by
some to infect the entire product. We don't try to reach any farther than
our patent claims entitle us to go.

> I like the direction this is taking.  I just want the social contract 
> to be clear enough that we don't have to default to too many "trust 
> us" kinds of responses, and to avoid scaring off potential users of 
> this kind of software.

[LR:] Thanks! 

/Larry

[LR:] P.S. I welcome opinions from patent attorneys on this point. I agree
with Brian that we don't want any "trust us" responses when people ask what
this covenant means. If our language isn't clear or its legal interpretation
ambiguous, we should consider changing it.