Subject: RE: license with patent grants appropriate for specifications?

From: "Lawrence Rosen" <[email-masked]>
Date: Tue, 11 Jan 2005 10:39:14 -0800

The compromise I try to reach with patent owners in the context of industry
standards is that 
(1) patent owners may choose to limit the scope of their patent license
grants to compliant implementations, and 
(2) those patent licenses may not restrict anyone from creating and
distributing non-compliant implementations.

Point 2 is necessary so as to be consistent with open source freedom to
create derivative works. Point 1 recognizes that patent owners and standards
organizations are usually not interested in expressly granting broad patent
licenses for non-compliant implementations.

As to the specification copyright license, it is consistent with open source
principles if it grants you permission to create derivative works of the
specification. [Note that this is also consistent with the right of anybody
to create a derivative work of a published patent.] But anyone creating
non-compliant implementations of an industry standard should read the scope
of the patent license grants carefully to determine if additional patent
licenses will be necessary to make, use or sell those products. 

/Larry

P.S. I'm cross-posting this on the IETF IPR-WG list, because there is mutual
interest in both the open source licensing community and the IETF standards
community about how to license patents and copyrights for industry
standards.

Lawrence Rosen
Rosenlaw & Einschlag, technology law offices (www.rosenlaw.com)
3001 King Ranch Road, Ukiah, CA 95482
707-485-1242  ●  fax: 707-485-1243
Author of “Open Source Licensing: Software Freedom 
               and Intellectual Property Law” (Prentice Hall 2004)
 
> -----Original Message-----
> From: Ian Jackson [mailto:[email-masked]]
> Sent: Tuesday, January 11, 2005 3:41 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: license with patent grants appropriate for specifications?
> 
<snip>
> Note that it is not good enough, when approving a specification which
> involves patented techniques, for there to be a patent licence for
> implementations of the specification.
> 
> This is because the users (and other developers) of an Open Source
> program must be allowed to modify the program without fear of legal
> repercussions.  Permitting only those modifications where the program
> remains compliant with the spec is insufficient.
> 
> For the software to be Open Source, the patent licence must be
> sufficiently broad that all derivatives of the original work are
> covered; this usually means either a general royalty-free patent
> licence is needed, or a patent licence written so that it covers all
> software with the relevant copyright terms.
> 
> Ian.

_______________________________________________
Ipr-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipr-wg

---

From: Bob Scheifler <[email-masked]>
Date: Tue, 11 Jan 2005 18:46:15 -0500

> specification.

So, is it reasonable to take the following approach:
  - issue the specification itself under an existing open source license,
    one that in and of itself does not grant any patent rights with respect
    to implementations of the spec
  - provide separately a patent-only license that grants patent rights
    to compliant implementations of that specification (or broader if
    one wishes)
rather than trying to bundle these together into a single open source
license? The patent-only license, not being a source license at all,
presumably does not have to be an open source license.

- Bob

---

From: "Lawrence Rosen" <[email-masked]>
Date: Tue, 11 Jan 2005 19:52:38 -0800

> presumably does not have to be an open source license.

Most robust open source licenses contain both copyright grants and patent
grants. These licenses should be sufficient. But if the only thing that is
being contributed is a patent without any copyrightable subject matter, then
a standalone patent license would be needed. But that patent license must be
compatible with open source. It cannot impose conditions that are
incompatible with open source.

So, for example, in the Marid working group at IETF, Yahoo licensed
DomainKeys under a copyright/patent license, but Microsoft used only a
patent license (in that latter case, one that was not compatible with open
source).

/Larry

Lawrence Rosen

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Bob Scheifler
> Sent: Tuesday, January 11, 2005 3:46 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]'

---

From: "todd glassey" <[email-masked]>
Date: Wed, 12 Jan 2005 06:01:10 -0800

Bob Larry - why not build a couple of OS licenses like the different
copyright statements available under the current RFC's.

Todd

---

From: Bob Scheifler <[email-masked]>
Date: Wed, 12 Jan 2005 10:13:27 -0500

> grants. These licenses should be sufficient.

This goes to the heart of my original question. To be concrete,
if use the Apache License, Version 2.0 for a specification, and
I look at its grant of patent license, it covers patent claims
that are "necessarily infringed by the [specification]", it does
not explicitly cover patent claims that are necessarily infringed
by implementations of the specification. Am I correct in assuming
that a mere specification cannot directly infringe a patent claim?
(It may well be subject to claims of contributory infringement.)
In which case, the grant of patent license would seem to be
insufficient for enabling implementations. Or is there some other
existing open source license with more suitable grants? Looking at
AFL 2.1, perhaps "patent claims ... embodied in the [specification]"
is broad enough, but since the grant is only to "make, use, ... the
[specification] and Derivative Works", is that reasonably interpreted
as extending to implementations of the specification? And the AFL 2.1
termination provision appears to be limited to claims that the
"[specification] infringes a patent", so the same question about
whether a specification can directly infringe a patent arises.

- Bob

---

From: Bob Scheifler <[email-masked]>
Date: Wed, 12 Jan 2005 10:40:42 -0500

> copyright statements available under the current RFC's.

In the relicensing effort that we (Sun) are currently undertaking
for Jini technology (specifications and code), our number one
requirement is to use an existing, commonly used and accepted
open source license. I really, really don't want to invent a new
license if I can possibly avoid it. Ideally, we'd like to use the
same license for our specifications that we use for our code. The
Apache License, Version 2.0 is a prime contender, but when used
for specifications, I'm concerned that its patent license will
not be construed as extending to implementations of the spec.

- Bob

---

From: Ian Jackson <[email-masked]>
Date: Fri, 14 Jan 2005 16:17:41 +0000

> distributing non-compliant implementations.

This is disingenuous.

The only way to read those two statements so as not to be directly
contradictory is to infer that point 2 means that the patent licences
fail to licence non-compliant implementations but do not contain an
explicit contractual term forbidding the licensee from producing
non-compliant implementations.  Of course, such a term would
(depending on its terms) very likely be heinously awful.

But what your point 2 _appears_ to say is that the patent fails to
restrict non-derivative works, which is a direct contradiction of
point 1.

So I say that your posting is misleading.

> licenses for non-compliant implementations.

These two points are in fact in direct opposition.  The freedom to
create and distribute noncompliant derivative works is one of the
freedoms that define Open Source (or Free) software.  If there is a
patent that prevents this then the software is not Open Source.

Ian.

---

From: Ian Jackson <[email-masked]>
Date: Fri, 14 Jan 2005 16:22:54 +0000

>     to implementations of the spec

Yes, that is fine as far as it goes, but of course as you recognise

>     to compliant implementations of that specification (or broader if

As I wrote earlier, the patent licence must extend at least to
noncompliant Open Source derivatives of an original compliant
implementation.  Otherwise the software is not Open Source because the
community is not free to make and distribute modified versions.

Ian.

---

From: "todd glassey" <[email-masked]>
Date: Sun, 16 Jan 2005 11:38:06 -0800

The problem is ultimately that one size doesn't fit all needs, and that
means either reconfigurable licensing or multiple licenses.

Todd

---

From: Sam Hartman <[email-masked]>
Date: Fri, 21 Jan 2005 11:59:14 -0500

>>>>> "Ian" == Ian Jackson <[email-masked]> writes:

    Ian> Lawrence Rosen writes ("RE: license with patent grants
    Ian> appropriate for specifications?"):
    >> The compromise I try to reach with patent owners in the context
    >> of industry standards is that (1) patent owners may choose to
    >> limit the scope of their patent license grants to compliant
    >> implementations, and (2) those patent licenses may not restrict
    >> anyone from creating and distributing non-compliant
    >> implementations.

    Ian> This is disingenuous.

    Ian> The only way to read those two statements so as not to be
    Ian> directly contradictory is to infer that point 2 means that
    Ian> the patent licences fail to licence non-compliant
    Ian> implementations but do not contain an explicit contractual
    Ian> term forbidding the licensee from producing non-compliant
    Ian> implementations.  Of course, such a term would (depending on
    Ian> its terms) very likely be heinously awful.

    Ian> But what your point 2 _appears_ to say is that the patent
    Ian> fails to restrict non-derivative works, which is a direct
    Ian> contradiction of point 1.

    Ian> So I say that your posting is misleading.

    >> Point 2 is necessary so as to be consistent with open source
    >> freedom to create derivative works. Point 1 recognizes that
    >> patent owners and standards organizations are usually not
    >> interested in expressly granting broad patent licenses for
    >> non-compliant implementations.

    Ian> These two points are in fact in direct opposition.  The
    Ian> freedom to create and distribute noncompliant derivative
    Ian> works is one of the freedoms that define Open Source (or
    Ian> Free) software.  If there is a patent that prevents this then
    Ian> the software is not Open Source.

It's a bit more complicated than that.  There are a lot of folks in
the open-source community that ignore patents to one degree or
another.  I'm most familiar with Debian's policies in this matter, but
I know other projects have similar requirements.

What Debian seems to do is isomorphic to the following.  Debian looks
at a license assuming that there are no patents on the software and
considers whether the license is free.  In this analysis a patent
grant applicable only to compliant implementations [*] would be OK, but a
license condition requiring you only produce a compliant
implementation would not be OK.  I.E. the license can say you get
these open-source copyright licenses and in addition if your
implementation happens to be compliant you get these other patent
licenses.  A license that required your implementation be compliant
and gave you both the copyright and patent licenses would be
problematic.

Patents are of course not completely ignored.  If it looks like a
particular patent is going to be enforced, the analysis gets more
complicated.  There are a lot of patents out there.  You cannot assume
all of them are valid.  Moreover most open-source projects do not have
the resources to determine whether some software actually infringes
some particular patent.  Putting it mildly, there is significant risk
in the strategies people adopt in practice.

[*]  The case that has actually been analyzed is a patent grant for
patents infringed by the software as originally shipped.  Some in the
Debian community would probably argue that the compliant
implementation requirement is somehow more odious.
In this respect, Debian, like the IETF is consensus based.  As we are
aware, building consensus on IPR issues is challenging.

--Sam