ietf
[Top] [All Lists]

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

2007-04-25 09:24:15


--On Monday, 23 April, 2007 17:17 -0500 Mark Brown
<mark(_at_)redphonesecurity(_dot_)com> 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



_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf