Subject: RE: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns

From: Russ Housley <[email-masked]>
Date: Mon, 09 Apr 2007 09:35:41 -0400

Dean:

I always recuse myself from IESG evaluation of a document for which I 
am an author.  You will find this to be the normal practice for all 
IESG members.

I have no financial interest in PedPhone Security or the patent 
filing.  I provided consulting services to RedPhone Security; it was 
a simple work for hire.

I have no investors in my very small consulting company: Vigil 
Security, LLC.  I am the owner, and I am the only full-time employee.

Russ

ItAt 07:47 PM 4/7/2007, Dean Anderson wrote:
>On Fri, 6 Apr 2007, Russ Housley wrote:
>
> > Dean:
> >
> > >I'm still not clear on a few things:
> > >
> > >-- When did Russ Housley learn of the Patent Filing?
> >
> > I was aware that Mark Brown was working on a patent; however, I did
> > not begin working with him until after his provisional patent
> > application was filed.  I did not see the claims until the filing
> > became public.
> >
> > Since I knew that a patent was in the works, but I did not know the
> > details, at the time we submitted the -00  draft to the repository
> > (which was February 2006), I reminded Mark Brown that an IPR
> > statement might be necessary.
>
>How long did it take to produce the draft? Presumably, you must have
>started working on the project earlier than the date of submission.
>Did you know of the patent application before submission?
>
>
>I note that you recused yourself from the decisions made on this draft.
>That is commendable. It also implies that you stand to benefit somehow
>from the draft. But the patent (assuming it is granted) gives Brown and
>Wilke a monopoly on the technology.  How is it, in general terms, that
>you will benefit from this draft?  Do you have, perhaps, a favorable
>license agreement with Brown?  Perhaps stock in Brown's company?  Did
>Brown agree to invest in your company?  Is there another patent
>application? As it stands, the information we have, indicates that only
>Brown stands to benefit, and this doesn't explain your involvement in
>these drafts. Some clarity on how you stand to benefit would be helpful.
>
>
>--
>Av8 Internet   Prepared to pay a premium for better service?
>www.av8.net         faster, more reliable, better service
>617 344 9000

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

---

From: Russ Housley <[email-masked]>
Date: Mon, 09 Apr 2007 13:29:36 -0400

Todd:

This is a follow-on note.  Did you miss the earlier one, where I said:
 >
 > I was aware that Mark Brown was working on a patent; however, I did not
 > begin working with him until after his provisional patent 
application was filed.
 > I did not see the claims until the filing became public.
 >
 > Since I knew that a patent was in the works, but I did not know the details,
 > at the time we submitted the -00  draft to the repository (which was
 > February 2006), I reminded Mark Brown that an IPR statement might be
 > necessary.

Without seeing the claims, I could not know whether or not an IPR 
statement was required.  Thus, the reminder to my coauthor was the 
appropriate action on my part.

Russ

At 12:23 PM 4/9/2007, todd glassey wrote:
>Russ - this isn't about Financial Interests its about the need to 
>formally disclose something that you are uniquely aware of that the 
>rest of the IETF isn't. That makes you liable IMHO for any damages 
>someone suffers because of this failure to disclose. And since you 
>are a IETF Manager its worse.
>
>Todd Glassey
>
>----- Original Message ----- From: "Russ Housley" <[email-masked]>
>To: "Dean Anderson" <[email-masked]>
>Cc: "Mark Brown" <[email-masked]>; <[email-masked]>; <[email-masked]>
>Sent: Monday, April 09, 2007 6:35 AM
>Subject: RE: Withdrawal of Approval and Second Last Call: 
>draft-housley-tls-authz-extns
>
>
>>Dean:
>>
>>I always recuse myself from IESG evaluation of a document for which 
>>I am an author.  You will find this to be the normal practice for 
>>all IESG members.
>>
>>filing.  I provided consulting services to RedPhone Security; it 
>>was a simple work for hire.
>>

---

From: [email-masked]
Date: Mon, 09 Apr 2007 22:08:31 -0400

>>>>> "Russ" == Russ Housley <[email-masked]> writes:

    Russ> Dean: I always recuse myself from IESG evaluation of a
    Russ> document for which I am an author.  You will find this to be
    Russ> the normal practice for all IESG members.

Russ, Dean, Todd and others.  Might I suggest that this part of this
discussion has outlived its useful life on the ietf list.  I'd like to
thank all those who have participated for helping us understand what
happened and for expressing their opinions.

However, at this point, people seemed happy with taking the draft to
the TLS working group.  The authors asked for a week delay while they
prepared a new IPR disclosure.  That disclosure seems to have hit the
IETF servers, so I'll touch back with the authors and then engage the
TLS chairs.

I'd like to suggest that discussions of what Russ should or should not
have done,rehashing the facts of the situation yet again,and comments
about specific legal obligations the IETF or its participants may or
may not have with regard to this situation are not benefitting the
ietf list.

Thanks,

Sam Hartman 
Security Area Director

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 11 Apr 2007 08:17:04 +0200

[email-masked] writes:

> The authors asked for a week delay while they prepared a new IPR
> disclosure.  That disclosure seems to have hit the IETF servers

Ah, good.  For easy reference, the new IPR disclosure is available
from:

https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=833

>From a proprietary perspective, it appears to be a rather permissive
license.  It seems to be one of the better ones that I have read
relative to the other licenses in the IETF IPR disclosure list.  Kudos
to Mark!

However, if I understand the license correctly, it seems incompatible
with free software licenses.  The RedPhone license contains:

   "1. General Use License"

   "Upon request, RedPhone Security will provide a worldwide,
   nonexclusive, fully-paid, perpetual, royalty-free patent license to
   manufacturers who (a) implement the Protocol, (b) acknowledge this
   general use license as described in Schedule B, and (c) refrain
   from implementing any Protected Assurance System Functions defined
   and listed below.  This general use license granted to
   manufacturers also flows down to sublicensees and users, to permit
   end users of these systems (including both client and server
   components) to use the Protocol, provided those users do not use
   the system as a Protected Assurance System (PAS) as defined in
   Schedule A without obtaining an End User License."

There are two problems here:

     1) Requires that vendors 'request' the license.  It would be
     better if the license was given directly to third parties without
     any action required by the third parties.

     2) The restriction of field-of-use (i.e., cannot be used with
     PAS) is incompatible with free software norms: implementations
     must be usable for any purpose as long as the license is
     followed, and several free software licenses does not permit
     restrictions like this.

Studying problem 2) in more detail for some common licenses:

     1) Section 6 of the GPL and section 10 of the LGPL which says:

     "You may not impose any further restrictions on the recipients'
     exercise of the rights granted herein."

     http://opensource.org/osi3.0/licenses/gpl-license.php
     http://opensource.org/osi3.0/licenses/lgpl-license.php

     2) Section 2.1 of the Mozilla 1.1 License:

     "The Initial Developer hereby grants You a world-wide,
     royalty-free, non-exclusive license, subject to third party
     intellectual property claims:
...
        (b) under Patents Claims infringed by the making, using or
        selling of Original Code, to make, have made, use, practice,
        sell, and offer for sale, and/or otherwise dispose of the
        Original Code (or portions thereof).

     http://opensource.org/osi3.0/licenses/mozilla1.1.php

     3) Section 3 of the Apache 2.0 License:
     http://opensource.org/osi3.0/licenses/apache2.0.php

I stopped looking at licenses after that, but I'm sure similar
problems can be found with other licenses.  These are licenses that
widely adopted TLS implementations are distributed under.

Thus, it seems that this license may allow some proprietary vendors to
implement tls-authz, but it prevents free software vendors to provide
a GPL/LGPL/Mozilla/Apache/etc implementation because the RedPhone
license is incompatible with these free software licenses.

I don't believe this was the intention.  Mark, would you like to
comment?  I am inclined to believe that Mark's license is more
consequence of lack of understanding how free software licensing
works, rather than bad-faith against free software.

Perhaps there is some use of an informational document that explains
how IPR disclosures needs to be written in order to be free software
friendly.  Mark, others, would such a document be helpful when trying
to write an IPR disclosure?

At this point, I think I'm bringing up a generic concern which also
affects many other drafts with IPR disclosures than Mark's.  It is
somewhat unfair to Mark to have to go through all these discussions
because the IETF doesn't have fully functioning procedures and/or
guidelines on this.  Still, since this document is a good example of
patented technology aiming at the standards track, with a license
incompatible with free software licenses, and I believe the IETF
should discuss the problem -- as a general problem, not just for
Mark's document -- further.

/Simon

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Apr 2007 09:28:11 +0200

Simon,

Can you identify any instance of a non-profit GPL implementor or
distributor being sued for not having "sent a postcard" for the
style of RF license you are objecting to?

    Brian

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 11 Apr 2007 10:08:09 +0200

> style of RF license you are objecting to?

Brian, two responses:

1) You seem to assume that GPL implementers would violate the patent
   license by redistributing their code without sending a postcard.
   In order words, your question assumes and implies bad-faith amongst
   GPL implementers.

   What typically happens in practice, among good-faith practitioners,
   is that there won't be any GPL (or Apache, or Mozilla, or ...)
   implementation of the patented technology at all, because the
   necessary rights cannot be acquired.

1) I don't believe this is a 'send a postcard' license.  If you read
   Mark's patent license, it starts with:

   "Upon request, RedPhone Security will ...

   I interpret this to mean that unless RedPhone responds to your
   requests, you have not received any rights.  Is this incorrect?

There are examples where companies won't respond to requests for these
type of RF patent licenses.  A recent example that came to mind was
related to the BOCU patent by IBM:

http://permalink.gmane.org/gmane.text.unicode.devel/23256

A different problem is if the patent is owned by a small company, and
the company goes away.

Still, I'm not sure even a "send-a-postcard" patent license would be
compatible with free software licenses.  Sending the postcard appear
to be an additional requirement, something that some free software
licenses explicitly forbid.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 11 Apr 2007 10:15:56 +0200

> http://permalink.gmane.org/gmane.text.unicode.devel/23256

A better URL is:

http://thread.gmane.org/gmane.text.unicode.devel/22875/focus=22938

/Simon

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Apr 2007 10:27:31 +0200

>    In order words, your question assumes and implies bad-faith amongst

Not specifically. My question is a practical one. People who receive
open source code, tweak it, and install it may often be completely
unaware that they should be asking for a license. Do we have any
practical evidence that IPR owners actually care?

>    necessary rights cannot be acquired.

Doesn't that sound like a bug in the OSS licenses to you, assuming the
desired result is to make the Internet work better?

>    requests, you have not received any rights.  Is this incorrect?

I'm assuming you will get a postcard in reply, certainly.
> type of RF patent licenses.

The phrase you quote doesn't allow for that.

> A recent example that came to mind was

I won't respond here on that specific issue.

> A different problem is if the patent is owned by a small company, and

Normally the patent will fall into the hands of whoever strips
the assets. That's why a carefully constructed perpetual RF
license is needed, in any case.
> licenses explicitly forbid.

I think that is a bug in the OSS licenses. Whatever you or I may think
of patent law, it isn't going away, and the OSS licenses need to deal
with it realistically IMHO.

    Brian

---

From: Jari Arkko <[email-masked]>
Date: Wed, 11 Apr 2007 11:29:42 +0300

Simon,

Do you have examples of licenses/IPR declarations that work better with
GPL and other forms of open source? Something for Mark and the rest
of us to use as a model, perhaps?

Jari

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 11 Apr 2007 11:16:30 +0200

> practical evidence that IPR owners actually care?

I don't know.  However, I don't understand how this aspect matters.
Let me explain how I see things, and you can pinpoint where our logic
differ.  I believe that any IPR owner would first contact this person
and ask him to follow their patent license.  Then they either they
play by the rules, and requests the license, or they don't (and a
lawsuit may happen).  Is the IETF interested in supporting people who
doesn't follow the rules?  I believe these people can and should be
educated, but the IETF should not write its rules assuming that people
will not follow rules.

> desired result is to make the Internet work better?

The assumption is false: the goal of free software is not to make the
Internet work better.

Would you also claim that Microsoft Windows license has a bug in it
because it does not permit certain things (i.e., creating patches
yourself to avoid massive security holes) that would make the Internet
work better?

I hope you get the point that your assumption here was flawed.

The IETF has the goal of making the Internet work better.  Thus, the
IETF has to accept the license reality, both proprietary and free
software, and do whatever leads to a better Internet.

I don't see how favoring proprietary software makes the Internet work
better, rather the opposite.  Thus I believe the IETF can be more free
software friendly, especially since doing that isn't in conflict with
proprietary vendors.  The proprietary vendors needs similar rights as
the free software community does.

The only reason I can see to be non-friendly to the free software
community would be because the market share for proprietary vendors
would decline in favor of free software.  But I have not seen any
convincing results that indicate that this would modify how well the
Internet works, which should be the IETF's primary concern.

(I would argue that making the Internet run on free software actually
would make the Internet better, because it is easier to fix security
bugs, although I suppose it will be difficult to find consensus on
this here.)

> The phrase you quote doesn't allow for that.

But reality allow for that.  The URLs I quoted indicate that this do
happen.  It is better if the license were written in a way to avoid
this problem.

> license is needed, in any case.

Right, and a carefully constructed license would avoid the requirement
to send and receive postcards.

> with it realistically IMHO.

I disagree.  Seen from the point of view of the goals of free
software, there is no bug.  If the IETF has conflicting goals, and I
believe that it clearly does here, it will have to deal with the
reality in order to further its goals.

You may argue that free software licenses should change, and if you
participate in that process, you may very well influence it.  GPLv3 is
in draft form right now.  But that is a different story.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 11 Apr 2007 11:22:07 +0200

> of us to use as a model, perhaps?

Jari, thank you for asking!

I am working on a document with guidelines for free standards in the
IETF, and I have written the following regarding patents.  Much of the
material came from this thread.  I have not yet discussed this
document in the free software community (which I intend to do before
publishing it), so be aware that things may change considerably.

/Simon

4.  Patent Concerns

   The IETF rules (see [RFC3978]) demands that authors notify the IETF
   when they submit documents with patented technology (as far as the
   authors are aware of).  Third parties are also encouraged to submit
   disclosures about patented technology in others' documents.

   This process does not guarantee that all IETF documents will have no
   IPR concerns.  That was not the intention, and there are several
   documents with a complicated IPR situation.  One example is the
   standards-track use of the patented RSA public-key algorithm.
   Fortunately, the IETF process encourages and makes it easy to verify
   whether there are known patents for a particular document.

   If a documented is known to be patented, that may complicate the use
   of the document in free software environments.

   The first conclusion here is that readers will have to search the
   online IETF IPR Disclosure page at http://www.ietf.org/ipr/ for the
   document they are interested in.

4.1.  What To Look For In A Patent Disclosure

   An alternative title for this section may be 'How To Write A Free-
   Software Friendly Patent Disclosure'.

   Words to look for in a patent license is free-of-charge, world-wide,
   royaltee-free, perpetual and non-exclusive right to the patent.

   Some patent disclosures demands that you to write to the patent owner
   and request a license.  Such a clause leads to problems if a company
   goes away or won't respond to requests.  Depending on the text used,
   it may even require that every user of the software is required to
   apply for a license.  That is not feasible for free software, which
   is widely distributed to everyone.  The recommendation here is that
   the license should grant rights directly to third parties.

   Some patent licenses restricts how you can use the technology.  This
   causes an incompatibility with many free software licenses, which
   says that no additional restrictions may be placed on the
   redistribution of the software.  Further, free software is intended
   to be generally useful.  If one field-of-use is restricted, that goes
   against the spirit of free software.  The recommendation here is that
   patent licenses should not impose any additional restrictions before
   granting the rights.

4.2.  Handling Submarine Patents

   In some cases, patent disclosures are filed late in the process.  It
   may after a WG has accepted a document, after it has been last-
   called, after it has been approved by the IESG, or even after it has
   been published as an RFC.  We call such late notification of earlier
   patents as a submarine patent.

   If the document has already been approved as an RFC, the published
   document itself cannot be modified.  However, the documents' status
   on the standards track can be modified by publishing an approved
   document containing the reasons for doing so.  If the patent
   disclosure is not considered to grant sufficient rights to third
   parties, it is recommended to consider alternative technologies and
   to write a document moving the RFC with patented technology off the
   standards track.

   In the other situations, it is recommended that interested parties
   evaluate the patent disclosure and re-evaluate their earlier decision
   to accept, last-call or approve the document.

4.3.  Example License Text

   Here is a simplistic patent license that would grant third parties
   the necessary rights in order to use it in free software.

               X grants a worldwide, non-exclusive, fully-paid,
               perpetual, royaltee-free patent license to everyone for
               any purpose.

   [XXX: Most likely, this section will be heavily modified based on
   feedback from the community.]

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 11 Apr 2007 11:34:15 +0200

Just one comment:

Brian E Carpenter writes:
>>    What typically happens in practice, among good-faith 
>>    practitioners, is that there won't be any GPL (or Apache, or 
>>    Mozilla, or ...) implementation of the patented technology at 
>>    all, because the necessary rights cannot be acquired.
>

In this kind of situation, what would _you_ choose?

[ ] Apply for an IPR license/sign an NDA/do other paperwork
[ ] Violate someone's something
[ ] Go do something else

My choice tends to be the last, because my goal is generally not to 
implement some specific technology, it is to increase people's 
happiness and productivity. I can do that by implementing whatever Mark 
has patented. Or in any of ten thousand other ways. See?

Arnt

---

From: Tony Finch <[email-masked]>
Date: Wed, 11 Apr 2007 11:44:42 +0100

> of us to use as a model, perhaps?

A recent slap given by Apache to Sun <http://www.apache.org/jcp/sunopenletter.html>
implies that the Java Community Process has very open requirements on
patent licences granted via the Java Specification Participation
Agreement. The ASF thought a lot about patent licensing to produce the
Apache Licence 2.0 - most other patent-aware open source licences are
sponsored by businesses rather than non-profit foundations.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
FORTIES CROMARTY FORTH: WEST OR SOUTHWEST 5 OR 6 DECREASING 3 OR 4. SLIGHT OR
MODERATE, OCCASIONALLY ROUGH IN FORTIES. RAIN AT TIMES. MODERATE OR GOOD.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 11 Apr 2007 13:57:22 +0300

Simon,

> I am working on a document with guidelines for free standards in the

Great!
> publishing it), so be aware that things may change considerably.

Ok. But let me clarify my question. I was specifically after "running
code" that
has worked well in some case, and not so much specific new text. (Running
code would show that at least some open source project was OK with the
license and that at least some specific set of company lawyers were OK with
making such a license.)

Maybe we should move this thread to IPR WG...

Jari

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Apr 2007 13:01:00 +0200

On 2007-04-11 11:34, Arnt Gulbrandsen wrote:
>>> Mozilla, or ...) implementation of the patented technology at    all, 
>>> because the necessary rights cannot be acquired.
>>
> implement some specific technology, it is to increase people's happiness 
> and productivity. I can do that by implementing whatever Mark has 
> patented. Or in any of ten thousand other ways. See?

[X] Use a different OSS license that doesn't have this perceived problem.

    Brian

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 11 Apr 2007 13:27:23 +0200

> license and that at least some specific set of company lawyers were OK with

Oh, I see.  As far as company lawyers, I can think of RedHat's patent
policy:

http://www.redhat.com/legal/patent_policy.html

I realize that this is not a 'Patent License' but rather a 'Promise
not to enforce', but the end result for free software developers is
the same, I think.

I do not know which patents RedHat owns or whether there is any free
software that depends on this promise, though.

/Simon

---

From: Theodore Tso <[email-masked]>
Date: Wed, 11 Apr 2007 07:33:58 -0400

> practical evidence that IPR owners actually care?

Well, if IPR owners don't actually care, why are they asking people to
send a postcard?  It would seem to be an unnecessary administrative
burden for the IPR owners, yes?

> desired result is to make the Internet work better?

It's not bug in the OSS licenses at all.  Rather, it's a choice (based
on ethics/legal paranoia/whatever) of implementors not to risk having
to spend millions and millions of dollars defending a patent lawsuit.
In some cases, paranoid corporate lawyers might be involved as well,
telling implementors that if they can't fulfill the terms of the
patent license, they may not write or release code which could
potentially result in a lawsuit claiming the person implementing said
patented technology was inducing end users to infringe (since it's
pretty much axiomatic that 99.99% of people downloading code won't
know that they need to "send a postcard").  I suppose if the RF
license allow a program to automatically send an HTTP request to
automatically request a license --- but that seems like a great way to
slashdot the IPR holder's web servers, if an open source software
package using said RF license gets popular!

Let's reverse the question --- why do IPR holders feel they need
people to explicitly request a royalty-free license?  It seems like
it's just unnecessary administrative work on their end for no cost.
Unless, of course, it's not perpetual, as was alleged with a certain
XML office document patent grant, which meant that a certain company
could pretend to release sofware under what appeared to be a Royalty
Free License, but then required every user to go on bended knee to
request a license, which could be denied at any point in the future if
said company changed its mind.

The state of Massachusetts chose to use the OASIS Open Document format
partially because of this concern, so such patent licensing choices
can make a huge difference in terms of standards adoption.

So to me this seems to be more of a question similar to the
controversy of labelling food as "Organic".  There will be companies
that may want to label their patent licenses as "Royalty Free", but
not necessarily make them be perpetual, or require each individual end
user to fill out a form and mail it via paper mail and wait for a
paper response before they wouldn't be infringing the patent --- but
the net result of it may be to inhibit using the patent unless actual
dollars are paid to the IPR holder.  No question, that is the right of
the IPR holder to do so, to the extent granted by the relevant legal
jurisdition(s).  But the question is whether they should be allowed to
call such a patent "royalty free" --- either by creating some set of
standards which are trademarked, much like the Open Source Definition
did for copyrights --- or by some organization, like the IETF,
refusing to a characterize a patent license as being "royalty free"
(or pick some other term denoting that the license could actually be
practically used in Open Source Software).  And like the massive
debates over "organic foods", there will no doubt be a lot of debate
and disagreement about what those standards should be. 

					- Ted

Disclaimer: These are my own personal opinions and not necessarily the
opinions of my employer; I'm not important enough to affect the
opinions of my employer.  :-)

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 11 Apr 2007 13:43:25 +0200

Brian E Carpenter <[email-masked]> writes:

>>> Doesn't that sound like a bug in the OSS licenses to you, assuming
>>> the desired result is to make the Internet work better?
>>
>> happiness and productivity. I can do that by implementing whatever
>> Mark has patented. Or in any of ten thousand other ways. See?
>

How would using, say, the MIT or BSD license give you or your users
the right to violate someone's patent?

The problem would be the same even if you were to release your
implementation under the Windows or Mac OS X license.

/Simon

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Apr 2007 13:54:53 +0200

Ted,

> burden for the IPR owners, yes?

My assumption is that they care if the party that fails to send
a postcard is one of their competitors. That's what the defensive
clauses in these licenses are all about, afaics.

...
> opinions of my employer.  :-)

Ditto. (Full disclosure: Ted and I have the same employer, but
we're allowed to disagree :-)

    Brian

---

From: Scott W Brim <[email-masked]>
Date: Wed, 11 Apr 2007 08:18:49 -0400

On 04/11/2007 05:22 AM, Simon Josefsson wrote:
> IETF

Please don't use "free standards" this way.  The IETF produces free
standards.  Some of those standards have IPR licenses that you don't
like.

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 11 Apr 2007 14:25:48 +0200

Scott W Brim <[email-masked]> writes:

> standards.

According to what definition of 'free standards'?

> Some of those standards have IPR licenses that you don't like.

Yes, and that would make them non-free to me.

The copyright license also makes IETF standards non-free, and here at
least one major GNU/Linux distribution agrees with me.

Anyway, the point of having optional guidelines is that people who do
not agree with the ideas behind the guidelines don't have to follow
them.

/Simon

---

From: Theodore Tso <[email-masked]>
Date: Wed, 11 Apr 2007 08:29:45 -0400

> clauses in these licenses are all about, afaics.

So if there is a license which is not sublicensable, where if a
competitor wanted to field a product that required the patent license
--- I would rather doubt it if the competitor would want to ship
software or hardware where each individual end user had to send a
signed, notarized paper form to the IPR holder, and wait for a paper
response, before they would be allowed to use that product.

So that brings up an interesting question.  Suppose an IPR holder
approached the IETF, with a claim that they were offerring an "royalty
free" license, but one which was not sublicensable and which contained
extremely onerous terms that applied to the individual end user.
(``After receiving an individually framed patent license, the end user
must jump up and down 17 times on one foot while chanting, "Hail
Billy, the Gates is with you, I promise to never use Open Document."''  :-)

Now suppose the IPR disclosure filed with the IETF didn't say anything
at all about any reasonable and nondiscriminatory licenses alternative
to said royalty free license.

At this point, we could end up with a situation where a company tries
to implement an IETF standard, realizes that the reliance on the
"royalty free" license is untenable, goes back to the IPR holder, only
discover that the only other alternatives are under terms which are
anything but RAND.  So at the minimum, if we're not going to establish
requirements on royalty-free licenses being at least (a) perpetual,
and (b) automatically sub-licensable, (maybe those could be defined as
part of "reasonable" as it applies to RF licenses?) it would probably
be a good idea to require a statement by the IPR holders to state
their position on a RAND licensing as well.  Otherwise, we could end
up in a situation where we discover after the fact that the only way
to implement the standard is via a completely unreasonable set of
"royalty-free" terms that make it completely useless for either an OSS
or commercial/propietary product, and with no statement about RAND
licensing terms.

Basically, there seems to be a loophole in our current wording which
could allow a bad actor who was determined to use patents as a
strategic weapon a way to lay trap which could seriously compromise
the deployment of an IETF standard.

						- Ted

P.S.  For the record, my personal list of reasonable RF license terms
include:

1) Perpetual (MUST)
2) Sub-licensable (MUST)
3) Restriction to essential claims necessary to implement a
	standard (MAY)
4) Defensive clauses which revoke a patent license in the event
	of patent litigation (MAY)

(Some OSS advocates will disagree with me on #3, and there I will
agree with Brian that if an OSS requires a universal patent license,
it's probably a bug in the OSS license --- and the ones who try to use
the OSD language about fields of endeavor are trying to apply
standards designed for copyright licenses, and they may not be
appropriate for patent licenses.  But there will be plenty of room to
debate this particular issue --- but probably better to do it in the
IPR working group.  :-)

---

Disclaimer: These are my own personal opinions and not necessarily the
opinions of my employer; I'm not important enough to affect the
pinions of my employer.  :-)

---

From: [email-masked]
Date: Wed, 11 Apr 2007 06:33:54 -0700

> clauses in these licenses are all about, afaics.

I'm not sure I understand the "Upon request...will provide" clause. 
Actually, I'm sure I don't understand it...

Does it in any significantly enforcable way *require* RedPhone Security to do
anything? If so, then all the competitor has to do is send a postcard, so the
defensive value is effectively zero -- anyone who is a significant 
competitor can certainly afford a postcard.

If, on the other hand, it imposes no real requirements on RedPhone Security, 
what does it do?  Why is it there?

---

From: Theodore Tso <[email-masked]>
Date: Wed, 11 Apr 2007 09:43:01 -0400

> clauses in these licenses are all about, afaics.

I was thinking about your response, and I wonder if we might be
talking past each other.  The concern that I think a number of raising
about "send a postcard" specifically about patent licenses which are
not sub-licensable, so that each individual end-user has to request
their own individual patent license.  

Were you perhaps thinking of the scenario where only the a developer
had to do is to send a postcard to request a patent license?  If so, I
agree that's much less of an issue, although it still could
potentially be considered too onerous by some.

We could construct some really extreme ways such a "Royalty Free"
license could be worded that illustrates how our lack of definition of
"Royalty Free" in the IPR disclosure template could come back to haunt
us.  Suppose a company declared that they would make a "Royalty Free"
license available.  If they subsequently published the the following,
at which point would it be construed that they had violated the IPR
declaration (of which I hope some lawyer has commented about whether
or not it is legally binding)?

	"This patent license is not sub-licensable.  Each developer
	and individual end user must travel in person to the MegaCorp
	offices located in Nome, Alaska, and apply for a royalty-free
	patent license, which shall not be refused unless you or your
	company has ever used or developed software which utilizes the
	Open Document format."

If the answer is that a company could declare in an IPR declaration
that they are offerring an Royalty Free license, and not make any
promises for offerring RAND terms, and then could offer their patent
under the above license without sufferring any legal consequences, I'd
argue we have a significant hole in our processes.

						- Ted

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 11 Apr 2007 09:57:38 -0400

Hello;

> what does it do?  Why is it there?

I always figured that these things were poison pills - if company A  
sues company B about a
password infringement, company B will counter sue, and, for company  
A, yank any applicable RAND license, and look
to see if A did things like send in the postcard. (Or, if A was  
diligent about sending them in, it
provides a handy list of the patents for B to hassle them about.)

It might also be useful for performance evaluations, to see how many  
people are using your patents.

Regards
Marshall

---

From: Douglas Otis <[email-masked]>
Date: Wed, 11 Apr 2007 07:07:37 -0700

> we're allowed to disagree :-)

A statement of claims and conditions should also protect software  
distribution as a practical matter, or this limitation should be  
clearly disclosed.

-Doug

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 11 Apr 2007 07:59:56 -0700

> of us to use as a model, perhaps?

Non-assert works well...

http://www.ietf.org/ietf/IPR/nokia-updated-ipr-draft-saifullah-rohc-ip-addr-comp-context-replicat.txt

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 11 Apr 2007 11:34:42 -0400

> The assumption is false: the goal of free software is not to make the

The assumption is not false.  The goal of the IETF is to make the Internet 
work better.  I assume Brian chose those words with care; they are taken 
directly from the IETF's mission statement, RFC3935.

> software, and do whatever leads to a better Internet.

That does not always mean discarding technologies because the people who 
developed them want to protect their legal right to benefit from their 
invention, or to protect themselves from liability.  The reality is that 
the law is not going away, patents are not going away, and both the IETF 
and the free software community (to the extent that such a thing exists) 
need to learn to deal with that.

Disclaimer: I am not a lawyer; this message is not legal advice.

For the record, I think your concerns about this particular license are 
overstated.  Neither this patent license nor the open-source software 
licenses you quote are as buggy as you seem to think they are.  For 
example, the patent license contains the following text, which you quoted: 
"This general use license granted to manufacturers also flows down to 
sublicensees and users".  This would appear to have the effect that only 
the original implementor of the patented technology would need to obtain a 
license from RedPhone; he would then simply include in the software license 
a recursive sublicense for the patent.

The field-of-use restriction is annoying, of course, but I don't think it's 
actually fatal in this case.  The GPL does indeed prohibit "you"; that is, 
the GPL licensee, from imposing futher restrictions on recipients exercise 
of rights granted within the GPL.  However, it does not prevent such 
restrictions from already existing; the GPL does not prevent you from 
adding support to GPL'd software for patented crypto technology and then 
distributing the result, provided the patent license does not require you 
do place additional restrictions on the activities of people you distribute 
to.  In fact, the most common problem I've heard of with GPL 
incompatibility as it relates to patents is that the GPL prevents adding a 
restriction that requires preparers of derivative works to license any 
relevant IPR that they own.  The text you referenced in the Mozilla and 
Apache licenses are examples of such requirements, and make those licenses 
GPL-incompatible.

The Mozilla license covers this explicitly, again in the text you quote: 
"The Initial Developer hereby grants... subject to third party intellectual 
property claims".  Of course, that's not really the important part, since 
most people are not the Initial Developer.  What you really want is section 
2.2, "Subject to third party intellectual property claims, each Contributor 
hereby grants...".  In either case, what is going on here is that anyone 
who contributes code to software covered by that license must grant 
licenses to any relevant IPR that he owns; it explicitly excludes IPR owned 
by someone else.  Thus, it is possible to include patented crypto in 
software covered by the Mozilla license, even if the patent holder requires 
every user to pay a large fee to use the patented technology.

The section you refer to from the Apache license is similar - it consists 
of a license grant by each contributor of rights held _by that 
contributor_.  The grant does not cover IPR not held by the distributor.

In any case, the text you quote from the Mozilla and Apache licenses has 
nothing to do with the argument you are trying to make; it has no effect on 
the ability to create and distribute software under these licenses which 
implements technology patented by someone other than the contributor.  What 
makes these clauses problematic is that they cause the licenses that 
contain them to be GPL-incompatible (but not necessarily non-free).

-- Jeff

---

From: "Lawrence Rosen" <[email-masked]>
Date: Wed, 11 Apr 2007 08:29:01 -0700

> > of us to use as a model, perhaps?

and

> I am not speaking
> for any particular company, and certainly not for the one that pays me,
> but it's clear that no company in today's IT market and today's legal
> environment could make such a grant. Any RF license is going to come with
> conditions that protect the IPR owner in certain ways.

See http://www.microsoft.com/interop/osp/default.mspx, for but one example. 

/Larry Rosen

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 11 Apr 2007 11:51:15 -0400

On Wednesday, April 11, 2007 11:34:42 AM -0400 Jeffrey Hutzelman 
<[email-masked]> wrote:

> example, the patent license contains the following text, which you
> quoted: "This general use license granted to manufacturers also flows
> down to sublicensees and users".  This would appear to have the effect
> that only the original implementor of the patented technology would need
> to obtain a license from RedPhone; he would then simply include in the
> software license a recursive sublicense for the patent.

Hm.  Unfortunately, it seems there is other text that is problematic...

This...

   The Protected Assurance System Functions listed below (the "PAS
   Functions") define a set of functionality that Manufacturers under
   this General Use License (e.g. manufacturers of receiver / server
   components) must ensure is NOT implemented or provided to its users.

... would indeed appear to require anyone distributing an implementation
to impose additional restrictions, which is a problem.

Also, this is very bad:

   In the event that a Manufacturer has (a) only been granted a General
   Use License and (b) implemented and released to end users any PAS
   Functions, such events shall cause the General Use License of that
   Manufacturer to be immediately revoked, and any license rights
   conferred to any users of the system that has implemented any PAS
   Functions (above) shall be likewise revoked.

This appears to say that if someone violates the license terms, then
anyone who received a sublicense from them, directly or indirectly, is
also screwed, even if the user has not violated the terms of the license.
This is extremely unfriendly, not just to open source but to users in
general.

Finally, schedule B requires that specific text be "unambiguously displayed 
at time of system installation".  This requirement is impractical and in 
any case impossible for open-source implementors to enforce.

-- Jeff

---

From: John C Klensin <[email-masked]>
Date: Wed, 11 Apr 2007 13:24:02 -0400

--On Wednesday, 11 April, 2007 09:43 -0400 Theodore Tso
<[email-masked]> wrote:

>> My assumption is that they care if the party that fails to
>> send a postcard is one of their competitors. That's what the
>> defensive clauses in these licenses are all about, afaics.
> 
> talking past each other.  The concern that I think a number of
> raising about "send a postcard" specifically about patent
> licenses which are not sub-licensable, so that each individual
> end-user has to request their own individual patent license.  
>...
  
> We could construct some really extreme ways such a "Royalty
> Free" license could be worded that illustrates how our lack of
> definition of "Royalty Free" in the IPR disclosure template
> could come back to haunt us.  Suppose a company declared that
> they would make a "Royalty Free" license available.  If they
> subsequently published the the following, at which point would
> it be construed that they had violated the IPR declaration (of
> which I hope some lawyer has commented about whether or not it
> is legally binding)?
>...
 
> If the answer is that a company could declare in an IPR
> declaration that they are offerring an Royalty Free license,
> and not make any promises for offerring RAND terms, and then
> could offer their patent under the above license without
> sufferring any legal consequences, I'd argue we have a
> significant hole in our processes.

Ted, jumping ahead a little bit, how much of your concern would
be eliminated if that entry in the template said "Royalty Free
and RAND" (or "RAND and Royalty Free"), rather than just RF?  I
agree that "RF and totally unreasonable" is a possible case, but
am trying to understand whether we have a disconnect about the
language we have used or about some general and important
principle?

I would ask just about the same question about questions of
revocability.   Independent of what the other provisions are,
should we insist that any grant of rights incorporated in an IPR
disclosure be permanent and irrevocable, or at least permanent
and irrevocable in the absence of specific violation of other
terms?  How much of your concern would that eliminate?

     john

---

From: "Contreras, Jorge" <[email-masked]>
Date: Wed, 11 Apr 2007 14:29:57 -0400

> language we have used or about some general and important

A useful convention that's being used more and more is the term RANDz, 
which means "RAND without monetary compensation".  This captures
both the monetary aspect as well as the reasonableness of other terms.

Of course, to avoid any uncertainty, it would be helpful to define RANDz
somewhere in the IETF policy documents (RFC 3979, etc.).

---

From: Theodore Tso <[email-masked]>
Date: Wed, 11 Apr 2007 15:36:42 -0400

> language we have used or about some general and important

I believe that this is the minimum we should have just simply to
protect the needs of commercial/propietary consumers of our standards,
so yes, that addresses much of my concern.

I believe it would be better if "Royalty Free" were more strictly
defined to include irrevocability *AND* either (a) the ability to
sublicense or (b) the ability for end-users to automatically get a
grant of permission without having to perform any explicit action, as
was done in Microsoft's Open Specification Promise.  Unlike some OSS
advocates, I don't feel a particular need to to require a patent
license which is valid for any field of endeavor; just the essential
claims necessary to implement an IETF standard is IMHO sufficient
(realistically I doubt many IPR holders would be willing grant more
than that).  And I suspect there is general consensus that terms which
revoke permission in case of patent litgation (even the GPLv3 has such
terms) is not controversial at all.

But regardless of what definition we end up, I think we should more
explicitly define what we mean by Royalty Free, just to prevent
companies from engaging in PR/Marketing games.  If it ends up being a
definition which means that it might not necessarily be useful to OSS
implementors (i.e., the end-user must in apply in person at the
offices of MegaCorp in Nome, Alaska example), at least it's well
defined and people are put on notice that they can't trust the IETF
when we say something is Royalty Free that the specification could be
really implemented by Open Source Software developers without doing
more digging into the details of the license --- which might not be in
the IPR disclosure.  It's not ideal, but at least people would know
where they stand.

						- Ted

Disclaimer: Any opinions expressed in this message are my own and does
not necessarily reflect the opinions of my employer.  I'm not
important enough to affect the opinions of my employer.  :-)

---

From: Pekka Savola <[email-masked]>
Date: Thu, 12 Apr 2007 07:54:45 +0300 (EEST)

On Wed, 11 Apr 2007, Theodore Tso wrote:
...
> Unlike some OSS advocates, I don't feel a particular need to to 
> require a patent license which is valid for any field of endeavor; 
> just the essential claims necessary to implement an IETF standard is 
> IMHO sufficient (realistically I doubt many IPR holders would be 
> willing grant more than that). [...]

FWIW, many declarations (taking the one shown by Joel as an example), 
permission is granted to "technically necessary to implement the IETF 
standard spesification.." and similar has been seen in other 
declarations (possibly in the form, '.. to interoperate with XXX 
standard specification').

Does that allow you to implement everything in the specification if 
'everything' is not 'technically necessary to implement' [for 
interoperability or otherwise]?  MAYs?  SHOULDs?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "Mark Brown" <[email-masked]>
Date: Wed, 11 Apr 2007 14:20:30 -0500

Simon,

> relative to the other licenses in the IETF IPR disclosure list.  Kudos

I want to speak informally and just kick some ideas around right now.  So,
disclaimer, For this and other posts to this IETF email list, please
understand that I'm speaking for myself and not as an agent of RedPhone
Security.  Ok.

You raise two problems:

>      followed, anFrom [email-masked] Mon Apr 16 15:34:32 2007
From: "Mark Brown" <[email-masked]>
To: "'Simon Josefsson'" <[email-masked]>,
	<[email-masked]>
Date: Wed, 11 Apr 2007 14:20:30 -0500
Cc: [email-masked], [email-masked]
Subject: RE: Withdrawal of Approval and Second Last Call:
	draft-housley-tls-authz-extns

Simon,

> relative to the other licenses in the IETF IPR disclosure list.  Kudos

I want to speak informally and just kick some ideas around right now.  So,
disclaimer, For this and other posts to this IETF email list, please
understand that I'm speaking for myself and not as an agent of RedPhone
Security.  Ok.

>      followed, and several free software licenses does not permit

Problem 1 seems solvable to me, but I'd like more input.  For 2, My goal is
this exchange:

Manufacturer: "We're requesting the General Use License from RedPhone
Security.  In exchange, we promise not to implement (or on a per-release
basis: we did not implement) the PAS Functions."  

Each Manufacturer needs to take responsibility only for "his" own actions;
any subsequent Manufacturer (alters the code in a way that may or may not be
material to the PAS Functions) either voids the license or inherits it or
requests their own license -- but that's not "your" problem.  

A Manufacturer will develop code, test the functionality and release the
software.  At each of these steps it should be pretty clear if the software
being developed, tested and released violates the PAS Functions.  ..Doubly
clear if the function of the software is to make use of X509 certificates
which are marked with a "critical" policy that identifies RedPhone Security
(a hard-coded OID ending in .23106 will likely show up in the software).

I think a free software provider/clearinghouse could choose to not go beyond
the RedPhone Security General Use License with no problem.  In the event
that some third party contributor made a code contribution "back" to the
provider that violated the PAS Functions, simply classify that
code-contribution as "buggy" -- and choose to not roll that contribution up
into any release.

I can imagine a case where a user of free software chooses to start with
free software and then obtain a PAS License from RPS and become
Manufacturer2.  Then the score would be:  Manufacturer1: GUL, Manufacturer2:
PASL, and both would remain true to their commitments -- no problems.  The
only problem would be if Manufacturer2 contributed PAS Functions back to
Manufacturer1 and then Manufacturer1 rolled those functions in (and tested
and released them) under GUL.

Back to question 1, I guess the question for me is, Who is making the
promise to RedPhone Security?  How the promise is communicated is not the
main issue.  If the preferred OpenSSL approach is to put a legal stuff into
comments atop source files which are published for anyone to see, that may
be more effective than sending one postcard.

This may also help (somewhat) the "on installation" question.  If one
Manufacturer only releases (presumably tested) source code, then "on
installation" for source code could simply be comments atop the source code
file.  What I want to accomplish is fair warning to downstream users /
Manufacturers, so that we can help users steer clear of accidental GUL
violations. 

In summary, for (1) I'd like more input.  RPS "will provide" a GUL upon
request, by snail mail or electronically.  The question I have is how an
open source provider might prefer to make that request with its associated
promise about PAS Functions -- once and for all, or from time to time, etc.
This question could be sorted out on a per-license basis, but I think
consistency would be preferable.

For (2) I'd like each Manufacturer/User to stand on his or her own two feet.
If "you" made or used the PAS Functions, "you" need a license.  Otherwise,
say "you" didn't under the GUL.  No Manufacturer under the GUL should be
responsible for implementations of PAS Functions that they did not develop,
test and/or release.

Thanks for your response Simon.

Best regards,
--mark

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 19 Apr 2007 12:20:02 +0200

> responsible for implementations of PAS Functions that they did not develop,

Hi Mark!  I believe I understand what you are trying to achieve here.
It looks like a clean separation, but the problems are in the details.

Below I'm speaking only from my point of view as a developer,
independent contractor and software company.  Others may of course
have different opinions, and I would encourage more developers to
share their thoughts.  That would give you a more broad picture of the
kind of problems you are likely to encounter.

A basic problem is that you are not likely to get free software
projects to request and agree with your GUL at all.  This is related
to problem (1).  If you would rewrite your license to grant the rights
to everyone without any need to contact you, that would solve this
problem.

It would be useful if you could explore with your lawyers if it is
actually easy for you to avoid problem (1).  I'm wondering what
exactly the requirement for implementers to "request" this license
from you gives you.  Your text suggest that you will never refuse to
grant the rights in your license to someone who ask, is that right?
If so, what problem would there be in granting the rights immediately
to everyone, without a need to request it from you?

Is your reason that you want to know who is using your IPR, and open
up a communication channel with them?  To solve that concern, you
could write a request that everyone is requested, but not legally
required, to get in touch with you.  That would get you into contact
with the majority that is positive about talking with you, and you
wouldn't need to hear from people who doesn't want to talk with you.

Replacing the need to request a license from you with a requirement to
place a comment in header files to make things clear to end users may
be acceptable, possibly barring the problem in the next paragraph.
This is basically the same as giving the rights directly to everyone,
without a need to contact you.  So it seems you have already started
leaning towards that solution.  (It is important that you do not
require that the comment is placed in all "advertising material", or
similar, or you will run into the problem that the original BSD
license had with GPL-compatibility.)

Another basic problem is that free software projects may not be able
to agree to your field-of-use limitation in (2) and at the same time
be compatible with license such as the GNU General Public License.
Thus they would never be able to implement tls-authz even without any
support for PAS under your license.  I am not certain of this, but I
could ask the Free Software Foundation's lawyers about this -- they
are the copyright holder of GnuTLS which implements tls-authz without
PAS today, and can speak authoritatively about this.

Finally, here is another problem to consider: Your patent isn't valid
in the entire world.  You will run into situations where a manufacture
is not bound or affected by your license.  Only end-users or
re-distributors in some countries will be affected.  I believe this is
the case for GnuTLS, I developed the tls-authz functionality in Sweden
and as far as I can tell your patent isn't valid here.  I see no
reason to request or agree with the GUL.  You may want to offer a
license not only to manufacturers, but to end-users or
re-distributors.  This makes the licensing situation much more
complex.

At the end of the day, I think you won't get many advantages from your
current license compared to a license that would give everyone the
right to use your technology for any purpose as long as they don't sue
you.  Compare the licenses, linked to by others in this thread, from
Microsoft, Nokia, etc.  I believe that if your license is not regarded
as liberal enough to grant free implementations (and that doesn't seem
unlikely given the discussions on this list), people will standardize
alternative technology that solves the same problem.  If that happens,
you won't even have the protection in revoking licenses of your IPR to
companies that sue you.

Best Regards,
Simon

---

From: "Mark Brown" <[email-masked]>
Date: Mon, 23 Apr 2007 17:17:25 -0500

Hi Simon,

> wouldn't need to hear from people who doesn't want to talk with you.

My understanding is this: The "request" for the GUL implies a promise not to
implement the PAS Functions.  This promise is valuable to RedPhone Security.
If it's worth it to you to make the GUL promise (for whatever reasons, laws,
or possibilities that you see) then you can make the promise and receive the
GUL from RedPhone Security.  Of course everyone is free to make their own
decision about whether it's better to make the GUL promise or not.  But if
you don't make the promise, you won't get the GUL.  

> leaning towards that solution.  (It is important that yFrom [email-masked] Wed Apr 25 09:22:47 2007
From: "Mark Brown" <[email-masked]>
To: "'Simon Josefsson'" <[email-masked]>
Date: Mon, 23 Apr 2007 17:17:25 -0500
Cc: [email-masked], [email-masked], [email-masked]
Subject: RE: Withdrawal of Approval and Second Last Call:
	draft-housley-tls-authz-extns

Hi Simon,

> wouldn't need to hear from people who doesn't want to talk with you.

My understanding is this: The "request" for the GUL implies a promise not to
implement the PAS Functions.  This promise is valuable to RedPhone Security.
If it's worth it to you to make the GUL promise (for whatever reasons, laws,
or possibilities that you see) then you can make the promise and receive the
GUL from RedPhone Security.  Of course everyone is free to make their own
decision about whether it's better to make the GUL promise or not.  But if
you don't make the promise, you won't get the GUL.  

> license had with GPL-compatibility.)

Making the GUL promise costs no money (that part is free); I hope it doesn't
cost anybody any time to _not_ implement the PAS Functions; and I don't want
to make the mechanics of making the request / promise cost a lot of time
either.  But the GUL promise as "valuable consideration" is the cost of the
GUL to Manufacturers.  As far as I can see, it's not ok to omit this.  

I hope many people find the offer attractive.  As I mentioned, I'm open to
suggestions and feedback on the mechanics of making the "request".

> PAS today, and can speak authoritatively about this.

I would appreciate if you would follow up with your lawyer(s) on this
question.  As I've said before, I believe that even if GNUTLS/FSF (for
example) made the GUL promise, its software would continue to be "free to
use" because only GNUTLS (or whatever parent organization) would be bound to
honor that promise.  I hope your lawyers will find this to be true.

Best regards,

mark

---

From: John C Klensin <[email-masked]>
Date: Wed, 25 Apr 2007 12:22:46 -0400

--On Monday, 23 April, 2007 17:17 -0500 Mark Brown
<[email-masked]> wrote:

>...
> My understanding is this: The "request" for the GUL implies a
> promise not to implement the PAS Functions.  This promise is
> valuable to RedPhone Security. If it's worth it to you to make
> the GUL promise (for whatever reasons, laws, or possibilities
> that you see) then you can make the promise and receive the
> GUL from RedPhone Security.  Of course everyone is free to
> make their own decision about whether it's better to make the
> GUL promise or not.  But if you don't make the promise, you
> won't get the GUL.  
>...

Mark, with the usual IANAL qualifications, I've seen lots of
general, "you don't need to ask us" licenses that contain "this
license is valid only as long as you refrain from doing the
following things..." language.  The most common form of that
language involves provisions about not suing the company
granting the license, but that is by no means the only version.
At least a few of the organizations that have written such
licenses are very big players in the patent game.  So, while
reasonable people (and I assume lawyers :-( ) may disagree on
how far it is necessary to go to get people to explicitly agree
to those provisions, I infer that some organizations who are
probably not naive about these things have concluded that an
application process is not necessary.

Now I want to turn the logic of your note around.   You and/or
RedPhone Security have presumably concluded that you would
derive some value from having the IETF publish this document,
preferably on the standards track.  I don't need to speculate as
to where on the spectrum between altruism, a belief that it
would enhance your reputation(s), or a belief that having this
out there as an RFC would enhance your ability to market the PAS
bits that you are not giving away to conclude that you see
_some_ benefit to yourselves or the larger community: if you
don't, the investments you have clearly made in this would be
dumb and I have no reason to believe that you, your
organization, or your lawyers are dumb.

Without getting into a discussion about whether particular
provisions are or are not usable by particular communities, I
assume it is clear to everyone that, if an encumbered technology
is proposed for standardization, the IETF's rules require making
a decision as to whether or not the technology is important
enough to justify accepting the encumbrances.  For me, at least,
that isn't a binary decision -- it involves weighing the level
of encumbrances and/or aggravation in working around them
against that perception of importance.

I think you are being told --by a number of people and in
different ways-- that there is a perception that having to ask
for a license is seen as appreciably more burdensome and, for
various reasons, risky than if a general license is granted
without an application process.  My impression is that is a
general perception around the IETF, not just related to your
work or proposal.  

So, rather than (or at least in addition to) telling others to
go consult their lawyers to find out whether they could possibly
work with your licensing requirements, I would encourage you to
go back to your own and see if you can either (i) get the
requirement to formally apply to you for a license removed or
(ii) get a really good explanation as to why no strategy other
than such an application is sufficient to meet your
organizational needs.

In my personal opinion, and given that experts in the relevant
parts of the community are telling us that this technology is
not critical to the most-important functions of TLS, if you
can't or won't do that, the IETF should simply conclude that our
interests in publication of this material are not sufficient to
overcome the disadvantages of the encumbrances, stop spending
time on this discussion, and move on.

      john

---

From: "Mark Brown" <[email-masked]>
Date: Wed, 25 Apr 2007 13:06:08 -0500

John,

On the one hand, let's just get started figuring out how the promise /
request can be made so that it's not a burden to the open source community.
I'm asking for input.  Maybe a comment in the open-source source code (the
way the EAY disclaimers read atop OpenSSL files for example) is sufficient
to publicly request the GUL.  Maybe that also satisfies the "install"
disclosure as well, at least as far as the open source provider is
concerned.  I'm open to reasonable suggestions here.  And I have benefited
from Simon's pushback so far.  My revised sense is that those who publish
source code, such that promises embedded within that source code also get
published, don't need to write a postcard.  Those who are keeping their
source code as a secret will need to notify RedPhone Security of their
acceptance of the GUL more explicitly than in source code comments.

On the other hand, I want to ask open source providers who accept the GUL to
avoid knowingly trafficking in PAS Function implementations.  Here's an
analogy: PAS Function implementations aren't kiddie porn, but all the same
they're not very compatible with public ftp sites, etc.  In the analogy I
mean this: In some countries, users of PAS Functions could/may be doing
something illegal if that user doesn't have a license.  I want to ask
GUL-compliant open source publishers to discard contributions that implement
PAS Functions, e.g. not roll them up into a release.  

This is my personal opinion of the GUL: IF person X, who doesn't participate
in (or know about) the GUL makes a PAS Function, that's RedPhone Security's
concern, not any open source provider's.  If person X checks PAS Functions
into a development/unstable source code tree operated by a GUL licensee,
then I'd expect the GUL licensee to just delete that contribution when it's
discovered, and not worry any further about it.  In my mind, a scenario that
violates the GUL would be where person X contributes (checks into source
control), and a GUL licensee accepts the contribution, and that licensee
functionally tests and approves the PAS Functions (thereby confirming that
the contribution performs the PAS Functions described in the GUL), and then
that licensee releases the PAS Functions as a stable / blessed build.  That
seems to me to be a "three strikes and you're out" GUL violation.

In saying this, I'm trying to be flexible.  I could go farther and try to
work out more detailed scenarios that might reduce risk and burden, but I'd
just be guessing.  Instead, let me stop here and ask for input.  Is there
burden in putting a comment in source code that recites the RPS GUL, or is
the burden in the postcard?  I'm open to suggestions on the mechanics for
making the GUL promise.  Is it risky that a (possibly open source) software
provider might accidentally but in good faith cruise through all three
strikes with respect to the PAS functions (accept, test and release) and
that their GUL might be void until things get patched up with RedPhone
Security?  Then let me know what risks are of concern so I can try to
address them.

To be fair, I can see that the open source community probably bears a higher
burden to keep PAS Functions out of their source code, so I would like to
try to ease the burden of requesting the GUL.  So I'd like to work this out,
but I will need some clear and direct feedback to get it right.

Best regards,

mark

> -----Original Message-----
> From: John C Klensin [mailto:[email-masked]]
> Sent: Wednesday, April 25, 2007 11:23 AM
> To: Mark Brown; 'Simon Josefsson'
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: Withdrawal of Approval and Second Last Call: draft-housley-
> tls-authz-extns
> 
> 
>

---

From: "Mark Brown" <[email-masked]>
Date: Wed, 25 Apr 2007 13:35:34 -0500

John,

> than such an application is sufficient to meet your

Sure, I can do that too.  

I'm a newcomer to the IETF, and sometimes I find myself a bit out of the
loop regarding the general perception around the IETF.  I appreciate you
filling me in.

--mark