Subject: Re: IETF Trust FAQ

From: Brian E Carpenter <[email-masked]>
Date: Mon, 15 Jan 2007 17:35:00 +0100

Switched to a more relevant list, where this horse has
been thoroughly flogged already:

On 2007-01-15 16:49, Simon Josefsson wrote:
> Brian E Carpenter <[email-masked]> writes:
> 
>> I would refer you to the IETF Trust FAQ on RFC copyright,
>> http://trustee.ietf.org/24.html, point 6 and point 9.
> 
> Interesting.  Point 6 seem incorrect to me, as there is nothing in BCP
> 78 that permits computer code extracts from RFC for third parties. 

Wrong. The parenthesis "(and not limited to use within the IETF Standards
Process)" in BCP 78 does exactly that.

> I
> believe the IPR WG has established that point.  

You may believe that, but our lawyer doesn't.

> Point 9 seem
> irrelevant since the IETF Trust doesn't (by point 1) own the copyright
> on code in RFCs.

Point 9 means what it says. When combined with the parenthesis
quoted above, it's highly relevant.

> 
> I think the FAQ should be updated to reflect the perception of the
> problem being solved by the IPR WG.  

When the ipr WG delivers its homework to the Trust, we'll surely
do that.

     Brian

> You may also want to update point
> 3 to mention RFC 4748.  Adding contact information to the page, and in
> particular, whether it was written with advice from a lawyer familiar
> with BCP 78 would be useful.
> 
> /Simon
> 

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

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 15 Jan 2007 18:07:49 +0100

> Process)" in BCP 78 does exactly that.

I disagree.  Let's take a look at the license:

   a. To the extent that a Contribution or any portion thereof is
      protected by copyright and other rights of authorship, the
      Contributor, and each named co-Contributor, and the organization
      he or she represents or is sponsored by (if any) grant a
      perpetual, irrevocable, non-exclusive, royalty-free, world-wide
      right and license to the ISOC and the IETF under all intellectual
                        ------------------------
      property rights in the Contribution:
...
      (E) to extract, copy, publish, display, distribute, modify and
          incorporate into other works, for any purpose (and not limited
          to use within the IETF Standards Process) any executable code
          or code fragments that are included in any IETF Document (such
          as MIB and PIB modules), subject to the requirements of
          Section 5 (it also being understood that the licenses granted
          under this paragraph (E) shall not be deemed to grant any
          right under any patent, patent application or other similar
          intellectual property right disclosed by the Contributor under
          [RFC3979]).

The first paragraph of the license says that the rights in the
remaining part of the section are granted to 'ISOC and the IETF' (that
part happen to be updated by RFC 4748, but that's not the point here).

The parenthesis you quote clarify that the _PURPOSE_ these licensee's,
ISOC/IETF (now IETF Trust and IETF), are not restricted to use the
document within the IETF Standards Process.

Third parties are not granted rights by the parenthesis, as far as I
can tell.

> quoted above, it's highly relevant.

Point 9 says:

  the IETF Trust has no intention of taking any action that will cause
  difficulty for open source software containing code from RFCs.

If authors retain ownership of code, the IETF Trust appear to have
little weight to take any such actions.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 15 Jan 2007 19:11:59 +0100

> been thoroughly flogged already:

Btw, to move closer to a settling the issue, it would be useful to add
more information to the issue tracker:

https://rt.psg.com/Ticket/Display.html?id=1339

Relevant information would include statements by Scott Bradner:

http://tools.ietf.org/html/draft-bradner-rfc-extracts-00

   "Section 3.3(a)(E) of RFC 3667 [RFC 3667] requires that the author(s)
   of IETF contributions grant the IETF the right to make and use
   certain types of extracts of the contributions for purposes not
   limited to the IETF standards process.  When I wrote that section I
   intended that to mean that anyone could make such extracts but the
   wording I used limited the permission to the IETF.  This document
   tries to fix the words to match my intent."

That confirm that I interpret the wordings of RFC 3978 the same as
Scott Bradner.  I agree that the intention wasn't the same as the
wording, and that we should fix that.

Debian interpret the BCP 78 license as non-free:

http://release.debian.org/removing-non-free-documentation
http://bugs.debian.org/199810

As a consequence, Debian do not include RFCs (or, supposedly, material
derived from RFCs) in their distribution.

I recall receiving replies from the FSF legal department regarding the
RFC 2026 license, and possibly also the RFC 3978 license, that may be
relevant.  If there is genuine interest, I could dig it up.

/Simon

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 16 Jan 2007 10:58:13 +0100

On 2007-01-15 18:07, Simon Josefsson wrote:
> I disagree.  

The Trust issued its FAQ after taking legal advice, and the Trust has
made its interpretation of its own IPR clear via the FAQ.

     Brian

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 16 Jan 2007 18:21:27 +0100

> made its interpretation of its own IPR clear via the FAQ.

The Trust seem to have done a poor job of convincing the community
that their interpretation is correct.  It is not clear whether they
considered the problem mentioned in this thread.  Making more of the
discussions in the Trust that led to this interpretation available
would help them to convince others and build community confidence in
that the Trust is working properly.

/Simon

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 16 Jan 2007 20:36:12 +0100

> that the Trust is working properly.
They haven't convinced you. I'm happy.
Let others speak for themselves.

---

From: "Lawrence Rosen" <[email-masked]>
Date: Tue, 16 Jan 2007 16:40:15 -0800

At Harald's suggestion that others "speak for themselves," I'll speak up. I
agree with Simon. I'd feel more comfortable about this working group punting
Simon's issues and passing them to the IETF Trust if I had some assurance
that they were going to solve these IP policy problems in a public way with
public input. 

I do not believe that the current draft of RFC 3978 solves the problems
Simon and others have identified. For the record, I'm copying an earlier
private thread with Simon. I copied Brian and Jorge but they haven't
responded. So I'm going to copy it to the full list below. We might as well
discuss these problems now rather than have to do it right a second time.

I wish the IETF Trust lawyers who promise to help that organization draft
its policies were here now to help us, because our current policies aren't
sufficient to do the job.

/Larry Rosen

*********************************

Thanks, Simon. I specifically wrote to you and Brian directly so that I can
get to the gist of the problem you wrote about without in-channel "noise."
:-) I look forward to Brian's response. What I ultimately say publicly on
the list depends upon what I learn from you two.

I agree, though, with the fundamental premise you raised in your earlier
email, and so I suggested that contributors to IETF should be given express
notice and assurance that their contributions are intended to be
*sublicensed to the public by the IETF Trust* in the form of published
specifications compatible with both open source and proprietary licenses.

> Stating your opinion of whether the RFC 3978 license gives third
> parties the right to extract and use code portions from RFCs to the
> IPR WG list would be useful.  I think it is problematic from several
> views, but Brian and the IETF Trust appear to be pushing for an
> interpretation that says "there is no problem here, go away".

RFC 3978 states that "[the] rights addressed in this document fall into the
following categories: rights to make use of contributed material...." 

The words "make" and "use" come from patent law, not copyright law.
Copyright addresses the relatively trivial problem of copying expressive
code into a computer's memory but it doesn't affect what happens when you
press start. For that you may need patent rights.

We can't wish that demon to go away by saying simply, as we currently do in
RFC 3978, section 3.3(a)(E), that the licenses "granted under this paragraph
(E) shall not be deemed to grant any right under any patent...." Every
modern open source and proprietary license contains a clear statement of
patent rights being granted along with distribution of the copyrighted code
so that licensees know what they may make or use.

This problematic statement in 3.3(a)(E) is apparently contradicted by the
last words of the leading paragraph 3.3(a), which refers to "all
intellectual property rights in the Contribution." Certainly that includes
patents?

I'm confused by the reluctance to address patents head-on in this document.

/Larry

P.S. Since I am stating my views of legal language and effect, I will now
copy Jorge.

> -----Original Message-----
> From: Simon Josefsson [mailto:[email-masked]]
> Sent: Monday, January 15, 2007 1:47 PM
> To: [email-masked]
> Cc: 'Brian E Carpenter'
> Subject: Re: IETF Trust FAQ
> 
<snip>
> 
> See RFC 3978 section
> 3.3 of <http://www.ietf.org/rfc/rfc3978.txt>. 
>  
> If I understand correctly, the current goal is not to write legal
> text, but to document the IETF's intention, and let the IETF Trust
> craft the legal text, with help from lawyers.  I don't expect the
> IETF community to be able to influence or review the end result.  I'd
> love to be wrong on that, or see the process change to something more
> open and something that have any chance of resulting in a workable
> outcome, but there seem to be no interest in exploring any options.
> 
> Stating your opinion of whether the RFC 3978 license gives third
> parties the right to extract and use code portions from RFCs to the
> IPR WG list would be useful.  I think it is problematic from several
> views, but Brian and the IETF Trust appear to be pushing for an
> interpretation that says "there is no problem here, go away".
> 
> /Simon

---

From: "Contreras, Jorge" <[email-masked]>
Date: Tue, 16 Jan 2007 20:34:34 -0500

Larry,

I think that you are attempting to find ambiguity in the language
of RFC 3978 when there is none.

Section 3.3.a deals with the licenses that Contributors
grant to IETF participants with respect to their Contributions
(which are mostly text, but can also be code).  These
licenses enable the standards development and publication work
that is coordinated through IETF.  To the extent that a patent
license may be required to conduct IETF standards development
work (a proposition that is debatable), such a license is granted.
That's why 3.3.a says "under all intellectual property
rights in the Contribution".  However, if a license is granted
under patents under 3.3.a, it is very limited and only extends to standards
development work within the IETF.

The licenses under 3.3.a (other than 3.3.a.E, see below)
do NOT grant any rights to implement IETF standards 
in products.  IETF Contributors are NOT required to grant patent
licenses to implementers.  This has always been IETF's policy, and
there is no ambiguity here.

Section 3.3.a.E covers a special case in which code is embedded
in IETF documents.  Under this license, code can be extracted
and used.  However, there is an explicit exception in the license:
it does not include a license under patents.  That exception was
included for very reason stated above.  IETF does not require
participants to grant patent licenses to implementers.  Someone who
extracts code from an RFC for use in a product is an implementer,
and that implementer does not automatically get a license under
the patent.  Arguing that the implementer gets a patent license
is contrary to both the express wording of 3.3.a.E, as well as 
IETF's general policy relating to patent licenses.

Finally, please note that these policies were formed prior 
to the establishment of the IETF Trust.  I don't understand why
the Trust is being criticized here, or why the Trust is expected
to do something different that what's stated in 3978.

Of course, the community is free to change the rules as it desires.
If a change to the above structure is desired by the community,
such a change would not be difficult to implement.  However, I think
it is disingenuous to claim that ambiguities exist in 3978 and
that these ambiguities support an argument for change.

Jorge

> From: Lawrence Rosen [mailto:[email-masked]]
> Sent: Tuesday, January 16, 2007 7:40 PM
> To: [email-masked]
> Subject: RE: IETF Trust FAQ
> 
>

---

From: "todd glassey" <[email-masked]>
Date: Tue, 16 Jan 2007 17:41:51 -0800

----- Original Message ----- 
From: "Harald Alvestrand" <[email-masked]>
To: "Simon Josefsson" <[email-masked]>
Cc: "Joel M. Halpern" <[email-masked]>; "Brian E Carpenter" 
<[email-masked]>; <[email-masked]>; "IPR WG" <[email-masked]>; 
"Steven M. Bellovin" <[email-masked]>
Sent: Tuesday, January 16, 2007 11:36 AM
Subject: Re: IETF Trust FAQ

>> that the Trust is working properly.

No Harald, actually what it will do is document that the Trust is running 
open-loop. Its why the Trust as it was set up is and continues to be a bad 
idea.

Its not that the IETF shouldnt have a Trust to manage its IP's - just not 
this Trust.

Todd

---

From: "todd glassey" <[email-masked]>
Date: Tue, 16 Jan 2007 18:04:29 -0800

Jorge - what exactly does section 3.3c mean anyway? its very poorly written 
and since it clearly has two sub headings that are misnumbered as equals 
with C (that would be D and E), this document is even more confused.

Todd Glassey

----- Original Message ----- 
From: "Contreras, Jorge" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Tuesday, January 16, 2007 5:34 PM
Subject: RE: IETF Trust FAQ

Larry,

Jorge

---

From: "Contreras, Jorge" <[email-masked]>
Date: Tue, 16 Jan 2007 21:10:36 -0500

3.3.a.D and 3.3.a.E are not intended to be sub-parts of 3.3.a.C.

There is a typo is 3.3.a.C, which has been pointed out before.
The period after "Process" should be a comma, and "The" should
not start a new sentence.

> From: todd glassey [mailto:[email-masked]]
> Sent: Tuesday, January 16, 2007 9:04 PM
> To: Contreras, Jorge; [email-masked]; [email-masked]

---

From: "Lawrence Rosen" <[email-masked]>
Date: Tue, 16 Jan 2007 18:39:36 -0800

Jorge Contreras wrote:
> However, if a license is granted

That is precisely my point, and perhaps Simon's also. Well said!

> there is no ambiguity here.

And that is why this is, and always has been, a policy issue. You can't
solve this by merely restating the previous position of IETF that you don't
care about receiving patent grants from contributors for the making and
using of their contributions in both open source and proprietary
implementations. This isn't just an engineering game. We create standards to
enable functional implementations, not for the expressive beauty of the
specifications.

> to do something different that what's stated in 3978.

No ad hominem criticism intended. Again, this is an important *policy*
issue.

> that these ambiguities support an argument for change.

No, that's not the argument for change. We need change because the current
IETF policy does not guarantee that every contributor's necessary IP is
licensed to the public for implementation of IETF specifications in both
proprietary and open source software. 

Without that they are not open standards. Without that they are just pretty
documents available under IETF copyright licenses. Thanks but that's not
enough!

/Larry Rosen

> From: Contreras, Jorge [mailto:[email-masked]]
> Sent: Tuesday, January 16, 2007 5:35 PM
> To: [email-masked]; [email-masked]

---

From: "Contreras, Jorge" <[email-masked]>
Date: Tue, 16 Jan 2007 22:25:49 -0500

> And that is why this is, and always has been, a policy issue. 

Larry is right.  This is a "policy" question for the group.  I can
tell you what the current rules say, and can help write
new rules if there is consensus to change them (and if the chairs ask
me to).

So far, Larry and Simon have voiced a desire to
change IETF policy so as to grant implementers a patent 
license to use code that's embedded in RFCs (oversimplifying,
of course).

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 16 Jan 2007 22:30:08 -0500

On Tue, 16 Jan 2007 18:39:36 -0800
"Lawrence Rosen" <[email-masked]> wrote:

> And that is why this is, and always has been, a policy issue. You
> can't solve this by merely restating the previous position of IETF
> that you don't care about receiving patent grants from contributors
> for the making and using of their contributions in both open source
> and proprietary implementations. This isn't just an engineering game.
> We create standards to enable functional implementations, not for the
> expressive beauty of the specifications.
> 
Larry, are you suggesting that we reopen the patent issue within this
working group?  If so, I'm afraid that my answer, as chair, is "no".
We're not chartered to consider the question.  When we discussed it at
some length in early 2003, the very strong consensus of the group was
that the IETF should not change its patent policy.  I do not know of
any major changes in the law or the technical culture around us that
would lead to different outcome.  I'm also unconvinced that enough time
has passed that it makes sense to reopen the question yet.

We do have several tasks we're supposed to complete.  I hope we'll soon
see the documents we discussed in San Diego; at that point, perhaps we
can wrap up this WG -- it's gone on far too long.

I'm certainly not saying that the IETF's patent policy can never
change.  I am saying that it would need at least a new charter, and
possibly a different working group (and almost certainly at least one
new chair, but that's another matter....).  For either, the usual rules
would apply: a demonstration to the General Area AD and the IESG as a
whole that there was sufficient community interest to make it worth
everyone's time.  Speaking personally and not as chair, I do not think
there is such interest at this time.  I am, though, quite certain that
it's not something that this group could undertake at this time.

So -- until we've completed our chartered tasks, I'm ruling discussion
(on this mailing list) of the basic IETF patent policy out of scope.
When we're done, if there's sufficient interest we can revisit that
question -- but not now.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb

---

From: "Lawrence Rosen" <[email-masked]>
Date: Tue, 16 Jan 2007 20:39:18 -0800

Steve Bellovin wrote:
> everyone's time.  
<snip>
> When we're done, if there's sufficient interest we can revisit that

Then I suppose we should take this decision public and see whether that
encourages better results. I am absolutely opposed to any IETF IP policy
that results in industry standards that have fundamental patent impediments
to their implementation in open source--and for that matter in
proprietary--software. Jorge just confirmed this to the group, in case
anyone doubts that our current policy has this effect.

I'd rather see this WG dissolve right now than to see it publish an IP
policy that doesn't work for anyone. If Steve Bellovin and others are tired
of this discussion, then perhaps we should get a new chairman (although
finding one with Steve's credentials will be difficult) and a new charter
(although selling that to the current participants in IETF will be
difficult). 

I'd nominate Simon to lead this effort. (Sorry, Simon, but someone with
fresh ideas and energy needs to do this right.) Whatever the procedure to do
so, we need a working group that tackles the important IP problems and
recommends IETF IP policies that really work. It shouldn't take a long time
for a new WG, with Jorge's help, to transform the current draft RFC 3978
into something meaningful and effective.

To be perfectly clear, *my* goal is to have all contributors to IETF
covenant their necessary patent claims for the free implementation of IETF
specifications to which they contribute. My current favorite version of this
is the Microsoft Open Specification Promise, a covenant that apparently
satisfies this proprietary software company as much as it satisfies the open
source community, but I'm open to other wording. 

What matters most right now is that we debate this, not bury it. If
procedurally we need to dissolve this WG with its task uncompleted and
charter another under new leadership, so be it.

/Larry Rosen

> From: Steven M. Bellovin [mailto:[email-masked]]
> Sent: Tuesday, January 16, 2007 7:30 PM
> To: [email-masked]
> Cc: [email-masked]

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 17 Jan 2007 07:55:18 +0100

> That is precisely my point, and perhaps Simon's also. Well said!
But has nothing to do with the extraction of code from RFCs, which is 
what Simon started talking about.
> enable functional implementations, not for the expressive beauty of the
are you still talking about the issue of extracting code from RFCs, or 
have you switched to talking about the IETF's patent policy?

The latter is not a work item of this WG at this time, but if you want 
to discuss it, please change the subject line.

                     Harald

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 17 Jan 2007 09:38:41 +0100

On Tue, Jan 16, 2007 at 08:36:12PM +0100,
 Harald Alvestrand <[email-masked]> wrote 

> Let others speak for themselves.

Is this a call to "hum"? If so, I can say that I'm not convinced
either. Lawyers may disagree but, as a simple programmer, I still do
not find a simple reply to the "Can I take code from a RFC and use it
in free software?" question.

---

From: "Lawrence Rosen" <[email-masked]>
Date: Wed, 17 Jan 2007 00:41:37 -0800

> have you switched to talking about the IETF's patent policy?

All along in this WG I've been talking about exactly one thing: The freedom
to implement any IETF specification under any open source (and proprietary)
software license. That's what "open standards" mean. Nothing else really
matters. That is the sole purpose for revising the IETF IP policy. That is
the sole reason for IETF.

It was not me but others here who insisted on transforming this discussion
into one about unhelpful distinctions between "code" and "text," and on the
unhelpful concept of "extracting code" to "make/use." The bigger issue is
putting software (whether derived from code or text in an IETF specification
or an original implementation of that specification) to work. That's why I
have insisted all along not only upon a compatible IETF contributor
*copyright* license, but an IETF contributor *patent* license that allows
everyone to make and use software-based products that implement IETF
specifications. (I have written MANY emails on this topic; I have not
switched to a new topic!)

Now it has come to pass that this group charged off and accomplished nothing
of real value except a copyright license that nobody dares rely upon to
implement IETF specifications in actual commercial products. I partly blame
myself for becoming bored and paying scant attention to a lot of emails in
recent months, but regardless of fault this current result is foolish in the
extreme given the person-years that so many people have devoted to this
topic in this WG. 

The problem became clear to me again two days ago when Simon wrote that this
WG may punt the entire issue to another group, the IETF Trust, which will
decide something in private later. That's not an acceptable result. 

It's time to make changes to this WG or create a new one. None of us can
afford to waste more time on meaningless exercises. We need a clear
statement of IETF principles agreeable to everyone who depends on IETF
specifications, and an exercise in drafting by real lawyers who will write
the rules in legally-enforceable terms. This effort cannot be punted
upstairs to unknown others in the IETF Trust. There is too much at stake
here.

/Larry Rosen

> From: Harald Alvestrand [mailto:[email-masked]]
> Sent: Tuesday, January 16, 2007 10:55 PM
> To: [email-masked]
> Cc: [email-masked]

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 17 Jan 2007 09:52:44 +0100

(chair / mailing list moderator hat on)

> switched to a new topic!)
You have entered text in reply to a topic entitled "IETF Trust FAQ".

I freely grant you that you have said the same thing on these topics all 
along, but I cannot accept that you go on posting on your specific topic 
in threads that concern other topics without changing the subject line.

Please respect mailing list civility.

                       Harald, speaking as chair.

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 17 Jan 2007 13:26:14 +0100

Lawrence Rosen wrote:

> I am absolutely opposed to any IETF IP policy that results in industry
> standards that have fundamental patent impediments to their
> implementation in open source
> --and for that matter in proprietary
> --software. Jorge just confirmed this to the group, in case anyone
> doubts that our current policy has this effect.

+1

Fortunately any "patented algorithm" is AFAIK legally still nonsense in
my part of the world.  And I've no problem with a license saying "feel
free to use this unless you threaten us with some of your patent
claims".

That's BTW the main reason why I pushed for something in the direction
of "share alike".  I hate "embrace, extend, and extinguish" strategies
<http://en.wikipedia.org/wiki/Embrace%2C_extend%2C_and_extinguish>, and
if folks try it anyway they should at least be forced to do this in the
IETF with whatever it takes them to get the required "No Objection" by
the IESG and the IAB.

Frank

---

From: "Contreras, Jorge" <[email-masked]>
Date: Wed, 17 Jan 2007 07:32:40 -0500

> "Can I take code from a RFC and use it
> in free software?" 

Under the current rules, if it is patented, 
you will need a license from the patent owner.

Also under the current rules, if the Contributor
has a patent covering the software, he/she is
required to disclose the patent.  These
disclosures are posted at https://datatracker.ietf.org/public/ipr_disclosure.cgi.

The idea being that, if you want to use code from
an RFC, you should be able to determine whether the
Contributor claims patent rights in it.  If there
is no disclosure of patent rights, then it would not
be unreasonable to assume that the Contributor does
NOT have such patent rights.  However, this says nothing
about whether or not third parties may have patent
rights that are relevant and need to be licensed.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 17 Jan 2007 13:38:55 +0100

On Wed, Jan 17, 2007 at 07:32:40AM -0500,
 Contreras, Jorge <[email-masked]> wrote 
 a message of 19 lines which said:

> > "Can I take code from a RFC and use it in free software?"
> 

Patented where? Software patents do not exist on my side of the world.

> The idea being that, if you want to use code from an RFC, you should
> be able to determine whether the Contributor claims patent rights in
> it.  If there is no disclosure of patent rights, then it would not
> be unreasonable to assume that the Contributor does NOT have such
> patent rights.

I did not specially mention the patent issue. Even if there is no
patent, I cannot use at will software written by someone else unless
there is a *specific* authorization to do so. This is this
authorization that we miss.

---

From: "Contreras, Jorge" <[email-masked]>
Date: Wed, 17 Jan 2007 07:53:18 -0500

> Patented where? Software patents do not exist on my side of the world.

Then you're safe!  (But don't count on it.)
 
> authorization that we miss.
3.3.a.E gives this authorization, but excluding patents.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 17 Jan 2007 14:23:04 +0100

> license to use code that's embedded in RFCs (oversimplifying,

Granting rights that you don't have remains tricky,
as far as I understand these things  :-)

     Brian

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 17 Jan 2007 14:26:27 +0100

> 3.3.a.E gives this authorization, but excluding patents.

There seems to be disagreement about that.  Is there support for
updating BCP 78 to clarify the above?

The current text (the parenthesis) appears to be permissive about the
_purpose_ of the rights granted, but does not modify _whom_ is given
those rights.  Scott Bradner's draft-bradner-rfc-extracts-00 confirm
that interpretation, as does the FSF and debian-legal's
interpretations, if I remember correctly.

In other words, change:

        as MIB and PIB modules), ...

into:

    (E) to extract, copy, publish, display, distribute, modify and
        incorporate into other works, for any purpose (and not limited
        to use within the IETF Standards Process) and by anyone
                                                  -------------
        (including third parties) any executable code or code
        -------------------------
        fragments that are included in any IETF Document (such as MIB
        and PIB modules), ...

I underlined the modified part.

This modification would improve the copyright-aspect of this problem
until the other work that this WG is doing is finished.  Timing is an
issue here, since new rules in this area cannot apply retroactively
(as far as I understand).  Until this is fixed in BCP 78, each
document that contain code would need additional text to give the
necessary rights to third parties.

/Simon

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 17 Jan 2007 14:40:33 +0100

(on the basis that this point *is* relevant to the
Trust FAQ, I have not changed the subject)

> in free software?" question.

Not surprising, since there is no simple reply. But there is,
as the FAQ tells you, a slightly more complex reply:

1. You can embed and modify code from RFCs in software
(FAQ #6 and #7).

2. If you put such software under an OS license, the Trust
will not bother you (FAQ #9). (But, we can never say what
the original author might do.)

I realise it's the last parenthesis that might be troublesome.
But we can't give rights that we don't own.

     Brian

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 17 Jan 2007 14:43:07 +0100

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

>> change IETF policy so as to grant implementers a patent license to
>> use code that's embedded in RFCs (oversimplifying,
>> of course).
>

The IETF can require that _the authors_ grant these rights.  The IETF
do that today, for other rights, in BCP 78.

While BCP 78 is flawed in many respects, this is not one of them.  It
would be possible for the IETF to require that rights are granted to
third parties that the IETF does not own itself.  I believe that would
be a good thing, as I don't want to see the IETF "own" (in the legal
sense) contributions.  My perception is that the IETF has wisely kept
out of that business.

I want to clarify that I have NOT been talking about patents at all so
far, as our chairs have declared that shouldn't be discussed here.

/Simon

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 17 Jan 2007 14:57:00 +0100

On 2007-01-17 09:41, Lawrence Rosen wrote:
> software license. That's what "open standards" mean. 

Actually not. "Open standards" is generally taken to mean
one or both of openly developed and openly available. Usability for
open source is a joint attribute of the standard and the technology
it describes.

> Nothing else really
> matters. That is the sole purpose for revising the IETF IP policy. 

That may be your sole purpose. As far as I know, the purpose
is exclusively defined at
http://www.ietf.org/html.charters/ipr-charter.html. As the chairs
have said, when that charter has been executed, the IETF will
need to determine whether the WG should be closed, or rechartered
for new work.

> That is

The IETF's mission is defined in RFC 3935 and is not what you say.
And this is definitely not the list to discuss the IETF's mission.
> switched to a new topic!)

But, it's a topic that is out of scope in this WG at this time.

Note, if there was an emerging consensus among active technical
participants in the IETF for a change in our patent policy, that would
be a very legitimate proposal for a General Area BOF. I don't exclude
that happening, but for the last ten years or so we haven't seen
such a consensus form.

<snip>

> decide something in private later. That's not an acceptable result. 

You misunderstand. The plan of record is that when this WG (mainly
active IETF engineers) has decided the effects it wishes the copyright
language to produce, and the IETF has reached general consensus on
that, then the IETF Trust, which is a servant of the IETF, will take
legal advice to craft the necessary legal language.

     Brian

---

From: "todd glassey" <[email-masked]>
Date: Wed, 17 Jan 2007 06:10:44 -0800

----- Original Message ----- 
From: "Frank Ellermann" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, January 17, 2007 4:26 AM
Subject: Patent licenses (was: IETF Trust FAQ)

> free to use this unless you threaten us with some of your patent

The problem is Frank that it isnt in this part of the world and the IETF has 
to serve this country as well... considering it was created and financed 
here.

> IETF with whatever it takes them to get the required "No Objection" by

Gee Frank - How is the IETF's process any different?

>
> Frank
>
>
>
> __________________________________________From [email-masked] Wed Jan 17 09:05:27 2007
From: "todd glassey" <[email-masked]>
To: <[email-masked]>,
	"Frank Ellermann" <[email-masked]>
Date: Wed, 17 Jan 2007 06:10:44 -0800
Cc: 
Subject: Re: Patent licenses (was: IETF Trust FAQ)

----- Original Message ----- 
From: "Frank Ellermann" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, January 17, 2007 4:26 AM
Subject: Patent licenses (was: IETF Trust FAQ)

> free to use this unless you threaten us with some of your patent

The problem is Frank that it isnt in this part of the world and the IETF has 
to serve this country as well... considering it was created and financed 
here.

> IETF with whatever it takes them to get the required "No Objection" by

Gee Frank - How is the IETF's process any different?

---

From: "todd glassey" <[email-masked]>
Date: Wed, 17 Jan 2007 06:07:51 -0800

Wow Larry - did you take a "Todd Pill" or what? Its like listening to myself 
through a 1 & 1/2 year delay loop.

More in-line...

----- Original Message ----- 
From: "Lawrence Rosen" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, January 17, 2007 12:41 AM
Subject: RE: IETF Trust FAQ

> the sole reason for IETF.

Not necessarily - But I understand your point. If you want to continue the 
terraforming of the IETF so that it finally becomes what it was intended to 
be please continue.

> unhelpful concept of "extracting code" to "make/use."

Larry - whoa - lets blame me for that OK - But what I am saying is that 
derivative uses outside the standards process ar_____

---

From: "todd glassey" <[email-masked]>
Date: Wed, 17 Jan 2007 06:07:51 -0800

More in-line...

----- Original Message ----- 
From: "Lawrence Rosen" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, January 17, 2007 12:41 AM
Subject: RE: IETF Trust FAQ

Larry - whoa - lets blame me for that OK - But what I am saying is that 
derivative uses outside the standards process are what needed to be 
identified.

By the way - I dont object to a true Open-Source based IETF as long as that 
model will allow commercial operators to processes their standards 
initiatives through the IETF.

One major mistake of this WG has been in thinking it was solving something. 
It isnt... The issues of the rights of the users are somewhat irrelevant if 
the internal standards process is so screwed up that rampant abuse is 
possible against those claiming the process is broken, like me.

What needs to happen is that a new level of accountability needs to be 
instillind into the Standards Process and its Players held to that standard.

>  The bigger issue is

Scary thought that - I claimed the same thing a year and a half ago - search 
the archives and you will find me ranting about how Patent Rights cannot be 
separated from the Publishing Rights in a Technologies Disclosure before a 
Standards Committee, and to think so is ludicrous. What's amazing is that a 
year + after I was slammed by the management for saying exactly this about 
Patents, that you, the ex-Counsel to OSI, are saying the same thing...

>  (I have written MANY emails on this topic; I have not

No comment.

> decide something in private later. That's not an acceptable result.

That's why the Trust either needs to be disbanded or reformed under a new 
and more open charter. Also with specific milestones instead of a position 
on a foundation dedicated to creating permanent positions for people to hold 
rather than managing the IP's within the IETF.

> the rules in legally-enforceable terms.

Wow - didnt I say this too about a year or so ago?

> This effort cannot be punted
e what needed to be 
identified.

By the way - I dont object to a true Open-Source based IETF as long as that 
model will allow commercial operators to processes their standards 
initiatives through the IETF.

One major mistake of this WG has been in thinking it was solving something. 
It isnt... The issues of the rights of the users are somewhat irrelevant if 
the internal standards process is so screwed up that rampant abuse is 
possible against those claiming the process is broken, like me.

What needs to happen is that a new level of accountability needs to be 
instillind into the Standards Process and its Players held to that standard.

>  The bigger issue is

Scary thought that - I claimed the same thing a year and a half ago - search 
the archives and you will find me ranting about how Patent Rights cannot be 
separated from the Publishing Rights in a Technologies Disclosure before a 
Standards Committee, and to think so is ludicrous. What's amazing is that a 
year + after I was slammed by the management for saying exactly this about 
Patents, that you, the ex-Counsel to OSI, are saying the same thing...

>  (I have written MANY emails on this topic; I have not

No comment.

> decide something in private later. That's not an acceptable result.

That's why the Trust either needs to be disbanded or reformed under a new 
and more open charter. Also with specific milestones instead of a position 
on a foundation dedicated to creating permanent positions for people to hold 
rather than managing the IP's within the IETF.

> the rules in legally-enforceable terms.

Wow - didnt I say this too about a year or so ago?

> This effort cannot be punted

---

From: John C Klensin <[email-masked]>
Date: Wed, 17 Jan 2007 09:17:04 -0500

--On Wednesday, 17 January, 2007 07:32 -0500 "Contreras, Jorge"
<[email-masked]> wrote:

> disclosures are posted at
> https://datatracker.ietf.org/public/ipr_disclosure.cgi.
>...

Let me add one observation here, without advocating either a
change in policy (or not) or extended further discussion right
now.

In general, the IETF patent policy more or less assumes the
possibility of patents on the technology underlying a standard
and _perhaps_ necessary to practice it.  Now I think we are
talking about patents that specifically cover specific code or
data formats that actually appears in an RFC and that is
necessary to implement it.  Under the current model, where the
IETF can (and should) consider the nature of patent claims and
the state of licensing promises and disclosures in deciding
whether or not to standardize a particular technology, a WG
would be, IMO, insane to define a standard by copying patented
technologies or text directly into an RFC.   If nothing else,
doing so would not add value: one might as well write an RFC
that says "if you are interested in doing this in an
IETF-standard way, read the following patents and then go beg
the patent holder for a license".

I think this points out two things:

(1) During these oft-repeated debates about standards whose
obvious implementations involve encumbered technology, we keep
losing sight of the fact that nothing in the rules _requires_ a
WG to do that.  The policy merely creates the possibility of a
WG (and the IETF) making a choice to standardize something
encumbered.  It certainly does not eliminate the possibility of
declining to create a standard because the only options are
encumbered.  I believe we have made the choice to do nothing
when faced with "encumbered or nothing" in the past.  I would
hope that an individual (non-WG) submission for the standards
track that required encumbered technology, especially encumbered
technology from which the submitter stood to benefit, would be
treated, at best, with extreme skepticism.

The current policy doesn't require that we standardize
encumbered technology, it merely broadens our options.  Speaking
personally, I'd prefer to see a lot more complaints during WG
deliberations or, if necessary, at Last Call that point out that
there are encumbering technologies involved in a draft under
consideration and arguing more strongly for either un-encumbered
approaches or that standardization isn't useful enough given the
encumberances.  I would expect such arguments to be very
powerful against a definition that contained embedded code with
associated patent claims.

(2) IMO, all of this should strongly reinforce the importance of
standardizing results and observable behavior and not particular
methods and processes.   While that principle doesn't help much
in the case of data structures like MIBs, in general, while it
may be easier to write a standard in terms of code examples, or
even pseudo-code, than to do so in terms of descriptive text
that can be implemented in multiple ways, the latter is almost
always to be preferred, both to permit innovation and to reduce
vunerability of the standard itself to patent issues.

Just my opinion.
    john

---

From: "todd glassey" <[email-masked]>
Date: Wed, 17 Jan 2007 06:18:56 -0800

Jorge - this makes an assumption of informed consent and that is something 
we both know is missing from all IETF submission and IP right conveyance 
processes. That said I think you are missing the real issues herein.

    1)     Any submission will have Patent Implications and as such MUST be 
disclosed in proper language honoring those.  Patent rights cannot be 
separated from technologies discussions made in print through the IETF.

    2)    Any submission made to the IETF under an IP that is challenged by 
a 3rd party must be halted until such time as that IP's ownership is 
resolved.

    3)    Individuals rights are more important than the IETF's rights since 
the IETF is only operating a Standards Process and not creating a war-chest 
of IP right?

Todd

----- Original Message ----- 
From: "Contreras, Jorge" <[email-masked]>
To: "Stephane Bortzmeyer" <[email-masked]>; "Harald Alvestrand" 
<[email-masked]>
Cc: "IPR WG" <[email-masked]>
Sent: Wednesday, January 17, 2007 4:32 AM
Subject: Patented RFC Code

The idea being that, if you want to use code from
an RFC, you should be able to determine whether the
Contributor claims patent rights in it.  If there
is no disclosuFrom [email-masked] Wed Jan 17 09:23:16 2007
From: "todd glassey" <[email-masked]>
To: "Contreras, Jorge" <[email-masked]>,
	"Stephane Bortzmeyer" <[email-masked]>,
	"Harald Alvestrand" <[email-masked]>
Date: Wed, 17 Jan 2007 06:18:56 -0800
Cc: IPR WG <[email-masked]>
Subject: Re: Patented RFC Code

Jorge - this makes an assumption of informed consent and that is something 
we both know is missing from all IETF submission and IP right conveyance 
processes. That said I think you are missing the real issues herein.

    1)     Any submission will have Patent Implications and as such MUST be 
disclosed in proper language honoring those.  Patent rights cannot be 
separated from technologies discussions made in print through the IETF.

    2)    Any submission made to the IETF under an IP that is challenged by 
a 3rd party must be halted until such time as that IP's ownership is 
resolved.

    3)    Individuals rights are more important than the IETF's rights since 
the IETF is only operating a Standards Process and not creating a war-chest 
of IP right?

Todd

----- Original Message ----- 
From: "Contreras, Jorge" <[email-masked]>
To: "Stephane Bortzmeyer" <[email-masked]>; "Harald Alvestrand" 
<[email-masked]>
Cc: "IPR WG" <[email-masked]>
Sent: Wednesday, January 17, 2007 4:32 AM
Subject: Patented RFC Code

---

From: "todd glassey" <[email-masked]>
Date: Wed, 17 Jan 2007 06:21:24 -0800

Jorge
You mean 3.3.C.1.1 - the clauses are misnumbered. 3.3.D is actually a 
continuation as a sub-heading under the last sentence of 3.3.C. Likewise 
3.3.E has the same relation to 3.3.D

Todd Glassey

----- Original Message ----- 
From: "Contreras, Jorge" <[email-masked]>
To: "Stephane Bortzmeyer" <[email-masked]>
Cc: "IPR WG" <[email-masked]>
Sent: Wednesday, January 17, 2007 4:53 AM
Subject: RE: Patented RFC Code

re of patent rights, then it would not

---

From: "todd glassey" <[email-masked]>
Date: Wed, 17 Jan 2007 06:21:24 -0800

Jorge

Todd Glassey

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 17 Jan 2007 16:36:42 +0100

> updating BCP 78 to clarify the above?
There is, in the form of approving -outbound and -inbound. See 
resolution of issues from San Diego.

If those two documents (one of which isn't drafted yet, one of which 
hasn't been republished) don't satisfy you on this point, a comment 
pointing that out is in order.

But that particular door has been flat on the ground for a year or more, 
I believe. Stop trying to bash it in.

Harald

---

From: "Lawrence Rosen" <[email-masked]>
Date: Wed, 17 Jan 2007 08:06:36 -0800

> Patented where? Software patents do not exist on my side of the world.

But they exist on *my* side of the world. And there are laws here that
prevent the import into the U.S. of infringing products, including in some
situations the import of essential components of infringing products.

All patents are local, unlike copyright.

I simply can't imagine why we'd create an IETF specification that can't for
patent reasons be implemented in the U.S. as readily as in other countries.

/Larry

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 17 Jan 2007 17:21:14 +0100

> patent reasons be implemented in the U.S. as readily as in other countries.
We've done that before - IPSec and the minimum keylength of 56 bits (DES).
In that case, it was a deliberate protest against a broken policy.

But I suspect that we can't create standards that have that effect in 
this context....

Harald

---

From: Ted Hardie <[email-masked]>
Date: Wed, 17 Jan 2007 11:08:47 -0800

>At 8:39 PM -0800 1/16/07, Lawrence Rosen wrote:

>policy that doesn't work for anyone.

The patent policy of the IETF boils down to "The WG decides based on information
which its participants are required to provide".  WGs can and do decide
to decline to make standard technologies that have fundamental patent
impediments.  They also can, and have, decided that a particular
technology is so useful that it should be made standard despite
the fundamental patents--public key crypto being the most cited
example.  The key aspect of the IETF's policy is that it is the participants
who make the judgement call.  If someone invents a faster-than-light
data transport based on quantum entanglement, patents it, then asks for
the IETF's help in making IP run on it, the IETF participants interested
get to decide whether having FTL transport is worth dealing with the
patent.  It isn't pre-decided for them; it's a judgement call. 

That is why it is key that the IETF remain committed to open standards
in the sense that has been true here all along:  open participation and
open availability.  That makes sure anyone who cares can have a voice.
Efforts to pre-dispose the playing field toward specific patent/license
regimes *reduce* the openness of the IETF, as they discourage some
players who would otherwise participate. 

				Ted Hardie

---

From: "Lawrence Rosen" <[email-masked]>
Date: Wed, 17 Jan 2007 12:49:38 -0800

> players who would otherwise participate.

Unfortunately that way you define "open availability" doesn't ensure that
IETF standards can be implemented in open source software. Those standards
aren't open enough, AFAICare. 

But my earlier point was broader than that even: This proposed IETF policy
doesn't even work for private companies seeking proprietary solutions. There
is no advantage to participate in setting industry standards that come with
no promise even of RAND patent licenses, much less free ones. 

If the owners of private patents want to play with other companies in
private arenas for private standards, that's fine with me. But that is not
what I see as IETF's mission, or rather it is not part of any mission I
consider important for free and open source software. 

Leaving these matters, as you recommend, to the whims and wishes of
individual IETF working groups and later licenses TBD isn't a solution for
anyone. Decide now that the IETF is a form of public trust and not just an
engineer's playground*, and act accordingly.

/Larry Rosen

* Forgive me, my engineer friends, for this bit of hyperbole. 

> From: Ted Hardie [mailto:[email-masked]]
> Sent: Wednesday, January 17, 2007 11:09 AM
> Subject: IETF Patent policy (was RE: IETF Trust FAQ)
>

---

From: Ted Hardie <[email-masked]>
Date: Wed, 17 Jan 2007 13:11:45 -0800

>no promise even of RAND patent licenses, much less free ones.

Participating means you have a say in what the standards say, including
whether its technology requires adhering to a license or not.

The bulk of your argument boils down to:  we shouldn't trust those people
in the working group to make the right decision, despite them having
the context, knowing the alternatives, and having to live with the
results.  We should make it once, for them, and deal only with the
people who liked that decision enough to stick around.

That works in some contexts, but the Internet can't fork and remain
valuable.  Sticking to open participation means the largest group of people
can participate whenever they care to, and it is the right way to go here.

If you're going to talk about public trusts, you should learn to trust
the public.  Tying the hands of those who want to participate and
will live with the results isn't the right way to go.  If history is a
guide, WGs will continue to choose unencumbered technology the
great majority of the time, and when they do not it will be for reasons
grounded in the context of the work of the group's work, not in abstract
statements about what generality is better or worse.

			Ted Hardie

---

From: John C Klensin <[email-masked]>
Date: Wed, 17 Jan 2007 16:31:39 -0500

--On Wednesday, 17 January, 2007 12:49 -0800 Lawrence Rosen
<[email-masked]> wrote:

> Ted Hardie wrote:
>> That is why it is key that the IETF remain committed to open
>> standards in the sense that has been true here all along:
>> open participation and open availability.  That makes sure
>> anyone who cares can have a voice. Efforts to pre-dispose the
>> playing field toward specific patent/license regimes *reduce*
>> the openness of the IETF, as they discourage some players who
>> would otherwise participate.
> 
> Unfortunately that way you define "open availability" doesn't
> ensure that IETF standards can be implemented in open source
> software. Those standards aren't open enough, AFAICare. 
> 
> But my earlier point was broader than that even: This proposed
> IETF policy doesn't even work for private companies seeking
> proprietary solutions. There is no advantage to participate in
> setting industry standards that come with no promise even of
> RAND patent licenses, much less free ones. 

Certainly individuals sensitive to the needs and concerns of
such a company should vigorously oppose any WG action that would
develop a standard whose provisions require practicing a patent
for which there are no assurances that licenses will be
available.

> If the owners of private patents want to play with other
> companies in private arenas for private standards, that's fine
> with me. But that is not what I see as IETF's mission, or
> rather it is not part of any mission I consider important for
> free and open source software. 
> 
> Leaving these matters, as you recommend, to the whims and
> wishes of individual IETF working groups and later licenses
> TBD isn't a solution for anyone. Decide now that the IETF is a
> form of public trust and not just an engineer's playground*,
> and act accordingly.

Assuming that the decisions of those WGs are "whims" is either
more hyperbole or deeply insulting to the people who participate
in them.  What I've seen in the IETF, in practice, is a
significant distaste for encumbered technologies coupled with a
willingness to face reality when something sufficiently
important cannot be standardized without dependence on something
encumbered. The Public Key Crypto issue mentioned earlier stands
out as an example and I believe that we made the right decision,
rather than ignoring the issues and waiting for all of the
relevant patents to expire (which appeared to be the only other
choice).  You may disagree, of course.

> * Forgive me, my engineer friends, for this bit of hyperbole. 

And forgive us, including those of us who are not engineers, for
resisting having the IETF turn into a playground for lawyers who
want us to adopt sweeping policy rules that would prevent us
from making finely-tuned decisions in the best interests of the
Internet.

       john

---

From: Mukundan R <[email-masked]>
Date: Thu, 18 Jan 2007 18:29:43 +0530

Hi,

<<snip>>

>choice).  You may disagree, of course.
If the IETF has in practice has a distaste for encumbered technologies 
(fair thinking), coupled with the local power of being applied for a 
patented piece of code, this issue becomes a local affair - no bearing 
on the other parts of the world wrt the status of the policy's ambiguity..

what is the number of patented codes which has not been given a license 
as part of a RFC to be used / imported in(to) the americas for 
development of systems by competitors?

If that is a big number, that would have raised a series of other issues 
which in turn must have left a bad taste leading to the sorting out of 
the ambiguity in the policy. but has that occured? - i am not aware.

The issue raises when there is a serious shift towards having software 
patents being introduced in all parts of the world, which i am afraid 
cannot happen in the near / distant future.

Thanks and Regards
Mukundan

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 19 Jan 2007 04:28:37 +0100

Contreras, Jorge wrote:
 
> NOT have such patent rights.

Yes, that was also my impression.  But this should be
pointed out where authors can't miss it - especially
if earlier related (but different) contributions were
published with an IPR statement.  

E.g. if an I-D is renamed, modified, and later published
as RFC it's not more as obvious as it should be on the
IPR pages.  There should be a link to the IPR statement
in the RFC if that is possible.

Frank

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Thu, 18 Jan 2007 22:38:59 -0500

On Fri, 19 Jan 2007 04:28:37 +0100

> in the RFC if that is possible.
The problem with that is 3rd-party patents may be discovered later.
Our IPR policy encourages notification about these, and entry into the
IETF's IPR database, but there's no way to retroactively change the RFC.

---

From: [email-masked] (Scott O. Bradner)
Date: Thu, 18 Jan 2007 22:38:40 -0500 (EST)

> There should be a link to the IPR statement

see RFC 3979 section 11 for a discussion about this sort of thing

Scott

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 19 Jan 2007 04:50:28 +0100

> patent reasons be implemented in the U.S. as readily as in other countries.

It would be also not funny if some code I've published can't be legally
used in the U.S.  Probably U.S. users copying say published SHA-256 code
in their favourite programming language won't know this potential issue.

Frank

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 19 Jan 2007 04:59:58 +0100

> The problem with that is 3rd-party patents may be discovered later.

Yes, the case I've in mind was a "first party" claim, and about the
readers of the RFCs without direct pointer from or to the IPR pages,
unless they happen to know the former name of the renamed draft.

> there's no way to retroactively change the RFC

Sure, I was talking about known IPR, not something discovered later.

Frank

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 19 Jan 2007 08:07:16 +0100

>> in the RFC if that is possible.

I think that would be a useful thing to do.

> see RFC 3979 section 11 for a discussion about this sort of thing

Ouch.  The problems noticed in that section could be solved by
requiring certain text to make it clear that there may be other
relevant IPR for the document, that the IPR notice in a document does
not constitute an informed opinion of the IETF/IESG/etc, and there
should be a pointer to the online IPR disclosures.

/Simon

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 19 Jan 2007 08:15:56 +0100

> in the RFC if that is possible.
If an I-D is renamed, modified and published as an RFC, AND THE 
SECRETARIAT KNOWS ABOUT THE TRAIL, a search in the IPR database will 
actually find all the relevant disclosures. Try it and see.

Note: If an I-D is renamed, and nobody tells the secretariat that it's a 
rename, that won't be recorded anywhere. They're not omniscent.

---

From: [email-masked] (Scott O. Bradner)
Date: Fri, 19 Jan 2007 07:22:04 -0500 (EST)

>  and there

see RFC 3979 section 5

Scott

---

From: "todd glassey" <[email-masked]>
Date: Fri, 19 Jan 2007 11:38:41 -0800

Isnt the real issue the precedents set to date. I think the bigger question 
is whether the IETF can force new standards process participants to fork 
over their rights to the Trust when the IETF didn't do that previously.

Further, what happens to IP relative to BCP 78 and 79 when a revised RFC is 
submitted or a standard which was issued under the previously in place 
RFC2026 guidelines. I think the current terms for participation are pretty 
egregious in comparison and forcing any new submissions as updates to 
previously published works may have issues. IP Extortion is a term that 
comes to mind pretty easily here.

Todd Glassey

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 20 Jan 2007 05:48:30 +0100

Harald Alvestrand wrote:

> If an I-D is renamed, and nobody tells the secretariat that it's a

Same problem here, I'm far from sure how #434 might be still related
to RFCs 4405..4407.  It's also somewhat discouraging if the nice
ipr_search.cgi gives me "shared" + "shadow" + "shaper", but no "SHA".

BTW, in reply to an unrelated off list mail by somebody else here:

I've heard that the design of SHA-256 might be patented, and that
software claiming to support SHA-anything must pass a mandatory
conformance test for usage in the U.S. (or U.S. government ?).  So
if somebody publishs SHA-code, and somebody else uses this code in
their product, and they distribute or sell the result in the U.S.,
then I've no clue if that's allowed.

The RFC 3979 rule about no links to IPR claims in RFCs makes no 
sense for me wrt known first party claims, and this statement:

| The idea being that, if you want to use code from
| an RFC, you should be able to determine whether the
| Contributor claims patent rights in it.  If there
| is no disclosure of patent rights, then it would not
| be unreasonable to assume that the Contributor does
| NOT have such patent rights.
 <http://permalink.gmane.org/gmane.ietf.ipr/4399>

Frank

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 22 Jan 2007 08:41:32 +0100

> then I've no clue if that's allowed.

Interesting, I looked in my mailing list archives, and found a link
that appears to be relevant:

http://patft.uspto.gov/netacgi/nph-Parser?patentnumber=6829355

I can't find anything about this for RFC 4634.  Maybe I'm using the
IPR disclosure search tools incorrectly?

RFC 4634 contains source code, and a license statement that appears to
be in conflict with the IETF license - the RFC 4634 license require
that a references to RFC 4634 be added to everything that reference
the software, but the IETF license do not require that, and thus the
RFC 4634 license requires more things of the user than what the IETF
license may be interpreted to require, and thus are incompatible.

   Permission is granted for all uses, commercial and non-commercial, of
   the sample code found in Section 8.  Royalty free license to use,
   copy, modify and distribute the software found in Section 8 is
   granted, provided that this document is identified in all material
   mentioning or referencing this software, and provided that
   redistributed derivative works do not contain misleading author or
   version information.

   The authors make no representations concerning either the
   merchantability of this software or the suitability of this software
   for any particular purpose.  It is provided "as is" without express
   or implied warranty of any kind.

How this looks to me is that we have a patented technology published
in an RFC with code licensed in a way that is incompatible with the
IETF copying conditions, major free software licenses, and several
proprietary software licenses.

/Simon

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 22 Jan 2007 22:14:54 +0100

> IPR disclosure search tools incorrectly?
Feel free to file a third party disclosure.

Is there any evidence that Glenn M. Lilly has ever been an IETF participant?

---

From: "Lawrence Rosen" <[email-masked]>
Date: Mon, 22 Jan 2007 14:04:41 -0800

> Is there any evidence that Glenn M. Lilly has ever been an IETF

A more important point is that "The United States of America as represented
by the National Security Agency" is the Assignee of that patent. Has anyone
spoken to them? What's their email address? :-)

/Larry

> Sent: Monday, January 22, 2007 1:15 PM
> To: Simon Josefsson
> Cc: Frank Ellermann; [email-masked]
> Subject: Re: Case study: SHA2
> 
> Simon Josefsson wrote:

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 23 Jan 2007 00:03:41 +0100

Lawrence Rosen wrote:

> Has anyone spoken to them?

http://www.proper.com/lookit/hash-futures-panel-notes.html

The part I like best is the modified "road to nowhere"...
the patent is mentioned in the "after the panel" section.

Frank

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Mon, 22 Jan 2007 20:23:54 -0500

On Mon, 22 Jan 2007 14:04:41 -0800
"Lawrence Rosen" <[email-masked]> wrote:

> A more important point is that "The United States of America as
> represented by the National Security Agency" is the Assignee of that
> patent. Has anyone spoken to them? What's their email address? :-)
> 
See http://www.nsa.gov/techtrans/index.cfm -- it would seem to be the
correct reference.  It's a much better place to discuss their patents
than this mailing list, where they're out of scope (hint, hint, hint...)

---

From: "Barr Hibbs" <[email-masked]>
Date: Tue, 23 Jan 2007 18:47:32 -0800

Simon,

the section that you call out reads a great deal like my
memory of the BSD license provisions...  I don't recall too
many people claiming that these provisions were overly
burdensome on their use of BSD code...

on the other hand, I might not be accurately reacting to
your point regarding the apparent (or actual) confusion and
contradiction between RFC 4634 and IETF licensing....

--Barr Hibbs

> Sent: Sunday, January 21, 2007 23:42
> To: Frank Ellermann
> Cc: [email-masked]
> Subject: Case study: SHA2 (was: Re: Patented RFC Code)
>
>

I can't find anything about this for RFC 4634.  Maybe I'm
using the
IPR disclosure search tools incorrectly?

RFC 4634 contains source code, and a license statement that
appears to
be in conflict with the IETF license - the RFC 4634 license
require
that a references to RFC 4634 be added to everything that
reference
the software, but the IETF license do not require that, and
thus the
RFC 4634 license requires more things of the user than what
the IETF
license may be interpreted to require, and thus are
incompatible.

   Permission is granted for all uses, commercial and
non-commercial, of
   the sample code found in Section 8.  Royalty free license
to use,
   copy, modify and distribute the software found in Section
8 is
   granted, provided that this document is identified in all
material
   mentioning or referencing this software, and provided
that
   redistributed derivative works do not contain misleading
author or
   version information.

   The authors make no representations concerning either the
   merchantability of this software or the suitability of
this software
   for any particular purpose.  It is provided "as is"
without express
   or implied warranty of any kind.

How this looks to me is that we have a patented technology
published
in an RFC with code licensed in a way that is incompatible
with the
IETF copying conditions, major free software licenses, and
several
proprietary software licenses.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 24 Jan 2007 08:06:12 +0100

> burdensome on their use of BSD code...

Yes, you are right, the RFC 4634 license is like the original BSD
license.  (One difference is that the BSD license require that
copyright notices are present and preserved, though.)

However, I don't have the same impression that you do.  Many people
have rightly claimed that those provisions _are_ overly burdensome,
see for example:

http://en.wikipedia.org/wiki/BSD_license
http://www.gnu.org/philosophy/bsd.html

Ultimately, the University of California changed their license in
1999, creating the "revised BSD license".

The problems caused by the acknowledgement clause in licenses are
still causing severe problems for many implementers.  See the work
that (amongst others) the Debian community have been doing to avoid
the use of OpenSSL, in order to be GPL-compatible.  OpenSSL have a
license similar to the original BSD license.

> contradiction between RFC 4634 and IETF licensing....

The RFC 4634 license is similar to the original BSD license, in that
they both require acknowledgements.  That by itself has all the
problems discussed in the above link.

Further, Jorge has said that the RFC 3978 license gives third parties
the right to extract code and use it in their implementation (I
disagree, but that's another story).

If you follow to the RFC 3978 license, you won't necessarily conform
to the license expressed in RFC 4634.

To see what I mean: Under the RFC 3978 license according to Jorge, I
don't have to add acknowledgements when I borrow code from an RFC.
However, the license in RFC 4634 requires that I do.  That is the
conflict I'm concerned with.

If we worry about putting conflicting copyright license statements
into RFCs, and this appears to be the consensus and current rules even
if not the current practice, RFC 4634 would be another document to
study to see how our current process has failed.

I'm sorry that I cannot explain it clearer than this.

/Simon

---

From: "todd glassey" <[email-masked]>
Date: Wed, 24 Jan 2007 05:32:55 -0800

Speaking Of SHA - http://en.epochtimes.com/news/7-1-11/50336.html might be 
of interest and amusement.

T.

---

From: "todd glassey" <[email-masked]>
Date: Wed, 24 Jan 2007 05:32:55 -0800

T.

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Wed, 24 Jan 2007 10:16:06 -0500

On Wed, 24 Jan 2007 05:32:55 -0800
"todd glassey" <[email-masked]> wrote:

> Speaking Of SHA - http://en.epochtimes.com/news/7-1-11/50336.html
> might be of interest and amusement.
> 

This is not news, either in the security community as a whole or the
IETF's security area.  In fact, just yesterday NIST announced a
competition for selecting a new hash function.  As I mentioned
privately to some list members, the Federal Register item said

	The algorithm must be publicly	disclosed and available
	on a worldwide, non-exclusive, royalty-free basis.

See http://www.nist.gov/hash-function for details.

But -- we're getting off-topic.  Now that we have a WG document to
discuss, I'd like people to restrict their postings to in-scope.  I
mentioned that issue a little while ago, but didn't repeat it while
there was no WG business to discuss.  Now thereis.