Subject: ANNOUNCEMENT: The IETF Trustees invite your review and comments on a proposed Work-Around to the Pre-5378 Problem

From: "Ed Juskevicius" <[email-masked]>
Date: Thu, 8 Jan 2009 16:43:50 -0500

The purpose of this message is twofold:

1) To summarize the issues that some members of our community 
   have experienced since the publication of RFC 5378 in November 2008, 
   and
2) To invite community review and discussion on a potential work-around 
   being considered by the IETF Trustees.

Some I-D authors are having difficulty implementing RFC 5378.  An  
example of the difficulty is as follows:

  - an author wants to include pre-5378 content in a new submission
    or contribution to the IETF, but
  - s/he is not certain that all of the author(s) of the earlier  
    material have agreed to license it to the IETF Trust according
    to RFC 5378.

If an I-D author includes pre-5378 material in a new document, then s/he
must represent or warrant that all of the authors who created the  
pre-5378 material have granted rights for that material to the IETF Trust.
If s/he cannot make this assertion, then s/he has a problem.

This situation has halted the progression of some Internet-Drafts and  
interrupted the publication of some RFCs.  The Trustees of the IETF Trust
are investigating ways to implement a temporary work-around so that IETF
work can continue to progress.  A permanent solution to this "pre-5378
problem" may require an update to RFC 5378, for example new work by the
community to create a 5378-bis document.

The remainder of this message provides an outline of the temporary work- 
around being considered by the Trustees.

RFC 5378 sections 1.j and 5.3.c provide the IETF Trust with the  
authority to develop legend text for authors to use in situations where
they wish to limit the granting of rights to modify and prepare
derivatives of the documents they submit.  The Trustees used this
authority in 2008 to develop and adopt the current "Legal Provisions
Relating to IETF Documents" which are posted at:
http://trustee.ietf.org/license-info/.

The Trustees are now considering the creation of optional new legend text  
which could be used by authors experiencing the "pre-5378 problem".

The new legend text, if implemented, would do the following:

  a. Provide Authors and Contributors with a way to identify (to the
     IETF Trust) that their contributions contain material from pre-5378  
     documents for which RFC 5378 rights to modify the material outside
     the IETF standards process may not have been granted, and

  b. Provide the IETF Trust and the community with a clear indication 
     of every document containing pre-5378 content and having the
     "pre-5378 problem".

So, how could the creation and use of some new legend text help people
work-around the pre-5378 problem?

The proposed answer is as follows:

  1. Anyone having a contribution with the "pre-5378" problem should add
     new legend text to the contribution, to clearly flag that it includes
     pre-5378 material for which all of the rights needed under RFC 5378
     may not have been granted, and

  2. The IETF Trust will consider authors and contributors (with the  
     pre-5378 problem) to have met their RFC 5378 obligations if the
     new legend text appears on their documents, and

  3. Authors and contributors should only resort to adding the new  
     legend text to their documents (per #1) if they cannot develop  
     certainty that all of the author(s) of pre-5378 material in
     their documents have agreed to license the pre-5378 content to
     the IETF Trust according to RFC 5378.

The proposed wording for the new legend text is now available for your
review and comments in section 6.c.iii of a draft revision to the
IETF Trust's "Legal Provisions Relating to IETF Documents" located at
http://trustee.ietf.org/policyandprocedures.html.

Please note that the above document also contains new text in section 5.c
dealing with "License Limitations".

If your review and feedback on this proposed work-around is positive,
then the new text may be adopted by the Trustees in early February 2009,
and then be published as an official revision to the Legal Provisions
document.  If so adopted, Internet-Drafts with pre-5378 material may 
advance within the Internet standards process and get published as RFCs
where otherwise qualified to do so.  Unless covered by sections 6.c.i or
6.c.ii, authors of documents in which there is no pre-5378
material must provide a RFC 5378 license with no limitation on
modifications outside the IETF standards process.

The IETF Trust will not grant the right to modify or prepare derivative
works of any specific RFC or other IETF Contribution outside the IETF
standards process until RFC 5378 rights pertaining to that document have
been obtained from all authors and after compliance by the IETF Trust
with RFC 5377.  The Trustees will establish one or more mechanisms by
which authors of pre-5378 documents may grant RFC 5378 rights.

The Trustees hereby invite your review, comments and suggestions on this
proposed work-around to the "pre-5378 problem".  The period for this review
is 30 days.  Microsoft WORD and PDF versions of the proposed revisions are
attached to this message.  Copies are also available on the IETF Trust
website under the heading "DRAFT Policy and Procedures Being Developed" at:
http://trustee.ietf.org/policyandprocedures.html 

All feedback submitted before the end of February 7th will be considered by
the Trustees.  A decision on whether to move forward with this proposal will
be made and communicated to you before the end of February 15th.

Please give this your attention.

Regards and Happy New Year !

Ed Juskevicius, on behalf of the IETF Trustees
[email-masked]
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 09 Jan 2009 11:27:59 +1300

Ed,

Thanks for this.

As I understand it, the proposal boils down to adding a disclaimer to
affected documents that reads:

"This document contains material from IETF Documents or IETF Contributions
published before November 10, 2008 and, to the Contributor’s knowledge,
the person(s) controlling the copyright in such material have not granted
the IETF Trust the right to allow modifications of such material outside
the IETF Standards Process. Without obtaining an adequate license from the
person(s) controlling the copyright, this document may not be modified outside
the IETF Standards Process, and derivative works of it may not be created
outside the IETF Standards Process, except to format it for publication as
an RFC and to translate it into languages other than English."

That's a little bit long-winded but I agree that this is a correct fix.
However, I didn't see in your note an explanation of the procedure
for approving the use of this boilerplate (and preventing it being
used simply as an easy way out). Rather than ranting about that, I
will shortly submit an I-D that makes a concrete and, I hope, simple
proposal for that as a fix to RFC5378. I see no reason that we need
to revisit RFC5378 in a fundamental way.

Regards

      Brian

---

From: TSG <[email-masked]>
Date: Thu, 08 Jan 2009 15:20:51 -0800

Ed Juskevicius wrote:

Ed - you nor the rest of this list is going to like this retort but I 
would ask that you read all of it prior to flushing the response.
>     material have agreed to license it to the IETF Trust according
Then the submission of such an assertion would be a criminal act of 
fraud by wire... and that is not a joke.
> pre-5378 material have granted rights for that material to the IETF Trust.
Something which by the way is physically impossible because of how the 
RFC2026 licensing model was setup. Hell even BCP78 and 79 exist under 
RFC2026 rules since they had to be published as such to get them into 
the channel to review and advance them to the BCP's. As such these all 
are moot... funny that eh?
> community to create a 5378-bis document.
You mean a POST-5378 IP Disclosure Document. The issue is what happens 
to any derivative licensing which stems from RFC2026 based controls. And 
since 5378 is a derivative of the BCP78 document it is tied itself to 
the RFC2026 rules still too one could easily argue.
> http://trustee.ietf.org/license-info/.
RFC2026 will not allow this. In fact once published under RFC2026 those 
document's are cast in concrete as far as the license model is concerned.
>      the IETF standards process may not have been granted, and
Meaning that those documents would be published under yet another set of 
IP licensing constraints - So lets see that makes

    1)   Pre BCP78
             o-   Pure RFC2026 based licensing

    2)   Post BCP-78 publishing with Pre-BCP 78 licensing included
             o- Includes non-trust managed IP
             o- Includes trust managed IP

    3)   Post BCP-78 with pure BCP-78 licensing through the Trust
>      of every document containing pre-5378 content and having the

Ahahahah - Oh damn that's funny. Try all of the RFC's published prior to 
(IMHO) the IESG's #$%^&*()_ act of putting BCP78 and BCP79 into production.
> work-around the pre-5378 problem?
It cannot. The RFC2026 Licensing model clearly must survive the original 
filing of the original BCP78 and its ludicrously funny and pretty stupid 
brother BCP79.
>      may not have been granted, and
They, according to the IETF submission process, cannot do this because 
the amended document supposedly has to be submitted under the BCP78/79 
Terms which is what we are saying doesn't work here. So this is clearly 
impossible.
>      new legend text appears on their documents, and
The TRUST isn't the issue - its the US Courts that are the issue.
>      the IETF Trust according to RFC 5378.
I would suggest that this also is not enough...
> Please give this your attention.
Ed this is garbage... If the earlier releases IP Owners will not 
formally change their licensing terms then the ONLY solution is that the 
original license terms for any initiative apply to any and all 
derivative works unless those works have more restrictive licenses. 

There is also an issue as to any physical works which were derived from 
those earlier licenses since they also would be constrained by those 
original terms too one would think. Further this is NOT rocket-science, 
its common sense. If work-product "A" contained specific IP then the 
uses of that IP cannot exceed the original licenses including being 
given to the Trust which RFC2026 doesn't provide for in any form. That 
means that the IETF may not in fact convey those document's to the Trust 
at all. They remain inside the IETF until those other licensees agree to 
relicense their work, and still anyone who was a relying party is still 
bound by the original RFC2026 release rules.

So as an example of how simple this is, take for instance work-product 
"A" which was filed under RFC20206 alone, and that means that the 
follow-on derivatives MUST also be totally contained/constrained by that 
same set of terms and conditions otherwise the original conveyance 
contract is flawed, and may be unenforceable.

Which brings us back to the issue of that the Trust MAY not rewrite 
licenses for any IP that the IETF processed under RFC2026 unless ALL of 
the parties - the people who wrote those drafts, the IP owners of that 
work and anyone who has relied on a SW or systems product fabricated 
under those licenses.

Wake up and smell the coffee... BCP 78 and BCP79 are a waste of time and 
were fabricated by individuals of questionable expertise since they 
pretty clearly have screwed the pooch on this one. Nice move Harald...

Todd Glassey
On behalf of the victims of the IETF Trust.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 9 Jan 2009 00:59:06 +0000

+1 to fred's proposal, let the exceptions be just that and don't  
bother most I-D authors,
Stephen.

On 8 Jan 2009, at 22:49, Fred Baker <[email-masked]> wrote:

> You asked me to make this comment publicly, so here it is.
>
> In my opinion, we need a 5378-bis that keeps the good bits but  
> corrects the issue that has been problematic. The question before  
> the house is how best to achieve that. The proposal here is to  
> provide a work-around that enables an internet draft author to state  
> that s/he has not verified the transferability of his/her text,  
> which will work until an appropriate 5378-bis can be produced. This  
> means that the tools people have to produce and accept the work- 
> around and later on change the tools to accept 5378-bis, and it  
> places a burden on authors to make that statement.
>
> From my perspective, the best approach involves keeping the general  
> case simple. The documents that have been transferred outside the  
> IETF in the past five years is a single digit number, a tenth of a  
> percent of all RFCs if not a smaller fraction. From my perspective,  
> the simplest solution to the transfer issue is to ask the people  
> relevant to a document for which transfer has been suggested whether  
> they have an issue with transferring it, rather than asking every  
> document author his or her opinion on the vast majority of  
> documents, which will never be transferred. Remember that this  
> boilerplate affects internet drafts, but most internet drafts are  
> discussion documents - a fraction of internet drafts even become  
> RFCs, and a small fraction of RFCs are transferred elsewhere.
>
> As to the other issues that 5378 addresses, I suspect that a better  
> approach will be to fall back to 3978/4748/2026 temporarily and move  
> to 5378-bis when it comes rather than to use this very general  
> workaround to 5378's issues until 5378-bis is resolved. 3978 etc  
> worked just fine for most purposes...
>
>
>
> On Jan 8, 2009, at 1:43 PM, Ed Juskevicius wrote:
>
>> <Draft-Update-to-IETF-Trust-Legal-Provisions-1-06-09.DOC><Draft- 
>> Update-to-IETF-Trust-Legal- 
>> Provisions- 
>> 1-06-09.pdf>_______________________________________________
>> Trustees mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/trustees
>

---

From: "Ed Juskevicius" <[email-masked]>
Date: Thu, 8 Jan 2009 20:46:54 -0500

Todd, Thank You for your comments. I've read them. Carefully. Three times.

I'm not sure if we are on the same page.

For example, you wrote:

> licenses for any IP that the IETF processed under RFC2026 unless ALL
> of the parties - the people who wrote those drafts, the IP owners of
> that work and anyone who has relied on a SW or systems product
> fabricated under those licenses.

The IETF Trust is not looking for a way to rewrite licenses for IP processed
under RFC2026.  That is not the objective or the driver of the proposed
revision to the Trust's "Legal Provisions" document. 

You also wrote:

> ... If work-product "A" contained specific IP then the used of that
> IP cannot exceed the original licenses including being given to the
> Trust which RFC2026 doesn't provide for in any form. That means that
> the IETF may not in fact convey those document's to the Trust at all.

Could you please point me to text in RFC2026 that pertains to the above?
When I read 2026, I see the following:

10.  INTELLECTUAL PROPERTY RIGHTS
10.3.  Rights and Permissions 
10.3.1.  All Contributions

   l. Some works (e.g. works of the U.S. Government) are not subject to
      copyright.  However, to the extent that the submission is or may
      be subject to copyright, the contributor, the organization he
      represents (if any) and the owners of any proprietary rights in
      the contribution, grant an unlimited perpetual, non-exclusive,
      royalty-free, world-wide right and license to the ISOC and the
      IETF under any copyrights in the contribution.  This license
      includes the right to copy, publish and distribute the
      contribution in any way, and to prepare derivative works that are
      based on or incorporate all or part of the contribution, the
      license to such derivative works to be of the same scope as the
      license of the original contribution.

I believe the text (above) is quite broad and does permit an author (today)
to prepare a derivative work from a pure 2026 licensed work, and then submit
that derived work into the IETF process.  RFC 5378 is the current BCP with
respect to rights in IETF Contributions; it replaces all of the text in
Section 10 from RFC 2026.  5378 requires new author(s) to make some clear
statements about rights to and for the IETF Trust.  

The issue for some authors today is that they may not be able to assert that
the original licenses (covering some earlier work that they may be using)
would allow for use of the new work outside of the IETF process.  Sam
Hartman identified this concern during the IETF Plenary in November 2008,
and that was a trigger for the "work-around" proposal which the Trustees
sent out for review to everyone a few hours ago.

BCP78 is not, in my personal opinion, "garbage".  Rather, I think it is
incomplete with respect to providing guidance on how pre-5378 content in new
contributions should be handled.  That issue is the driver for the proposed
(and temporary) work-around (per below), and it is also the reason I said
that a permanent solution may require new work by the IETF community to
update RFC 5378.

Regards,

Ed J.

-----Original Message-----
From: TSG [mailto:[email-masked]] 
Sent: January 8, 2009 6:21 PM
To: Ed Juskevicius
Cc: 'IETF Discussion'; [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; 'Trustees'
Subject: Re: ANNOUNCEMENT: The IETF Trustees invite your review and comments
on a proposed Work-Around to the Pre-5378 Problem

Ed Juskevicius wrote:

    1)   Pre BCP78

Todd Glassey

---

From: John C Klensin <[email-masked]>
Date: Thu, 08 Jan 2009 23:05:01 -0500

Stephen and Fred,

One of the interesting issues with 5378 is that there has never
been consensus about what problem(s) it was trying to solve.
The WG reached consensus on the two documents without, IMO,
reaching consensus on the problem statement.  Nothing in our
procedures prohibits that, whether it is wise or not in a
particular case.

However, to the extent to which "the problem" has been handing
off documents to other bodies, I believe it has always been a
distraction because there is a far easier solution... even
easier than the "go ask that set of authors" suggestion that
Fred proposes.  

One thing that has always been vague, perhaps deliberately, is
just where the boundary of "use in the IETF for IETF purposes"
(a crude paraphrase of the intent that has dominated our
thinking since 2026 and before) lies.    With the understanding
that their situations are a bit different because of different
basic IPR rules, other standards bodies have regularly
interpreted their equivalent principles as giving them the
ability to transfer change control to someone else _as a natural
part of their own work_.  I say "regularly", rather than "often"
because, AFAIK, inter-SDO transfers have never been frequent
(except for specifications developed as national standards by
ISO Member Bodies and then transferred to ISO (or ISO/IEC) for
development and maintenance as International Standards).
Sometimes it might require a bit of a dance --for example, we
could define an IEEE WG as being joint with a shadow IETF one,
but then permit it to work under IEEE rules and approval and
publications process-- but the big issue is the handing over of
change control, not the handing over of the document and the
right to maintain it.

>From that perspective, the "transfer" situation is entirely a
problem of definitions.  It is up to the Trustees to get an
opinion from Counsel, but, as a common-sense matter and with the
understanding that I'm one of the more reluctant members of the
community to hand "do whatever you want" rights off to the Trust
without a formal copyright transfer, I just can't imagine an
author/ contributor who would be ok with the IETF using a
Contribution in IETF Standards work for the benefit of the
Internet community taking serious exception to the IETF's
delegating responsibility for that Standard and its maintenance
to some other body.

If I'm correct and transfer of a Standard to another SDO is
really a non-issue, then perhaps the question of what problem(s)
5378 was intended to solve becomes more relevant... or perhaps
it does not.  But, given the problems the 5378/5377 model has
turned out to create, eliminating one of the major claimed
reasons for creating that model makes it much easier to consider
just repealing the things and doing a small update to 3978/4748
to de-glitch them.

     john

--On Friday, January 09, 2009 0:59 +0000 Stephen Farrell
<[email-masked]> wrote:

> +1 to fred's proposal, let the exceptions be just that and
> don't bother most I-D authors,
> Stephen.
> 
>> In my opinion, we need a 5378-bis that keeps the good bits
>> but   corrects the issue that has been problematic. The
>> question before   the house is how best to achieve that. The
>> proposal here is to   provide a work-around that enables an
>> internet draft author to state   that s/he has not verified
>...
>> From my perspective, the best approach involves keeping the
>> general   case simple. The documents that have been
>> transferred outside the   IETF in the past five years is a
>> single digit number, a tenth of a   percent of all RFCs if
>> not a smaller fraction. From my perspective,   the simplest
>> solution to the transfer issue is to ask the people  
>> relevant to a document for which transfer has been suggested
>> whether   they have an issue with transferring it, rather
>> than asking every   document author his or her opinion on the
>...
>> As to the other issues that 5378 addresses, I suspect that a
>> better   approach will be to fall back to 3978/4748/2026
>> temporarily and move   to 5378-bis when it comes rather than
>> to use this very general   workaround to 5378's issues until
>> 5378-bis is resolved. 3978 etc   worked just fine for most
>> purposes...

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 09 Jan 2009 17:13:39 +1300

On 2009-01-09 13:59, Stephen Farrell wrote:
> +1 to fred's proposal, let the exceptions be just that and don't bother
> most I-D authors,
> Stephen.
> 
>> corrects the issue that has been problematic. The question before the
>> house is how best to achieve that. The proposal here is to provide a
>> work-around that enables an internet draft author to state that s/he
>> has not verified the transferability of his/her text, which will work
>> until an appropriate 5378-bis can be produced. This means that the
>> tools people have to produce and accept the work-around and later on
>> change the tools to accept 5378-bis, and it places a burden on authors
>> to make that statement.
>>
>> case simple. The documents that have been transferred outside the IETF
>> in the past five years is a single digit number, a tenth of a percent
>> of all RFCs if not a smaller fraction. 

If that was the main problem, I would agree. But it isn't; it's the ability
to allow appropriate use of extracts, including code extracts, in 3rd
party documents. That potentially concerns every RFC, and automatically
concerns every RFC that is a new version of an older one.

It isn't hard to fix in my opinion (well, I just posted a draft with
the proposed fix) and I don't see that it *requires* any tool fixes.
Optionally, the tools could provide a macro that expands to the
disclaimer text, but cut-and-paste would work equally well.

     Brian

>> From my perspective, the
>> simplest solution to the transfer issue is to ask the people relevant
>> to a document for which transfer has been suggested whether they have
>> an issue with transferring it, rather than asking every document
>> author his or her opinion on the vast majority of documents, which
>> will never be transferred. Remember that this boilerplate affects
>> internet drafts, but most internet drafts are discussion documents - a
>> fraction of internet drafts even become RFCs, and a small fraction of
>> RFCs are transferred elsewhere.
>>
>>> <Draft-Update-to-IETF-Trust-Legal-Provisions-1-06-09.DOC><Draft-Update-to-IETF-Trust-Legal-Provisions-1-06-09.pdf>_______________________________________________
>>>
>>> Trustees mailing list
>>> [email-masked]

---

From: Martin Duerst <[email-masked]>
Date: Fri, 09 Jan 2009 19:42:20 +0900

>party documents.

First, my gut feeling would be that use of ABNF and similar stuff
in actual implementations might simply be considered fair use, or
it may just be possible to consider implementations as part of the
IETF standards process (which they very much are).

The situation may be somewhat different for longer/longish pieces
of code, a typical example of which might be Appendix A of
http://www.ietf.org/rfc/rfc2192.txt. But the code is essentially
there to serve as an example, as an additional guarantee that
there is a common, shared understanding of the specification,
not as a drop-in implementation. Also, such code in many
instances is already covered under a more appropriate licence
anyway.

>That potentially concerns every RFC,

Given the above (some of which might be a bit out on a limb, or not),
I'm still not convinced the potential issue is that big.

>and automatically

I have read your draft. I have one suggestion for modification.
The text says:

                           "the person(s) controlling the copyright in
   such material have not granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process."

I think it might be more appropriate to change "the person(s)" to
"some person(s)".

Overall, I think currently the aspect most overlooked in the general
discussion, but most relevant for somebody who would actually like
to move on with publications (I'm both a WG chair with some drafts
that have completed WG Last Call, but which are now in "RFC 5378 limbo",
and an author of some individual IDs that I'd like to update
and move forward) is:

WHO exactly are we supposed to get permissions from.

The situation of a deceased author is a tought one, but it's an
obvious one. But I haven't seen any clear answer to whether
permission from all the authors/editors (the people listed in
the front of the document) is sufficient, whether we have to
ask everybody above a certain percentage of email contributions
in the WG, everybody who's mentioned in the Acks section, or
what. It's a significant nuissance for everybody to go around
and beg people (maybe including for their former employer)
to confirm something they probably couldn't care less, even if
they otherwise think the IETF does great stuff and everything.
So it would really be good to know who exactly has to be
bothered, and who not.

Regards,    Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 9 Jan 2009 07:08:20 -0500

On Jan 9, 2009, at 5:42 AM, Martin Duerst wrote:

>>> bother
>>>> IETF

That is really the Trust's text, from

http://trustee.ietf.org/docs/Draft-Update-to-IETF-Trust-Legal-Provisions-1-06-09.pdf

And, it is from the DRAFT legal provisions, not the current legal  
provisions.

At any rate, I think it needs to be "persons or entities" as some  
copyrights are controlled by corporations, universities
or maybe even governments.

Regards
Marshall

---

From: Thomas Narten <[email-masked]>
Date: Fri, 09 Jan 2009 09:32:25 -0500

>      the IETF standards process may not have been granted, and

One thing that I don't recall being mentioned explicitely is that any
such clause (IMO) needs to make clear which contributers are granting
full 5378 rights, and which are not. What I mean is that all *current*
contributers (i.e., those involved in the editing the *current*
version of the document) need to make clear that their *new*
contribution *is* covered by 5378. That is, we do not want existance
of pre-5378 text to allow a current contributer to continue to operate
under the pre-5378 rules. It is only the pre-existing text that is
covered by the older rules. Presumably, if at some future time we can
get proper rights from all previous contributers, the document should
then be covered in full by 5378.

Looking at the updated draft legal provisions, this aspect needs a
little bit more clarification, IMO. (I'd be happy to comment further
offline if that is not clear.)

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Fri, 09 Jan 2009 10:16:19 -0500

> So it would really be good to know who exactly has to be

IANAL, but if you are expecting anyone (like the IETF) to give a clear
final, legally defensible answer to "who do you need permission from",
you won't get it. That is the nature of legal questions and is what
makes this entire discussion so difficult. And why what is an
accptable risk for you may not be an acceptable risk for me or someone
else.

To answer the question, you have to look at who bears the risk if they
make an assertion (i.e, by claiming that all contributers have signed
off) that someone later challenges. And what the potential
consequences would be.

How likely is such a challenge? (the answer is almost always "it
depends").

What is the likelyhood of a challenge having merit? (answer is "it
depends").

What is the cost (time/money/aggrevation) of having to deal with such
a situation? ("it depends" -- see the pattern?)

While you (personally) may think the risk is negligble and silly, does
your employer (who also probably bears some risk) share your opinion
("it depends").

Etc.

And, it is all made that much worse by having to go through the same
excercise for each document. Having done the analysis on 10 documents,
doesn't help you much when it comes to the next document.

Thomas

---

From: John C Klensin <[email-masked]>
Date: Fri, 09 Jan 2009 11:01:09 -0500

--On Friday, January 09, 2009 10:16 -0500 Thomas Narten
<[email-masked]> wrote:

>> The situation of a deceased author is a tought one, but it's
>> an obvious one. But I haven't seen any clear answer to whether

> IANAL, but if you are expecting anyone (like the IETF) to give
> a clear final, legally defensible answer to "who do you need
> permission from", you won't get it. That is the nature of
> legal questions and is what makes this entire discussion so
> difficult. And why what is an accptable risk for you may not
> be an acceptable risk for me or someone else.
> 
> To answer the question, you have to look at who bears the risk
> if they make an assertion (i.e, by claiming that all
> contributers have signed off) that someone later challenges.
> And what the potential consequences would be.

I think this is the crux of the issue.  Let's consider three
possible assertions (deliberately trying to avoid expressing
them in lawyer-speak):

	(1) I give the Trust any rights that I or my company
	have and can give, but make absolutely no assertions
	about anyone else's rights.
	
	(2) I give the Trust any rights that I or my company
	have and can give, and have verified that everyone
	listed on the front page (or in some other list), with
	the following exceptions, have signed off on this.  But
	I make absolutely no assertions about either the rights
	of anyone not listed, nor about anyone whom I had to
	identify as an exception.
	
	(3) I transfer all rights in the document to the Trust
	and guarantee the Trust that I've gotten the ok to do so
	from everyone who might be able to assert a claim of
	rights to the content, whether they are explicitly
	listed or not and whether the claim is bogus or not.
	Implicitly, if the Trust acts on the assumption that
	they have all the rights and someone complains or
	litigates, that is my problem to defend against and not
	the Trust's.

Unless I am hugely confident, either

	*  That I wrote every word of the text myself,
	paraphrasing contributions or suggestions from others,
	or 
	
	* that no one will pop out of the woodwork,

I believe that making assertion (3) is basically insane unless
one is convinced that no one will _ever_ litigate any of this.
If the Trust and IPR WG believed the latter, we wouldn't need
any of this stuff, so forget that.  The 2026/ 3739/ 4879
requirement is not insane because it only requires me to make
assertions based on what I can be reasonably expected to know
(and the transfer is less general, lowering the odds of protests
somewhat).  That doesn't eliminate the risk, but, IMO, brings it
into manageable proportions.

(1) is easy.  (2) is a lot harder, but still plausible.   But
either of those do the one thing that (3) does not and that the
current state of things seem intended to avoid: With (1) or (2),
the Trust cannot write licenses that assert that they actually
control all of the relevant rights (at least without a lot of
expensive insurance).  Consequently, with either of those
options, the risk that someone unidentified might show up and
assert a claim falls on either the Trust or the user of the
material, not the author/editor of the document.

That is the common characteristic of my I-D, Brian's recent I-D,
and at least part of some of the "repeal 5378" suggestions: the
Trust doesn't get to assume that they have clear and unambiguous
title to documents and permission to license them further on
whatever terms they determine (and that, if the assumption is
wrong, it is the author's problem).

It is also, IMO, the fundamental problem with 5378/5377 and with
almost any attempt to patch them.  They are designed to protect
the Trust against granting rights it doesn't have by making the
submitter assume all of the obligations and risks of
guaranteeing the Trust that it does have certain rights.  That
is just not how we ought to be designing things if we want
people to make contributions to the IETF that build on the work
of others.

YMMD
   john

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 9 Jan 2009 11:19:34 -0500

> accptable risk for you may not be an acceptable risk for me or someone

My personal feeling is that is it is reasonable to ask authors to give  
their
permission, and to obtain their company's permission, if need be, but  
that
it is not reasonable to ask _authors_ to obtain permissions from third  
parties.

Regards
Marshall

---

From: Fred Baker <[email-masked]>
Date: Thu, 8 Jan 2009 14:49:16 -0800

of all RFCs if not a smaller fraction. From my perspective, the  

On Jan 8, 2009, at 1:43 PM, Ed Juskevicius wrote:

> Provisions-1-06-09.pdf>_______________________________________________
> Trustees mailing list
> [email-masked]

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 8 Jan 2009 15:30:35 -0800

> will never be transferred.

Certainly in the IETF as we have known it, situations such as those
described in RFC 4663 have been rare.  If handling those scenarios is
the major focus, then I'd agree with your argument for "optimizing for the
common case".  In particular, corner conditions have a way of being 
somewhat unique (that's why they are corner conditions) so that 
trying to handle all of them in a unified way can prove elusive. 

So overall, the question seems to come down to whether transfers

are likely to become much more commonplace in the future than
they have in the past.  It strikes me that the situations in which
this would occur would tend to be rather dark -- and indeed the
discussion on this topic has wandered into some of those less rosy
scenarios. While an organization (or person) is healthy, it is often 
difficult to muster much enthusiasm for "estate planning" discussions. 

However, even if one considers those situations, it still is not entirely
clear to me that these provisions are required.  For example, over the 
last few years we seem to have made it through a number of wrenching
transitions without requiring this.   

For example, do we believe that the situation described in RFC 4663
is likely to become increasingly common in the years ahead? 
To be blunt, the only scenarios in which that would seem possible
would be "worst case" 

 Remember that this boilerplate affects

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 09 Jan 2009 09:36:42 -0800

Fred Baker wrote:
> in the past five years is a single digit number, a tenth of a percent of 
> all RFCs if not a smaller fraction. From my perspective, the simplest 
> solution to the transfer issue is to ask the people relevant to a 
> document for which transfer has been suggested whether they have an 
> issue with transferring it, rather than asking every document author his 
> or her opinion on the vast majority of documents, which will never be 
> transferred. 

+1 for simplicity, pragmatics, stability, narrowness of impact, and probably 
"legality".

A number of the comments, so far, appear to hinge on a rather basic cost/benefit 
model that is clearly quite different from what the proposal is based.  I 
suspect that difference comes from a different sense of the problem, per John 
Klensin's posting.

My reference to "legality" is based on a view of the proposal which sees it as 
having individual submitters essentially say "I am required to get permission 
and I have not gotten it".  That's an admission of guilt, which seems like a 
very bad thing to admit and formally document, particularly for an issue 
involving the law.  And if you don't think that's what the proposal calls for, 
please explain, because I don't think my interpretation is all that creative.

I am also struck by the proposal's noting:

> interrupted the publication of some RFCs.  

This means that we have a crisis which is stopping productive work, yet the 
crisis appears to be caused by a faulty new requirement, rather than by the 
situation that the document seeks to correct.  In other words, remove the new 
requirement and we no longer have a crisis.  We have an issue to pursue -- the 
same one that prompted the new requirement -- but no crisis.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: John Leslie <[email-masked]>
Date: Fri, 9 Jan 2009 13:15:03 -0500

Dave CROCKER <[email-masked]> wrote:
> 
> A number of the comments, so far, appear to hinge on a rather basic 
> cost/benefit model that is clearly quite different from what the proposal 
> is based.  I suspect that difference comes from a different sense of the 
> problem, per John Klensin's posting.

   Agreed.

> My reference to "legality" is based on a view of the proposal which sees
> it as having individual submitters essentially say "I am required to get 
> permission and I have not gotten it". That's an admission of guilt...

   I don't read it that way. Refer to:

http://trustee.ietf.org/docs/Draft-Update-to-IETF-Trust-Legal-Provisions-1-06-09.pdf
] 
] 6. c. iii.
] ... This document contains material from IETF Documents or IETF
] Contributions published before November 10, 2008 and, to the
] Contributor's knowledge, the person(s) controlling the copyright 
] in such material have not granted the IETF Trust the right to allow
] modifications of such material outside the IETF Standards Process.
] Without obtaining an adequate license from the person(s) controlling
] the copyright, this document may not be modified outside the IETF
] Standards Process, and derivative works of it may not be created
] outside the IETF Standards Process, except to format it for
] publication as an RFC and to translate it into languages other than
] English. 

   If you believe there is an admission of guilt there, please send
text. (But understand, lawyers have to sign off on any changes.)

> And if you don't think that's what the proposal calls for, please
> explain, because I don't think my interpretation is all that creative.

   I may not be the one to explain, but I _don't_ think that's what
the proposal calls for. I think it calls for inclusion of the
boilerplate I listed above, which simply disclaims knowledge of
_whether_ all the rights of 5378 are granted (and thus derivative
works "outside the IETF Standards Process" are not authorized by
the IETF Trust).

> This means that we have a crisis which is stopping productive work,
> yet the crisis appears to be caused by a faulty new requirement,
> rather than by the situation that the document seeks to correct.

   True...

> In other words, remove the new requirement and we no longer have a
> crisis. We have an issue to pursue -- the same one that prompted
> the new requirement -- but no crisis.

   Alas, I must disagree. We have an IETF Consensus document (5378),
and that consensus must be overturned to get to where Dave claims
we are. In my experience, overturning consensus is hard. (That's
the _point_ of having a consensus process.)

   However wrong some of us (now) believe that consensus to be, we
should not expect to overturn it in 30 days -- whereas this quick
fix can be applied in 30 days. I strongly urge all of us to let
the quick fix go through without holding it hostage to overturning
the consensus of 5378.

--
John Leslie <[email-masked]>
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Lawrence Rosen" <[email-masked]>
Date: Fri, 9 Jan 2009 11:09:29 -0800

> works "outside the IETF Standards Process" are not authorized by

I want derivative works "outside the IETF Standards Process" to be
authorized by the IETF Trust and see no legal reason, at least in US law,
why the IETF Trust can't authorize that without even mentioning the
co-authors of those RFCs.

The concern expressed in this thread is whether derivative works are
authorized by the co-authors of those earlier RFCs. We need no statement
(admission of guilt or otherwise) about that. Users of IETF RFCs should be
comfortable that at least the IETF Trust authorizes such derivative works. 

Certainly the term "open industry standard" must mean that an RFC is a
cooperative expressive and technical work by individuals and companies
interested in a common result. We should accept the notion that IETF, and
now the IETF Trust, as a public interest corporation that manages the
expressive creative activities through which these joint works are written,
is the joint owner of copyright in every RFC. As such, a license from the
IETF Trust is all we need to create derivative works, without even asking
the co-authors of those old (or new) documents. 

Does anyone here believe that the IETF Trust doesn't own a joint copyright
interest in every RFC it publishes and can thus authorize derivative works
of those RFCs? [1]

/Larry

[1] I intentionally avoid the argument, made in my previous emails here,
that we don't even need the permission of the IETF Trust to copy and
modify--when necessary for functional purposes--any industry standard
specification. That's a bigger argument based on 17 USC 102(b), not one
based on the Copyright Act definition of "joint work":

   "A 'joint work' is a work prepared by two or more authors 
   with the intention that their contributions be merged into 
   inseparable or interdependent parts of a unitary whole. 
   17 USC 101.

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

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> John Leslie
> Sent: Friday, January 09, 2009 10:15 AM
> To: [email-masked]
> Cc: IETF Discussion
> Subject: Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your
> reviewand comments on a proposed Work-Around to the Pre-5378 Problem
>

---

From: Ted Hardie <[email-masked]>
Date: Fri, 9 Jan 2009 11:42:18 -0800

At 11:09 AM -0800 1/9/09, Lawrence Rosen wrote:
>We should accept the notion that IETF, and

Are you willing to personally indemnify the individuals who are later
sued by those who don't hold this view or are you willing to pay for
the appropriate insurance cover?

Take a look for a moment at RFC 2822.  It is a successor to a document
that does not contain an ISOC copyright (because ISOC came into being
approximately 10 years later).  It does have an ISOC copyright
but RFC 2822 also has a very extensive list of contributors:

   Matti Aarnio              Barry Finkel           Larry Masinter
   Tanaka Akira              Erik Forsberg          Denis McKeon
   Russ Allbery              Chuck Foster           William P McQuillan
   Eric Allman               Paul Fox               Alexey Melnikov
   Harald Tveit Alvestrand   Klaus M. Frank         Perry E. Metzger
   Ran Atkinson              Ned Freed              Steven Miller
   Jos Backus                Jochen Friedrich       Keith Moore
   Bruce Balden              Randall C. Gellens     John Gardiner Myers
   Dave Barr                 Sukvinder Singh Gill   Chris Newman
   Alan Barrett              Tim Goodwin            John W. Noerenberg
   John Beck                 Philip Guenther        Eric Norman
   J. Robert von Behren      Tony Hansen            Mike O'Dell
   Jos den Bekker            John Hawkinson         Larry Osterman
   D. J. Bernstein           Philip Hazel           Paul Overell
   James Berriman            Kai Henningsen         Jacob Palme
   Norbert Bollow            Robert Herriot         Michael A. Patton
   Raj Bose                  Paul Hethmon           Uzi Paz
   Antony Bowesman           Jim Hill               Michael A. Quinlan
   Scott Bradner             Paul E. Hoffman        Eric S. Raymond
   Randy Bush                Steve Hole             Sam Roberts
   Tom Byrer                 Kari Hurtta            Hugh Sasse
   Bruce Campbell            Marco S. Hyman         Bart Schaefer
   Larry Campbell            Ofer Inbar             Tom Scola
   W. J. Carpenter           Olle Jarnefors         Wolfgang Segmuller
   Michael Chapman           Kevin Johnson          Nick Shelness
   Richard Clayton           Sudish Joseph          John Stanley
   Maurizio Codogno          Maynard Kang           Einar Stefferud
   Jim Conklin               Prabhat Keni           Jeff Stephenson
   R. Kelley Cook            John C. Klensin        Bernard Stern
   Steve Coya                Graham Klyne           Peter Sylvester
   Mark Crispin              Brad Knowles           Mark Symons
   Dave Crocker              Shuhei Kobayashi       Eric Thomas
   Matt Curtin               Peter Koch             Lee Thompson
   Michael D'Errico          Dan Kohn               Karel De Vriendt
   Cyrus Daboo               Christian Kuhtz        Matthew Wall
   Jutta Degener             Anand Kumria           Rolf Weber
   Mark Delany               Steen Larsen           Brent B. Welch
    Steve Dorner              Eliot Lear             Dan Wing
   Harold A. Driscoll        Barry Leiba            Jack De Winter
   Michael Elkins            Jay Levitt             Gregory J. Woodhouse
   Robert Elz                Lars-Johan Liman       Greg A. Woods
   Johnny Eriksson           Charles Lindsey        Kazu Yamamoto
   Erik E. Fair              Pete Loshin            Alain Zahm
   Roger Fajman              Simon Lyall            Jamie Zawinski
   Patrik Faltstrom          Bill Manning           Timothy S. Zurcher
   Claus Andre Farber        John Martin

It would be reasonable for everyone in that list to believe that
their work could be re-used within the IETF context (it post
dates RFC 2026 sufficiently for that).   We have now changed
the rules such that their work can be used in other contexts,
provided the Trust authorizes it; prior to that, the individuals
would have had to authorize it.    To let the Trust authorize that without
explicit permission requires us to believe that everyone in that
list (and every other similar list) either believed at the time
that their work could be so used, believes now that it can
be so used, or is sufficiently laissez-faire that they won't
do anything to stop it, even if they don't agree.

My reading of John's point is that this creates either a coordination
burden or a legal risk for the authors re-using text created prior to
the new rules. He doesn't want to bear that burden/risk, and I don't
think the Trust can (because it would have to analyze each document
prior to assuming it, as it would be otherwise trivial for
someone to submit a draft that clearly had no permission from
the copyright holders).

He wants an out that says "I'm granting these rights to
my text, you worry about any other rights".   As a transition
to text based on documents written within the new rules,
that may be the way to go.  What none of us wants is to
have to restart this conversation at ground zero, because a lot
of the other rights (like re-using code) set out in the new
document should be applying to new work in new drafts now.

Just my two cents, untarnished by law degrees or other
impediments.
		regards,
				Ted Hardie

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 10 Jan 2009 08:43:28 +1300

John,

On 2009-01-10 07:15, John Leslie wrote:
...
> the quick fix go through without holding it hostage to overturning

I agree. I also agree with the Trust's claim that it has discretion
to apply this fix *right now* by allowing documents to go out
containing the disclaimer, without any need to seek IETF consensus
for another change to BCP 78. I've proposed a specific change to
BCP 78 that would (IMNSHO) act as a permanent fix, but we don't
need that to go forward with normal business.

    Brian

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 09 Jan 2009 14:54:34 -0500

--On Thursday, January 08, 2009 02:49:16 PM -0800 Fred Baker 
<[email-masked]> wrote:

>  From my perspective, the best approach involves keeping the general case
> simple. The documents that have been transferred outside the IETF in the
> past five years is a single digit number, a tenth of a percent of all
> RFCs if not a smaller fraction. From my perspective, the simplest
> document for which transfer has been suggested whether they have an issue
> with transferring it, rather than asking every document author his or her
> opinion on the vast majority of documents, which will never be
> transferred. Remember that this boilerplate affects internet drafts, but
> most internet drafts are discussion documents - a fraction of internet
> drafts even become RFCs, and a small fraction of RFCs are transferred
> elsewhere.

The difficulty with this approach is that it allows authors to decide 
whether to grant us the rights we require until the point at which we wish 
to exercise them, rather than requiring that they grant those rights before 
we take their contribution and turn it into a widely-deployed Internet 
standard.

I don't believe we need to go back and ask every author of every published 
RFC and I-D to grant the additional rights, and I don't believe we need to 
have a system that blocks the submission and/or progress of current 
documents solely because they are built on earlier documents which were 
published before the new rules came into effect.  However, I do think if we 
want the additional rights required by RFC5378, we need to require they be 
granted at the time that a document is submitted.

It sounds to me like the trustees' proposal does a reasonable job of 
balancing the conflicting goals and achieving something useful.

-- Jeff

> approach will be to fall back to 3978/4748/2026 temporarily and move to
> 5378-bis when it comes rather than to use this very general workaround to
> 5378's issues until 5378-bis is resolved. 3978 etc worked just fine for
> most purposes...

If we reach consensus that the solution to the problem is to change 5378, 
rather than to semi-permanently adopt a workaround such as the trustees 
have proposed, then I would not object to falling back to the older rules 
until the issue is resolved.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Lawrence Rosen" <[email-masked]>
Date: Fri, 9 Jan 2009 12:34:10 -0800

> the appropriate insurance cover?

Of course not. Are you (or your company) warning me that *you* might sue me
for infringement of anything you contributed to a joint industry standard
RFC? If so, thanks for the warning. Now, I'll ignore it. As I hope will most
of the people and companies who rely on IETF RFCs. You can't threaten me by
listing hundreds of people who had something to do with an RFC in the past.
Or make me beg you or your company or any of those people for permission in
order to treat an industry standard as a part of our common heritage with
the authority in the IETF Trust to deal with it (as a copyrighted document)
as it wishes in the public interest.

> would have had to authorize it.

Under US law, a joint copyright owner doesn't have to ask anyone's
permission to change the rules. Sorry you don't like that. Or are you
threatening to sue the IETF Trust if it changes the rules? Based on what
legal principle?

/Larry

> From: Ted Hardie [mailto:[email-masked]]
> Sent: Friday, January 09, 2009 11:42 AM
> To: [email-masked]; 'IETF Discussion'
> Subject: RE: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your

---

From: Ted Hardie <[email-masked]>
Date: Fri, 9 Jan 2009 13:31:27 -0800

At 12:34 PM -0800 1/9/09, Lawrence Rosen wrote:
>RFC?

Nope.  And turning up the rhetoric to "flame" neither advances the discussion
nor makes your arguments any more valid.
>permission to change the rules. Sorry you don't like that.

I don't have any opinion, like, or dislike  on that, and, as I said, I'm not lawyer.
The point made repeatedly, though, is that even if all of the current individual
contributors agree that this is the case, they run the risk of litigation by
those who do not when they use the current system.  It asks the contributor
to assert something; they either must do the work of being sure they can
make that assertion or they must assume the risk of having made the assertion
if they find themselves in disagreement with other contributors.

We did not previously get these rights explicitly; we did get others. 
Whether we have the "new" rights now due to the characteristics
of the work does not seem to be settled enough for the contributors
to believe they can assume the risks.  They see the enumerated
list and worry someone will sue them for it. Their lawyers may be
wrong and you right, but that doesn't get them to assume the risks.

>Or are you

No, I am threatening to go get a calming cup of white tea, to remind myself
why I was so happy when the IPR working group shut down.

And, once again, I would be far happier having these discussion with
you, Larry, if you had *ever* contributed anything to the IETF that didn't
amount to mailing list political rhetoric.   Since you have no evident likelihood
of putting forth a document revision any of our standards, it's pretty
hard to believe your view of the risk is as personal as, say, John's.

			Ted Hardie

---

From: John C Klensin <[email-masked]>
Date: Fri, 09 Jan 2009 16:32:57 -0500

--On Friday, January 09, 2009 11:42 -0800 Ted Hardie
<[email-masked]> wrote:

>...
> My reading of John's point is that this creates either a
> coordination burden or a legal risk for the authors re-using
> text created prior to the new rules. He doesn't want to bear
> that burden/risk, and I don't think the Trust can (because it
> would have to analyze each document prior to assuming it, as
> it would be otherwise trivial for someone to submit a draft
> that clearly had no permission from the copyright holders).
> 

Exactly.

And note that makes a clear and plausible transition model:

	(1) Pre-5378 documents exist under pre-5378 rules, so
	any potential user for non-traditional purposes needs to
	either figure out who the relevant authors are and get
	their permission or decide the risk isn't worth worrying
	about.  If some of those authors/ contributors make
	explicit transfers to the Trust, that is great, but none
	of them have to take responsibility for identifying all
	of the others.
	
	(3) Post-5378 new documents are posted according to 5378
	rules, with no exceptions.
	
	(2) Post-5378 documents that incorporate pre-5378
	materials must used 5378 rules for any material that is
	new.  For the earlier materials, and for sorting out
	which is which, the burden falls on the potential user
	for non-traditional purposes to either figure out who
	the relevant authors are and get their permission,
	determine that all relevant authors have already given
	permission, or assume the risks.   No one else --neither
	the author(s)/ editor(s) of the new document nor the
	Trust-- is required to take responsibility for pre-5378
	contributors or contributions.  Even an editor of the
	new document that worked on the old material is not
	required to make assertions about new rights on behalf
	of his or her former employer.

This doesn't weaken the core grant of rights in 5378 in any
fundamental way.  If we are being realistic, it doesn't get us
to the point 5378 wants to get us to any more slowly.  It makes
one fundamental change: the responsibility and liability for
sorting out the IPR status of materials created and contributed
prior to the 5378 shifts from the author of a post-5378 document
to the person who wants to copy material out of that document in
excess of 2026 / 3978/ 4748 rules.  

That does not increase the burdens on that person at all
relative to the burdens he or she inevitably has with pre-5378
documents that are not being revised.  It does not increase the
risks to the Trust at all.  It does let people trying to do
technical work in the IETF do that work without signing up for
legal determinations, work, or risks that do not involve the
earlier work of others, and it is that sign-up requirement that
is the problem with 5378.

Now, what I recommend is that we try to see if we can agree that
the three-stage description above is what we intend.   If we can
agree, then the _next_ step is figuring out how to get there in
the minimum period of time.  

My problem with the Trust's latest proposed policy is that we've
got extensive evidence --including the consensus decision that
got us into the mess-- that the IETF is not good at evaluating
legal documents and theories and their possible consequences and
side-effects.  I don't believe that the right way to solve that
problem is to hand the IETF yet another legal document, with
some language and a theory in it that seems subtle, and ask us
to evaluate it.  

I believe that the IETF should accept a clearly-stated set of
principles and that the Trust should then come back and say "on
the advice of Counsel, the following text implements that
principle".  If lawyers then want to argue about whether the
text is optimal to implement those principles, that is fine with
me, as long as the argument is limited to the relationship
between principles and text and not an attempt to change
principles.   Remember that the Trustees do have insurance
against getting that sort of thing wrong; the rest of us are not
insured against either getting those things wrong or against the
Trust doing so.

Now, if the Trust will reassure us, on that same basis, that the
new proposal gets us closer to those principles without creating
an additional mess that will need to be sorted out in the
future, then I'm in favor of the text.   If the Trust is really
saying, as the announcement appears to do "here is this new
strategy and some proposed legal language to implement it,
please review it and sign off on its being the correct _legal_
solution", then I'm opposed to doing that and am tempted to
repeat the old saw about doing the same thing multiple times and
expecting a different outcome as well as the observation that we
keep making our IPR rules more and more complex with patches and
workarounds and that it is not a good way to move forward.

If we can reach consensus on the principles about (or something
like them), then I think there are all sorts of ways to move
forward.  Some of them start with the observation that, if the
community also agrees that 5378 does represent a consensus about
principles of IPR but that the implementation of the transition
policy was botched, then a two-week Last Call on something that
narrowly un-botches it (or that gives the Trustees the authority
to do what they propose to do if anyone still thinks that
necessary (see Note 1, below) should be in order -- the intent
of the requirement for longer Last Calls is to be sure that the
community has an opportunity to review the document and issues
and the community has definitely had that opportunity to review
this one via these discussions, the previous Last Call, etc.

      john

Note 1: In December, a few of the Trustees and one or two IESG
members, seemed to be taking the position that the Trustees did
not have the authority to do exactly the sort of thing they are
now proposing to do but that they were stuck with a literal and
narrow interpretation of 5378 until and unless a replacement
came along in the community, was reviewed by a WG, and came
through the conventional consensus process.   I thought that
interpretation was wrong then and is wrong now, but I'm not a
Trustee or an AD.   Something has obviously changed and, before
the community reviews this proposal and takes responsibility for
it, I'd like to hear, either from the people who took the
earlier position, from Counsel, or from the Trustees as a group
what it is.   Otherwise, we (and not the Trustees) run the risk
that this disclaimer is trash because only the text of 5378
counts.

Note 2: Larry, I'm not competent to debate your "joint
authorship" theory and hope that no one else, at least no one
who is not an attorney admitted to practice in some relevant
jurisdiction, will engage you on it.  However, it appears to me
as a non-lawyer that, if you are correct, we should be blowing
away 5378 and all of its language and concentrating on 5377
(which no one has attacked since the WG concluded).   If the
theory is correct, then 5378 complicates things because it can
easily be read as an attempt to establish principles of separate
authorship in the IETF case and get everyone to agree to those
principles, even if only as a between-contributors agreement.
And one should not wish for those complications.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 10 Jan 2009 11:07:29 +1300

John,

On 2009-01-10 10:32, John C Klensin wrote:
...
> 	of his or her former employer.

Thanks John, I believe that is an excellent summary of the
viable options. My draft implicitly adds

  (2.5) Post-5378 documents that incorporate pre-5378
  materials whose original contributors have duly agreed are
  posted according to 5378 rules, with no exceptions.

To my mind the main open issue is whether we want to
require authors to try for (2.5) before proceeding to (2).

    Brian

---

From: "Lawrence Rosen" <[email-masked]>
Date: Fri, 9 Jan 2009 14:16:43 -0800

> And one should not wish for those complications.

I agree that the proper forum for this discussion is with the officers and
legal counsel of IETF and not this public list. I have previously written to
Jorge Contreras about some of these points and am always pleased by his
thoughtful private responses.

My only reason for bringing it up again on-list is that people here are
publicly discussing specific legal wording to fix 5378. But as a fundamental
principle of property law, I don't believe in IETF asking anyone's
permission, even respected IETF contributors, to create derivative works of
works already in the public domain or any works that IETF already owns
jointly. As John Klensin noted, 5378 and the proposed workaround
"complicates things because it can easily be read as an attempt to establish
principles of separate authorship in the IETF case and get everyone to agree
to those principles." I can't agree to that. Can you?

That's why I challenged Ted Hardie directly. Please don't take it personally
or as flaming, but anyone who wants to assert a private ownership right in
any copyright in any IETF RFC ought to do so now or forever hold your peace.
Otherwise, I think it best that the IETF Trust exercise its rights under its
joint copyright to do whatever is deemed appropriate and in the public
interest, as determined by the IETF Trustees and its legal counsel, and not
ask permission.

/Larry

> From: John C Klensin [mailto:[email-masked]]
> Sent: Friday, January 09, 2009 1:33 PM
> To: Ted Hardie; [email-masked]; 'IETF Discussion'

---

From: [email-masked]
Date: Fri, 09 Jan 2009 14:45:42 -0800 (PST)

I've tried really hard to stay out of this whole IPR mess - there are only
so many hours in the day - but the point John makes here is so vital I simply
have to chime in and support it.

> insured against either getting those things wrong or against the

This is EXACTLY the approach we should be using: Formulate a set of goals, get
agreement on them, and only then ask the laywers to turn that informal
specification into competent legalese.

When Innosoft, the company I co-founded, got to the point of hiring a real CEO
with serious business chops, one of the first things the new CEO did was to
change how we engaged with our lawyers from what was effectively the approach
the IETF has been using to the approach John describes.

The difference was like night and day. Instead of being mired in interminable
discussions with engineers playing at being laywers and doing a crappy job of
it, we divided the task in a fashion that suits the actual competencies of the
players. Process sped way way up and the quality of the product improved
dramatically.

I actually have tried to articulate this several times in the past, but for
whatever reason I couldn't find the right words to do so. I'm delighted that
John has done so here.

				Ned

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 09 Jan 2009 15:25:57 -0800

...
> The difference was like night and day. 

+1

That matches my experience, over the years.

d/

-- 

   Dave Crocker

---

From: John C Klensin <[email-masked]>
Date: Fri, 09 Jan 2009 18:30:14 -0500

> require authors to try for (2.5) before proceeding to (2).

I am all in favor of authors trying for 2.5 if they have the
time and inclination although, mostly, I'd rather have them
spend time on technical work (Marshall's suggestion last month
that the Trust itself should take responsibility for rounding up
old rights has some appeal here).   What I'm opposed to is
requiring authors of documents that might have had a very long
history to take responsibility for claiming that they have
identified all of the original contributors.   My problem with
2.5, stated somewhat more aggressively than is probably
desirable, is that it requires the submitter of a 2.5 document
to stand up and say "I have identified all of those who might
claim to have rights in this document, will take responsibility
for getting that identification right, and obtained their
consent".  

There is a possible 2.5bis, which would be something like "I've
made a good-faith, reasonable-effort, attempt to identify
everyone
and have the agreements from everyone whom that process
identified, but I make absolutely no warranty that I've
identified everyone or that other claims won't come up; if they
do, it is the user's problem, not mine."

Whether that is enough different in practice from my (2) to be
worth the complexity... I don't know.

    john

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 09 Jan 2009 18:52:40 -0500

My own take has been that the code reuse problem is the dominant 
problem.  Document transfer outside the IETF is sufficiently rare that I 
would agree with Fred that not solving that is fine.

This also means that from my personal perspective, a solution that says 
(loosely based on a suggestion from someone else in a side conversation) 
that
1) If you can, you grant 5378 rights
2) If you can't, you grant the old rights, as long as there is no code 
in the document
3) If there is code, get the rights to the code so people can actually 
use the code in the RFC to implement the RFC.  (MIBs are already 
covered, but we have lots of other kinds of code.)

would seem a workable path.
Yes, point 3 may hold up some work.  But one could reasonably argue that 
such work needs to be held up so that folks can use the code we are 
giving them.

And I fully agree that we should leave all legal wordsmithing to the 
trust and the lawyers.  They have to do it anyway.

Yours,
Joel

---

From: John C Klensin <[email-masked]>
Date: Fri, 09 Jan 2009 19:15:11 -0500

--On Friday, January 09, 2009 15:25 -0800 Dave CROCKER
<[email-masked]> wrote:

>> This is EXACTLY the approach we should be using: Formulate a
>> set of goals, get agreement on them, and only then ask the
>> laywers to turn that informal specification into competent
>> legalese.
> ...

If my memory is correct, that was exactly the basis on which the
most recent IPR WG was told to proceed.  For one reason or
another, it ended up expressing its ideas of the principles in
the form of quasi-legal documents (or, if you prefer, documents
containing legal-language statements) rather than publishing a
clear statement of those principles independent of those
documents.

In fairness to the WG, that turned out to be easier, especially
in the absence of clear consensus about which problems were most
important.

If the community -- and assorted ADs -- learn anything from this
experience it should be, IMO, that if such a document shows up
on Last Call instead of (or without) a normative statement of
principles against which legal text can be checked and verified,
we should Just Say No.

But that discussion doesn't help much with the short-term
problem.

    john

---

From: Theodore Tso <[email-masked]>
Date: Fri, 9 Jan 2009 23:14:16 -0500

> would agree with Fred that not solving that is fine.

If it really is the case that the *only* two problems was document
transferoutside of the IETF (rare) and code reuse problem (what
percentage of documents are are actual code that would require special
case licensing --- small) it's actually pretty amazing that the
problem was allowed to balloon to cover **all** text for **all I-D's
and RFC's**.

There's the old saying --- an engineer takes a large problem and break
it up into several smaller problems, and having solved each of the
small problems, solves the overall problem; a bureaucrat takes several
small programs, and tangles them all together into one, gigantic,
intractable problem.

> covered, but we have lots of other kinds of code.)

We do have precedent for include code that has explicit open source
licensing rights.  For example, the MD5 implementation in RFC 1321 has
an explicit BSD-style license.  How much code is there, really?  I
suppose pseudo-code might be a gray area tht will depend on how
paranoid of a lawyer you are dealing with.  One who uses the argument
that "copyright can not protect ideas, just the expression of the
idea", will probably say that it's OK.  One who tries to draw a
parallel to translations as derived works might be more concerned.

	    		    	    	  	- Ted

---

From: Bill Manning <[email-masked]>
Date: Sat, 10 Jan 2009 03:16:27 -0800

> interest, as determined by the IETF Trustees and its legal counsel, and not

	are you talking about -all- IETF related documents (IDs, postings,
	april 1st RFCs, etc...) or RFCs that are standards?  (discounting
	BCPs, Informational RFCs, etc)

	for a period of time, text like this appeared in at least a dozen
	documents:

"This document is an Internet-Draft and is subject to all provisions of 
Section 10 of RFC2026 except that the right to produce derivative works 
is not granted."

	there were even a few documents that had explicit copyright statements
	that excluded ISOC & IETF from doing anything with the document, other
	than the right to publish for the period of performance for an ID, e.g.
	no longer than six months.

	one reaction to that was the promulgation of the "Note Well" legal advice
	and the path that lead us to this point.

	So for some IETF work product, there are/were people who assert a private
	ownership right in the materials they generated.  I think that the IETF
	Trust should be very careful in using/reusing that material, esp w/o
	asking permission.

	There, I've spoken up ... reserving my right to speak now and later on this
	topic. (not going to "forever hold my peace").

--bill
Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 10 Jan 2009 14:37:50 +0100

> My own take has been that the code reuse problem is the dominant

My interpretation has been that the problem has been (and remain) that
the license on IETF documents is incompatible with free software
licensing, which is counter-productive for the IETF.

> Document transfer outside the IETF is sufficiently rare that I would
> agree with Fred that not solving that is fine.

I agree too.

Theodore Tso <[email-masked]> writes:

> an explicit BSD-style license.

Sure, but under the post-RFC 2026 rules that would not be allowed since
the rules do not permit additional copyright notices to be present in
documents.  There has been exceptions and mistakes, so there are
post-RFC 2026 documents with other licensing information in them, but
the IESG/IAB has also rejected including free software code in RFCs.
Allowing BSD-like code to be included in RFCs would be great step
forward.  It is not allowed under the RFC 5378 license either, at least
not generally when the code was not written by the document author.

> How much code is there, really?

Looking at the last 10 published RFC's for material (text or code) that
potentially may end up in free software implementations, I find:

5391 sample test-vectors
5393 no
5394 pseudo-code
5395 data table with messages
5396 no
5397 no
5398 no
5401 code, pseudo-code
5405 no
5407 pseudo-code

This is a small sample, and you could discuss each interpretation, but
still I believe this shows that this is a common enough problem to worry
about.  RFC 5378 improves the situation in some specific cases but does
not solve the general problem, and understanding whether the specific
case rules apply or not is complex.

> I suppose pseudo-code might be a gray area tht will depend on how

A more realistic approach may be to think about how text in RFCs are
used.  Text often end up in free software projects as comments.  This is
useful and helps get the RFC implemented correctly in a more
maintainable fashion.  The goals of the IETF is furthered by this, I
argue, so it is disappointing RFC 5378 does not solve the problem.

/Simon

---

From: Theodore Tso <[email-masked]>
Date: Sat, 10 Jan 2009 14:10:55 -0500

> not generally when the code was not written by the document author.

This should clearly be fixed in RFC 5378-bis, in my opinion.  If the
goal is to allow code to be allowed in Open Source Software, then
requiring a maximally compatible OSS license for code makes sense.
But requiring for random protocol text, especially if this is going to
make reuse of older RFC's text, seems to not be a great cost/benefit
tradeoff.

> argue, so it is disappointing RFC 5378 does not solve the problem.

At least in the linux kernel, quoting a 2-3 sentences of an RFC in
comments is common practice, even before RFC 5378.  It is also been
done with great frequency in documentation, magazine articles and
journals, and so on.  Fair use takes care of this problem, and there I
don't think even the most insanely paranoid and unreasonable corporate
lawyer would think that 2-3 sentences quoted in manuals, code, etc.,
would be unreasonable.  

Certainly this is something where we have over two decades historical
practice, and if anyone thinks an IETF contributor or company would be
suicidially idiotic enough from a Public Relations point of view to
try to sue someone for using 2-3 sentences when this would be pretty
clearly fair use, and the reputations of said IETF contributor or
company would be pilloried in the press, I would gently suggest that
whoever is worried about is greatly disconneted from reality, if they
were to think about the risks involved.

					- Ted

---

From: "Lawrence Rosen" <[email-masked]>
Date: Sat, 10 Jan 2009 11:17:47 -0800

> Section 10 of RFC2026 except that the right to produce derivative works
-  and  -
> So for some IETF work product, there are/were people who assert a
> private ownership right in the materials they generated.  I think 
> that the IETF Trust should be very careful in using/reusing that 
> material, esp w/o asking permission.

This is consistent with what I've been saying, namely that IETF RFCs are
joint works of authorship.

1. The fact that IETF never previously granted the right to produce
derivative works can easily be corrected by one of the joint copyright
owners, in this case the IETF Trust, now granting that license. As I
understand it, this is what Simon and others have been arguing for all along
for the IETF out-license.

2. The IETF Trust owns a joint copyright. That also means that we can't
object if the other joint copyright owners assert their own private
ownership rights in the materials they generated. Who's stopping them? None
of the joint owners needs to ask permission of IETF or any others to do
anything they want with those jointly-owned IETF RFCs.

> There, I've spoken up ... reserving my right to speak now and later
> on this topic. (not going to "forever hold my peace").

Please excuse my poetic turn of phrase. As others have privately pointed out
to me, it is unlikely that anyone on here will respond to my plea to declare
their private claims any more than anyone does even at the worst of
weddings. That is another reason why the IETF Trust asking permission to do
what we wish with our own industry standards is such a futile exercise.
Hardly anyone has the courage or incentive to say "No" and publicly declare
their private ownership of our common standards. That is why we have to take
the risk to do what we need to do and simply dare anyone on here to sue IETF
when we allow certain kinds of derivative works.

For the lawyers on here, I'm hoping that silence now, particularly by the
major IETF contributors on this list, will be interpreted as laches or
waiver if one of them later claims an exclusive copyright interest in any
IETF RFC.

/Larry

> From: Bill Manning [mailto:[email-masked]]
> Sent: Saturday, January 10, 2009 3:16 AM
> To: Lawrence Rosen
> Cc: 'IETF Discussion'

---

From: John C Klensin <[email-masked]>
Date: Sat, 10 Jan 2009 15:12:54 -0500

+1

It seems to me that we are spending a great deal of energy on
non-problems (including the one Ted discusses below) and too
little time on real issues... like how to encourage people to do
real work around here (where requiring authors try to figure out
who might have contributed parts of a document that a
predecessor to one they are working on and get them to sign off
is not "encouragement").

    john

--On Saturday, January 10, 2009 14:10 -0500 Theodore Tso
<[email-masked]> wrote:

> At least in the linux kernel, quoting a 2-3 sentences of an
> RFC in comments is common practice, even before RFC 5378.  It
> is also been done with great frequency in documentation,
> magazine articles and journals, and so on.  Fair use takes
> care of this problem, and there I don't think even the most
> insanely paranoid and unreasonable corporate lawyer would
> think that 2-3 sentences quoted in manuals, code, etc., would
> be unreasonable.  
> 
> Certainly this is something where we have over two decades
> historical practice, and if anyone thinks an IETF contributor
> or company would be suicidially idiotic enough from a Public
> Relations point of view to try to sue someone for using 2-3
> sentences when this would be pretty clearly fair use, and the
> reputations of said IETF contributor or company would be
> pilloried in the press, I would gently suggest that whoever is
> worried about is greatly disconneted from reality, if they

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 11 Jan 2009 09:13:53 +1300

Ted,

On 2009-01-11 08:10, Theodore Tso wrote:

...
> If the

As a point of information, this was raised as an issue in the IPR WG
because of cases where it makes more sense to recycle text extracts
from RFCs in product documentation than to paraphrase the RFC. The
consensus was to cover it in 5378. The only glitch is that we forgot
to insert a transition rule for old stuff.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 11 Jan 2009 09:17:28 +1300

Joel,

Yes. I'll accept any solution in the range covered by my draft and your
and John's messages.

   Brian

---

From: John C Klensin <[email-masked]>
Date: Sat, 10 Jan 2009 15:25:00 -0500

--On Saturday, January 10, 2009 11:17 -0800 Lawrence Rosen
<[email-masked]> wrote:

>... 
> For the lawyers on here, I'm hoping that silence now,
> particularly by the major IETF contributors on this list, will
> be interpreted as laches or waiver if one of them later claims
> an exclusive copyright interest in any IETF RFC.

Larry,

Please don't ask me to waive anything, explicitly or implicitly,
without identifying who you are representing in this matter and
related ones... or making a clear enough statement that you are
working strictly pro bono and in your perception of the public
interest to create COI or other problems should you later choose
to represent some particular interest in the area.

Failure to do either while pressing IETF participants to
disclose what we might or might not do in the future, or waive
the right to do anything by not making such a disclosure,
borders on the sort of activity that has given your profession a
reputation for being ethically challenged in many lay quarters
(from Shakespeare's recommendation about how to dispose of the
problem forward and probably much earlier).

I trust that even the most creative of lawyers cannot interpret
my comments above, or Bill's similar ones, as "silence".   While
I cannot speak for anyone else, and would not try, I don't
believe you can either (at least without identifying them as
parties with whom you have a client-attorney relationship).

Just my opinion.

    john

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 11 Jan 2009 09:31:43 +1300

+1.

Which is why I suggest that we should support the Trustees' proposed
short term fix, to allow normal work to continue +/- cutting and pasting
some boilerplate. We do have a glitch in 5378 to mend, but let's get that
off the critical path.

   Brian

---

From: John C Klensin <[email-masked]>
Date: Sat, 10 Jan 2009 15:46:47 -0500

--On Sunday, January 11, 2009 9:31 +1300 Brian E Carpenter
<[email-masked]> wrote:

> +1.
> 
> Which is why I suggest that we should support the Trustees'
> proposed short term fix, to allow normal work to continue +/-
> cutting and pasting some boilerplate. We do have a glitch in
> 5378 to mend, but let's get that off the critical path.

To repeat myself, I will support that fix the moment the
Trustees' come forward and say, explicitly, "this is the problem
we are trying to solve, this is the principle we are using as
the basis of the solution, and, with the advice of Counsel, we
believe that this fix represents a competent, best-efforts,
legal-text representation of that principle and nothing else".

I am not going to engage in trying to evaluate any more legal
documents in a way that involves making inferences about their
possible effects, direct or indirect, or about whether the text
is necessary and sufficient to the solution of a particular
problem or the implementation of a particular principle.

I also continue to be troubled by the fact that, in December,
more than one of the Trustees made public statements to the
effect that 5378 was in effect and that the Trustees could do
absolutely nothing about it, including this sort of fix, without
a new IETF consensus document that updated or replaed 5378.
Either we need to hear from the Trustees, with the support of
Counsel, that the interpretation offered in December was
incorrect and has been withdrawn, or anyone who submits a
document that incorporates the short term fix language risks
being told --by one or more Trustees or others-- that the
disclaimer does not count and that, but submitting the document,
they are still making the warrantees that have been the subject
of this discussion.

   john

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 10 Jan 2009 12:52:07 -0800

> some boilerplate. We do have a glitch in 5378 to mend, but let's get that

I can't begin to guess at the logic that uses Larry's somewhat bizarre assertion 
as a basis for trying to press approval of this clearly and substantially 
problematic proposal.

To create a paraphrase, what part of "neither short term nor a fix" did you not 
understand?

The concept of "short term" never applies to infrastructure changes, and as Fred 
pointed out -- ableit again my paraphrase -- we are messing with something deep 
in the IETF's processing infrastructure.

Equally, taking something that already imposes unnecessarily broad impact, and 
layering onto it a hack that imposes even more impact, is not a fix.

d/
-- 

   Dave Crocker

---

From: John C Klensin <[email-masked]>
Date: Sat, 10 Jan 2009 16:13:41 -0500

--On Saturday, January 10, 2009 12:52 -0800 Dave CROCKER
<[email-masked]> wrote:

>...
> I can't begin to guess at the logic that uses Larry's somewhat
> bizarre assertion as a basis for trying to press approval of
> this clearly and substantially problematic proposal.
> 
> To create a paraphrase, what part of "neither short term nor a
> fix" did you not understand?
>...

With the understanding that this is _not_ a fix to any
short-term problem, I think I've learned something from the IPR
WG process and its "too few people really understood the
documents and their implications" consensus and the resulting
IETF consensus that produced 5378.   That lesson goes beyond "we
don't evaluate legal language at all well" and into some defects
in how we approve procedural documents.

Independent of the much more controversial question of which
body should be approving these things and under what process, I
note that we require "IANA Considerations" sections for
technical documents so that IANA can check to be sure that the
instructions make sense and are consistent with other registries
and practices.  It is now clear to me that any document that has
procedural, administrative, or legal provisions or consequences
should be required to contain:

	(i) Explicit "IASA Considerations" and/or "IETF Trust
	Considerations" sections, as appropriate.
	
	(ii) A requirement for explicit signoff, or at least
	formal comments, from those bodies before the IESG makes
	a decision about IETF consensus.

While it isn't clear that the Trustees would have identified
these implementation / transition problems during this review,
giving them the opportunity and obligation to spot
implementation problems --and to think through how they would
implement a particular set of requirements before those
requirements are cast in stone-- would have at least eliminated
the "not our problem; we are just doing what we were told"
attitude and comments that resulted in our looking at proposals
in January rather than before the holidays.

The general idea would be to explicitly put the Trustees (or the
IAOC for other situations) into the position of being able to
say "nice idea, but it won't work legally and/or procedurally",
just as IANA can say "we have read that specification and have
no idea how to implement it in practice"... and to give them the
obligation to review a document, pre-approval, and decide
whether to provide that advice.

I believe that the IESG can impose these requirements and the
additional checking/validation cycle on its own initiative,
based on their having imposed the "IANA Considerations" and
others on their own initiative.   This is a call for that
initiative or, if it is not forthcoming, for others to think
enough about the issue to determination of whether collaboration
on an I-D would be appropriate.

It doesn't need to be done this week, but it appears to me to be
something we had better have in place before anyone starts
considering 5378bis (or a forked 3978ter).

    john

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 11 Jan 2009 10:34:46 +1300

On 2009-01-11 09:52, Dave CROCKER wrote:
> I can't begin to guess at the logic that uses Larry's somewhat bizarre
> assertion as a basis for trying to press approval of this clearly and
> substantially problematic proposal.

I was responding to JCK and Ted Ts'o.
I didn't intend to comment on Larry's remarks in any way, shape
or form. It's reasonably well established that IANAL. Please take my
comment as a direct reponse to the Subject header of this thread.

> To create a paraphrase, what part of "neither short term nor a fix" did
> you not understand?

I understand. I disagree.

> 
> The concept of "short term" never applies to infrastructure changes, and
> as Fred pointed out -- ableit again my paraphrase -- we are messing with
> something deep in the IETF's processing infrastructure.
> 
> Equally, taking something that already imposes unnecessarily broad
> impact, 

Er, is that a Last Call comment on draft-ietf-ipr-outbound-rights
and draft-ietf-ipr-3978-incoming? A bit late, if so.

> and layering onto it a hack that imposes even more impact, is
> not a fix.

Look, the IPR WG, and all those who reviewed its drafts, including
me, missed that fact that there was a transition problem that should
have been covered in those drafts. I'm sorry, I made a mistake, as
Basil Fawlty once said. We need to fix that mistake.

   Brian

---

From: [email-masked]
Date: Sat, 10 Jan 2009 13:45:56 -0800 (PST)

+1

				Ned

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 10 Jan 2009 13:55:13 -0800

> and draft-ietf-ipr-3978-incoming? A bit late, if so.

Brian, "too late" makes sense for stray comments.

It doesn't make sense when we discover that a spec doesn't work. There have been 
quite a few comments and events that make concretely clear that this 'spec' 
doesn't work, and that the proposed fix introduces significant new problems, 
even assuming that it 'fixes' the primary problem.

> Basil Fawlty once said. We need to fix that mistake.

You keep referring to this as a 'transition' problem as if that minimizes the 
problem.  Even assuming that the label is formally correct, it's clear that 
there is nothing brief about the transition nor minimal about the impact.

Like most infrastructure changes, "transition" is a strategic, long-term concern.

d/
-- 

   Dave Crocker

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 11 Jan 2009 11:12:43 +1300

On 2009-01-11 10:55, Dave CROCKER wrote:
> It doesn't make sense when we discover that a spec doesn't work. There
> have been quite a few comments and events that make concretely clear
> that this 'spec' doesn't work, and that the proposed fix introduces
> significant new problems, even assuming that it 'fixes' the primary
> problem.

I haven't seen anything to suggest that the new copyright regime
doesn't work for all-new documents, or for documents whose original
contributors have agreed to the new regime.

> You keep referring to this as a 'transition' problem as if that
> minimizes the problem.  Even assuming that the label is formally
> correct, it's clear that there is nothing brief about the transition nor
> minimal about the impact.
> 

Yes. I have IPv6-shaped scars to prove that. That's exactly why I
support the notion of a short-term fix to give us time to agree
on an enduring solution.

    Brian

---

From: Bill Manning <[email-masked]>
Date: Sat, 10 Jan 2009 14:42:57 -0800

> joint works of authorship.

	er... thats -NOT- what I was trying to point out.  The IETF
	was given permission to publish an authors work but was not
	allowed to impune joint authorship. The IETF did not create the
	work - it provided a publication vehicle.

> for the IETF out-license.

	going forward, perhaps.  retro-active, not so sure.

> anything they want with those jointly-owned IETF RFCs.

	I think the basis of the argument revolves around the assertion
	of "joint" ownership. ... and there are concerns with all forms
	of communications over IETF sanctioned/sponsored channels - e.g.
	the "Note Well" - not just the RFC series.

> when we allow certain kinds of derivative works.

	thats ok... i'm not really "anyone" so i am sorry for taking 
	your statements at face value.

> waiver if one of them later claims an exclusive copyright interest in any

	sorry - not waiving those rights to you or anyone else.

--bill
> > private
> > on this

-- 
--bill

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 10 Jan 2009 16:28:31 -0800

Hi -

> From: "Bill Manning" <[email-masked]>
> To: "Lawrence Rosen" <[email-masked]>
> Cc: "'IETF Discussion'" <[email-masked]>
> Sent: Saturday, January 10, 2009 2:42 PM
> Subject: Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewandcomments on a proposed Work-Around to the Pre-5378
Problem
...
...

That certainly was *not* my understanding when I offered my services
as an editor for the various IDs and RFCs where I've functioned in
that role.  I, and I'm sure many others in those working groups,
thought those documents were products of the working group,
which did that work for the IETF.  For me to claim authorship of,
e.g., RFC 3417, would be intellectually dishonest.  For the IETF
to claim that I was its author, rather than merely an editor acting
on the instruction of a working group, is downright delusional.

Randy

---

From: Bill Manning <[email-masked]>
Date: Sat, 10 Jan 2009 19:33:49 -0800

> on the instruction of a working group, is downright delusional.

	there are a broad range of possible interpertations on
	ones activities in such a loose confederation of like-minded
	individuals (since the IETF has no membership per se).

	i was pointing out that for some period of time, (and i suspect
	this is still true for non-WG generated materials) where the
	work product was developed independently of any given WG effort.
	the NFS spec comes to mind.

	for a few months/years, this was recognized by the RFC editor
	and the IAB/IESG - which created three specific copyright statements
	that reflected the various origins of the submitted materials.

	one of those "boilerplate" texts allowed for the listed authors
	to own the copyright to the text and gave specific permission to
	the IETF to publish the work "as-is".

	that said, i can not disagree with you on your understandings.
	
	so ... prior to the dis-engagement of CNRI and the rise of the
	IETF TRUST, just how would one define "the IETF" anyway?

-- 
--bill

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 11 Jan 2009 16:09:54 +0100

> requiring a maximally compatible OSS license for code makes sense.

No, the problem of using an appropriate license has already been taken
care of (the trust uses the BSD license for code-like portions).

One of the remaining problems is, as described above, that the IETF
license does not permit authors to take BSD licensed code and use them
as illustration in RFCs because RFC 5378 does not permit additional
copyright notices to be present in RFCs.

> were to think about the risks involved.

I would agree with you for the 2-3 sentences scenario, but that's
missing my point.  I would fully disagree when it comes to 2-3
paragraphs, 2-3 pages, or entire I-D's.  I believe the latter is the
reality with several free software projects, including the Linux kernel.

/Simon

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 11 Jan 2009 10:28:56 -0500

Let's be quite clear here.
Your stated requirement for doing this was that authors had to be able 
to take and modify any text from anywhere in an RFC.
The Working Group concluded that while that was reasonable relative to 
code (and we tried to give the open source community that ability 
relative to code), that such a wide grant was not reasonable relative to 
the text content of RFC.  (Among other concerns, such changes would 
include modification of normative text and text carefully worked out by 
working groups to get the meanings right.  If the WG got it wrong, the 
IETF is the place to fix it, not comments in code somewhere.)

Also, it should be understood that this issue is largely orthogonal to 
the topic under discussion.  The working group could have included what 
Simon asked for in 5377.  The rough consensus of the WG was not to do 
so.  A more narrow 5378 would make it harder to make such a grant, but 
since the working group didn't choose to do so (and personally, I think 
doing so would undermine much of our work) the issues seems to have no 
bearing on "whould we rescind 5378?" or "is there a better transition 
strategy to get 5378 to apply to the bulk of our work?" or "how do we 
get 5378 rights in code, without holding up all the other documents?"

Yours,
Joel

---

From: John C Klensin <[email-masked]>
Date: Sun, 11 Jan 2009 10:56:44 -0500

--On Sunday, January 11, 2009 10:28 -0500 "Joel M. Halpern"
<[email-masked]> wrote:

> Also, it should be understood that this issue is largely
> orthogonal to the topic under discussion.  The working group
> could have included what Simon asked for in 5377.  The rough
> consensus of the WG was not to do so.  A more narrow 5378
> would make it harder to make such a grant, but since the
> working group didn't choose to do so (and personally, I think
> doing so would undermine much of our work) the issues seems to
> have no bearing on "whould we rescind 5378?" or "is there a
> better transition strategy to get 5378 to apply to the bulk of
> our work?" or "how do we get 5378 rights in code, without
> holding up all the other documents?"

One addition to Joel's remarks.  Even if, as part of the medium
to long-term solution to the 5378 problem, we were to return to
the basic model of 2026, i.e., any rights for non-IETF use have
to be worked out directly with authors, 5377 would need only a
conceptually fairly minor amendment requiring that authors grant
those rights at the time of document submission, rather than
recommending that the Trust doing so on a licensing basis.   I
don't see any reason to believe that pulling out that core
change in 5378 is necessary to solve the problem of what to do
about old documents/ Contributions, but, even if we did...

So, please, let's focus on that old document transition problem
and what is necessary to make it go away efficiently, safely,
and with great confidence, rather than trying to move from "5378
has a problem" to "this is an excuse to rehash every decision
taken by the WG".

Just my opinion, but...
     john

---

From: "Lawrence Rosen" <[email-masked]>
Date: Sun, 11 Jan 2009 09:54:35 -0800

Joel Halpern wrote:
> The working group could have included what
> so.

That is accurate. It is also a damned shame, and many of us still don't
agree. 

/Larry Rosen 

Lawrence Rosen

> Joel M. Halpern
> Sent: Sunday, January 11, 2009 7:29 AM
> To: Simon Josefsson
> Cc: 'IETF Discussion'
> reviewandcomments on a proposed Work-Around to the Pre-5378 Problem
>

---

From: Theodore Tso <[email-masked]>
Date: Sun, 11 Jan 2009 14:18:58 -0500

> reality with several free software projects, including the Linux kernel.

2-3 paragraphs would probably still be fair use.  I'm not aware of any
place in the Linux kernel where there was more than a few paragraphs
quoted from RFC's.  There were a few projects that included full
verbatim copies of RFC's for reference/documentation purposes,
although most of those have been removed due to the fact that previous
RFC permission statements were not compliant with the Open Source
Definition, and so distributions such as Debian required that such
full copies of the RFC had to be stripped from the source packaging.

That was never the case with the Linux Kernel, however.  Some Debian
Free Software Fanatics are having a field day with firmware binary
blobs, but not with any I-D's or RFC's as far as I am aware.

              	       	    	      	 - Ted

---

From: TSG <[email-masked]>
Date: Sun, 11 Jan 2009 11:57:06 -0800

> comfortable that at least the IETF Trust authorizes such derivative works. 
Which there are serious concerns about whether the Trust ever owned that 
IP. I.e. that the transfer of the IP to the Trust is permanently flawed 
by the derivatively requirement's that all derivative works be licensed 
under the same rights requirements' are the originals are.
> interested in a common result. 

But the RFC is not an open license to use the IP for any and all 
purposes, i.e. that beyond publishing written copies of those IP's that 
the content can be used to create other IP's like Software Systems which 
implement that standard.
> is the joint owner of copyright in every RFC. 
No we shouldn't Counsel. The Trust DOES NOT OWN ANYTHING that was 
licensed under RFC2026 unless a separate contract was executed by those 
authors authorizes that change in the original licensing.

The problem is that *** ANY *** derivative work which is done under a 
later filing but also includes component's or technology from one of 
those earlier filings those new filings must also track that earlier 
licensing.
> As such, a license from the
I disagree.
> interest in every RFC it publishes and can thus authorize derivative works

yes.
>>> cost/benefit model that is clearly quite different from what the
>>>       
>> proposal
>>     
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com 
> Version: 8.0.176 / Virus Database: 270.10.4/1880 - Release Date: 1/7/2009 8:49 AM
>
>

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 11 Jan 2009 22:13:13 +0100

> to take and modify any text from anywhere in an RFC.

No, that's a different issue.  Being able (as RFC author) to include
code not written by IETF contributors is different from being able to
modify text in an RFC (as RFC reader).

> relative to code), that such a wide grant was not reasonable relative
> to the text content of RFC.

Alas.

> (Among other concerns, such changes would include modification of
> normative text and text carefully worked out by working groups to get
> the meanings right.  If the WG got it wrong, the IETF is the place to
> fix it, not comments in code somewhere.)

I obviously disagree.  Users of free software need the ability to fix
the source code and modify the documentation that goes along with it.
The issue should of course be brought up within the IETF too, but it
does not serve the IETF's goal of running a "smooth Internet" to make it
harder for people to fix software that runs the Internet.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 11 Jan 2009 22:20:59 +0100

> full copies of the RFC had to be stripped from the source packaging.

As far as I can tell, current RFC permission statements are not
compliant with the Open Source Definition either.

/Simon

---

From: "Doug Ewell" <[email-masked]>
Date: Sun, 11 Jan 2009 19:41:46 -0700

This has been an interesting (at times) philosophical discussion. 
However, as editor of a WG Internet-Draft, I have a couple of very 
pragmatic questions that I hope someone can answer authoritatively:

1.  What do I, as editor of an I-D and previously editor of a related 
RFC that is not quoted in the current I-D, need to do in order to allow 
the WG chairs to move my draft forward into IETF Last Call?

2.  What do the co-editors of the WG's other I-D, who were previously 
also the co-editors of a related RFC that *is* quoted in the current 
I-D, and at least one of whom has co-authored other RFCs, need to do to 
allow the WG chairs to move *their* draft forward into IETF Last Call?

Our WG has stalled due to the uncertainty surrounding the legal 
requirements and verbiage.  None of us are attorneys, AFAIK, but all of 
us would like to get our work done.

--
Doug Ewell  *  Thornton, Colorado, USA  *  RFC 4645  *  UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ

---

From: Fred Baker <[email-masked]>
Date: Fri, 9 Jan 2009 16:15:35 -0800

So what I hear (and for the benefit of others, let me note that you  
and I have ha a fairly detailed discussion privately that I think I am  
summarizing the result of) is that you want a short term solution and  
a long term solution. The short term solution would be adequately  
solved by using the 3978 options for most documents, and for documents  
with code, the 5378 option or a letter-or-whatever sent in parallel  
that was equivalent. In the long term, you would be fine with a rule  
that supported all existing 3978 options plus some number (one?) that  
said "this contains code, and...". Am I correct?

If so, the present dilemma can be resolved by
  - the IESG rescinding its acceptance of 5378, reinstating 3978
    as the rule of the day
  - the IESG directing the Trust to accept legal communications
    (letters, PGP-signed emails, whatever) that convey the sense of
    the 5378 license for code-bearing documents as a
    temporary workaround
  - in the long term, the development of a 5378-bis that
       * accepts 3978 options as is for non-code documents and <the
         right option> for documents containing code,
       * treats movement of documents to other SDOs as a special
         case to be handled by the parties to the transaction
         including the trust and relevant authors etc.

Close?

On Jan 9, 2009, at 3:52 PM, Joel M. Halpern wrote:

> problem.  Document transfer outside the IETF is sufficiently rare  
> that I would agree with Fred that not solving that is fine.
>
> This also means that from my personal perspective, a solution that  
> says (loosely based on a suggestion from someone else in a side  
> conversation) that
> 2) If you can't, you grant the old rights, as long as there is no  
> code in the document
> 3) If there is code, get the rights to the code so people can  
> actually use the code in the RFC to implement the RFC.  (MIBs are  
> already covered, but we have lots of other kinds of code.)
>
> Yes, point 3 may hold up some work.  But one could reasonably argue  
> that such work needs to be held up so that folks can use the code we  
> are giving them.
>
>> consent".  There is a possible 2.5bis, which would be something  
>> like "I've

---

From: [email-masked]
Date: Sun, 11 Jan 2009 17:02:40 -0500

John,

> just repealing the things and doing a small update to 3978/4748

My recollection of one of the major problems that 5378 was
intended to solve is allowing use of text from IETF standards
outside of the IETF.  Two specific examples are:
1) Use of code from an RFC in an implementation.  This often
	requires the ability to modify the code in some minor
	ways.
2) Use of text from an RFC in another standard.  This is *not*
	transfer of the standard, but rather allowing use of
	the actual text in a different standard that does
	something similar.
The pre-5378 copyright rules block both of these.

The ipr WG spent a great deal of time discussing code use, and
whether to apply the same provisions to text (ultimately, the
same provisions were not applied).  I have personally been in a
situation where an editor in another standards organization had
to do a complete rewrite of a large quantity of text obtained
from an RFC because the IETF could not grant copyright
permission independent of whether the IETF wanted to grant
that permission or not.

Regardless of the mess that's been made for revisions of
documents that used the old rules, I doubt that a "de-glitch"
effort on 3978/4748 can address the two examples noted above, 
as both require additional permissions from authors that the
IETF has not obtained in the past (and hence that the IETF
does not have for documents created under past rules).

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "David Harrington" <[email-masked]>
Date: Mon, 12 Jan 2009 14:07:35 -0500

> case simple. 

I concur.
I think we should continue to use the RFC3978 rules as the default,
and to allow WGs to choose to assign, or not, the new rights on new
documents.

I was author of 4663, and I coordinated the whole effort to transfer
the rights to the Bridge MIB documents from IETF to IEEE. I can state
that getting permission from the authors and their companies was not
onerous, but I would not want to do that for documents that were not
being transferred.

I will observe that the requirement we met for RFC4663 was to get
permission from the authors of the current drafts, and the authors of
the previous revisions, and their companies. We did not try to
determine the complete list of people who contributed to the works as
WG members. I think THAT task would have been so onerous that I would
have argued against doing the transfer, and told IEEE persons to just
come work in the IETF instead.

In actuality, for RFC4663, the IEEE lawyers got the permissions. I
just helped by identifying the authors and their companies. I suggest
the right way to handle this in the future is to let the copying
organization go get the permissions and assume any related risk. To
make that easier, I would not have a problem with a WG deciding to
include the right to copy. But then the question becomes "is rough
consensus adequate?" or must it be unamimous? If it has to be
unanimous, then we apparently would need a membership and voting
system, so we know who has a say, and whether they have voted or not.

I have been an editor of IETF documents for years, and have never
tried to document where every contribution came from, or tried to
track the legal permissions granted by each contributor for their
text. If I am expected to assume legal risk for asserting that all
rights have been granted for text in documents being transferred or
being copied into other documents, for all contributors to a WG
document, then I would gladly give up editing.

I really do not like the changes this new boilerplate forces onto the
IETF process.
I would rather continue to use RFC2026/3978 rules.

David Harrington
[email-masked]
[email-masked]
[email-masked]

---

From: Russ Housley <[email-masked]>
Date: Mon, 12 Jan 2009 16:07:45 -0500

Doug:

I hope this response answers your pragmatic questions.

>1.  What do I, as editor of an I-D and previously editor of a 
>related RFC that is not quoted in the current I-D, need to do in 
>order to allow the WG chairs to move my draft forward into IETF Last Call?

You can proceed to IETF Last Call now.  However, if updates to the 
I-D are needed you may be faced with a problem depending on your 
situation.  I presume that some or all of the text in the I-D was 
contributed before 10 Nov 2008.  If so, then an update to that I-D 
requires you or the WG chair to determine if the people that made the 
contribution are willing to grant the additional rights required by 
RFC 5378.  If so, you are done.  If not, you will need some 
work-around like the one being discussed on this thread.

If IETF Last Call or IESG Evaluation brings comments that require an 
update to the I-D, then you end up with the same situation.

If the document is approved without change, then the RFC Editor will 
ask each of the authors to grant the additional rights required by 
RFC 5378.  If this cannot be done, then the document will sit in the 
queue until some work-around like the one being discussed on this 
thread is implemented.

>  2.  What do the co-editors of the WG's other I-D, who were 
> previously also the co-editors of a related RFC that *is* quoted in 
> the current I-D, and at least one of whom has co-authored other 
> RFCs, need to do to allow the WG chairs to move *their* draft 
> forward into IETF Last Call? Our WG has stalled due to the 
> uncertainty surrounding the legal requirements and verbiage.  None 
> of us are attorneys, AFAIK, but all of us would like to get our work done.

You can proceed to IETF Last Call now.  As above, at some point 
contributors will be asked to grant the additional rights required by 
RFC 5378.  If you can do so, there is no problem.  If not, you will 
need some work-around like the one being discussed on this thread.

Russ

---

From: John C Klensin <[email-masked]>
Date: Mon, 12 Jan 2009 16:28:02 -0500

--On Monday, January 12, 2009 16:07 -0500 Russ Housley
<[email-masked]> wrote:

>...
> If the document is approved without change, then the RFC
> Editor will ask each of the authors to grant the additional
> rights required by RFC 5378.  If this cannot be done, then the
> document will sit in the queue until some work-around like the
> one being discussed on this thread is implemented.

Russ, the RFC Editor does not, in general, know about any
Contributors other than listed authors and has never been tasked
with figuring that out.   Does the above imply that the Trustees
have made a determination, with the advice of Counsel, that it
is safe and appropriate to interpret the 5378 rules wrt older
text such that only listed authors are relevant to obtaining
necessary rights?   Has the RFC Editor been advised of that
determination?

I ask only because of my continuing concern that a fix/patch
will be adopted with the best of intentions all around but then
will turn out to not cover enough cases to make it really useful.

     john

---

From: Russ Housley <[email-masked]>
Date: Mon, 12 Jan 2009 17:15:49 -0500

>will turn out to not cover enough cases to make it really useful.

The RFC Editor is asking the authors.  That is the list of people 
that is readily available.  If the authors cannot speak for all 
Contributors, then the document will have to wait until a work-around is found.

Russ

---

From: Russ Housley <[email-masked]>
Date: Mon, 12 Jan 2009 17:24:20 -0500

John:

I think that the cover note from the Chair of the IETF Trust, Ed 
Juskevicius, included the vast bulk of the information that you are 
requesting.  Let's look at all three parts of your request.

(1)  "this is the problem we are trying to solve"

 > If s/he cannot make this assertion, then s/he has a problem.

In my view, the Trustees are trying to prevent a situation that 
forces people to make assertions on behalf of third parties.  From 
this thread, and you messages in particular, it is quite clear that 
forcing people to do so would be a very big problem.

(2)  "this is the principle we are using as the basis of the solution"

 > ... The Trustees of the IETF Trust

In my words, the Trustees are trying to use the flexibility in the 
existing BCPs to provide a work-around, and then the IETF can craft a 
long-term solution once this work-around has relieved the 
pressure.  The Trustees approach requires community review, but it 
does not require IETF consensus because it stays within the bounds of 
our of the existing BCPs.

As General Area Director, I support this approach for four 
reasons.  First, I believe that this work-around can be put in place 
faster than updating the BCP.  Even if we had the perfect 
Internet-Draft in hand three steps would be needed to approve it: AD 
Review (a day if it is really perfect), IETF Last Call (four weeks), 
and IESG Evaluation (a week or two).  And once it is approved, the 
RFC Editor would need to process the document (up to four 
weeks).  Second, I believe the discussion of the work-around will 
shed light on the long-term solution.  Third, I think that discussion 
of the work-around and the long-term solution at the same time will 
cause confusion, not provide clarity.  Fourth, I would like to keep 
the good things in RFC 5378 while repairing this problem. Clarity 
about the role of the IETF Trust and clarity about the rights to 
modify code in a way that is acceptable to the open source community 
are the most important things that would be lost by reverting to the 
previous IPR policy.

(3)  "with the advice of Counsel, we believe that this fix represents
a competent, best-efforts, legal-text representation of that principle
and nothing else".

The cover note does not address all of these points.  The Trustees 
did seek legal advice, and Counsel fully support this 
work-around.  As you might imagine, Counsel was heavily involved in 
the discussions as well as the words themselves.  The Trustees are 
trying to provide a near-term work-around within the current BCPs and 
nothing else.

The IETF Trust does not approve BCPs, but the IETF Trust has a role 
in implementing this BCP.  As explained in the cover note:

 > derivatives of the documents they submit.

Counsel provided very clear justification for this 
interpretation.  My initial reading of RFC 5378 lead me to a 
different conclusion, but I missed some important context in section 
1.j.  I'm glad to say that the Trustees do have the authority to 
implement this work-around if the community supports it.

Finally, the Trustees are not trying to repair RFC 5378.  That task 
is left for the General Area of the IETF.

Russ

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 12 Jan 2009 15:17:27 -0800

Ed,

I'd like to thank the Trustees for working to resolve this
situation. Unfortunately, after reviewing the new text, I don't think
it's really adequate. 

To recap, the the old text required the contributor to affirm (and
consequently to verify) that adequate permissions had been obtained to
publish legacy (pre-5378) material under the 5378 rules. This was
impractical both because of the difficulty of obtaining such
permissions and the difficulty of tracing every portion of the
document. This new text, reproduced below, solves the first problem,
but not the second:

    This document contains material from IETF Documents or IETF
    Contributions published before November 10, 2008 and, to the
    Contributor?s knowledge, the person(s) controlling the copyright in
    such material have not granted the IETF Trust the right to allow
    modifications of such material outside the IETF Standards Process.
    Without obtaining an adequate license from the person(s) controlling
    the copyright, this document may not be modified outside the IETF
    Standards Process, and derivative works of it may not be created
    outside the IETF Standards Process, except to format it for
    publication as an RFC and to translate it into languages other than
    English.

The first problem here is the phrase "and, to the Contributor's
knowledge, the person(s) controlling the copyright in such material
have not granted the IETF Trust the right...". As I read this, I am
directly affirming my belief that there are copyright holders who have
not granted these rights. This is all fine if I know exactly who the
original copyright holders are and that they have not given
permission, but the more likely case is that I don't know one way or
the other, and am simply unwilling to affirm the converse.
However, I am equally unwilling to affirm my knowledge and belief
that the persons controlling the copyright have not made grants.
I simply don't know. This text should be rewritten as:

    This document contains material from IETF Documents or IETF
    Contributions published before November 10, 2008. Some material
    may be subject to copyright claims for which the holders have not
    granted the IETF Trust the right to allow modifications of such
    material outside the IETF Standards Process.

In addition, the final sentence "Without obtaining..." seems overly
strong. It's phrased as if it were a condition imposed by the
contributor, i.e., I the contributor doesn't license you to use
this document unless you obtain "adequate" permission from the original
copyright holders (with the contributor to be the judge of adequate,
perhaps). But that's not what's in play here. Rather,
it's that I the contributor can't give me license to material
I don't control. So, this sentence serves as advice, not
a license restriction and should be rewritten accordingly.
Perhaps:

    Modification or creation of derivative works outside of the
    scope of RFC 4978 may require obtaining a license from the
    person(s) controlling the copyright on the relevant sections
    of the document. 

Best,
-Ekr

---

From: John C Klensin <[email-masked]>
Date: Mon, 12 Jan 2009 19:00:36 -0500

--On Monday, January 12, 2009 17:24 -0500 Russ Housley
<[email-masked]> wrote:

> John:
> 
> I think that the cover note from the Chair of the IETF Trust,
> Ed Juskevicius, included the vast bulk of the information that
> you are requesting. 

Russ,  I think your note addresses several more of the issues I
was concerned about than Ed's note did.  Assuming that your note
represents the consensus of the Trustees where that is relevant,
I don't see any reason to quibble about that point.

More to the point, while I think I disagree with parts of your
analysis, the disagreements, if any, are in areas that should
not block progress at this point, i.e., I can live with your
interpretation without any need to dispute those differences.

I do have a comment on (3) in context...

> The cover note does not address all of these points.  The
> Trustees did seek legal advice, and Counsel fully support this
> work-around.  As you might imagine, Counsel was heavily
> involved in the discussions as well as the words themselves.
> The Trustees are trying to provide a near-term work-around
> within the current BCPs and nothing else.

Good. However, what I was looking for was assurance from Counsel
that he had done an in-depth analysis of the language and
concluded that it was both necessary and sufficient to address
and solve (or work around) the problem.  That is different from
"supporting the work-around", "involved in the discussions", etc.

Ekr's recent note points out part of the problem that I believe
that Counsel should have caught (and would have caught if asked
the right question).   The intent, as ekr and I understand it
and as I think your and Ed's note indicated, was to eliminate
the requirement that authors make any assertions at all about
work other than their own, much less requiring that they
guarantee those assertions.  Perhaps, for a document some of
whose text predates 5378, I am certain about the origins of all
of the text and can make assertions about it and about whether
or not everyone has signed off.  But, if I am not, I should not
be required to make assertions, one way or the other, that
require that I claim and take responsibility for, complete
knowledge.  Even if I am willing to take responsibility for
identify all of the relevant Contributors, unless there is a
compelling reason that I haven't heard yet, we should not be
requiring authors to search the Trust's archives to determine
who has signed off, who has not, and whether the statements they
made in signing off are sufficient to meet the conditions of
5378 as modified by the workaround.

So I strongly support the general thrust of ekr's proposed
modified text rather than the text as posted.  If a change is
made that is consistent with the general principle that authors
who know that they are working on documents that contain
pre-5378 text, text about which others might make claims, do not
need to make any affirmative assertions at all about the IPR
status of that other work.

      john

---

From: "Ed Juskevicius" <[email-masked]>
Date: Mon, 12 Jan 2009 19:27:02 -0500

Eric, Thank You for your comments and for your suggestions (below)

I like your proposal for how to clarify and improve the wording of the draft
legend text.

Best Regards,

Ed J.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Eric Rescorla
Sent: January 12, 2009 6:17 PM
To: Russ Housley
Cc: [email-masked]; [email-masked]
Subject: Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your
reviewand comments on a proposed Work-Around to the Pre-5378 Problem

Ed,

Best,
-Ekr

---

From: "Ed Juskevicius" <[email-masked]>
Date: Mon, 12 Jan 2009 19:28:22 -0500

John Klensin wrote:

> The intent, as ekr and I understand it and as I think your and Ed's
> note indicated, was to eliminate the requirement that authors make any
> assertions at all about work other than their own, much less requiring 
> that they guarantee those assertions.  

Correct!  That is indeed the purpose of the proposed "work-around" legend
text.

> So I strongly support the general thrust of ekr's proposed modified
> text rather than the text as posted.  

Thank You.  This is good feedback.

Regards,

Ed  J.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of John C Klensin
Sent: January 12, 2009 7:01 PM
To: Russ Housley
Cc: [email-masked]; [email-masked]
Subject: Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your review
and comments on a proposed Work-Around to the Pre-5378 Problem

      john

---

From: Stephan Wenger <[email-masked]>
Date: Mon, 12 Jan 2009 17:18:51 -0800

Hi Russ,

On 1/12/09 2:15 PM, "Russ Housley" <[email-masked]> wrote:

[...]
> Contributors, then the document will have to wait until a work-around is

In this case, wouldn't it make sense to (temporarily?) suspend the rule that
an RFC should not have more than 5 co-authors?

Regards,
Stephan

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 12 Jan 2009 17:27:16 -0800

Hi -

> From: "Russ Housley" <[email-masked]>
> To: "Doug Ewell" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Monday, January 12, 2009 1:07 PM
> Subject: Re: ANNOUNCEMENT: The IETF Trustees invite your review andcomments on a proposed Work-Around to the Pre-5378 Problem
>
> Doug:
> 

When updates have been wordsmithed by the WG, is it true that
only a person whose exact N words (where N >= X) were used
needs to sign off on it, and we don't need to track down every
single variation suggested during the wordsmithing?  Can
we have a guideline for WG chairs on a value for X?

...

In the particular case Doug mentions, there are *no* authors, only
editors working under the direction of a WG.  Does this still apply?
Wouldn't it make more sense for the WG to grant the additional rights,
since it is the WG which authored the work.

Randy

---

From: Martin Duerst <[email-masked]>
Date: Mon, 12 Jan 2009 16:30:12 +0900

Re. pre-5378 vs. post-5378 material, please note that in many
cases, an RFC may be post-5378, but the Internet-Drafts having
lead up to it may be pre-5378, or the lastest available Internet-
Draft may be post-5378, but earlier ones may be pre-5378.
In other words, just looking at things at the RFC level is not
enough. That may be obvious to many, just wanted to make sure
it doesn't get forgotten.

Regards,    Martin.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 13 Jan 2009 10:37:58 +0100

> it doesn't get forgotten.

In particular, at the moment the RFC was published, the whole issue 
we're discussing here may not have been known. Certainly my co-authors 
and myself weren't aware of it when we approved publication of RFC 5323.

Best regards, Julian

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 13 Jan 2009 07:21:32 -0800

At Mon, 12 Jan 2009 19:27:02 -0500,
> I like your proposal for how to clarify and improve the wording of the draft

Thanks.

Can you advise as to when the community can expect to see a revised
legend proposal from the trust that incorporates the community feedback
you're receiving?

Best,
-Ekr

---

From: Russ Housley <[email-masked]>
Date: Tue, 13 Jan 2009 12:07:47 -0500

>status of that other work.

Counsel certainly reviewed the text, but like many groups, there was 
input from several individuals coming in at roughly the same 
time.  One of the portions the text that EKR is concerned about 
resulted from edits that I suggested.  I do not agree with some 
aspects of his interpretation, but that is not important because I 
think his suggested words are even better.  This is the point of the 
community review.  I'm pleased to support them.

Russ

---

From: TSG <[email-masked]>
Date: Tue, 13 Jan 2009 10:00:15 -0800

Russ Housley wrote:

Russ the phrase COUNSEL reviewed the text is meaningless from a legal 
standpoint without specifically asking particular questions. So what is 
it exactly that the Counsel reviewed and is willing to issue a formal 
opinion on?

Todd Glassey
> input from several individuals coming in at roughly the same time.  
> One of the portions the text that EKR is concerned about resulted from 
> edits that I suggested.  I do not agree with some aspects of his 
> interpretation, but that is not important because I think his 
> suggested words are even better.  This is the point of the community 
> review.  I'm pleased to support them.
>
> Russ
>
> Internal Virus Database is out of date.

---

From: Russ Housley <[email-masked]>
Date: Tue, 13 Jan 2009 14:52:38 -0500

>an RFC should not have more than 5 co-authors?

This guideline was developed by the RFC Editor, so it is appropriate 
for them to speak to this point.

Russ

---

From: "Contreras, Jorge" <[email-masked]>
Date: Tue, 13 Jan 2009 15:32:45 -0500

Eric,

Thank you for the careful reading and constructive suggestions.

>     material outside the IETF Standards Process.

With a little bit of wordsmithing, I think that rephrasing this sentence
is fine.

> a license restriction 

Actually, this is not correct.  The sentence *is* intended as a license
restriction, not merely advice.  Remember:  all of this language is
being included pursuant to the authority granted to the Trust under
Section 5.3.c of RFC 5378, which allows a Contributor to limit the
Trust's right to grant derivative works (and thus avoid non-compliance
with the warranty contained in Section 5.6.c).

Thus, I'm happy to discuss re-wording the sentence to make it clearer,
but changing its meaning in this way would not allow the Trust to
address this issue within the parameters of RFC 5378.

> and should be rewritten accordingly.
> Perhaps:
>

---

From: "Tom.Petch" <[email-masked]>
Date: Wed, 14 Jan 2009 10:41:21 +0100

Russ

I would like greater clarity about the meaning of pre-5378.

Ed's original announcement said that the new regime was in effect from 12
November 2008 (no time specified).

Ed's revised text uses 'before 10 November 2008' (no time specified).

Ed's original announcement also placed significance on 0100 UTC on 16th December
appearing to allow a grace period up until then during which 5378 was not in
effect, since old boiler plate was acceptable.

We appear to have four zones of time (up to 23:59:59 9th Nov, 10th/11th Nov,
12th Nov sometime to 00:00:59 UTC 16th December, thereafter).

Please define, in a legally binding manner, pre- and post- 5378.

After which, we may need transitional arrangements for people who posted in the
middle two time zones, particularly for those who published in the first two
weeks of December, thinking that they had a waiver and now find that they may
have claimed rights in their Contribution that they will never possess (because
it contains old text from earlier Contributions).

(We may even have a fifth time zone, up until the time at which people were
informed of the new regime - at least up until the turn of the year, not all our
emissions yet carried the new text referring to RFC5378 so anyone new to the
IETF could reasonably claim that their Contributions were being made under
RFC3978 as modified - but I digress :-(.

Tom Petch

----- Original Message -----
From: "Russ Housley" <[email-masked]>
To: "Doug Ewell" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Monday, January 12, 2009 10:07 PM
Subject: Re: ANNOUNCEMENT: The IETF Trustees invite your review andcomments on a
proposed Work-Around to the Pre-5378 Problem

---

From: Russ Housley <[email-masked]>
Date: Wed, 14 Jan 2009 11:20:30 -0500

Tom:

RFC 5378 was published on 11 November 2008, and it went into effect 
on that date.  Pre-5378 material refers to contributions that were 
made before the BCP went into effect.  I do not believe that anyone 
tracked the posting time at a finer granularity than a day.

Russ

---

From: Bill Fenner <[email-masked]>
Date: Wed, 14 Jan 2009 10:35:11 -0800

> effect, since old boiler plate was acceptable.

This is not quite accurate.  RFC 5378 became BCP 78 at the time of
publication on November 11th; even the old text says
"      This document is subject to the rights, licenses and restrictions
      contained in BCP 78, and except as set forth therein, the authors
      retain all their rights."

So if you published an I-D with those words in it after RFC 5378 was
published as BCP 78, then that I-D is subject to the rights, licenses
and restrictions contained in RFC 5378.

  Bill

---

From: Russ Housley <[email-masked]>
Date: Wed, 14 Jan 2009 16:36:20 -0500

Correction:  RFC 5378 was published on 10 November 2008.
http://mailman.rfc-editor.org/pipermail/rfc-dist/2008-November/002142.html

Russ

---

From: "Tom.Petch" <[email-masked]>
Date: Thu, 15 Jan 2009 09:41:14 +0100

----- Original Message -----
From: "Bill Fenner" <[email-masked]>
To: "Tom.Petch" <[email-masked]>
Cc: "Russ Housley" <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Wednesday, January 14, 2009 7:35 PM
Subject: Re: ANNOUNCEMENT: The IETF Trustees invite your review andcomments on a

> and restrictions contained in RFC 5378.

Thanks for the correction.  I also had in mind contributions to mailing lists
where the Note Well - eg the one sent out to this list on 1 January 2009 -
references RFC5378 (or not as is the case in other settings) rather than  BCP78.
I am unclear whether this is by design or whether it is something that has yet
to be brought in line with current thinking.

Isn't it complicated?

Tom Petch

---

From: "Tom.Petch" <[email-masked]>
Date: Thu, 15 Jan 2009 11:52:59 +0100

----- Original Message -----
From: "Russ Housley" <[email-masked]>
To: "Tom.Petch" [email-masked]
Sent: Wednesday, January 14, 2009 10:36 PM

> http://mailman.rfc-editor.org/pipermail/rfc-dist/2008-November/002142.html

Thanks for the correction.  I was about to point out that the latest draft
licence from the IETF Trust refers in 5c to material published 'before November
10, 2008' but this now makes sense.

( In passing, the reference to November 12th was a mistake on my part; I was
looking at Ed's announcement which spoke of the new rules coming in force
'today' and which my e-mail client tells me is November 12th.  I should of
course have looked at the e-mail headers and seen that he submitted the e-mail
so as to generate
'Received: from [127.0.0.1] (localhost [127.0.0.1])
 by core3.amsl.com (Postfix) with ESMTP id 8C51A28C173;
 Tue, 11 Nov 2008 15:40:08 -0800 (PST)'
which for GMT or places West is November 11th:-(

Whatever, November 10th it is.

What then is post-5378?  Is it material published on or after November 10th?

Tom Petch

<snip>

---

From: Russ Housley <[email-masked]>
Date: Thu, 15 Jan 2009 16:54:41 -0500

>What then is post-5378?  Is it material published on or after November 10th?

Yes.

Russ

---

From: Dean Willis <[email-masked]>
Date: Wed, 21 Jan 2009 01:58:59 -0600

> Contributors, then the document will have to wait until a work- 

Given that we've historically weeded out the contributor-list on a  
document to "four or less", even if there were really dozens of  
"contributors" at the alleged insistence of the RFC Editor, I don't  
see how any older document or even a majority of new documents-in- 
progress could be adapted to the new rules.

This appears to require complete abandonment of all previous works and  
"clean room" rewrites under the new terms.

--
Dean

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 21 Jan 2009 07:39:38 -0500

>
> On Jan 12, 2009, at 4:15 PM, Russ Housley wrote:
>
>>>
>>
> This appears to require complete abandonment of all previous works  
> and "clean room" rewrites under the new terms.

Even in this worse case scenario (which clearly won't be true in all  
cases), I think that that is only true for documents that need to be
licensed outside of the IETF process.

Regards
Marshall

---

From: John C Klensin <[email-masked]>
Date: Wed, 21 Jan 2009 09:20:17 -0500

<[email-masked]> wrote:

> On Jan 21, 2009, at 2:58 AM, Dean Willis wrote:
>...
  
>> Given that we've historically weeded out the contributor-list
>> on a   document to "four or less", even if there were really
>> dozens of   "contributors" at the alleged insistence of the
>> RFC Editor, I don't   see how any older document or even a
>> majority of new documents-in-  progress could be adapted to
>> the new rules.
>> 
>> This appears to require complete abandonment of all previous
>> works   and "clean room" rewrites under the new terms.
> 
> Even in this worse case scenario (which clearly won't be true
> in all cases), I think that that is only true for documents
> that need to be licensed outside of the IETF process.

But there is no way to know whether a particular document will
be licensed outside of the IETF process at the point the RFC
enters the publication queue, much less when the first I-D that
will (or might) lead to such a submission is posted.  

My recollection (which could easily be wrong) is that it was
precisely that lack of foreknowledge that drove the WG to adopt
the 5378 plan: if one wants the Trust to be able to license
documents for use outside the IETF, and to do so well after
those documents are posted as I-Ds or published as RFCs, then
the Trust has to acquire the needed rights when the
Contributions are made.  If they have to wait until they need
those rights to issue licenses, they have to take responsibility
for tracking down anyone who might be a Contributor (known or
unknown, dead or alive, etc.) or they have to license whatever
they have, leaving responsibility for getting permission from
anyone the Trust hasn't identified and tracked down  to the
person or group who want to use things outside the IETF.

If one takes the definition of "Contribution" and "Contributor"
used in 5378 (and 3978, etc.) -- as distinct from the RFC
Editor's definition -- seriously, then the first posting of an
I-D could contain text contributed to a mailing list months
earlier.   The length of time between first relevant
Contribution and the publication date of an RFC can be very
long, certainly measured in years in some cases.   That implies
that there will be a very long time before we can assume that
every Contribution in a document pending publication occurred
since 10 November (or whenever 5378 can be legally assumed to be
effective).

It is clearly outside the authority of the Trust to undo that
"everyone transfers rights at submission time" 5378 model, even
if it can effectively be made non-retroactive (which the
work-around appears intended to do).  If we decide, in
retrospect, that we don't like it, either someone needs to post
an I-D that is much more radical than the three posted so far or
we need to spin up a WG.  I suspect, given other conversations,
that the IESG will insist on a WG unless there is overwhelming
consensus for a particular I-D and I believe there is no
possibility for overwhelming consensus for anything in this area.

While each approach involves many details to be sorted out
(including whether there are differences between I-Ds and RFCs,
which some of us consider an important question), I think we
might adopt any of three models for the long term, any of which
would require WG action.  There may of course be others but, as
general categories, they just don't occur to me right now.  The
three options are deliberately stated in non-lawyer language and
legal theories on which they might be based are not discussed.
In no particular order:

(1) Abandon the entire 5377 "the Trust gets to grant particular
licenses" model and use a "once something is Contributed to the
IETF, it is available for use by anyone, for any purpose,
including excerpting, modification, and inclusion in for-profit
publications" model.  Of course, that still leaves a legacy
problem of what to do about pre-5378bis Contributions;
presumably that would have to fall on those intending to use the
material.

(2) Discard 5378 and most of 5377.  Go back to 3978 as a
starting point, modify it to make special provisions for "code"
and to make clear that, from a permissions standpoint, any
IESG-authorized handoff of a specification to an IETF-recognized
standards body is an extended part of the IETF standards process
and covered by the same rules.   Any _other_ non-IETF use would
require those intending to use the material to sort things out
(or to decide that they don't need to), just as has been the
case for decades.  That is potentially burdensome for those who
want to include large chunks of RFCs in program documentation
(inline or separate) or manuals, but, even if we change the
rules to something 5377/5378-like, they still have to deal with
older documents unless the Trust is able to guarantee that it
has rights to _all_ Contributions that may have made up the
document.  I continue to believe that IETF handoff of
maintenance and responsibility for a spec to another SDO is
"part of the IETF standards process" and hence that this could
be a clarification that would apply to pre-3978ter
contributions, but IANAL and all of the other usual disclaimers.

(3) Keep 5378 but remove all obligations for author/submitters
to obtain consent from anyone else or guarantee that all rights
have been obtained.  That would take us all the way down the
path that the workaround (and both my I-D and Brian's) starts us
down: 5378 could not be assumed to be fully effective for all
new documents for a couple of years and would never be fully
effective for documents that are revisions of most older ones
(where "older ones" are documents containing 5378 material,
including descending from I-Ds posted before 10 November).
Consequently, the Trust would have trouble granting any licenses
under 5377 that were not full of qualifications about rights the
Trust might not have and be able to transfer.

  --john

---

From: "Doug Ewell" <[email-masked]>
Date: Wed, 21 Jan 2009 07:24:52 -0700

o Dean Willis:

>> see how any older document or even a majority of new 
>> documents-in-progress could be adapted to the new rules.
>>

Is there any wording in RFC 5378 which states that the additional burden 
imposed on RFC authors applies only to documents that are intended to be 
licensed outside of the IETF process?  I realize this may be the intent, 
but this is legal wording, where <ianal>the words are binding and not 
the intent</ianal>.

---

From: Russ Housley <[email-masked]>
Date: Wed, 21 Jan 2009 10:33:10 -0500

>>>"contributors" at the alleged insistence of the RFC Editor, I 
>>>don't see how any older document or even a majority of new 
>>Even in this worse case scenario (which clearly won't be true in 
>>all cases), I think that that is only true for documents that need 
>>to be licensed outside of the IETF process.
>
>Is there any wording in RFC 5378 which states that the additional 
>burden imposed on RFC authors applies only to documents that are 
>intended to be licensed outside of the IETF process?  I realize this 
>may be the intent, but this is legal wording, where <ianal>the words 
>are binding and not the intent</ianal>.

That is one component of the proposed update to the Trust License 
Policy.  If the notice in 6.c.iii is in the document, the authors are 
telling the Trust that it may not have the rights outside the IETF 
Standards Process.  In this case, the Trust or anyone else that wants 
to make use outside the IETF Standards Process must obtain those 
rights directly from the copyright holders.

Russ

---

From: Russ Housley <[email-masked]>
Date: Wed, 21 Jan 2009 09:49:42 -0500

>"clean room" rewrites under the new terms.

The point of the proposed change to the Trust License Policy is to 
avoid that situation.  The proposed change will allow authors to 
indicate that the document contains pre-5378 material, and thus 
derivative works are limited to the IETF Standards Process are unless 
additional rights are obtained.

Russ

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 21 Jan 2009 10:14:30 -0600

Spencer

From: "John C Klensin" <[email-masked]>
>>> majority of new documents-in-  progress could be adapted to

[deleted down to ]

> possibility for overwhelming consensus for anything in this area.

(1) Between Dean's concern (author-list pruning) and John's concern 
(contributions through postings to mailing lists, possibly months before the 
text appears in a draft), I'm having a very difficult time understanding how 
new editors are supposed to even know who contributed what to a draft when a 
new editor takes over an existing document, much less which contributors has 
granted copyright rights under 5378-as-it-exists-today.

(2) I encourage the adoption of the proposed workaround text. I agree with 
Eric's proposed changes if they are acceptable.

(3) I would strongly discourage spinning up a General-Area working group 
without adopting the workaround - as an editor, even if I thought all 
contributors had granted 5378-as-it-exists-today rights, I'm not sure why I 
would make such a declaration. What if I was wrong?

In short - please do something quickly, because the current situation is 
making things harder for people who want to get work done in the IETF, and 
that should trump every other consideration, IMO.

Thanks,

Spencer

---

From: Theodore Tso <[email-masked]>
Date: Wed, 21 Jan 2009 12:22:45 -0500

> contributors had granted 5378-as-it-exists-today rights, I'm not sure why 
> I would make such a declaration. What if I was wrong?

I know what *I* would do, if I were editing a I-D document in this
post-5378 regime.  I'd put the darned thing under source control, and
in each changelog message I would include a reference to the message
ID and author names for each textual contribution that I didn't
personally author.  That would hopefully control the legal liability I
would suffer if someone tried to sue me claiming that I had somehow
included text which violated copyright in some way, since I would be
able to demonstrate provenance at least to who actual contributed the
text to the wg mailing list.  I still might end up having to sell my
house to defend the lawsuit, but at least I would hopefully not lose
my house as a result of making the promises required by RFC 5378 ---
at least I would hopefully be able to take down whoever had
misappropriated the text with me.  :-)

> making things harder for people who want to get work done in the IETF, 
> and that should trump every other consideration, IMO.

Indeed; I was only partially serious when I suggested that the IETF
trust should indemnify or otherwise provide insurance to I-D authors.
RFC-5378 is requiring them to take on potentially fearsome liability
risks, even if we're not dealing with legacy RFC's from the pre-5378
era.

     	     	 		     	       	    - Ted

---

From: Bob Braden <[email-masked]>
Date: Wed, 21 Jan 2009 10:16:04 -0800

>progress could be adapted to the new rules.

Whoa!  This contains several errors of fact and implication.  The number 
authors named
on the front page of  an RFC are generally limited to 5 (there are 
occasional exceptions for
good cause).  This rule was arrived at after discussions in
the IETF and it has enjoyed general community support; it was not "at the 
insistence of the RFC
Editor".  The RFC Editor 's role was to alert the community to a tendency 
towards
ballooning of author lists when every telecomm vendor wanted their name on the
RFC, and perhaps it is true that the magic number "5" (which could have 
been 4 or 6 or ....)
was chosen and documented by the RFC Editor.  Otherwise, it was a community
consensus.

At the time that the 5 limit was put in place, a new Contributors section 
was added to RFCs
to contain the overflow authors/contributors.

It is my personal opinion, based on this history, that for IPR purposes we 
ought to treat
those listed in the Contributors sections as having equal copyrights to 
those named on
the front page.  (Maybe the Contributors section ought to come early in the 
RFC, rather
than late. but that would be another discussion.)  OTOH, the RFC Editor 
recoils from the
idea that those in the Contributors section should logically be included in 
the AUTH48
process; let's not!.

Bob Braden

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 21 Jan 2009 11:33:50 -0800

> Whoa!  This contains several errors of fact and implication.  The  
> number authors named
> the IETF and it has enjoyed general community support; it was not  
> "at the insistence of the RFC
> Editor".  The RFC Editor 's role was to alert the community to a  
> tendency towards
> RFC, and perhaps it is true that the magic number "5" (which could  
> have been 4 or 6 or ....)
> At the time that the 5 limit was put in place, a new Contributors  
> section was added to RFCs
> It is my personal opinion, based on this history, that for IPR  
> purposes we ought to treat
> those listed in the Contributors sections as having equal  
> copyrights to those named on
> the front page.  (Maybe the Contributors section ought to come  
> early in the RFC, rather
> than late. but that would be another discussion.)  OTOH, the RFC  
> Editor recoils from the
> idea that those in the Contributors section should logically be  
> included in the AUTH48
> process; let's not!.
>
> Bob Braden

Sorry, but that is seriously confused.  Copyright is owned by the  
authors of
copyrightable text.  The IETF has no ability nor process to restrict the
number of people who have (over time) contributed text that is  
sufficient
for copyright.  The notion that the IETF or the "general community" can
somehow arbitrarily restrict it to 5 is absurd, and in my opinion the  
RFC
guidelines are illegal because they separate authors from their moral
right of attribution for their work and effectively prevent some authors
from justifying their IETF work as citable.  I know one spec editor who
quit the IETF for that reason alone.

If the AUTH48 process existed to ensure that all copyright owners have
approved of publication of their work as an RFC, then moving the names
of those copyright owners to a separate section would just bypass the
process and make it illegitimate.  Personally, I don't think that is
why we have AUTH48 -- legal approval for publication should have been
given during contributions and AUTH48 should be strictly for editorial
content approval.

What the IETF should be doing is restricting the number of editors to 5,
list only the editors on the front page (clearly marked as such), place
the editors' addresses in a section called Editors (if they differ from
the complete set of authors), and then have another section for Authors
that would include all of the people whose copyrightable text has been
incorporated under the Contribution terms.

That would satisfy the rights of authors and the needs of IETF process,
without complicating AUTH48.  Note that this is essentially what the
"contributors" section was supposed to accomplish, but because that
section is named wrong it does not satisfy the moral rights
(the editors are named as authors while the contributors are not).

In any case, my recommendation is to ditch 5377/5378 and start over,
because I consider the entire IETF trust concept to be ill-formed and
the liability burden placed on IETF editors to be obscene.  What is
the point of having a trust if it doesn't act as protection for
those doing the work?  We all expect the IETF process to work for us,
not against us.

I would prefer an explicit statement of joint work (as Larry
described) in which the Trust (or some other IETF legal entity)
had joint rights to republish and permit derivative works,
with a simple exception for previous works similar to what
John has proposed.  That is what most of us think we are doing
when we have contributed to the IETF standards process, IMO,
and it usually works better to match the legalese to people's
existing expectations instead of inventing new ones.

FTR, httpbis is on hold until this is resolved.

....Roy

---

From: Julian Reschke <[email-masked]>
Date: Thu, 22 Jan 2009 17:40:17 +0100

> incorporated under the Contribution terms.

I do agree that if we have a limit for the front matter, it should name 
editors, not authors.

It seems to me that, assuming we agree on "editors are authors", all of 
them could be put into an "Authors" section (with the editors marked as 
they already are).

That leaves us with the question whether any contributor (IPR-wise) 
needs to be called "author". Not sure about that. But if we don't call 
them authors, they should be listed in a agreed-upon place in the spec. 
Because of the IPR implications, that probably should also include 
contact info, just as for authors.

BR, Julian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 23 Jan 2009 09:43:23 +1300

On 2009-01-23 05:40, Julian Reschke wrote:
...
> them authors, they should be listed in a agreed-upon place in the spec.

For minor contributors, the Acknowledgments section seems appropriate,
and that follows normal practice in all kinds of publications.

> contact info, just as for authors.

That would only arise for pre-RFC5378 text that is subject to the
disclaimer clause *and* fails a "fair use" test. But it isn't much use
anyway - the contact info in almost every older RFC is obsolete.

    Brian

---

From: Theodore Tso <[email-masked]>
Date: Thu, 22 Jan 2009 16:30:12 -0500

> anyway - the contact info in almost every older RFC is obsolete.

Well, it might also be useful post RFC-5378 if there was some claim
that someone had contributed text that was copyrighted by a third
party, in violation of IETF's policies.  But in order for that to be
useful, the editor would have had to have kept the document under some
kind of source code management system, or a long, painful search of
the mailing list archives would be necessary to see *who* contributed
the text in question, so the issue of who had cribbed copyrighted text
from whom could be clarified.

And of course, you're right that contact information changes so
rapidly that it would almost certainly be obsolete.  Fom a practical
perspective, obtaining at least the e-mail address and corporate
affiliation given a particular contributor name isn't hard, at least
at the time that he/she was participating in the working group.

The hard part is knowing for example, if AT&T were to come wanting to
hunt down who was responsible for including "exit 0" in some RFC
(since as we all know that is an unpublished, proprietary source code
subject to trade secret per AT&T's Unix sources for "/bin/true" :-)
that there be some way of figuring out who was responsible for
originally contributing that specific piece of the spec.  If it turns
out that person posted the text came from an ATT.COM address, and it
could be shown that he/she was given due notice of IETF's policies,
that would of course be highly useful; but you almost need to have an
SCM or be prepared to do a huge amount of searching of mailing list
traffic and face to face meetings minutes to be able to accurately
track attributions at that granularity.

Ultimately, I suspect the list of contributors is a good and polite
thing to do out of courtesy, but it's not all that useful from an IPR
point of view.  Even if there was code that you wanted to use from a
pre-RFC5378 text, you wouldn't need or want to contact *all* the
contributors; you would want to know who contributed the portion of
the RFC containing the code that you wanted to use in an
implementation (either proprietary or open source).

							- Ted

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 23 Jan 2009 10:49:01 +1300

On 2009-01-23 10:30, Theodore Tso wrote:
...
> implementation (either proprietary or open source).

To be clear about the case of code: the right to use code was already
granted under the old rules; it's the right to use non-code text in
non-IETF derivative works that is made possible by the new rules.

RFC3978 and RFC3667 include:
      "(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..."

There's also a clause in the RFC2026 copyright boilerplate that can be
interpreted to allow code re-use (note the reference to implementation):
         "derivative works that comment on or
         otherwise explain it or assist in its implmentation may be
         prepared, copied, published and distributed, in whole or in
         part, without restriction of any kind"

    Brian

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 23 Jan 2009 11:20:25 +0100

>           or code fragments that are included in any IETF Document..."

Those right are not granted to "third parties", only to the ISOC/IETF.
The section before the paragraph you quote from RFC 3978 begins with:

   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:

So I disagree that the right to use code was already granted under RFC
3978.  In fact, I believe this was one of the main flaws with RFC 3978.

/Simon

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 24 Jan 2009 10:56:02 +1300

Simon,

My recollection, without doing an archive search, is that our counsel
took the opposite view, i.e. that the parenthesis expanded the scope
beyond "ISOC and the IETF". IANAL and YMMV.

    Brian

On 2009-01-23 23:20, Simon Josefsson wrote:
> Brian E Carpenter <[email-masked]> writes:
> 
>> Ted,
>>

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 24 Jan 2009 01:15:05 +0100

> beyond "ISOC and the IETF". IANAL and YMMV.

Ah, I didn't recall the IETF counsel had made that analysis.  When the
FSF's license team reviewed the same license text, they came to the
conclusion that it didn't grant sufficient rights for third parties.
Others are free to make their own analysis of the RFC 3978 license, of
course, but I think this shows that there are different ways to
interpret it.  Thus, Ted's original dilemma is still present.

This is a parenthesis to the bigger discussion, and I think I have said
enough on this point now.

Thanks,
Simon

---

From: Dean Willis <[email-masked]>
Date: Thu, 29 Jan 2009 00:45:45 -0600

On Jan 21, 2009, at 12:16 PM, Bob Braden wrote:

> At 11:58 PM 1/20/2009, Dean Willis wrote:
>
>
>
>
>

Yes, 5 is the number I should have said, and I'll accept your  
description of the history involved. Note my use of the term "alleged"  
in ascribing the origin to RFCEd; it is what I recall my AD telling me  
at the time. As the judge might say, this is "hearsay", and  
inadmissible in court ;-).

> those listed in the Contributors sections as having equal copyrights  
> to those named on
> the front page.  (Maybe the Contributors section ought to come early  
> in the RFC, rather

I concur that Contributors need to be considered from a copyright/IPR  
perspective.

The problem is that every RFC I'm aware of that was produced by a  
working contains tens to hundreds of contributions made either on- 
list, off-list (direct to an editor, or indirectly through another  
contributor and onto an editor) or made verbally, possibly at a  
microphone, possibly in a hallway discussion, or possibly at a meeting  
of an entirely different SDO, such as 3GPP or OMA, and relayed  
directly or indirectly into IETF.

We don't track these in the Author's section, and generally only the  
most vigorous of such contributors are noted as Contributors in common  
practice. We might have to change this, and Theo has outlined one  
procedure for doing so using source-control, although we'd need to  
extend this to cover the additional contribution channels (which could  
be really hard).

While NEW contributions brought into IETF might ostensibly be covered  
by our "Note Well", it seems that this would NOT apply to any document  
currently in-progress, or any document derived from a pre-5378 document.

Consequently, the only way to develop a document that I could sign off  
as being "RFC 5378 compliant" in the fullest sense would be clean-room  
development; that is, it would have to be started post-5378, copy no  
text from pre-5378 documents (or external specifications), and have  
the provenance of every contribution to the document carefully  
recorded for the purpose of tracking the assignment and assignability  
of rights related to that contribution. Even then, it could get foiled  
by somebody accidentally including a blurb overheard at a 3GPP  
meeting; while this might protect the IETF's liability, it could still  
taint the document. Of course, that's nothing new, and we've lived  
with that aspect so far.

Otherwise said, since we don't have a record of the contributions made  
to pre-5378 documents, we can never be sure that the rights necessary  
to publish the document with a full assignment-of-rights ala RFC 5378  
have actually been granted. At best, we can assume that the untracked  
contributions were made under the IPR terms of the time, which  
obviously have a lesser scope than RFC 5378. So the only thing we can  
do with any documents that were discussed on-list, a a meeting, or  
otherwise contain pre-5378 contributions is to publish them with a  
restricted rights statement.

Caveat: I'm not a lawyer. I professionally consult to lawyers about  
technical aspects of intellectual property, and this whole thing makes  
my head throb worse than tensor calculus. I hope I'm completely wrong  
about everything I think I understand.

--
Dean