Subject: FSF's comment on draft-housley-tls-authz-extns

From: John Sullivan <[email-masked]>
Date: Wed, 11 Feb 2009 12:28:43 -0500

The Free Software Foundation and the GNU Project oppose publication
of "Transport Layer Security (TLS) Authorization Extensions"
(draft-housley-tls-authz-extns) as a proposed standard. We do not
think that RedPhone Security's 1026 disclosure filing provides
sufficient assurance to free software users that they will not be
considered in violation of RedPhone's patent. 

In response to a previous RedPhone patent disclosure, GnuTLS removed
its support for these authorization extensions. The updated
Licensing Declaration does not provide assurance sufficient for
GnuTLS to restore this support, and the same unfortunately holds
true for any other software maintained by the GNU Project.

The Licensing Declaration starts out right:

> RedPhone Security hereby asserts that the techniques for sending
> and receiving authorizations defined in TLS Authorizations
> Extensions (version draft-housley-tls-authz-extns-07.txt) do not
> infringe upon RedPhone Security's intellectual property rights
> (IPR).

However, it is then followed by an important caveat:

> The values provided in, and the processing required by the
> authorizations ("authz_data" in the Protocol Document) sent or
> received using the techniques defined in TLS Authorizations
> Extensions are not specified in the Protocol Document. When an
> implementation generates the authorizations or processes these
> authorizations in any of the four ways described below, then
> this practice may be covered by RedPhone Security's patent
> claims.

It appears that RedPhone's disclaimer covers software developers who
implement the standard in a vague sense, but not the people who then
actually use that software. A patent disclaimer must clearly cover
both developers and users to be acceptable. Furthermore, the caveat
is not written exclusively, leaving the door open for further
claims. It does not say that the four ways described are the *only*
practices that may be covered.

RedPhone's assurance that it will "grant licenses for such uses in a
fair and nondiscriminatory manner" does not address the problems
raised by their assertion, because software users cannot be expected
to place trust in a company's judgment of what constitutes fair or
nondiscriminatory. No company should be vested with the power to
make case-by-case licensing decisions about who can and who cannot
use or implement a standard, and users regardless should not have to
pay for permission to use Internet standards.

We know that the IETF and IESG largely share our view that
patent-encumbered standards are unacceptable. We believe that the
process has twice now reached the proper conclusion -- the draft has
been rejected as a standard. Please do not allow this decision to be
negated. If RedPhone is serious about providing a patent assurance
sufficient to cover both writing and using software that implements
these authorization extensions, the FSF would be happy to work with
them on drafting text that makes this intent clear.

On a broader note, we'd like to suggest that the IETF consider the
impact of of patents and copyrights on proposed standards
specifically and separately, instead of under the umbrella of IPR or
"intellectual property." The term lumps together disparate areas of
law and inaccurately frames questions then discussed as analogous to
questions about property rights over physical objects -- a framing
that suits companies who wish to extend the influence of their
copyrights and patents. It also has the effect of including other
laws in the discussion which don't actually pertain to the question
of who can use the standard. The term has unfortunately become
widespread, but a community as concerned and responsible with
language as the IETF should take leadership in this area and reject
its use.

Thank you for the opportunity to comment on these issues. We
recognize that the volume of mail generated by our announcement
about this issue to the free software community may be causing
inconvenience, but causing inconvenience was not the point of that
call. In our reading of the comments that have been sent so far from
the free software community, the majority of them are from people
who work in related areas and have taken time to think through and
express their concerns. We hope the IETF will consider each comment
on its individual merit, and if the volume of mail is interfering
with that process, consider providing in the future a separate
address for comment that is not the general mailing list. Our goal
and our encouragement to the public is to participate in the process
according to the directions provided, not to spoil it.

-- 
Sincerely,
The Free Software Foundation

---

From: Willie Gillespie <[email-masked]>
Date: Wed, 11 Feb 2009 15:24:52 -0700

I don't know anything about patents and how they all work -- so I am 
probably speaking out of place.  Is it possible to just have RedPhone 
re-issue the Licensing Declaration with "better" wording?

Willie

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 11 Feb 2009 15:01:49 -0800

>considered in violation of RedPhone's patent.

Serious question: what about every other protocol for which there are IPR claims in the IETF IPR repository? I suspect that most of those IPR statements do not give sufficient assurance to free software users that they will not be considered in violation of various patents.

That is, you have made a call to action on one particular document: what about the rest of the ones that have IPR claimed on them?

>true for any other software maintained by the GNU Project.

Maybe that will lead you to think that you should just not implement the authorization extensions. Why does the standards status of the eventual RFC affect your implementation decisions? This is an age-old rathole^Wdebate in the IETF, but one that most participants have answered for themselves.

>patent-encumbered standards are unacceptable.

Then "know" is too strong a word, given that you are most likely wrong.

>"intellectual property."

This sounds like you are suggesting that we spend much more time on our process to satisfy people who only contribute to the discussion (if I can call the recent mail flood a "contribution") only every few years. Please understand that we might not like that suggestion, any more than if we suggested to the FSF that they do extensive patent research on every protocol and format that is embodied in any GNU-licensed software anywhere.

>Thank you for the opportunity to comment on these issues.

This mailing list is open 24/7, not just when someone issues an call-to-arms. We would appreciate well-thought-out input at other times as well.

>We
>call.

Welcome to the world of calls for action having unintended negative consequences. The IETF has our own history with that...

--Paul Hoffman, Director
--VPN Consortium

---

From: Sam Hartman <[email-masked]>
Date: Fri, 13 Feb 2009 10:23:06 -0500

>>>>> "John" == John Sullivan <[email-masked]> writes:

    John> The Licensing Declaration starts out right:

    >> RedPhone Security hereby asserts that the techniques for
    >> sending and receiving authorizations defined in TLS
    >> Authorizations Extensions (version
    >> draft-housley-tls-authz-extns-07.txt) do not infringe upon
    >> RedPhone Security's intellectual property rights (IPR).

    >> this practice may be covered by RedPhone Security's patent

    John> It appears that RedPhone's disclaimer covers software
    John> developers who implement the standard in a vague sense, but
    John> not the people who then actually use that software. A patent
    John> disclaimer must clearly cover both developers and users to
    John> be acceptable. 

I'm sorry, I don't see this at all.  I appreciate that you quoted the
text in question.  However I don't see anything in the language you
quote that applies differently to either users or developers.

The text is saying that the transport mechanisms described in the
Housley draft are not covered by the patent.  However the text goes on
to say that some ways in which an implementation might employ those
transport mechanisms would be covered by the patent.  As I read the
text, both developers and users who used the mechanisms in the Housley
draft in any of these four ways would infringe the patent, Redphone
claims.

However I'll also note that there are significant uses of the
transport mechanisms in the Housley draft that are interesting both to
the free software and IETF communities that fall well outside these
four areas.  In particular, transporting in-band group memberships and
authorization/attribute assertions see.ms to fall outside these areas.

I can understand why the GNU project would not choose to ship an
extension to GNU TLS that used this transport to send agreement
locations.

However, it is completely absurd to claim that because some
infrastructure building block could (by writing additional software)
be used in a manner that infringes a patent that no free software
version of that building block can exist.  As an example, the FSF
ships a compiler collection that can be used to infringe a number of
patents in the hands of someone who has infringing source code.  The
GNU/Linux kernel includes a TCP implementation that can be used to
infringe Redphone's patent.

I'd agree with you that things would be problematic for the free
software community if the ways in which this technology were going to
be used by free software infringed the patent.  I also agree with you
that there are things that one could choose to standardize on top of
this draft that would be highly problematic for the free software
community.  Should anyone choose to standardize those items, I will
join you in a protest.

Until then, please pick battles worth fighting.  There are a lot of bad patent issues out there; this is no where near the top.

---

From: "Lawrence Rosen" <[email-masked]>
Date: Fri, 13 Feb 2009 08:18:10 -0800

Lots of the recent emails on this list refer to Redphone's "patent" but
there is no such thing.

As anyone who has ever worked with real patents knows, there is a great
difference between a patent application and a patent. Whatever claims are
written in patent applications are merely wishes and hopes, placeholders for
negotiated language after a detailed examination of the application. Until
the PTO actually issues a patent, nothing is fixed. And even then,
newly-found prior art and other issues can defeat an issued patent. 

Why are we all so afraid of Redphone? Who gives a damn what patent claims
they hope to get? 

There's something wrong with the IETF process if spurious and self-serving
assertions that "a patent application has been filed" can serve to hold up
progress on important technology. I wish you'd ask real patent attorneys to
advise the community on this rather than react with speculation and a
generalized fear of patents.

/Larry

Lawrence Rosen
Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com)
3001 King Ranch Road, Ukiah, CA 95482
707-485-1242 * cell: 707-478-8932 * fax: 707-485-1243
Skype: LawrenceRosen

---

From: [email-masked]
Date: Fri, 13 Feb 2009 08:13:35 -0800 (PST)

> ...

> quote that applies differently to either users or developers.

Well, there's something of an exemption for developers producing generic
uilding block software. But I take your point to be that a developer who, say,
puts in specialized support for a Redphone critical extension (item one of the
four), would clearly be infringing.

> draft in any of these four ways would infringe the patent, Redphone

Nicely put. I agree with this assessment.

> authorization/attribute assertions see.ms to fall outside these areas.

Exactly.

> extension to GNU TLS that used this transport to send agreement

Sure, that would clearly infringe. The question to my mind is whether or not
this is an overly onerous restriction. I don't think it is but others may
disagree.

> infringe Redphone's patent.

This is the point I was trying to make in my earlier response. There are many
use-case patents built on top of pretty much any protocol building block you
can think of. If we adopt the theory, which is implicit in many of the
objections I've seem to this document, that we cannot work on protocol building
blocks when such use-case patents exist, we'll effectively be out of business.

I will also point out that the list of IPR disclosures includes very few of
these patents. Demanding the disclosure of all such patents participants are
aware of would be ... interesting.

				Ned

---

From: "Powers Chuck-RXCP20" <[email-masked]>
Date: Fri, 13 Feb 2009 11:39:55 -0500

+1

Regards, 
Chuck 
------------- 
Chuck Powers, 
Motorola, Inc 
phone: 512-427-7261
mobile: 512-576-0008

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Friday, February 13, 2009 10:14 AM
> To: Sam Hartman
> Cc: [email-masked]
> Subject: Re: FSF's comment on draft-housley-tls-authz-extns
> 
> > ...
> 
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: Thierry Moreau <[email-masked]>
Date: Fri, 13 Feb 2009 13:19:30 -0500

> Lots of the recent emails on this list refer to Redphone's "patent" but

In my emails, I used the reference to US patent application 11/234,404
as amended on 2008/01/25.

> newly-found prior art and other issues can defeat an issued patent. 

Indeed, plus the geographical applicability restrictions that are
determined 30 or 31 months after the priority date according to PCT
rules - the above patent application has national or regional 
applications in Australia, Canadian, and the EU (I didn't check the EPO 
database, perhaps it's not the whole EPC member states).

> Why are we all so afraid of Redphone? Who gives a damn what patent claims

I guess (i.e. speculate) that it is more convenient for the FSF to get
publicity / support with a case involving a small organization without
significant market presence and lobbying resources that could retaliate
an FSF campaign more visibly. I thought the GnuTLS connection triggered
the FSF action, but Simon corrected me on this hypothesis.

> generalized fear of patents.

I agree.

You may notice that the FSF did not share (AFAIK) any result of
investigation into the patent application status which would include
some professional advice.

Actually, two PCT/WIPO search/examination reports are on-line, and one 
*denies* novelty to every claims but 3 of them, and denies inventive 
step to all of them! The patent applicant may (further) amend the claims 
at the national or regional phase, but the initial assessment is not so 
good for the patent applicant. Check by yourself, I do not provide 
professional advice in here.

So it's really the FSF campaign that is detracting the IETF process here 
in the way you are alluding above. The Redphone's IPR disclosure 1026 
verbatim does not detract the IETF process.

Again, finer investigations and analyses of IPR issues (finer than 
ideological opposition to patents) would be benefitial to the IETF.

Regards,

- Thierry Moreau

---

From: "Lawrence Rosen" <[email-masked]>
Date: Fri, 13 Feb 2009 10:48:09 -0800

Thierry Moreau wrote:
> Check by yourself, I do not provide

And that's why I made my suggestion that we do these analyses in a
professional manner! Too many patent-savvy attorneys (and their companies?)
expect the community to decide these things in a random fashion. The
IETF--collectively--needs professional advice, including from you. 

I will allow that you speak for yourself and offer no guarantees or
warranties. But expert attorneys need to give us their expert opinions about
the effects of specific patents on our specific work.

That's why I'm so irritated that the previous IPR WG, since disbanded
(fortunately), refused even to discuss a patent policy for IETF. Of course
such studied ignorance can lead to community displays of confusion and
anger. Hence the FSF campaign and others like it; entirely justified.

/Larry 

Lawrence Rosen

> From: Thierry Moreau [mailto:[email-masked]]
> Sent: Friday, February 13, 2009 10:20 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: References to Redphone's "patent"
> 
> 
> 
> Lawrence Rosen wrote:
>

---

From: Ted Hardie <[email-masked]>
Date: Fri, 13 Feb 2009 11:51:40 -0800

At 10:48 AM -0800 2/13/09, Lawrence Rosen wrote:
>(fortunately), refused even to discuss a patent policy for IETF.

Armed with my calming cup of white tea, I point out that this is not
true.   The group considered the question of whether an update in
this area was required, and it declined to take on any change. 

The current policy is that IETF participants are required to notify
the IETF of any IPR which they reasonably and personally know
to cover a contribution.  This allows individual participants to make
informed decisions about whether they wish to support work
on those contributions and the WGs and IETF as a whole whether it
wishes to publish the work, given the known situation.

Taking that set of decisions out of the WGs and into a specialist
body has substantial risks, chief among them the risk that the body's
analysis of the risk does not come with insurance cover for the
decisions taken by individuals.  If the body says "This patent
application is invalidated by prior art" and the patent examiners
do not agree, those who have acted on that basis are in a troublesome
situation.  If the specialist body says "This patent does not cover this draft"
and a court later disagrees, the same is true.  Also, if the body says "this
patent does cover this draft", it is the WG participants who spend
time and effort to develop an alternative, possibly only to later discover
that they would have disagreed with the specialist body on either
the coverage or the risks inherent in infringement.

The IPR working group also pointed out, repeatedly, the risk in demanding
that all submissions to the IETF have no known encumbrance:  anyone
can claim they have covering IPR at any time and use that tool to block progress
on a standard.  Given the value of maintaining a proprietary lock on some
areas, this is a substantial risk.

The IETF policy amounts to this:  you must disclose what you know, and the
people impacted by the decision make it.  I'm sorry that irritates you, Larry,
but I remain convinced that it is the right thing for the IETF.

Two cents and one bag of "Moonlight Spice", steeped 5 minutes, worth
of opinion,
			Ted Hardie

---

From: Thierry Moreau <[email-masked]>
Date: Fri, 13 Feb 2009 15:02:54 -0500

Lawrence:

I think we are close to intellectual agreement([0]), but see below. 
(Nothing to do about my personal position as an [---] advice provider.)

> anger. Hence the FSF campaign and others like it; entirely justified.

Maybe s/justified/to be expected/? I don't quite follow how the FSF 
campaign may be justified if the underlying patent application details 
has been ignored.

If among the high volume e-mails triggerd by the FSF there was one based 
on "finer investigation and analysis", I would expect the IESG to count 
this one as an IETF community participation. Simon, as a GnuTLS project 
leader, stated he did not read the patent.

You seem to suggest that "studied ignorance" should be fixed at the 
IETF/IESG institution level, and until done, the institution gets what 
it deserves (i.e. is hurt by FSF and othe campaigns as expected).

I'm comfortable with either way, fighting studied ignorance at the 
participant or institution level.

- Thierry Moreau

[0] "intellectual agreement" is distinct from "agreement" as understood 
by a lawyer and "agreement" in the terminology used in UP patent 
application 11/234,404 - by the way it's Friday afternoon!

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 13 Feb 2009 13:41:26 -0800

There is certainly something wrong, but the source is not necessarily the IETF. The USPTO seems to be a bigger source of the problem here.

There are many problems with the current approach of leaving patent policy to groups, not least the fact that case by case negotiation on a per-working group basis is the least likely to achieve what IETF participants want.

As we saw in the case of MASS, IPR holders are unlikely to make concessions in one working group unless they can expect reciprocity and that other IPR holders will be held to the same standards in other working groups.

At this point we do in fact understand how to grant a right to use a patent in an open source implementation in a manner that protects the interest of the IPR holder in enforcing reciprocal rights in the standard. But at the time we did not. The concept of a cure clause only came later.

There were many problems with the IETF patent process. Not least the fact that many of the participants had no idea what they were talking about. As far as I know, I was the only person to submit a proposal to that group that had a lawyer as a co-author. But that did not stop certain persons who are not lawyers and have never worked in a practices group as I have dismissing my position as being uninformed in their view.

I strongly suspect that one of the reasons for the current state of the IETF IPR policy is that the only people who get sufficiently interested in it to actually attend meetings tend to be open source ideologues, representatives of large IPR holders and private consultants offering expert testimony in patent disputes.

The proposal that I made then was that when a working group is started, it specify the IPR criteria under which it is chartered. In some cases it makes perfect sense to charter a group that will be using encumbered technology. In other cases the entire purpose of the group requires that any technology be open and unencumbered.

I also proposed that rather than attempting to create yet another patent policy, that the IETF simply outsource the approach. In OASIS a working group specifies the IPR policy at the start and may choose either an open or a proprietary one. In W3C all groups are required to have an open policy. 

What that means in practice is that it is possible to have a specification that has optional extensions that are encumbered or purportedly encumbered. But it must be possible to implement the spec without using the encumbered options.

Both policies are in theory vulnerable to the type of denial of standard by bogus assertion of IPR rights attack described. But in practice so are implementations. 

-----Original Message-----
From: [email-masked] on behalf of Lawrence Rosen
Sent: Fri 2/13/2009 11:18 AM
To: [email-masked]
Subject: References to Redphone's "patent"

/Larry

Lawrence Rosen

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 14 Feb 2009 12:40:41 +1300

Phill,

On 2009-02-14 10:41, Hallam-Baker, Phillip wrote:
...
> The proposal that I made then was that when a working group is started, it specify the IPR criteria under which it is chartered. In some cases it makes perfect sense to charter a group that will be…

We've been round that argument enough times that it's become a tradition.

A priori rules like that make no sense for the IETF.

1. They inhibit innovative thinking within the WG process, because
they mean that the major technical options must basically be
decided before you start, so that you can decide which IPR regime
is going to work. And if you decide a priori to be RF, the available
solutions are dramatically constrained. Or to say it more emotively:
all the good ideas have been patented anyway.

2. They would assist the patent trolls, who could make sure to
quietly acquire patents that encumber the 'royalty free' solution
just in time for the standard to be widely adopted.

Leaving the choice until later in the process isn't perfect,
but it reduces these two risks and matches the reality of
IPR laws and practices, which are heavily based on RAND and
reciprocity, like it or not.

IMHO, as always.

    Brian

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 13 Feb 2009 15:59:18 -0800

In my view major technical options should be decided before you start. This is a standards process, not an invention process.

I do not design protocols in committee, never have, never will. That type of work was possible when there were 40 people coming to IETF meetings and the problem was coordinating independent research projects. It is not a sensible use of people's time to do the type of unconstrained investigation you suggest with more than five people in the room.

Understanding the cost of the materials you intend to use is a key part of being an engineer. I like to work from price on the page catalogs. If a supplier wants to play 'guess my price' then I look to do the job another way.

What you suggest increases the leverage of patent trolls. The more working group effort is sunk into the idea that they claim proprietary ownership of, the more leverage they have. Moreover nobody can implement until the IPR issues are fully understood. 

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]]
Sent: Fri 2/13/2009 6:40 PM
To: Hallam-Baker, Phillip
Cc: [email-masked]
Subject: Re: How we got here, RE: References to Redphone's "patent"
 
Phill,

IMHO, as always.

    Brian

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 13 Feb 2009 19:43:18 -0500

I'll also add that we have now many working groups closing in on their  
ten-year anniversary, with a dozen RFCs to their credit. (DHC and AVT  
are probably among the oldest, but there are many others not far  
behind. AVT has about 90 RFCs listed.) I don't see how one can create  
a model that predicts the future that far ahead, and can be readily  
applicable across the range of items being specified. What's  
appropriate for a base spec may not be appropriate or necessary for a  
special-purpose extension.

Whether this WG model is a good one is another question, but it would  
seem peculiar to have the IPR model dictate how WGs are run in  
practice. (I suspect the pragmatic outcome would be that, say, RAI  
would have one WG for each IPR flavor...)

Also, most of the IPR these days seems to be filed by third parties,  
other than the I-D authors, often long after the I-D has been accepted  
as a WG item. (I think it would be interesting to do some statistics  
on who actually does the filing and at what stage of the I-D.) It  
would also be interesting to know whether any RFC author company has  
actually sued somebody for patent infringement, vs. the dozens of  
suits where third parties are involved. By now, we should have a fair  
amount of empirical data to know where the real threats are.

Henning

On Feb 13, 2009, at 6:40 PM, Brian E Carpenter wrote:

>> The proposal that I made then was that when a working group is  
>> started, it specify the IPR criteria under which it is chartered.  
>> In some cases it makes perfect sense to charter a group that will  
>> be using encumbered technology. In other cases the entire purpose  
>> of the group requires that any technology be open and unencumbered.
>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 13 Feb 2009 22:59:15 -0500

>>>>> "PHB" == Hallam-Baker, Phillip <[email-masked]> writes:
    PHB> The proposal that I made then was that when a working group is
    PHB> started, it specify the IPR criteria under which it is
    PHB> chartered. In some cases it makes perfect sense to charter a
    PHB> group that will be using encumbered technology. In other cases
    PHB> the entire purpose of the group requires that any technology be
    PHB> open and unencumbered.

  I didn't know you had proposed this.
  It's brilliant.  It means that we have decided things up-front.

  +1

---

From: Byung-Hee HWANG <[email-masked]>
Date: Mon, 23 Feb 2009 05:15:40 +0900

John,

> (draft-housley-tls-authz-extns) as a proposed standard. We do not

With the patent issue, i totally agree with you John. Personally i would 
like to offer a big "thank you" to FSF. Good job!

byunghee

---

From: John Sullivan <[email-masked]>
Date: Tue, 24 Feb 2009 08:42:09 -0800

> That is, you have made a call to action on one particular document: what about the rest of the ones that have IPR claimed on them?

That's a fair question -- we act on these issues as best we can, as they
come to our attention and according to their potential impact on free
software. This one in particular affects an important free software
project directly. We will continue doing our best to examine others and
respond to suggestions that people send us.

> Maybe that will lead you to think that you should just not implement
> the authorization extensions. Why does the standards status of the
> eventual RFC affect your implementation decisions? This is an age-old
> rathole^Wdebate in the IETF, but one that most participants have
> answered for themselves.
>

I'm not sure I understand this point -- the existence of the patent, as
disclosed through this process, forced the change in implementation
decision -- we were advised that the patent could apply to GNU projects
in this area.

> This sounds like you are suggesting that we spend much more time on
> our process to satisfy people who only contribute to the discussion
> (if I can call the recent mail flood a "contribution") only every few
> years. Please understand that we might not like that suggestion, any
> more than if we suggested to the FSF that they do extensive patent
> research on every protocol and format that is embodied in any
> GNU-licensed software anywhere.
>

No, we suggest this not to satisfy specific people but because we
honestly believe that it would improve the process -- intellectual
property is a loaded term that frames these discussions in a way that
favors particular points of view. 

-- 
John Sullivan
Manager of Operations
GPG Key: AE8600B6