Subject: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary

From: IETF Chair <[email-masked]>
Date: Thu, 11 Dec 2008 14:48:32 -0800 (PST)

During the IETF 73 Plenary, Sam Hartman asked some questions about the
recent updates to the IETF IPR policy.  Before responding to Sam's
question, it will be important to provide context about the recently
approved IPR policy.  The policy has two components, each governed by
different documents.

RIGHTS GRANTED BY IETF CONTRIBUTORS TO THE IETF TRUST

Under the previous IPR policy (most recently, RFC 3978), all contributors
were required to grant broad, perpetual licenses to all IETF participants,
for use of their contributions in the IETF Standards Process.  Under the
updated IPR policy, which is a product of the concluded IPR WG and
published as RFC 5378, contributors to the IETF are required to grant a
few additional rights.  The rights to IETF contributions are held by the
IETF Trust, and the additional rights cover cases beyond the IETF
Standards Process.  One fairly recent example where the IETF Trust could
have made use of these additional rights, had they existed at the time,
was the transition of a MIB that was developed in the IETF to IEEE 802.1
for maintenance.  Since these right were unavailable, IEEE 802.1 was asked
to contact each of the authors of the RFCs that contained the MIB to
obtain the necessary rights.

RIGHTS GRANTED BY THE IETF TRUST

The IPR WG asked the Trustees of the IETF Trust to construct licenses
that grant the rights needed for the IETF Standards Process and rights for
the use of code included in IETF contributions.  This request is
documented in RFC 5377.  The Trustees of the IETF Trust generated a
license for each situation, one for text and another one for code.  These
licenses can be found at http://trustee.ietf.org/license-info.

The text license grants a broad, perpetual license to all IETF
participants, for use of their contributions in the IETF Standards Process
and also allows the reproduction and translation of IETF Documents in
full, as well as excerpting from IETF Documents with certain requirements
of attribution.

The code license grants right to copy and modify code.  This is a
practical matter; code often needs modification to run in a particular
environment, and this license permits these modifications.

BACKGROUND FOR SAM'S QUESTION

As described above, prior to the publication of RFC 5378 authors did not
grant the IETF a license to modify their IETF contributions outside the
IETF Standards Process.  The IPR Working Group fixed this situation with
the new IPR structure.

RFC 5378 is an approved BCP, and it took effect the day that it was
published: 10 November 2008.  This action was not taken by the Trustees of
the IETF Trust.  This action was taken by the IETF community in the same
way that all process BCPs are approved.  In this case, that included
significant discussion within the IPR WG, significant discussion within
the IETF during Last Call, followed by IESG evaluation and approval.

When a someone makes a contribution to the IETF, for example by
submitting a Internet-Draft, they are required to make a representation
that they have all rights necessary to make that contribution and grant to
the IETF Trust all of the rights described in RFC 5378.  In most cases, a
contributor can make this representation without any problem for their own
work.  A contributor can also make this representation as to modifications
of older work, but only insofar as the original contributor granted rights
to IETF.  If the older work was contributed prior to RFC 5378, then the
original contributor granted IETF an unlimited license to use the that
older work in the IETF Standards Process; however, the new contributor is
required to grant the IETF Trust some additional rights.  The new
contributor is required to grant the IETF Trust a license that permits the
IETF Trust to give a license for modification outside the IETF Standards
Process.

SAM'S QUESTION

What does a contributor do in the situation when then want to build on an
older work that was contributed prior to RFC 5378?

In short, the contributor must obtain the additional rights from the
original contributor.  A form is being developed to assist in this task. 
There is no requirement that the form be used, but it will be available
shortly for anyone that chooses to make use of it.

BOILERPLATE AND NOTE WELL

As part of the IPR policy upgrade, the boilerplate and the IETF Note Well
text have been updated.

The updated boilerplate will be required on I-D submissions beginning 16
December 2008.  This boilerplate simply provides a pointer to the current
IPR policy.  Posting with the older boilerplate was allowed from 10
November 2008 through 15 December 2008 to facilitate document template
updates.  Regardless of the boilerplate that was used on a particular
contribution, the BCPs determine the IPR policy that applies, not the
boilerplate.

In other words, all contributions by participants after publication of
RFC 5378 are granting the Trust the license allow modification of their
IETF contributions outside the IETF Standards Process, but only in the
limited circumstances deemed by the IETF Trust to be consistent with the
wishes of the IETF community.

Likewise, the IETF Note Well text has been updated to reflect pointers to
the current IPR policy.

I hope this clarifies the situation.

Your General Area Director,
   Russ

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

---

From: John C Klensin <[email-masked]>
Date: Thu, 11 Dec 2008 18:40:00 -0500

--On Thursday, 11 December, 2008 14:48 -0800 IETF Chair
<[email-masked]> wrote:

> During the IETF 73 Plenary, Sam Hartman asked some questions
> about the recent updates to the IETF IPR policy.  Before
> responding to Sam's question, it will be important to provide
>...
> The updated boilerplate will be required on I-D submissions
> beginning 16 December 2008.  This boilerplate simply provides
> a pointer to the current IPR policy.  Posting with the older
> boilerplate was allowed from 10 November 2008 through 15
> December 2008 to facilitate document template updates.
> Regardless of the boilerplate that was used on a particular
> contribution, the BCPs determine the IPR policy that applies,
> not the boilerplate.

I just want to be sure that I understand this.

A question was asked during the Plenary that the Trustees
believed was significant enough to require further
investigation.  During that investigation, the IAD indicated, in
a fairly public way, that the boilerplate and/or the text to
which it pointed might change as the result of those
discussions, that people should not hastily start modifying
tools, and that a final announcement would be made when the
Trustees reached a final conclusion.

I assume this is that announcement.

Is that correct so far?

So, given that, the Trustees now believe that it is reasonable
to [re] impose a deadline that gives the community two working
days (it is already well into December 12 in much of the world)
to modify and update tools to incorporate the new boilerplate.

Do the Trustees/ IAOC believe that is reasonable?  Do you
believe it is necessary?

If members of the community who are responsible for the relevant
tools and/or templates conclude that it is not realistic and
consistent with other schedules and commitments to meet that
schedule, is the best option available to them to appeal this
action and, if so, to whom should the appeal be addressed?

thanks,
   john

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 12 Dec 2008 11:43:39 +0100

IETF Chair <[email-masked]> writes:

> original contributor.

Doesn't that make it possible for copyright holders to make it difficult
for the IETF to update older standards?

Let's consider if company X participated as editor, or merely a major
contributor, to document Y five years ago.  Today competitor Z is
critically dependent on this technology.  Company X no longer builds
products using Y technology.  I could see how company X would not see
any point in granting Z any rights to update the IETF standard in this
situation.  To update Y you will need to rewrite the entire document, to
avoid copyright tainting.

This seems like a serious problem with the new policy to me.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 12 Dec 2008 11:49:28 +0100

> In short, the contributor must obtain the additional rights from the

To my knowledge, there has never been a requirement to document all
copyright holders of material in documents approved under RFC 2026 or
RFC 3978.  There is wording that require "all major contributors" to be
mentioned, but it seems possible that some part of a document is
copyrightable but not be a major contribution.

So, how would you actually know which old contributors to contact?

Any what if the contributor is deceased?

It would be very useful if the IAOC/Trust develop, together with legal
aid, guiding instructions for this situation.  It would answer the
common questions.  It seems applicable to a lot of work that will happen
in the next 5 years: updating any RFC issues prior to RFC 5378.

/Simon

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 12 Dec 2008 08:51:24 -0500

> So, how would you actually know which old contributors to contact?

One of my general principles is that engineers should not try to be  
lawyers, and I am dubious about any attempt to make IETF contributors  
obtain licenses from third parties.

While this has been argued to death, here is what I propose :

Contributors of IETF material should represent that one or more of 3  
conditions apply to any particular contribution:

1.) There is no material in this contribution from pre-RFC5378 work.

2.) There is material in this contribution from pre-RFC5378 work by  
one or more of the
current set of authors, and they hereby license this older material  
under the current conditions.

3.) There is material in this contribution from pre-RFC5378 work and  
the license status of that material may not be consistent with RFC5378.

Number 3 is for the cases where the previous authors were different,  
or where the current authors do not own their previous work, and is in  
either case intended to flag the contribution as
possibly one needing attention by the Trust. Note that # 2 and #3 are  
not mutually exclusive, and obviously the Trust Counsel would need to  
pass any actual wording.

This would shift any work to obtain earlier licenses onto the Trust  
and the Trust Counsel, where in my opinion it belongs. This would also  
serve the useful purpose of automatically obtaining licenses from  
people who are just reusing their own work (if they are in a position  
to grant such a license).

Regards
Marshall

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 12 Dec 2008 15:51:17 +0100

Marshall Eubanks <[email-masked]> writes:

> While this has been argued to death

I disagree.  The issue was raised only few weeks ago, and this e-mail
thread is (as far as I have seen) the first where the problem has bee
re-stated in an e-mail to any public IETF list.

> the license status of that material may not be consistent with

I like this.

> possibly one needing attention by the Trust.

For # 3 it means that the Trust cannot sub-license it without contacting
the original contributors.  For all IETF internal purposes, there
shouldn't be any problem.

> Note that # 2 and #3 are not mutually exclusive, and obviously the
> Trust Counsel would need to pass any actual wording.

I believe even # 2 may need consideration by the trust, in case the
pre-RFC5378 work contain copyrightable material written by others.

> to grant such a license).

Indeed.

/Simon

---

From: John C Klensin <[email-masked]>
Date: Fri, 12 Dec 2008 10:10:43 -0500

Let's do keep in mind that the license permission for reuse in
IETF work has existed explicitly since RFC 2026 (1996) and
implicitly for a long time before that.   So, again for IETF
work, the notion of having to either contact a lot of people to
get permission or to completely rewrite is just not an issue, at
least for documents that have been originated or revised since
1996.

There is a gray area for "code" materials last published before
1996, but I suggest that they are few enough for the Trust to
deal with on a special-case basis.  That is, I assume, one of
the reasons the IPR WG gave the Trust some flexibility.

Given that, Marshall, your proposal essentially requires the
Trust (and potentially Counsel) to do considerable work on
behalf of hypothetical third parties who might want to make
non-IETF use of some IETF materials.  As someone who is getting
very sensitive to the rapidly rising costs of IETF registration
fees and other participation expenses, especially against the
background of deteriorating economies, I see no reason why I, or
any IETF participant who is not directly interested in the use
of those materials for non-IETF purposes, should pay for that
type of author-tracking-down and license-obtaining activity.   I
don't care how low that marginal cost is given volunteer time
from Trustees and pro bono work from Counsel; if it adds only
USD 10 to the meeting fees, it is far too much.   If someone
feels as need to reuse text that is not under the Trust's
control, let them incur the expense.

   john

p.s. I would not personally object to the Trust's imposing a
hefty copyright licensing fee on anyone who wanted to use
materials outside the IETF process, hefty enough to cover the
costs of what you have proposed and leave a significant safety
margin.  But that would clearly be inconsistent with the intent
of both the IPR WG generally and those who argued most strongly
for the Trust to have these rights in particular.

--On Friday, 12 December, 2008 08:51 -0500 Marshall Eubanks
<[email-masked]> wrote:

>...
> One of my general principles is that engineers should not try
> to be lawyers, and I am dubious about any attempt to make IETF
> contributors obtain licenses from third parties.
>...
> This would shift any work to obtain earlier licenses onto the
> Trust and the Trust Counsel, where in my opinion it belongs.
> This would also serve the useful purpose of automatically
> obtaining licenses from people who are just reusing their own
> work (if they are in a position to grant such a license).

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 12 Dec 2008 10:34:20 -0500

Dear John;

> least for documents that have been originated or revised since

But isn't that what Russ's statement would impose ? As I read it, it  
puts the
onus on the authors to "obtain the additional rights from the original  
contributor."

I think that in practice this requirement, if enacted, would lead to a  
lot of cosmetic
rewriting of old text.

> non-IETF use of some IETF materials.

Why ? I was trying to propose a means to alert the Trust to the  
potential of this work being required.
If no one requests it, why do anything ? If they should, at least the  
Trust would have an idea as to
whether or not they had these rights to give.

As to whether the Trust should pay for this, or someone else,  
shouldn't that be determined on a case by case basis ?

> As someone who is getting

I agree with you in principle, but that seems orthogonal to the  
question of what the author's of current
work should be doing.

Regards
Marshall

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 12 Dec 2008 10:36:10 -0500

Let us be quite clear.  The question of rights in pre-existing material 
is not a new question.  It is inherent in any effort to increase the 
rights granted to the trust.  While I can not assert what members of the 
WG or the community at last call understood, there is actually text in 
RFC 5377 that talks about the fact that there is a need to acquire 
suitable rights to older material.

Given that the VAST majority of IETF work is work on existing documents, 
and given that authors and author's companies change frequently, if we 
do not insist that all work be under the new rules we will have 
essentially failed to increase the rights grant.  As such, folks who use 
our material will not be able to make use of it in all the ways we intend.

Hence, my personal conclusion is that for the trust to have arrived any 
any enforcement policy other than the one they did would have seemed to 
me to be a case of the trust contravening the stated intention of the 
IETF, as captured in the RFCs.

Yours,
Joel M. Halpern

PS: TO be quite clear, the question of whether the enforcement date is 
December 12 2008, February 29, 2009, or April 1, 2009 is not a matter of 
meeting the IETF stated policy, but rather a question of the best way to 
meet that.  The only reason I am not more concerned by the date is the 
fact that as a practical matter the bulk of I-D authors will actually 
have until late February to get the rights sorted out.

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 12 Dec 2008 19:28:20 +0100

> least for documents that have been originated or revised since

That conflicts sharply with how I read Russ' answer "the contributor
must obtain the additional rights from the original contributor".

I wish you were right.  I was surprised by the conclusion in the initial
e-mail in this thread.  I had believed all along that the IETF had
sufficient rights to allow re-use of IETF documents within the IETF
standard.  I hope further explanation of the legal situation will give
us more information.

> the reasons the IPR WG gave the Trust some flexibility.

I don't see how this has anything to do with code vs text separation.
The issue applies equally to code and text written before pre-RFC5378.
There is nothing in Russ' note to suggest that this is related to only
code, nor was this an aspect brought up by Sam.  I listened to the
recorded plenary a few days ago to remember the details.

> non-IETF use of some IETF materials.

No.  As far as I understand, I can no longer take RFC 4398, fix some
minor problem, and re-submit it as a RFC 4398bis.  Even though I was
editor of RFC 4398.  The reason is that some material in that document
was written by others.  At least, I cannot do this, without getting
permission from the other people who wrote the initial document.  I wish
this is mistaken and that someone can explain how to reconcile this
example with what Russ wrote.

/Simon

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 12 Dec 2008 14:37:38 -0500

> standard.  I hope further explanation of the legal situation will give

My understanding (and IANAL and Jorge is welcome to correct me) is  
that the IETF
does indeed have "sufficient rights to allow re-use of IETF documents  
within the IETF", and
that this is purely concerned with the power of granting modification  
rights to other parties.

This is not a very common occurrence as far as I can tell, and so in  
some sense
this is a corner case.

Regards
Marshall

---

From: "Bill Fenner" <[email-masked]>
Date: Fri, 12 Dec 2008 11:39:56 -0800

On Thu, Dec 11, 2008 at 3:40 PM, John C Klensin <[email-masked]> wrote:
> ... the Trustees now believe that it is reasonable

They gave one working day of notice that they expected the tools to be
updated to begin accepting the new boilerplate last month, so this
notification is at least twice as reasonable.

  Bill

---

From: Russ Housley <[email-masked]>
Date: Fri, 12 Dec 2008 14:20:23 -0500

At 01:28 PM 12/12/2008, Simon Josefsson wrote:

>As far as I understand, I can no longer take RFC 4398, fix some

Correct.  RFC 5378 imposes this burden on the contributor.  All of 
the rights needed to make updates to the document within the IETF 
Standards Process are clearly already available, but the contributor 
is required to obtain the additional rights that are required by RFC 5378.

Russ

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 12 Dec 2008 20:54:02 +0100

Russ Housley <[email-masked]> writes:

> Correct.  RFC 5378 imposes this burden on the contributor.  All of the
> rights needed to make updates to the document within the IETF

Interesting.  Thanks for confirming the interpretation.

/Simon

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 13 Dec 2008 08:56:48 +1300

I hereby extend the rights in my contributions that I have personally
granted in the past to the IETF and to the IETF Trust to include
the additional rights required by RFC5378. Obviously by doing so,
I cannot extend the rights granted by my various employers.

I'm going to print the updated license from http://trustee.ietf.org/authorlic.html
and sign it and send it in. (My name is there because I signed
the older version.)

I'm disappointed at how few people have signed up. Even people who've
been active in this debate haven't signed up to the old version.
We should surely all be signing up to the new version, if we've ever
made any kind of contribution in the past. We should all be pressing
our employers to sign up.

The problem that Sam raised will become a minor concern if the vast
majority of us sign up.

   Brian Carpenter

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 13 Dec 2008 08:59:39 +1300

On 2008-12-12 12:40, John C Klensin wrote:
...
> to modify and update tools to incorporate the new boilerplate.

On a purely practical note, http://xml.resource.org/experimental.html
works just fine (thanks to Bill Fenner).

    Brian

---

From: Russ Housley <[email-masked]>
Date: Fri, 12 Dec 2008 15:12:45 -0500

>notification is at least twice as reasonable.

I do not understand these comments.  The Trustees are simply 
implementing the policy in RFC 5378 and the guidance given to them in 
RFC 5377.  The only change to the boilerplate is the one that was 
already announced.  The old boilerplate will no longer be accepted as 
of 16 December 2008, which is the same schedule that was announced earlier.

Russ

---

From: Russ Housley <[email-masked]>
Date: Fri, 12 Dec 2008 15:07:25 -0500

Marshall:

>does indeed have "sufficient rights to allow re-use of IETF 
>documents within the IETF", and
>that this is purely concerned with the power of granting 
>modification rights to other parties.
>

You are correct that the rights for the IETF Standards Process are 
already in place, at least for every contribution made after RFC 2026 
was published.  However, RFC 5378 does not include a provision for a 
contribution that does not grant all of the required rights.

Even if the IETF Trust were to never make use of any rights beyond 
the IETF Standards Process, these additional rights must be granted 
under the requirements of RFC 5378.  If a person cannot obtain the 
necessary rights, then that person cannot make a contribution to the 
IETF.  This was the consensus of the IPR WG and the IETF, and the 
IETF is now operating under the resulting process BCP.

Russ

---

From: John C Klensin <[email-masked]>
Date: Fri, 12 Dec 2008 15:42:28 -0500

--On Friday, 12 December, 2008 14:20 -0500 Russ Housley
<[email-masked]> wrote:

>> As far as I understand, I can no longer take RFC 4398, fix
>> some minor problem, and re-submit it as a RFC 4398bis.  Even
>> though I was editor of RFC 4398.  The reason is that some
>> material in that document was written by others.  At least, I
>> cannot do this, without getting permission from the other
>> people who wrote the initial document.  I wish this is
>> mistaken and that someone can explain how to reconcile this
> Correct.  RFC 5378 imposes this burden on the contributor.
> All of the rights needed to make updates to the document
> within the IETF Standards Process are clearly already
> available, but the contributor is required to obtain the
> additional rights that are required by RFC 5378.

Russ,

If you are correct then we should all put Tuesday on our
calendars as "the IETF grinds abruptly to a halt day".

This was almost certainly not what the IPR WG intended.  I am
nearly certain that group never discussed the possibility that
the expansion of rights granted to the IETF Trust would
constrain the ability of the IETF to utilize work traditionally
available to the IETF by effectively blocking I-D publication of
something for which those broader rights could no t be
completely and easily obtained.

While I did not anticipate this one (or anything else nearly
this drastic), participants in the IPR WG will recall that some
small number of us raised questions about whether the WG
understood the implications of "incoming" well enough for
consensus on it to be meaningful and whether it was actually
workable in practice.  That view obviously did not prevail in
the WG.

To take an example that is somewhat more immediate than Simon's,
I had planned to get rfc5321bis posted before the end of the
year.  5321 contains text from 2821 which, in turn was taken
from 821.  If I have to obtain the rights called for by 5378
from the author of 821 in order to post a 5321bis/2821ter
draft... well, I'm pretty sure I don't know how to accomplish
that, so that project is immediately dropped and stays dropped
forever.

Certainly that was not what the IPR WG intended, regardless of
whatever can be said about its consensus about the documents.
Even more certainly, the IPR WG was not advised by Counsel (a
listed co-author of 5378) of this particular implication of its
work.

At least some of us believed, apparently naively, that Section
2.1 of what became 5378 implied that it would be possible to
post an I-D (and ultimately publish an RFC) that contained old
material by transferring rights in _new_ material to the IETF
Trust but leaving the material carried forward under the
original license of use for IETF purposes.   If that is not the
intended interpretation, then are, IMO, in big, perhaps fatal,
trouble.

It is just my personal opinion, but I think the IESG and IAOC
had better figure out a way to untangle this mess, if necessary
by generating a pro-forma blocking appeal to yourselves on the
grounds of unintended consequences.  As far as I can tell, you
have one working day :-(

     john

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 12 Dec 2008 12:46:07 -0800

At 8:56 AM +1300 12/13/08, Brian E Carpenter wrote:
>I'm disappointed at how few people have signed up.

+1. The Trust even had cookies in the room when I signed my old form. New form is on the way to them.

--Paul Hoffman, Director
--VPN Consortium

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 13 Dec 2008 09:49:09 +1300

On 2008-12-13 08:20, Russ Housley wrote:
> rights needed to make updates to the document within the IETF Standards
> Process are clearly already available, but the contributor is required
> to obtain the additional rights that are required by RFC 5378.

Formally yes. But the Trust can take the sting out of this by
a vigorous effort to get former contributors to sign over the
necessary rights, and by providing a convenient method for
this to be done.

     Brian

---

From: [email-masked] (Scott O. Bradner)
Date: Fri, 12 Dec 2008 15:50:25 -0500 (EST)

> been active in this debate haven't signed up to the old version.

I signed the old form (on paper) and handed it in a while
back but do not see my name on the list -- did a bit get
dropped somewhere?

Scott

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 12 Dec 2008 22:00:23 +0100

> necessary rights, and by providing a convenient method for

Really?

As far as I read the form in [1], it will give the IETF Trust the rights
to your document.  It does not give IETF participants any rights.  And
it is the IETF participants that will need to be able to grant the Trust
these rights in order to submit a document, according to RFC 5378.

What appears to be missing is a grant from the IETF Trust to IETF
Participants for the documents signed over to them using the form.

The legal provisions in [2] does not appear to provide this grant-back.
It only grants rights to IETF participants to documents that are
submitted after the effective date:

  The licenses granted by the IETF Trust pursuant to these Legal
  Provisions apply only with respect to (i) IETF Contributions
  (including Internet-Drafts) that are submitted to the IETF following
  the Effective Date, and (ii) IETF RFCs and other IETF Documents that
  are published after the Effective Date.

Further:

  d.  In most cases, rights to Pre-Existing IETF Documents that are not
  expressly granted under these RFCs can only be obtained by requesting
  such rights directly from the document authors. The IETF Trust and the
  Internet Society do not become involved in making such requests to
  document authors.

/Simon

[1]
http://trustee.ietf.org/docs/Contributor_Non-Exclusive_License_RFC5378.pdf

[2]
http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 13 Dec 2008 10:44:12 +1300

Simon,

Yes, the Trust will need to issue a license that's retroactive
for contributions whose authors have issued a retroactive
grant. But I have considerable confidence that Jorge knows
how to do that.

    Brian

---

From: TSG <[email-masked]>
Date: Sat, 13 Dec 2008 05:51:38 -0800

Russ Housley wrote:
> Even if the IETF Trust were to never make use of any rights beyond the 
> IETF Standards Process, these additional rights must be granted under 
> the requirements of RFC 5378.  If a person cannot obtain the necessary 
> rights, then that person cannot make a contribution to the IETF.  This 
> was the consensus of the IPR WG and the IETF, and the IETF is now 
> operating under the resulting process BCP.
>
> Russ
Which changes the IETF from arguably a pure R&D NPO to a IP Licensing 
House with a portfolio worth at the very least the hundreds of millions 
spent on producing it.
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com 
> Version: 8.0.176 / Virus Database: 270.9.16/1840 - Release Date: 12/9/2008 4:53 PM
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 13 Dec 2008 08:12:17 -0800

At Sat, 13 Dec 2008 09:49:09 +1300,
Brian E Carpenter wrote:
At Sat, 13 Dec 2008 09:49:09 +1300,
> necessary rights, and by providing a convenient method for

Maybe I'm missing something, but I don't see how this helps, because
we have no tracking of all the contributors to those previous
documents. So, how can the contributor know that all forme
contributors have executed those additional rights grants?

-Ekr

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 13 Dec 2008 11:12:53 -0500

>contributors have executed those additional rights grants?

Additionally, I think the major problem isn't with active contributors, but 
with people who are inactive/unreachable.

Scott K

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 13 Dec 2008 09:52:12 -0700

On Dec 12, 2008, at 1:07 PM, Russ Housley wrote:

> This was the consensus of the IPR WG and the IETF,

I doubt the IPR WG really fully thought about this or understood it.  
If someone who was deeply involved can provide definitive evidence of  
this one way or the other that would be great. I am pretty sure this  
was not widely understood when it was IETF LC and I very confident it  
was not understood by the IESG when when they approved it.

---

From: "Lawrence Rosen" <[email-masked]>
Date: Sat, 13 Dec 2008 11:04:18 -0800

> On Dec 13, 2008, at 8:52 AM, Cullen Jennings responded:

Cullen Jennings is right. I remember that the IPR WG consistently focused on
narrow issues rather than assessing the big picture.

As to Sam Hartman's original question, he is free to take any RFC and modify
it to describe the essential functions of a different industry standard
functional specification without asking anyone's permission. He needn't seek
a copyright license from IETF or from any contributor to IETF. Quite simply,
copyright doesn't apply:

   "In no case does copyright protection for an original work
   of authorship extend to any idea, procedure, process, system,
   method of operation, concept, principle, or discovery, 
   regardless of the form in which it is described, explained,
   illustrated, or embodied in such work." 17 USC 102(b).

The notion is not right, albeit that it is reflected in the current IETF IPR
policy, that a process can be in any way restricted from being improved
because someone planted a copyright notice on its essential description. An
description of a process, method of operation, etc., cannot be locked away
and prevented from amendment and improvement because of copyright. Allowing
that would subject our functional process specifications in IETF to 100-year
copyright monopolies even though there aren't even 20-year patent monopolies
that apply to that specification. Nobody owns those ideas or the essential
descriptions of those ideas; they are public domain.

So my answer to Sam's question is: I dare anyone to try and stop you or me
from taking an IETF RFC and revising it as necessary to express any new
idea, procedure, process, system, method of operation, concept, principle,
or discovery. And I dare anyone to try and stop IETF or any other standards
organization from adopting such an improvement as a revised RFC because of a
copyright notice.

/Larry

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

---

From: Julian Reschke <[email-masked]>
Date: Sat, 13 Dec 2008 20:40:30 +0100

> organization from adopting such an improvement as a revised RFC because of a

So, in the process of doing this, can I use the original RFC text?

Best regards, Julian

PS: would I need sign off from all previous contributors for the IDs I 
posted in November, <draft-ietf-httpbis-p*>? How do I find out who these 
contributors are in case they are not listed as authors?
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Scott Brim <[email-masked]>
Date: Sat, 13 Dec 2008 15:05:57 -0500

> descriptions of those ideas; they are public domain.

You can improve any technology you want, modulo IPR -- that's not the
point here.  The problem is taking existing copyrighted text and using
it as a base for describing your technology.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Christian Huitema <[email-masked]>
Date: Sat, 13 Dec 2008 13:23:21 -0800

> it as a base for describing your technology.

That's indeed the problem we stumbled upon years ago. Suppose that a contributor has written a complete description of technology X, getting it published as a 100 pages RFC. A remarkable feat, and a great contribution to the community. A few years letter, the working group realizes that they like the technology, but would like to change a couple options. That normally translates into changing a paragraph or two, resulting in a new RFC, more than 90% identical to the previous one.

Suppose now that for whatever reasons, the original author disagrees with the changes, or with the new management of the working group, or with the new editor. People are human, these things do happen. IANAL, but my understanding at the time was that the original copyright still applied to the original text, and that the working group would be left with only bad options. They could issue a delta RFC that only contained the modifications, but that is somewhat confusing for the readers. Or they could undertake a complete rewriting of the standard, but that takes a long time and is also prone to errors and confusion.

This is very much why we got the statement on copyrights in RFC 1602, in 1996. You will notice that copyrights were only mentioned as something we might need to worry about later in the appendix of the previous rules, RFC 1310 published in 1992.

-- Christian Huitema

---

From: John Levine <[email-masked]>
Date: 13 Dec 2008 21:46:25 -0000

>So my answer to Sam's question is: I dare anyone to try and stop you
>or me from taking an IETF RFC and revising it as necessary to express
>any new idea, procedure, process, system, method of operation,
>concept, principle, or discovery. And I dare anyone to try and stop
>IETF or any other standards organization from adopting such an
>improvement as a revised RFC because of a copyright notice.

You are probably right that the combination of the broad formal and
informal license that people have given for RFCs and the thin
copyright protection on descriptive technical documents would mean
that even if a disgruntled author of an old RFC sued to prevent his
words from being adapted in a new RFC, he'd eventually lose.

But I sure don't want to pay for the lawsuit to find out.

The only way I can currently see out of this mess is for the IETF or
the IETF Trust to take it upon itself to get new licenses from as many
old authors or their heirs as it can.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 14 Dec 2008 12:15:04 +1300

...
>> contributors have executed those additional rights grants?

I would expect the original authors' agreement to be sufficient to
cover this, with any residual text fragments from unnamed contributors
being considered fair use. IANAL.

> with people who are inactive/unreachable.

Sure. I won't let this ruin my day, but I do expect the Trust to
add some appropriate waiver text to the outgoing license, so that
I can submit recycled text under RFC5378 with a clear conscience.

> it as a base for describing your technology.

But remember, it's only a problem for doing so *outside* the IETF
process (which is why it's the Trust's outgoing license that has
to deal with this).

    Brian

---

From: "AJ Jaghori" <[email-masked]>
Date: Sat, 13 Dec 2008 21:43:25 -0500

Modifying an author's original work without specified permission;
regardless of new findings, constitutes a copyright infringement.

On 12/13/08, Christian Huitema <[email-masked]> wrote:
> That's indeed the problem we stumbled upon years ago. Suppose that a
> contributor has written a complete description of technology X, getting it
> published as a 100 pages RFC. A remarkable feat, and a great contribution to
> the community. A few years letter, the working group realizes that they like
> the technology, but would like to change a couple options. That normally
> translates into changing a paragraph or two, resulting in a new RFC, more
> than 90% identical to the previous one.
>
> Suppose now that for whatever reasons, the original author disagrees with
> the changes, or with the new management of the working group, or with the
> new editor. People are human, these things do happen. IANAL, but my
> understanding at the time was that the original copyright still applied to
> the original text, and that the working group would be left with only bad
> options. They could issue a delta RFC that only contained the modifications,
> but that is somewhat confusing for the readers. Or they could undertake a
> complete rewriting of the standard, but that takes a long time and is also
> prone to errors and confusion.
>
> This is very much why we got the statement on copyrights in RFC 1602, in
> 1996. You will notice that copyrights were only mentioned as something we
> might need to worry about later in the appendix of the previous rules, RFC
> 1310 published in 1992.
>
> -- Christian Huitema
>
>

-- 
AJ Jaghori
Chief Network Architect | Author | Professor
[email-masked]
M: 703.362.5002
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 15 Dec 2008 11:14:48 +0100

> regardless of new findings, constitutes a copyright infringement.

Sure, but the old RFC copyright license (e.g., RFC 2026 and RFC 3978)
gave IETF participants the necessary rights to allow modifications of
earlier IETF work within the IETF standard process.  The new one
doesn't, and the consequences of that situation is what's discussed.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 15 Dec 2008 14:07:41 +0100

Cullen Jennings <[email-masked]> writes:

> I doubt the IPR WG really fully thought about this or understood
> it. If someone who was deeply involved can provide definitive evidence
> of  this one way or the other that would be great. I am pretty sure
> this  was not widely understood when it was IETF LC and I very
> confident it  was not understood by the IESG when when they approved
> it.

I agree.  I don't recall discussions that the intention was that the
documents would require IETF participants to contact earlier IETF
contributors about transferring rights to the Trust.  I believe the
intention was to maintain status quo in this area, i.e., to allow IETF
participants to freely re-use IETF documents within the IETF standards
process.

Given the complexity of the documents, I'm not surprised there are
unforeseen consequences like this.  Unfortunately, the problems I
brought up with the old copyright policy did not lead to discussions of
how to reduce complexity.  Instead, more complexity was added to work
around identified problems.

/Simon

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 15 Dec 2008 18:11:26 -0500

> doesn't, and the consequences of that situation is what's discussed.

My understanding (IANAL and other warning apply) is that the new
license does do this, inside the IETF. It's grants to other  
organizations which is the issue.

Regards
Marshall

---

From: Martin Duerst <[email-masked]>
Date: Tue, 16 Dec 2008 12:12:42 +0900

>and sign it and send it in. (My name is there because I signed

Oh, so you're saying that we have a list of names where we don't
really know who signed what (the older or the newer version)?
I hope that can be fixed! (well, the easiest way to fix it would
be for all those already on the list to upgrade :-)

Regards,    Martin.

>The problem that Sam raised will become a minor concern if the vast

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

---

From: Martin Duerst <[email-masked]>
Date: Tue, 16 Dec 2008 12:07:30 +0900

>and sign it and send it in. (My name is there because I signed

Thanks for the pointer. However, it would be helpful if that
page contained *short and simple* instructions on how to proceed
with signing, e.g. along the following lines:

- Print out licence (two copies? (2))
- Sign (on the "By" line, puting your name in print on the "Name" line
  and the date you signed on the "Date" line) (1) (two copies?)
- Send to: [exact address of IETF Trust]
- You will get back a copy signed by Ray in a few weeks. (2)

(1) Especially the meaning of the "By" line won't be clear to
    people not from the US/not speaking English as their mother tongue.
(2) It's unclear whether two copies are needed, and whether we'll
    get something back,...

Regards,    Martin.

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 16 Dec 2008 10:26:28 -0800

Cullen Jennings wrote:
> I doubt the IPR WG really fully thought about this or understood it. If 
> someone who was deeply involved can provide definitive evidence of this 
> one way or the other that would be great. I am pretty sure this was not 
> widely understood when it was IETF LC and I very confident it was not 
> understood by the IESG when when they approved it.

Indeed.  But more importantly, this sub-thread naturally and inevitably reduces 
down to an infinite, entirely unproductive finger-pointing game.

We have a reality that the new IPR rules are fundamentally problematic.  Prior 
to their imposition, we had a functioning system.  Now we don't.

And the only thing that changed was imposition of the new rules.  Nothing else 
happened.

The proposals are mostly about adding another layer of 'fix' to what was 
supposed, itself, to be an incremental fix.  The odds that we will get that 
additional layer wrong are demonstrably high.

We should, instead, re-invoke the previous rules, until we figure out how to 
make the correct changes.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: John C Klensin <[email-masked]>
Date: Tue, 16 Dec 2008 16:19:56 -0500

Dave,

--On Tuesday, 16 December, 2008 10:26 -0800 Dave CROCKER
<[email-masked]> wrote:

> Indeed.  But more importantly, this sub-thread naturally and
> inevitably reduces down to an infinite, entirely unproductive
> finger-pointing game.

For various reasons, I don't believe that game is infinite.  I
believe that we all had the opportunity to identify these
problems during Last Call or earlier and that no one did a
careful enough review.  That means that the finger points to
either everyone participating in the IETF or to the fundamental
process we use to review and approve this type of documents.
Neither is infinite, but it makes the exercise even more
non-productive.

> We have a reality that the new IPR rules are fundamentally
> problematic.  Prior to their imposition, we had a functioning
> system.  Now we don't.
> 
> And the only thing that changed was imposition of the new
> rules.  Nothing else happened.
> 
> The proposals are mostly about adding another layer of 'fix'
> to what was supposed, itself, to be an incremental fix.  The
> odds that we will get that additional layer wrong are
> demonstrably high.

And that is precisely why my I-D turns things into a choice
between new rules and old rules, based only on the conclusion of
the submitter about what is important... and why it does not
attempt to "fix" 5378.  I agree with you about the odds of
getting an additional layer right, especially so if we try to do
it quickly.

> We should, instead, re-invoke the previous rules, until we
> figure out how to make the correct changes.

Yes, "just suspend 5378 until we get this sorted out and then,
if necessary, repeal it and start over" did occur to me.  I
tried to suggest last week that the IAOC and Trustees figure out
a way to do just that, if necessary generating a pro-forma
appeal of something that would permit the IESG to take an
equivalent action.  If I correctly understand the responses we
received, that wasn't believed to be possible.   The Trustees
have advice of Counsel (who is also a co-author of 5378) and I
don't in that matter, so, if they concluded that they couldn't
figure out a way to defer 5378 and reinvoke the previous rules,
I think we need to accept that and move on.

Of course, we could generate an I-D whose only substantive text
was either

	"move 5378 to historic and un-obsolete 3978 and 4749"

or

	"suspend application of 5378 until some specified
	condition happens".

I know how to write the first.  I don't know how to write the
second, but maybe someone else does.

I took the path that my I-D specifies because I concluded that
we have gotten into a place in which re-invoking the old rules
is not possible.  With the usual IANAL disclaimers, it appears
to me that we are in the following situation:

	* Documents have been posted with RFC 5378 language.
	
	* At least some of the Trustees believe, presumably on
	advice of Counsel, that RFC 5378 has been in effect
	since November 10, that everything done in the IETF
	since November 10 is covered by it, including everything
	that happened during IETF 73, and that 3978 became
	obsolete and of no effect on that date.  It appears that
	all RFCs posted after that date carry the 5378 language.
	While some of us have a bit of trouble with the logic on
	which that belief  is based, we know that legal logic is
	sometimes different from normal logic and assume that
	any controversy about 5378 effectiveness would not be
	resolved until settled by a court.   I can't speak for
	others, but I don't want to go near that solution if it
	can be avoided.
	
	* Ignoring all of the non-IETF uses for the moment, RFC
	5378 is not a linear descendant of 3978 and its
	predecessors, but a change in direction from "authors
	grant rights to the IETF and its participants" to
	"authors grant rights to the IETF Trust, which then
	grants rights back to IETF participants so we can do
	work".  If we suspend or repeal 5378 to re-invoke the
	previous rules, it appears to me that any documents
	covered by the 5378 rules fall into a strange
	never-never land in which the IETF may have _no_ rights
	to them at all.  Remembering that set of documents
	contains anything from several RFCs and I-Ds to all of
	IETF history since before IETF 73, that is an
	unattractive situation, to put it mildly.
	
	* One could argue that everything published or
	contributed between November 10 and now is still covered
	by the (old) Note Well and hence that the old rules are
	still in effect in parallel to the rules of 5378, i.e.,
	that Contributors are making both the old grant direct
	to IETF participants and the new grant to the IETF
	Trust.  That position would be a little inconsistent
	with the assertion that 3978 become obsolete when 5378
	was published and with the belief that everything done
	since November 10 is strictly covered by 5378 but,
	again, IANAL and someone who is might be able to figure
	out a way to thread that particular needle.

What I'm pretty sure of, again subject to the usual disclaimers,
is that the draft-klensin-rfc5378rev skirts those problems,
leaving us in a position that the old rules can be used for
anything that contains old text if the author thinks that is
necessary but that leaves the new rules standing and
available.... at least until we can get all of  this sorted out.

Perhaps a different way to say that is that I think our intent
is the same but that, if it is plausible that documents actually
exist to which the new rules apply and the old ones don't, the
mechanism for accomplishing  it cannot be quite as simple as
"re-invoke the previous rules".

Looking up from the bottom of the rathole,...  At least I hope
I'm at the bottom and don't have further to descend...

     john

---

From: Sam Hartman <[email-masked]>
Date: Tue, 16 Dec 2008 16:41:16 -0500

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

    >> The proposals are mostly about adding another layer of 'fix' to
    >> what was supposed, itself, to be an incremental fix.  The odds
    >> that we will get that additional layer wrong are demonstrably
    >> high.

    John> And that is precisely why my I-D turns things into a choice
    John> between new rules and old rules, based only on the
    John> conclusion of the submitter about what is important... and
    John> why it does not attempt to "fix" 5378.  I agree with you
    John> about the odds of getting an additional layer right,
    John> especially so if we try to do it quickly.

For what it is worth, I as an individual support the new rules, and believe Russ gave me a fine answer.
I would not support turning this into a choice.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: SM <[email-masked]>
Date: Tue, 16 Dec 2008 16:23:59 -0800

>believe Russ gave me a fine answer.

You asked a good question.

>I would not support turning this into a choice.

According to a message [1] posted by the IETF Chair, the updated 
boilerplate is required as from December 16.  There was a Last Call 
on December 16 for draft-ietf-sieve-managesieve.  There is a 
sub-section in that I-D that is similar to text found in RFCs on the 
Standard Track.  Previously, reuse of text as part of the Standard 
Process wasn't an issue.  One could even argue that the reuse of some 
text falls under the doctrine of "fair use".

If I were to send comments pointing out that some parts of the 
document are not in line with what RFC 5378 prescribes, the IESG may 
have to determine whether BCP 78 and BCP 79 were followed even if the 
IETF "takes no position regarding the validity or scope of any 
Intellectual Property Rights or other rights".

1. http://www.ietf.org/mail-archive/web/ietf-announce/current/msg05509.html

Regards,
-sm

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 16 Dec 2008 22:08:43 -0500

I have a very different view of this situation, and disagree wstrongly 
with John's recommended "fix" (or the equivalent fix of completely 
rolling back 5378 and 5377.)

First and foremost, it should be kept in ming by anyone reading this 
that the IPR working was convened by the then IETF chair, and continued 
by succeeding chairs because there were problems that actually needed to 
be fixed.  There are things that the community considered (and 
presumably still does consider) either necessary or important that are 
not properly addressed by the earlier documents.  This varied between a 
lack of clarity in some areas, and a lack of ability to perform 
necessary actions in other areas.
The working group was not convened just because we wanted to, or even 
because we thought we could make things "better."  If it had not 
appeared that there were significant problems, I for one would have 
taken the much easier course and just said "leave it alone."  And I am 
quite confident I am not alone.

Secondly, giving people a choice of terms is basically going to create 
confusion.  For example, one of the issues raised in the working group 
was that our previous rights grant appeared not to properly allow folks 
to modify code.  And it required them to include things in used code 
that made it hard to use that code in various contexts.  We want to see 
implementations.  We want to see accurate, interoperable 
implementations.  Using the code and tables from various RFC is 
somewhere between necessary and and desirable.
But, if we assume that the folks who were concerned were right, then if 
we give everyone a choice, anyone trying to right code using our tables, 
etc has to figure out what rights they are being granted to use any 
given RFC or I-D.
Yes, there are those who argued that there was no problem.  However, the 
WG concluded that there was at the very least significant confusion, and 
probably an actual problem.

Yes, having to get rights from folks is a pain.
But if we are not willing to push to do that, then we might as well 
consider that the rights granted to the IETF are locked in stone 
forever, and can never be upgraded, because it will never happen.

It should be understood also that some folks actually wanted us to go 
further than we did in 5377.  5378 and 5377 represent the best 
compromise we could work out.  The community is certainly free to decide 
that it doesn't want to do that.

While some folks who were there say that they feel not enough attention 
was paid to this issue, it is the case that we did discuss at least some 
of the impact, and none of what turned out to be needed surprised me.

Yours,
Joel M. Halpern

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 17 Dec 2008 08:05:55 -0800

> Yes, having to get rights from folks is a pain.

When the person is not longer available, the effect is more than discomfort.

d/
-- 

   Dave Crocker

---

From: John C Klensin <[email-masked]>
Date: Wed, 17 Dec 2008 12:16:52 -0500

--On Tuesday, 16 December, 2008 22:08 -0500 "Joel M. Halpern"
<[email-masked]> wrote:

> I have a very different view of this situation, and disagree
> wstrongly with John's recommended "fix" (or the equivalent fix
> of completely rolling back 5378 and 5377.)
> 
> First and foremost, it should be kept in ming by anyone
> reading this that the IPR working was convened by the then
> IETF chair, and continued by succeeding chairs because there
>...
> Secondly, giving people a choice of terms is basically going
> to create confusion.  For example, one of the issues raised in
> the working group was that our previous rights grant appeared
> not to properly allow folks to modify code.  And it required
> them to include things in used code that made it hard to use
>...
> But if we are not willing to push to do that, then we might as
> well consider that the rights granted to the IETF are locked
> in stone forever, and can never be upgraded, because it will
> never happen.
>...

Joel,

Let me make my personal position on this, and the reason for my
draft, clear, since it obviously was not to you (and therefore I
presume others).

I agree that there were perceived problems that needed to be
fixed.  I think you have given a good summary of most of them.
It is exactly for that reason that I did not propose rolling
back 5378 (or 5377).  My comments about that move in my response
to Dave was to point out that it was impractical, not to
advocate it even if it was.  Please read the draft.

I have two major objections to 5378 as it turned out and as I
now understand things.  The first is that there will be cases in
which obtaining permission from previous authors or contributors
is effectively impossible, rather than merely inconvenient (if
it were merely a pain, I might be annoyed, but I wouldn't be
complaining or proposing alternatives at this late date).  But
we have situations in which people have died and getting those
rights would require action of probate courts; situations in
which companies that might have controlled those rights have
gone out of business, leaving complicated (and probably
expensive-to-resolve) legal questions about who can actually
grant the rights today; and situations in which people have
departed from companies under tense circumstances and would find
it extremely difficult (not merely "a pain") to go back and ask
for additional rights for the IETF.

5378 provides no waiver mechanisms or escape hatches for those
kinds of situations.  If someone is taking it seriously, they
are left with a choice:

	(i) Go to the time and expense to obtain the rights,
	despite obstacles and, if the rights available and their
	ownership are ambiguous, assume the risks of making the
	assertions and posting the document. 
	
	(ii) Decide that the provisions of RFC 5378 are really
	not intended to be taken seriously and just go ahead and
	post the document without worrying about those
	contributors whose permission is impractical to obtain.
	
	(iii) Rewrite the document to remove any copyright
	dependencies on text whose status is uncertain or for
	which rights transfers are significantly difficult.
	
	(iv)  Take a walk and abandon the document.

Now, assuming that you think 5378 is to be taken seriously (your
note certainly implies that), I infer that you think either (i)
or (iii) will happen.  Especially after noting that rewriting
significant amounts of text creates considerable risk of
introducing errors (e.g., for technical reasons, a WG might not
stand for a rewrite even if the author/editor were willing to do
it), I am less optimistic.   Losing even a single document that
way is not, IMO, good for the IETF.  Of course, you may disagree
and believe that these new IPR rules and the way they are
structured is more important.

Second, the structure of the new rules appears to require me, as
a submitting author, to make assertions that go well beyond
anything that has been required in the past.   Prior to 5378, I
could rely on custom (and sometimes contract) since the
beginning of the RFC series and, since 2026 and certainly since
the Note Well started being used, on them to know that previous
contributors had granted rights to the IETF to do the IETF's
work.   Consequently, if, for example, I started a new draft by
incorporating pieces of a published RFC, I could reasonably
expect that the rights were in place for all prior contributions
and go ahead and submit the document with only concern about new
contributions, especially mine.  I didn't even need to know who
the previous contributors were.   

Now we are in a position in which _no_ document posted before
the beginning of last month has the 5378 rights associated with
its content unless people have generated an explicit release.
And I have to assert that I've made an effort (consistent with
someone's interpretation of what I should have known), to puzzle
out who all of the previous contributors were and to make sure I
obtain releases from them before posting anything.  We may
differ as to whether doing that is "a pain" or "a significant
obstacle", but it significantly adds to the burdens of someone
trying to write and submit a document.  And, again, if that
drives even a single useful contributor or contribution away, I
think it is bad for the IETF.  YMMD.

I think it is worth stressing that neither of those issues are
essential to the "fixes" in 5378.  They relate only to how 5378
is structured and implemented and this fairly draconian (IMO)
way to apply it to documents that contain text carried forward
from earlier documents.

There are substantive decisions reached by the WG that I
opposed.  While I have doubts about the quality of the consensus
-- doubts that this discussion is reinforcing -- I nonetheless
accept that consensus.  For that reason, I did not raise those
issues during Last Call and will not raise them now.  I consider
them settled until and unless someone else reopens them using
normal IETF procedures for reopening previously-settled issues.
I've also got some issues with the smaller details of 5378 --
things that I assume the RFC Editor should have caught-- that I
don't consider important enough to raise formally and will not
do so.

I also believe that the confusion you refer to and fear is
something we are stuck with whether people are "given choices"
or not.  If the applicability of 5378 is tied to a date, then
one needs the exact date associated with a document in order to
figure out which rules apply.  That is fairly easy with I-Ds,
but, for RFCs, requires searching the announcement archive since
RFCs bear dates only in granularity of months.  Finding that
information is no more than "a pain", but I wonder how many
obstacles we really want to put in the path of the Trust and
IETF participants getting work done.  And even if one knows
which rules apply, imposition of 5378 doesn't change the IPR
status of any earlier document, so both the Trustee and anyone
intending to use documents outside the IETF have to deal with
both (actually all) sets of rules.  The I-D does not make that
situation worse.  Indeed, by tying the rules that apply to
specific text in documents, rather than dates, it makes things
less confusing.  That issue is discussed in the draft; please
read it.

Finally, your characterization of the I-D as "giving people a
choice of terms" is not, IMO, accurate.  Someone creating a new
document, with no old text, has no choice -- the rules of 5378
apply and, to the degree to which the intent of 5378 is to get
new documents using new rules, the I-D changes nothing.  For a
document using old text, it is up to the author/submitter
whether the 5378 transfers can be obtained with a reasonable
amount of effort and then to select the alternate rules if that
seems necessary.   In my personal opinion, given the commitments
5378 requires that authors make and the risks it requires that
they assume, leaving the decision with them is the only
plausible arrangement.  Again, leaving authors without that
option simply leaves them with the choice of not posting a
revised document at all (i.e., they still have a choice but the
other choice is, IMO, clearly bad for the IETF).  One could,
instead, require some sort of formal variance procedure, but I
think it would be costly and burdensome (i.e., more than "a
pain") and that it might well create even more confusion.  This
issue is also discussed in the draft; please read it.

regards,
    john

---

From: Sam Hartman <[email-masked]>
Date: Wed, 17 Dec 2008 12:31:07 -0500

>>>>> "Dave" == Dave CROCKER <[email-masked]> writes:

    >> Yes, having to get rights from folks is a pain.

    Dave> When the person is not longer available, the effect is more
    Dave> than discomfort.

Strictly speaking, that's not actually true.  We're talking about
copyright here; you can rewrite the ideas in your own words and avoid
needing to worry about rights.  Rewriting some ideas in your own words
might involve some significant discomfort, but it is doable.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 17 Dec 2008 10:38:27 -0700

> might involve some significant discomfort, but it is doable.

Given the care with which text is often drafted within a WG and the
requirement for often hard-won consensus regarding such text, I am
skeptical that such text can be rewritten to capture the same ideas and
still retain consensus.

Peter

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 17 Dec 2008 10:01:27 -0800

Sanm,

I believe it has already been observed by others that this is not a reasonable 
scenario.

However your response does provide a good example of just how badly the latest 
model is broken.

d/

-- 

   Dave Crocker

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 17 Dec 2008 13:02:15 -0500

Dear John;

 From your email :

> 	which rights transfers are significantly difficult.

This is a dangerous solution, and may not be one at all.

My mantra on these issues is : Engineers should not try and be lawyers.
(And, lawyers should not try and be engineers.) I try to follow it  
personally, as I
am definitely not a lawyer (and, of course, I am not referring to  
anyone who is cross-trained).

But I do know this - merely rewriting a document is not necessarily  
enough to remove copyright
dependancies. J.K. Rowling, for example, won a suit against someone  
who wrote a Lexicon of
her work :

<http://www.fictionaddiction.net/Publishing-Industry-News/rowling-wins-copyright-infringement-lawsuit.html 

If this actually became an issue, it would be decided by a court, and  
I would not regard either myself or the vast
majority of IETF contributors as competent to judge how a court would  
react to any given rewriting of an RFC
if it went to trial.

Regards
Marshall

---

From: John C Klensin <[email-masked]>
Date: Wed, 17 Dec 2008 13:08:16 -0500

--On Wednesday, 17 December, 2008 12:31 -0500 Sam Hartman
<[email-masked]> wrote:

>     Dave> When the person is not longer available, the effect
> is more     Dave> than discomfort.
> 
> 
> Strictly speaking, that's not actually true.  We're talking
> about copyright here; you can rewrite the ideas in your own
> words and avoid needing to worry about rights.  Rewriting some
> ideas in your own words might involve some significant
> discomfort, but it is doable.

Well, sort of.  Let me return to my current favorite example.
My (very) crude estimate is that RFC 5321 is about 20% Jon
Postel's text.  It is a 90-ish page document, so that is 15+
pages (my arithmetic isn't bad, I'm making some guesses about
boilerplate, table of contents, etc.), not a few paragraphs to
be rewritten.  In addition, the DRUMS WG that was responsible
for 2821 and the mailing list that was responsible for 5321
repeatedly made decisions to not make unnecessary textual
changes for fear or making subtle errors.  The judgment about
the risks associated with rewrites is the sort of technical
judgment that WGs are expected to make; it isn't a copyright
matter.  I assume they would be similarly resistant to
rewriting that much text into my own words.

The bottom line is that, for many documents, the plausible
choices aren't between "incur a little pain" and "rewrite text
into one's own words".   They are between "obtain releases that
are nearly impossible to obtain without investments of
considerable time, money, and other resources" and "abandon
document".  

That is going to leave individual authors, and the IETF, with a
decision about whether the universal implementation of RFC 5378
is important enough to not advance or revise some documents.  I
don't think so.  I don't even like the idea of having to make
that choice.  YMMD

    john

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 17 Dec 2008 10:31:33 -0800

John C Klensin wrote:
> back 5378 (or 5377).  

Unfortunately, we do not get to pick and choose the parts of a problematic 
standard that we like.  The thing is in force.  We have a crisis because of it. 
  While we had some problems before it went into force, we did not have any crises.

By pursuing a path of "use whichever you want" we wind up adding more ambiguity 
and, therefore, fuzziness, to an already seriously broken situation.

Folks,

We are stuck in the midst of a classic decision-making error, revolving around 
sunk costs <http://en.wikipedia.org/wiki/Sunk_cost> which leads to persistent 
efforts to fix the unfixable.

Gosh, only a little more effort or a small band-aid here or there, will take 
away the immediate problem.

In reality, tenacity due to a desire to save the invested effort is that it 
virtually never results in a real fix.

We need to reverse the current spec, go back to the one that worked fine (for 
the cases it covered) and re-think how to handle the new stuff.

To repeat:  The idea that anyone would think it viable to have a potentially 
small -bis effort need to rewrite potentially large portions of the original 
text demonstrates just how stuck in the mire we are, with no clue how to get out.

d/
-- 

   Dave Crocker

---

From: John C Klensin <[email-masked]>
Date: Wed, 17 Dec 2008 13:20:26 -0500

Marshall,

I completely agree.  I also don't want to have us start down the
path of rewriting text: most of what the IETF produces are
technical documents, not works of fiction, and the odds
significant rewriting screwing things up are high, perhaps a
near-certainty.

I also share your dislike for provisions whose validity we can
even guess at until they end up in front of a court.   I don't
know what to do about that other that to rely on advice of
Counsel, but that doesn't stop me from preferring "this is a
well-tested approach" to "we hope it will work out this way".

But both your comments and that "can't get it right" issue just
reinforce my view that we either need an escape mechanism for
old text or need a model in which the Trust, not the submitters,
take responsibility for text Contributed to the IETF under older
rules. For the record, I don't know how to make the latter work
(partially because, like you, I try to avoid simulating a
lawyer) and am not proposing it.  But, logically, it might be
the other possibility here.

    john

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 17 Dec 2008 15:45:14 -0500

Based on the discussion I have seen, an escape mechanism for old text 
that really can not be processed otherwise is probably reasonable.
However, if we are making an effort to retain the work that was done, my 
personal take is that the barrier to that escape mechanism has to be 
high enough that it is worth-while for folks to actually try to follow 
the community agreement.

And I will happily leave it to the alwyer to tell us whose signoffs 
folks need.  (While I have guesses, they are just that.)

Joel

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 17 Dec 2008 13:05:26 -0800

John C Klensin wrote:
> lawyer) and am not proposing it.  

I have held off proposing this latter view, because I've assumed it was obvious 
and that those expert in the legal issues rejected it.

But from a practical standpoint, it is the most accurate representation of work 
done on IETF documents (within the working gorup structure.)

That is:  Working groups are part of the IETF and 'authors' of working group 
documents are acting as  when writing IETF documents.agents of the IETF.  While 
there might be underlying intellectual property owned by the companies that 
authors work for, the actual document is commissioned by, and copyright should 
be owned by, the IETF.

Let me carry it further:  When Erik Huizer and I wrote the first IETF Working 
Group Guidelines document, it was at our initiative.  (Well, really, Erik's.) 
When it was adopted by the IETF, I automatically assumed that the IETF owned it.

That is, after all, what we assert when outside technology is brought into the 
IETF and we insist that they are handing over "change control". What is change 
control if not the authority to make changes to the document?

So when Scott Bradner did the revision to the IETF Working Group Guidelines 
document the idea that he had a legal obligation to get our permission would 
have -- and certainly now does -- strike me as silly.

That's me talking as a participant, about pragmatics, not me pretending to be a 
attorney, talking about copyright law.

d/

-- 

   Dave Crocker

---

From: Keith Moore <[email-masked]>
Date: Wed, 17 Dec 2008 16:17:19 -0500

Dave CROCKER wrote:

> What is change control if not the authority to make changes to the
> document?

exactly.  or to use copyright terminology, the right to make derivative
works.

Keith

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 17 Dec 2008 13:33:45 -0800

Fred Baker wrote:
> Silly question. Is this discussion more appropriate to ietf-ipr?

Not any more.

It was.  But the result is what a number of different folk who are serious, 
long-term IETF contributors consider the current situation to be a basic crisis 
that prevents working on some existing docs.

That's pretty serious, Fred, and most certainly not something that should simply 
be referred back to the relevant working group, with instructions to fix things.

> One could argue that ietf-ipr looked at this question for two years 
> prior to submitting the new boilerplate, and by missing it made it clear 
> that they weren't adequate to review. That said, there was also an IETF 
> last call, and none of us detected the issue until Sam brought it up.

This is at least the second time someone has tried to invoke the "well, it went 
through IETF Last Call" as some sort of presumably meaningful, reference, 
presumably with respect to shared blame or shared understanding or share 
something.

We really need to stop making those observations, since they have nothing to do 
with fixing the current problem, except to warn us that whatever we did before 
didn't work adequately, in spite of extensive, diligent effort.

> But really - isn't this about IPR?

Fred, when a team produces diligent effort and a failed product, is the usual 
management response to simply ask them to try again?  That's not what I'm used 
to seeing in the real world and I'll bet it is not what anyone who work for a 
successful company is used to, either.  Especially when the effort was by folks 
working outside of their area of expertise.

Whatever it is that produced the current situation, we should try to avoid 
repeating it.

d/

-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 17 Dec 2008 13:36:06 -0800

Not any more.

d/

-- 

   Dave Crocker

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 17 Dec 2008 14:00:30 -0800

Hi -

> From: "Dave CROCKER" <[email-masked]>
> To: "John C Klensin" <[email-masked]>
> Cc: "IETF discussion list" <[email-masked]>
> Sent: Wednesday, December 17, 2008 1:05 PM
> Subject: Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary
...
> documents are acting as  when writing IETF documents.agents of the IETF.  While 

I assume the missing word is "editors"

> authors work for, the actual document is commissioned by, and copyright should 

AMEN!
 
> When it was adopted by the IETF, I automatically assumed that the IETF owned it.

That has always been my understanding regarding work I've done for the IETF.
 
> control if not the authority to make changes to the document?

Yup.
 
> have -- and certainly now does -- strike me as silly.

Particularly since the permission to create derivative works and successor
standards has been granted as part of the boilerplate for a long long time.
 
> attorney, talking about copyright law.

Ditto.  Consequently, as a WG co-chair who wants his WG to finish up 
in this century, I read RFC 5378 section 5.3 as giving working
groups what they need so they can ignore all this stuff about tracking
down long-gone contributors, and that it's merely a re-incarnation of what
has long been the intent behind the NOTE WELL text.

One can easily imagine a situation in which a disgruntled party named
as a contributor in an early version of work might refuse to give permission
under some readings of an RFC 5378 regime, effectively killing the work.
As John says, paraphrase is *not* a realistic option, especially with carefully-crafted
WG compromise text.

Randy

---

From: John C Klensin <[email-masked]>
Date: Wed, 17 Dec 2008 17:09:06 -0500

--On Wednesday, 17 December, 2008 13:05 -0800 Dave CROCKER
<[email-masked]> wrote:

> John C Klensin wrote:
>> But both your comments and that "can't get it right" issue
>> just reinforce my view that we either need an escape
>> mechanism for old text or need a model in which the Trust,
>> not the submitters, take responsibility for text Contributed
>> to the IETF under older rules. For the record, I don't know
>> how to make the latter work (partially because, like you, I
>> try to avoid simulating a lawyer) and am not proposing it.  
 
> I have held off proposing this latter view, because I've
> assumed it was obvious and that those expert in the legal
> issues rejected it.
> 
> But from a practical standpoint, it is the most accurate
> representation of work done on IETF documents (within the
> working gorup structure.)
>...

An extreme (or not-so-extreme) version of this model is used by
most of the traditional standards bodies.  They use a formal
membership or participation agreement to [try to] establish the
principle that anything done for the standards body is work for
hire (for the standards body) and hence belongs to that
standards body from the moment it is written.

It has been proposed to several iterations of IPR WGs as a
mechanism that has considerable history if the WG really wants
the copyrights and sublicensing rights in the hands of the IETF
(which 5378 does, but nothing previous did).  It has never
gotten traction.   I don't know (or don't recall) if that is
because the WGs found the idea distasteful, because legal
counsel didn't believe it would hold up without signed
membership agreements, or a combination of  the two.

In fairness, if what became 5378 had been modeled on a "work for
hire and it all just belongs to the IETF" structure, rather than
the more elaborate and complex (IMO) system it uses, it wouldn't
change the problem we have today in any significant way.  Old
documents would still not be covered by the new rules.  If, like
5378, that hypothetical document contained a requirement that
people get the new rights from prior contributors rather than
somehow grandfathering their text, we would, I believe, still be
having exactly the same discussion.

I personally believe that the basic problem we are facing stems
from a problem that the IETF understands extremely well --at
least well enough to debate early, openly, and clearly-- for
technical specifications.  If there is an installed base (in
this case, some 4000+ RFCs that were written under the old rules
and assumptions), we don't generate a new specification that
ignores the installed base or that assumes that a transition can
occur on a flag day basis by retrofitting all earlier deployed
implementations if they are to be used after it.   The analogy
is not exact, but it appear to me that it is exactly what 5378
attempts to do.

> Let me carry it further:  When Erik Huizer and I wrote the
> first IETF Working Group Guidelines document, it was at our
> initiative.  (Well, really, Erik's.) When it was adopted by
> the IETF, I automatically assumed that the IETF owned it.
>...

The following is an attempt to provide a simplified explanation
of the relationship of 5378 to prior work, avoiding (for this
note) any opinion about whether the 5378 model is a good or bad
idea or how to get there in practice.  It should also be
considered to be covered by the usual disclaimers: IANAL, this
is not either legal advice or a legal opinion and, most
important, it is a quick summary that skips over details that I
don't consider important but about which others might disagree.

The assumption that you made was ultimately that work done for
or within the IETF was available for IETF use.  That assumption
is consistent with both long-term practice and with explicit
provisions in documents going back at least to 2026, the Note
Well (at least before today), and so on.  Pragmatically, if 5378
works, it doesn't change that at all. When Scott went to do his
version, he probably had some moral obligation to consult you
and Erik, to ask if you wanted to be involved directly, etc.,
but he was assumed to have no legal (copyright or otherwise)
obligation because he was reusing IETF text for IETF purposes.

The issues that drove 5378 have to do with non-IETF uses of text
from these documents.  For example, if someone on the other side
of the world decided to create an Intranet Dead Horse Kicking
Task Force and wanted to use significant text from the Working
Group Guidelines, and use that material by copy, not by
reference, would they have to ask for permission and, if so,
from whom?

Prior to 5378, the answer was that, if the folks intending this
non-IETF use were being careful, they would have to track down
and ask you, Erik, and Scott for permission.  If they chose to
not be careful, it would be their problem, not the IETF's (or
the Trust's, or yours, etc.)  If the document had been written
for the first time post-5378, they would need to ask only the
Trustees of the IETF Trust because you, Erik, and Scott would
have already transferred to the Trust the rights to deal with
those sorts of questions and license out the text as needed.

In this context, if I initiated an effort to rewrite those
guidelines today, again for IETF purposes, I would, for the very
first time, have to make sure I had the permission of the three
of you and that you (and any other significant contributors I
could identify) had, and were willing to, contribute the 5378
rights, most importantly the right to relicense to others, to
the IETF Trust.   And, also for the very first time, I would
need to make a legal assertion, with whatever liability might be
associated with being wrong, that I had tracked down and gotten
those rights from _all_ prior (significant?) Contributors, even
if the new document was to be used only within the IETF process
-- I could not rely on the previous introduction of the document
into, and publication by, the IETF because the 5378 requirement
for transfer of rights to the Trust is completely new.

> That's me talking as a participant, about pragmatics, not me
> pretending to be a attorney, talking about copyright law.

Me too.

   john

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 17 Dec 2008 14:09:33 -0800

> I assume the missing word is "editors"

fooey.  thanks for catching that. very sorry i didn't.

no, I meant to have it read "are acting as agents of the IETF, when writing IETF 
documents.

(For reference, I do not see the presence of the "editor" label as having any 
material impact on the nature of "ownership" of the text.

> standards has been granted as part of the boilerplate for a long long time.

I'm not sure whether it dates as far back as when we wrote that doc.  But my 
real point is that it doesn't matter, in terms of what I, as an IETF 
participant, thought was the situation.

d/
-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 17 Dec 2008 14:32:48 -0800

John C Klensin wrote:
> or within the IETF was available for IETF use. 
...
> reference, would they have to ask for permission and, if so,

My assumption was not that the work was "available" for "IETF use".

My assumption was that the IETF owned the work.  Pure and simple.

The IETF was free to do whatever the hell if felt like with the work and I 
retained no rights.  Use it.  Give it to another group.  Kill it.  Whatever.

Really.  That's the cultural basis that I believe formed this community and 
informed participants in it.

d/

ps.  Well, to be more complete, I assumed that IETF ownership meant that the 
document was required to be publicly available and -- though I didn't know the 
term at the time -- there was public permission for derivative works by whoever 
felt like doing the deriving.

-- 

   Dave Crocker

---

From: John C Klensin <[email-masked]>
Date: Wed, 17 Dec 2008 17:45:30 -0500

--On Wednesday, 17 December, 2008 14:32 -0800 Dave CROCKER
<[email-masked]> wrote:

> The IETF was free to do whatever the hell if felt like with
> the work and I retained no rights.  Use it.  Give it to
> another group.  Kill it.  Whatever.
> 
> Really.  That's the cultural basis that I believe formed this
> community and informed participants in it.

> ps.  Well, to be more complete, I assumed that IETF ownership
> meant that the document was required to be publicly available
> and -- though I didn't know the term at the time -- there was
> public permission for derivative works by whoever felt like
> doing the deriving.

Dave, this perspective and its implications have been debated by
every incarnation of an IPR WG (or WG including IPR issues) that
I can remember.  Many of those debates have been both lengthy
and heated.   I'm not going to rehash either the variations on
the position you state or the opposing one(s), but your summary
above is, for better or worse, definitely not what the relevant
documents from 2026 through 3978, versions of the Note Well,
etc., say.

And, if you are just now finding that out, it is more evidence
that there is something seriously wrong with how we develop,
review, and publicize specifications of this type.

      john

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 18 Dec 2008 11:54:17 +1300

Dave,

On 2008-12-18 11:32, Dave CROCKER wrote:
...
> My assumption was not that the work was "available" for "IETF use".

Correct.
> My assumption was that the IETF owned the work.  Pure and simple.

False. You never implicitly transferred ownership.

> 
> The IETF was free to do whatever the hell if felt like with the work and
> I retained no rights.  Use it.  Give it to another group.

Specifically, "Give it to another group." was never covered until 5378.
That's the entire problem.

   Brian

> Kill it. 
> Whatever.
> 
> Really.  That's the cultural basis that I believe formed this community
> and informed participants in it.
> 
> d/
> 
> ps.  Well, to be more complete, I assumed that IETF ownership meant that
> the document was required to be publicly available and -- though I
> didn't know the term at the time -- there was public permission for
> derivative works by whoever felt like doing the deriving.
>

---

From: Keith Moore <[email-masked]>
Date: Wed, 17 Dec 2008 18:00:49 -0500

Dave CROCKER wrote:

> I retained no rights.  Use it.  Give it to another group.  Kill it. 
> Whatever.

My understanding was that IETF had a non-exclusive, transferable license
to my rights to the work as creator, including the right to make
derivative works.  But that's not the same thing as IETF owning the work.

Keith

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 17 Dec 2008 15:23:47 -0800

Hi -

> From: "John C Klensin" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>; "IETF discussion list" <[email-masked]>
> Sent: Wednesday, December 17, 2008 2:40 PM
...
> What gives your WG the ability to function is 5.4, where the
> Trust gives back to the IETF participants what the Trust
> received under 5.1 and 5.3.   But they can't give back what they
> don't have, so, if your WG is required to derive its permission
> to do work from 5.4 and a previous author takes a walk rather
> than making the 5.1 guarantees and 5.3 transfers _to the
> Trust_...
...

Ok, so if my understanding was incorrect, at what point must we
stop work until this is corrected?  (I can virtually guarantee that
we will not get explicit permission from every individual named
in an acknowledgement section of one of the antecedants of
the documents we're updating.  Paraphrase the whole thing?
Ain't gonna happen.)

  a) We cannot submit any more I-Ds until this is fixed
  b) We can continue to submit I-Ds, but cannot hand off to the IESG
  c) We can hand off to the IESG, but not do IETF last call
  d) We can do IETF last call, but not hand it over to the RFC editor
  e) We can hand it over to the RFC editor, but not actually publish

I'd be willing to wager that, in its current mood, the WG would simply
disband rather than deal with any of these.

  z) We stop updating our documents, hand over an existing I-D without
      the offensive IPR language, and hope that the IESG requires no
      changes, and use RFC errata to deal with the (minor) problems
      that we know exist in that I-D.

Somehow this seems totally bogus, since the "authors" were all
editors working under the direction of the working group to produce
a work for the working group.  If anything, the transfer should be from
the WG (or the IETF) to the trust, not from the people who were high-
stress typists for the WG.  Likewise, the various contributors whose
words went into the collaborative blender were doing so under the
long-standing NOTE WELL provisions, so getting their permission
again seems, well, pointless.

Randy

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 17 Dec 2008 15:34:27 -0800

> False. You never implicitly transferred ownership.

Yes I did.  As I say, that was the culture.

Scott didn't have to come to Erik or me and ask permission, and he didn't even 
have to think about whether he was required to.  That was the culture. Law often 
follows culture, since culture creates established practice.

I do realize that that was a long time ago and that we certainly have many 
participants holding different views.

I was reviewing the history on the general belief that a crisis of the current 
sort can often be aided by taking a fresh look at first principles.

But since I've now had a number of public and private exchanges with folk who 
have been diligent participants in this topic and since none has seemed to 
understand -- nevermind embrace -- the line of discussion I've tried to raise, 
I'll go back to my observer status and let the folks who are putting the real 
effort into this continue on.

d/

-- 

   Dave Crocker

---

From: John C Klensin <[email-masked]>
Date: Wed, 17 Dec 2008 19:24:32 -0500

--On Wednesday, 17 December, 2008 15:23 -0800 Randy Presuhn
<[email-masked]> wrote:

>> To: "Randy Presuhn" <[email-masked]>; "IETF
>> discussion list" <[email-masked]> Sent: Wednesday, December
>> 17, 2008 2:40 PM
>> received under 5.1 and 5.3.   But they can't give back what
>> they don't have, so, if your WG is required to derive its
>> permission to do work from 5.4 and a previous author takes a
>> walk rather than making the 5.1 guarantees and 5.3 transfers
>> _to the Trust_...
> ...
> 
> stop work until this is corrected?

Here is where you are on your own.  In spite of saying that it
sets up binding legal agreements, RFC 5378 says that it isn't
legal advice (about what those agreements mean or anything else)
and that you need to find your own.  While some people have
offered the opinion that, since no one is likely to sue, you can
safely just ignore the specifics of that document and proceed as
usual, I assume that no one has promised that is legal advice on
which you can rely either.  Since I have already said it on
another list, I can tell you that I've been advised by my
attorney to not post any document for which I'm quite certain
that all prior contributors have made 5378-compliant transfers
to the IETF.  But he is far more aware of my circumstances,
circumstances that are almost certainly not the same as yours,
and what he has told me is definitely not legal advice to you or
on which you should rely.

As to dates, opinions about that seem to differ.  The WG decided
to not incorporate a date (or description of triggering events)
in the text of 5378, so you can't find a lot of help there.
There is an an analysis of the date issue in
draft-klensin-rfc5378var-02a.txt.  Since it lists around a
half-dozen possibilities based on common sense understanding of
the situation (again, not a legal opinion), you should go read
it rather than my trying to paraphrase, but I believe the answer
is "sometime between 10 November and tomorrow".  Some attorneys
who have been consulted have mumbled something that sounded like
"depends on when a reasonable person would have known about the
new rules", but mumbling definitely does not constitute legal
advice.

>  (I can virtually guarantee
> that we will not get explicit permission from every individual
> named in an acknowledgement section of one of the antecedants
> of the documents we're updating.  Paraphrase the whole thing?
> Ain't gonna happen.)
 
>   b) We can continue to submit I-Ds, but cannot hand off to

A common-sense reading of 5378 (not legal advice, etc., etc.)
says that it applies to all Contributions and that you aren't
supposed to be making one of those unless it conforms to the
requirements of  5378.  The definition of a Contribution [RFC
5378, Section 1(a)] is pretty much the same as it was in 3978
and earlier and very explicitly includes text intended for
posting in I-Ds.  I can't give you a legal opinion about what
you can or cannot do, but it is fairly clear that the cutoff
point applies to I-Ds and not some later step in the standards
process.

> I'd be willing to wager that, in its current mood, the WG
> would simply disband rather than deal with any of these.

That is the case that scares me, that prompted me to put up an
I-D posing an alternative in the hope that we could swiftly come
to consensus about it (or some other alternative), and get it
implemented and deployed before Bad Things Happen.   And WGs
shutting down is about the worst thing I can imagine happening
to the IETF (others may, of course, be more imaginative).

>   z) We stop updating our documents, hand over an existing I-D
> without the offensive IPR language, and hope that the
> IESG requires no changes, and use RFC errata to deal
> with the (minor) problems that we know exist in that I-D.

As I read 5378 (and understand the comments made by one of the
IPR WG document authors, the IETF Chair, and a Trustee or two),
the fact of handing that document over to the IESG would make it
subject to 5378 and would constitute an assertion on someone's
part --perhaps yours as WG Chair-- that all of the 5378 hoops
had been properly jumped through.  I would hope that, if the
IESG takes 5378 seriously, they would modify the submission
Checklist to say that explicitly if they have not already done
so.  (I don't have a clue where it would leave us if the IESG
decided it didn't want to take 5378 seriously, unless they
translated that into immediately moving it to historic, which I
gather they don't believe they have the authority to do.)

So that escape would probably not work either.

> editors working under the direction of the working group to
> produce a work for the working group.  If anything, the
> transfer should be from the WG (or the IETF) to the trust, not
> from the people who were high- stress typists for the WG.
> Likewise, the various contributors whose words went into the
> collaborative blender were doing so under the long-standing
> NOTE WELL provisions, so getting their permission again seems,
> well, pointless.

With a "please don't kill the messenger" disclaimer rather than
the "not legal advice one repeated too many times above, 5378
effectively makes the old permissions (from the author to IETF
participants, rather then from the author to the IETF Trust)
irrelevant and consequently requires transfers (of what are a
somewhat different set of rights) to the Trust.  You may have
the rights to work on the document (as a residual of the old
rules), but you cannot Contribute it (post as an I-D, send it
out on a mailing list, read it out loud in a WG meeting,...)
unless you get the 5378 rights.

I think that, if I were a WG Chair contemplating either shutdown
or paralysis over this, I'd be having a conversation with my AD
over how to proceed and when.    As a long-term observer of IETF
and IESG processes as actually practiced, I believe that there
is ample precedent for the IESG either ignoring the details of
rules or making up new ones when they believe it is sufficiently
important and especially if they have clear consensus that there
is a problem that needs to be solved.  So I am not persuaded
that they are helpless to do anything to clear up, or postpone,
this problem.  But my opinion on that subject may or may not be
worth much and, absent some other IESG creativity, I think all
of the appeal windows on 5378 or its implementation have closed
(but could be wrong about that).

If you do that, and the discussion sheds any light on how to
work around the problem, I hope you or the relevant AD will
share it with the rest of us -- with one or two notable
exceptions, whom I very much appreciate, the IESG has been
pretty silent since this came up.

    john

---

From: "Lawrence Rosen" <[email-masked]>
Date: Wed, 17 Dec 2008 16:56:09 -0800

Dave Crocker wrote:
> That was the culture. Law often

I hope you're right.

May I ask: Is there anyone on this list who is asserting a current copyright
interest in any IETF RFC--on your own behalf or on behalf of your
company--that would encumber the freedom of any IETF participants to copy,
create derivative works, and distribute that RFC in accordance with IETF
culture?

On what basis do you assert that current copyright interest in those RFCs?
Have you registered that copyright? Is that copyright interest sole or joint
with any other entity, including other contributors or the IETF Trust
itself?

I'm not interested to hear about hypothetical situations. I would like to
know if there are any actual claims of copyright ownership that people here
are even considering to assert against IETF's complete freedom to act and
establish functional Internet standards.

/Larry

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Dave CROCKER
> Sent: Wednesday, December 17, 2008 3:34 PM
> To: Brian E Carpenter
> Cc: IETF discussion list

---

From: John C Klensin <[email-masked]>
Date: Wed, 17 Dec 2008 22:02:18 -0500

--On Wednesday, 17 December, 2008 16:56 -0800 Lawrence Rosen
<[email-masked]> wrote:

> May I ask: Is there anyone on this list who is asserting a
> current copyright interest in any IETF RFC--on your own behalf
> or on behalf of your company--that would encumber the freedom
> of any IETF participants to copy, create derivative works, and
> distribute that RFC in accordance with IETF culture?
>...

Larry,

So that we don't get assertions about either universal negatives
or about people who are assumed to give up the right to claim
copyright interest as a consequence of not answering your
question,...

Your question does not distinguish between uses by IETF
participants for IETF-related purposes (e.g., standards
development) and uses by people who participate in the IETF for
purposes not directly related to IETF work (e.g., insertion into
programs or their documentation whether conforming to those
standards or not).  Was the failure to make that distinction
intentional?

If it was intentional, is your question intended as a back-door
way to reopen the questions about whether the IETF intends
unlimited use of its material, with or without acknowledgements
and citation and regardless of purpose, that the IPR WG resolved
in the negative?

Finally, when you ask this question, are you asking as an
individual participant in the IETF process or as an attorney who
might be called upon to advise one or more clients on the
subject of dealing with the IETF and/or IETF-related IPR?  If
the latter, would you mind identifying those clients and any
other interest you might have in the answers other than idle
curiousity?

   thanks,
    john

p.s. Even if it were clearly true at one time, which some would
dispute, Dave's assertion about the present IETF culture is
controversial given, at least, the IETF's history and positions
about IPR and copyright over the last decade or more.

---

From: "Lawrence Rosen" <[email-masked]>
Date: Wed, 17 Dec 2008 20:29:52 -0800

Reply below. /Larry

> From: John C Klensin [mailto:[email-masked]]
> Sent: Wednesday, December 17, 2008 7:02 PM
> To: [email-masked]; 'IETF discussion list'
> Subject: RE: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary
> 
> 
> 

[LR:] Universal negatives? I remember at least one email here yesterday or
today where someone cavalierly stated that he claimed a copyright in an
unnamed IETF spec. I wanted to flesh that claim out. Perhaps that person
will have the courage to speak up precisely.

That's the problem around here. People worry to death about IP claims that
nobody is willing to actually make. People develop IP policies that solve
nonexistent problems (such as the "code" vs. "text" debate) and, by doing
so, add further confusion, evidenced by this current problem. 

I refuse to be cowed by ambiguous claims of IP, particularly copyrights that
seek to inhibit the development of *functional* industry standards. It is
even worse than ambiguously claiming that "there might be patented
technology here" but then refusing to identify or license it, because
copyright lasts for 100 years, not just 20. I can outwait the patent IP
claims, but technology will be hostage for my entire lifetime to the
copyrights. That can't be justified.

> standards or not).  Was the failure to make that distinction

[LR:] Yes. Both are absolutely essential for implementation of open
standards.

> and citation and regardless of purpose, that the IPR WG resolved

[LR:] Yes, since the front door has been closed. My question is definitely:
Is anyone retaining a copyright in such functional materials with the intent
to prevent unlimited use by *anyone*? Please don't assert that this need be
"without acknowledgements and citation." I've never said that. As for
"regardless of purpose," as long as the purpose is to obtain a specific
standard functionality and thus the words are not subject to copyright, try
and stop me, regardless of what the IPR WG says.

> other interest you might have in the answers other than idle

[LR:] I am asking as an attorney and IETF participant (we're all individuals
here, I've been told, with individual opinions) who is anxious to understand
why so many people on here are worried about copyright infringement and are
seeking to protect copyrights they don't even have the honesty to claim
outright. I care about IETF specifications in this email thread, not about
any specific clients. As to whether I might represent one or more clients on
this issue, my lips are sealed.

> about IPR and copyright over the last decade or more.

[LR:] So if the "culture" is controversial, and the "process" we've
inadequately developed is controversial, perhaps we should actually consider
the law. Which is what I'm trying to do. Unfortunately what people are doing
here is speculating about hypothetical situations and refusing to declare
their real interests in promoting restricted copyright licenses for
functional specifications.

---

From: Keith Moore <[email-masked]>
Date: Wed, 17 Dec 2008 23:41:36 -0500

> so, add further confusion, evidenced by this current problem. 

This should not be surprising.  The vast majority of us are not lawyers,
and therefore we don't have the kind of wisdom that a lawyer has - in
particular the kind of wisdom that tells an experienced lawyer which
kinds of threats are actually worth worrying about, and more
importantly, which ones are not.

To most of us, the law - especially intellectual property law - is a
threat that we don't understand.  But we've seen it do considerable harm
to our profession, and many of us have been personally burned by it.  So
we can't afford to ignore the problem.

And while we also have some difficulty knowing how much to trust IETF's
 counsel on these matters, few of us are willing/able to pay for our own
legal advice in these matters.  Even if we did, it's not clear that we'd
get consistent answers from our individual lawyers.  So in order to get
rough consensus among ourselves, we'd still be trying to protect
ourselves against threats that many would feel were nonexistent.

I'm not sure what to do about any of this.

Keith

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 17 Dec 2008 23:23:48 -0700

Larry,  your email sounded dangerously close to suggesting that it  
might be ok to break the copyright law because no one would object to  
it. Is that what you are suggesting?

On Dec 17, 2008, at 5:56 PM, Lawrence Rosen wrote:

>> Scott didn't have to come to Erik or me and ask permission, and he  
>> didn't
>> even
>> have to think about whether he was required to.  That was the  
>> culture. Law
>> often
>> I was reviewing the history on the general belief that a crisis of  
>> the
>> current
>> But since I've now had a number of public and private exchanges  
>> with folk
>> who
>> understand -- nevermind embrace -- the line of discussion I've  
>> tried to
>> raise,
>> I'll go back to my observer status and let the folks who are  
>> putting the
>> real

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 18 Dec 2008 08:53:04 +0100

> derivative works.  But that's not the same thing as IETF owning the work.

Right.  One reason RFC 5378 is drafted the way it is, is that the IETF
didn't used to have the right to sub-license contributions to others.

If contributors would have licensed all their contributions to "anyone"
instead of to the Trust, the problem would be reduced.  The second step
in solving the problem would be to allow contributions to contain
material with separate licenses, to allow for older IETF contributions.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 18 Dec 2008 09:03:11 +0100

Dave CROCKER <[email-masked]> writes:

> The IETF was free to do whatever the hell if felt like with the work
> and I retained no rights.  Use it.  Give it to another group.  Kill
> it.  Whatever.
>
> ps.  Well, to be more complete, I assumed that IETF ownership meant
> that the document was required to be publicly available and -- though
> I didn't know the term at the time -- there was public permission for

These are good ideas to put in a "requirements for IETF copying license"
document, as input to lawyers to craft legal text for.  When translated
into legal text, I believe the IETF cultural preference maps closely to
the BSD license.

None of the RFC policies around copyright (including RFC 2026, RFC 3978,
and RFC 5378) are close to your assumptions.  Most critically, none of
the policies transfers copyrights from the contributor to the IETF.

It is unfortunate that there has been such a big gap between the IETF
policy texts and what many people with long IETF experience believe it
should say.  This complicated the IPR WG effort: rather than letting the
new text map more closely to the IETF culture, the document authors
re-used text from earlier documents.

/Simon

---

From: John C Klensin <[email-masked]>
Date: Thu, 18 Dec 2008 06:08:09 -0500

--On Wednesday, 17 December, 2008 20:29 -0800 Lawrence Rosen
<[email-masked]> wrote:

> Reply below. /Larry
>...
> [LR:] I am asking as an attorney and IETF participant (we're
> all individuals here, I've been told, with individual
> opinions) who is anxious to understand why so many people on
> here are worried about copyright infringement and are seeking
> to protect copyrights they don't even have the honesty to claim
> outright. I care about IETF specifications in this email
> thread, not about any specific clients. As to whether I might
> represent one or more clients on this issue, my lips are
> sealed.

To answer a slightly different question, but one that may be
more useful, the IETF was propelled along the path of specific
policies, with the original ones clearly recognizing the
"installed base", because of credible threats to block work
unless everything were rewritten from scratch to (at least)
remove all of the author's sentences.  The situation I remember
best involved work built on the author's text, but the WG
consensus differed from the author's concepts in some ways he
considered fundamental.   I don't recall the details, but I
believe that the threats extended at least into cease and desist
letters, not just the usual profile of posturing, noise, and
idle threats.

I think it would be fair to summarize the thinking of the
powers-that-be at the time as just not wanting to be the target
of that kind of interaction and process, much less any legal
action that might follow, regardless of estimates about who
would prevail in such an action.   You are, of course, entitled
to any opinions you may have about whether that was the right
decision and whether it was properly implemented.   However,
because it appeared nearly certain that any specific and
well-funded legal effort would result in significant delays to
the IETF's work, a large fraction of the community who were
close to the issues --probably large enough to constitute rough
consensus-- because extremely risk-adverse, where the perceived
risk involved the "opportunity" for lost time, service of
various documents and responses, preparation of other documents,
interaction with courts, etc., rather than more specific
questions about who would ultimately prevail.

My apologies for not supplying specific names, dates, and
descriptions of the incident, but there have also been threats
of libel actions if the positions of the actors were not
represented accurately (see risk-adversity and definition above)
and, independent of that, I have no wish to resurrect the ghosts
of that incident in the magical time of year (or ever).  But we
have certainly had people in the community who have tried to use
copyright in document text to impede the IETF process and to
strike out against people and actions of which they disapproved.

Finally, for better or worse, your belief that "Both are
absolutely essential for implementation of open standards" does
not represent the consensus in the IETF community, or at least
has not represented it so far, unless you use the term "open
standards" in a way that makes it tautologically true.
Certainly the FOSS community has managed to implement standards
from, e.g., ITU, JTC1, and several ISO member bodies whose text
is as or more restricted than anything the IETF has proposed.
Perhaps that has been done on the basis of advice from you or
others that no one is likely to actually try to enforce the
intrinsic or claimed rights, but the organizations that hold
those rights have not been persuaded to change their policies or
claims as a result.

I see a problem here, not necessarily because of claims someone
might assert but because of claims that 5378 requires authors to
assert.  The latter turns this into a series of decisions by
individuals and, in some situations, their employers.  If even a
few of them are sufficient adverse to the risk of getting tied
up in legal proceedings, we end up in exactly the situation that
we started down the path of IETF IPR policies to avoid --
significant delays to, or disruption of, the orderly progress of
the standards process.  Unless you are willing to give us legal
advice on which we can rely (and presumably, with it, assurances
that doing so would not put you in a potential conflict of
interest with anyone [else] who might have retained you), your
trying to make estimates of the likelihood of someone asserting
claims (and/or prevailing if they did) don't help me or the IETF
very much.

But the core of the issue I'm having with your note is that I
believe we have gotten ourselves into a situation that requires
a solution in the near term.  I see reintroducing an argument
that everything should just be free (presumably as in "free
beer") -- an argument that IETF WGs have rejected several
times-- and the rehashed discussion that would follow as a
distraction and impediment to getting to such a solution, not a
help on the critical path to making progress.  YMMD, of course,
but let's be explicit about what we are looking for.

     john

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 18 Dec 2008 11:35:40 +0000

FWIW my overall take on this is in line with Dave's.
I also think EKR and Larry made good points.

Basically, I'll just go with whatever xml2rfc produces
at any given moment.

Lastly, I can't really find the energy to get exercised
by any of this, and wonder if interminable discussions
like this are part of the reason folks keep away from all
the well meaning attempts to revise IETF processes.

Stephen.

---

From: Dave Cridland <[email-masked]>
Date: Thu, 18 Dec 2008 12:17:12 +0000

> letters, not just the usual profile of posturing, noise, and

It could well be that I'm misunderstanding, but that kind of  
situation would surely fall into "derogatory treatment", ie, the  
stuff covered by Article 6bis of the Berne convention, or, for UK  
people, the Copyright, Designs and Patents Act 1988 sections 80-83.  
In Berne language:

	the author shall have the right to claim authorship of the work and  
to
	object to any distortion, mutilation or other modification of, or  
other
	derogatory action in relation to, the said work, which would be  
prejudicial
	to his honor or reputation.

And this sounds like, basically, what happened, at least from the  
perspective of the contributor. Note that moral rights are often not  
transferrable in various jurisdictions, and certainly aren't  
automatically transferred anywhere as far as I know - section 11bis  
seems to prevent that.

Since these are moral rights, and not copyrights, and they're not  
mentioned at all by RFC 5378, surely the situation is entirely  
unchanged by this?

To put it another way, if the intent here was to avoid a repeat of  
this incident, then what's needed here is a waiver of moral rights,  
rather than a license of copyrights, which is beyond my ability to  
figure out. (I am, incidentally, not a lawyer, for those living in  
jurisdictions which like to have that in writing somewhere).

As another point, by submitting a document as author, I take it I am  
making the claim that all rights required under RFC 5378 are granted  
by all contributors, their employers, or estates, as appropriate -  
does this open me to litigation should a contributor I didn't know  
about complains? What if someone else submits the document, am I  
still liable? Where is the record of who submitted the document if  
not? (Presumably, once the document passes through AUTH48, I must be  
liable, having given explicit assent to it).

To put this another way, is contributing a revised document to the  
IETF now too risky an action to contemplate?

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 18 Dec 2008 08:08:00 -0500

> jurisdictions which like to have that in writing somewhere).

I have been involved a little in the US planning for various  
negotiations of the inclusion of webcaster rights in the
WIPO under the Berne convention (I generally oppose what has been  
proposed). At the risk of violating
my mantra ("Engineers should not try and be lawyers"), I do not think  
we should go there or need to go there.

Note that, while the USA is not a signatory to the Rome Convention  
(even though our WIPO negotiators
sometimes seem to like to act like we are), the USA is a signatory to  
the Berne Convention :

http://www.copyrightaid.co.uk/copyright_information/berne_convention_signatories

However, Article 6bis(3) allows national legislatures to determine the  
treatment of moral rights;
the USA has not done so. In fact, moral rights were a major sticking  
point in the US's signing the Berne convention at all.
Under the "Berne Convention Implementation Act of 1988", 17 USC 101,  
Section 2 (2)
"The obligations of the United States under the Berne Convention may  
be performed only pursuant to appropriate domestic law."

The IETF Trust is governed under the laws of the Commonwealth of  
Virginia, a state in the USA, so it is governed by US Law, not the  
Berne convention directly.

In the Berne Convention Implementation Act of 1988, 17 USC 101,  
Section 3 (b)

"(b) Certain Rights Not Affected.--The provisions of the Berne  
Convention, the adherence of the United States thereto, and  
satisfaction of United States obligations thereunder, do no expand or  
reduce any right of an author of a work, whether claimed under  
Federal, State, or the common law--

(1) to claim authorship of the work; or
(2) to object to any distortion, mutilation, or other modification of,  
or other derogatory action in relation to, the work, that would  
prejudice the author's honor or reputation."

If you want more, I would start here : http://www.rbs2.com/moral.htm

I would urge the IETF Trust to stick to US / Virginia law only.

Regards
Marshall

---

From: Thomas Narten <[email-masked]>
Date: Thu, 18 Dec 2008 10:26:03 -0500

Speaking as an individual, IANAL, etc., a few general comments...

First, overall, the issues John raises are real and need to be
addressed, IMO.

Second, I know of cases (while I was AD) where a WG participant owned
the copyright on an ID the WG had been discussing, and then balked at
making requested changes. In at least one case, a document was
rewritten in "clean room" fashion to get around potential problems. We
do not want to do these sorts of things. They are painful and
frustrating, they delay work, and they are a drain on precious cycles
that could better be spent doing other things.

Such scenarios may not happen often, but they can (and have)
happened. Some former IETF participants have walked away from the IETF
in a disgruntled fashion. In no way would it be acceptable for the
IETF as an organization to allow anyone to have the potential ability
to block IETF work by withholding any needed additional/new
rights. Yet, that is what RFC 5378 appears to do.

One of the "features" of the current IETF IPR (not copyright) policies
is that each individual WG decides on a case-by-case basis what to do
with IPR assertions. Those discussions are often messy,
non-terminating and contentious because there are unknowns (i.e.,
unquantifiable future risk), and the normal rules engineers follow
don't apply (e.g., the lawyers and licensing folk see issues very
differently than engineers do). Different people (and companies) see
the risks very differently. So what works for one individual won't
work for someone else.

Placing the responsibility on individual authors (and by implication
their employers) for getting necessary permissions to use text
contributions from others (e.g., when revising previous RFCs) is
problematic when such permissions can't easily be obtained because:

 - it places unknown/hard to quantify future risk on the individual (who may
   or may or may not care)

 - by implication, it places future risk on their employer (who
   probably very much will care)

One might hypothesize that some will say "this is silly" and just
continue to submit documents without worrying much. Others (like those
working for larger corporations) may well find that a general
corporate policy will not allow them to take such steps (legal
departments rarely issue blank checks for future unknown
risk). Consequently, all cases will likely be treated as exceptions to
be evaluated on individual merits and on a case-by-case basis. Anyone
who has had significant interactions with legal departments on such
matters will understand how problematic this would be in
practice. There would be a huge discincentive to authoring work of
this nature, and at best there would be (potentially lengthy)
delays. Most likely, the pool of available authors would simply
shrink. That would not be good for the IETF.

Thomas

---

From: Fred Baker <[email-masked]>
Date: Wed, 17 Dec 2008 13:16:13 -0800

One could argue that ietf-ipr looked at this question for two years  
prior to submitting the new boilerplate, and by missing it made it  
clear that they weren't adequate to review. That said, there was also  
an IETF last call, and none of us detected the issue until Sam brought  
it up.

On Dec 17, 2008, at 1:05 PM, Dave CROCKER wrote:

> I have held off proposing this latter view, because I've assumed it  
> was obvious and that those expert in the legal issues rejected it.
>
> representation of work done on IETF documents (within the working  
> gorup structure.)
>
> That is:  Working groups are part of the IETF and 'authors' of  
> working group documents are acting as  when writing IETF  
> documents.agents of the IETF.  While there might be underlying  
> intellectual property owned by the companies that authors work for,  
> the actual document is commissioned by, and copyright should be  
> owned by, the IETF.
>
> Let me carry it further:  When Erik Huizer and I wrote the first  
> IETF Working Group Guidelines document, it was at our initiative.   
> (Well, really, Erik's.) When it was adopted by the IETF, I  
> automatically assumed that the IETF owned it.
>
> That is, after all, what we assert when outside technology is  
> brought into the IETF and we insist that they are handing over  
> "change control". What is change control if not the authority to  
> make changes to the document?
>
> So when Scott Bradner did the revision to the IETF Working Group  
> Guidelines document the idea that he had a legal obligation to get  
> our permission would have -- and certainly now does -- strike me as  
> silly.
>

---

From: John C Klensin <[email-masked]>
Date: Wed, 17 Dec 2008 17:40:04 -0500

--On Wednesday, 17 December, 2008 14:00 -0800 Randy Presuhn
<[email-masked]> wrote:

> Particularly since the permission to create derivative works
> and successor standards has been granted as part of the
> boilerplate for a long long time.

Yes.  But that was permission given directly by the authors to
the IETF, for IETF use.  5378 removes that mechanism, which I
always considered fairly elegant, in favor of a transfer of
rights to the Trust which then licenses those rights back to the
IETF participant.  All 5.3 does is to give those rights to the
Trust (read the first paragraph), and the Trust doesn't get them
unless the author can and does make the assertions of 5.1 (which
includes rounding up the prior contributors).

>...
> Consequently, as a WG co-chair who wants his WG to
> finish up  in this century, I read RFC 5378 section 5.3 as
> giving working groups what they need so they can ignore all
> this stuff about tracking down long-gone contributors, and
> that it's merely a re-incarnation of what has long been the
> intent behind the NOTE WELL text.

My guess, with the usual non-lawyer disclaimers, is that we
would be having a less complicated discussion if 5378
_preserved_ the direct grant from Contributors to the IETF for
IETF use in addition to whatever it required be given to the
Trust.   That would let your WG (and Dave's revisions) continue
to function under the old rules and assumptions even if we still
needed to have a debate about whether 5378 conformance was
required of every document posted, obligations on submitters,
etc.

    john

---

From: "Lawrence Rosen" <[email-masked]>
Date: Thu, 18 Dec 2008 09:10:27 -0800

> it. Is that what you are suggesting?

Not at all. But every attorney is charged with an obligation to help others
understand and interpret the law even if that interpretation differs from
that of some other attorneys. 

Fifty years from now, after IETF is dissolved and most of us have passed
away, I don't want the dead hand of copyright reaching out from the grave to
prevent anyone from freely modifying TCP/IP to satisfy modern requirements.
It may be that, because Congress further extends the copyright term, the
Disney corporation will then still own and control the copyright in Mickey
Mouse cartoons, but the notion that anyone owns and controls the functional
underpinnings of technology by placing a copyright notice on it is simply
unacceptable.

That is a perversion of the law, not something that a copyright lawyer who
supports open source, open content and open standards can countenance. I
hope that the participants in IETF develop IPR policies that support the
fundamental freedom to invent--and to describe in words--whatever functions
we need for our world to progress.

Best regards,

/Larry

> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Wednesday, December 17, 2008 10:24 PM
> To: [email-masked]
> Cc: 'IETF discussion list'

---

From: John C Klensin <[email-masked]>
Date: Thu, 18 Dec 2008 14:02:37 -0500

--On Thursday, 18 December, 2008 09:10 -0800 Lawrence Rosen
<[email-masked]> wrote:

> Cullen Jennings wrote:
>> Larry,  your email sounded dangerously close to suggesting
>> that it might be ok to break the copyright law because no one
>> would object to it. Is that what you are suggesting?
> 
> Not at all. But every attorney is charged with an obligation
> to help others understand and interpret the law even if that
> interpretation differs from that of some other attorneys. 
> 
> Fifty years from now, after IETF is dissolved and most of us
> have passed away, I don't want the dead hand of copyright
> reaching out from the grave to prevent anyone from freely
> modifying TCP/IP to satisfy modern requirements. 
>...
> ...the notion that anyone owns and controls the functional
> underpinnings of technology by placing a copyright notice on
> it is simply unacceptable.
>...

> I hope that the participants
> in IETF develop IPR policies that support the fundamental
> freedom to invent--and to describe in words--whatever functions

Larry,

Now I'm confused.  To my weak, layperson's, mind, it appears
that you are conflating the underlying intellectual property in
TCP/IP (whatever, if anything, that means), or the "functional
underpinnings of [that] technology", with the copyright in the
form in which the protocols are expressed -- something that you
and your professional colleagues have repeatedly warned us
against.

I would assume that, if someone were revising TCP or IP fifty
years hence, they would end up creating new text, rather than
moving a lot of technical text forward, and that they would do
so for all sorts of technical reasons independent of copyright
constraints.    The practical issues are very different from
tweaking an existing protocol only a decade or so out (or
somewhat more) to clarify it or change its maturity level...
and, of course, are different from the image of a cartoon mouse.

As an exercise that I don't have time to conduct, it would be
interesting to see how much of the text of the original IP
specification is still present in the IPv6 one... and that was
only 20 years and may, in retrospect, have involved too few
substantive changes.
 
> That is a perversion of the law, not something that a
> copyright lawyer who supports open source, open content and
> open standards can countenance. 

Which is something about which you need to persuade the
Congress, not the IETF, as I assume you have tried to do.

      john

---

From: Thomas Narten <[email-masked]>
Date: Thu, 18 Dec 2008 14:15:47 -0500

> only 20 years and may, in retrospect, have involved too few

I wouldn't spend a lot of time on such an exercise. I'd be very
surprised if there is ANY common text. All the documents I am aware of
were written from scratch.

Thomas

---

From: Keith Moore <[email-masked]>
Date: Thu, 18 Dec 2008 14:42:54 -0500

John C Klensin wrote:

> constraints.    

Now I'm confused.  When we revise a technical specification in IETF, we
try (to some degree) to avoid creating new text unless necessary, for
fear of introducing subtle incompatibilities.  Why wouldn't "someone"
fifty years hence have similar concerns?

I'll grant that the text in a lot of these old RFCs looks a bit dated
and imprecise by now.  But if I were revising TCP, I'd still use RFC 793
as a starting point, and the resulting documents would probably qualify
as "derivative works".

Keith

p.s. Regarding the IPv4 to IPv6 comparison, one could argue that the
IPv6 spec _should_ have included more text from RFC 793, as there are
indeed subtle differences between the IPv4 and IPv4 protocols that have
caused unanticipated problems.

---

From: John C Klensin <[email-masked]>
Date: Thu, 18 Dec 2008 15:34:04 -0500

--On Thursday, 18 December, 2008 14:15 -0500 Thomas Narten
<[email-masked]> wrote:

> surprised if there is ANY common text. All the documents I am
> aware of were written from scratch.

That is pretty much what I expected.  To the extent to which we
can extrapolate from it (and I think we can), Larry's concern
about copyright-blockage on such work is probably not
significant.

    john

---

From: John C Klensin <[email-masked]>
Date: Thu, 18 Dec 2008 15:40:49 -0500

--On Thursday, 18 December, 2008 14:42 -0500 Keith Moore
<[email-masked]> wrote:

> Now I'm confused.  When we revise a technical specification in
> IETF, we try (to some degree) to avoid creating new text
> unless necessary, for fear of introducing subtle
> incompatibilities.  Why wouldn't "someone" fifty years hence
> have similar concerns?

Because there is a big difference between clarifying or updating
an existing spec and writing a new protocol.  

> I'll grant that the text in a lot of these old RFCs looks a
> bit dated and imprecise by now.  But if I were revising TCP,
> I'd still use RFC 793 as a starting point, and the resulting
> documents would probably qualify as "derivative works".

That would be your choice.  And you are a lot more likely to be
around 50 years from now to make it than I am.   However, trying
to write a new spec with IPR that conforms to 5378 but that used
significant text from 783 would require you to obtain Jon
Postel's permission which, I think, would send you swimming in a
can of worms of appropriate size for you to do so.

So, to write such a spec with 783 text, you would either have to
un-do 5378, create the type of exception procedure that caused
the current version of this thread to be initiated, or deal with
that can or worms.  It would be up to you to determine which of
those options would be most attractive... or whether a complete
rewrite or giving up entirely would.

Q.E.D.

     john

---

From: <[email-masked]>
Date: Thu, 18 Dec 2008 13:30:57 -0800 (PST)

tell you what - if by some very small chance (probably less than 1%) I'm still around 50 years from now and feel like revising RFC 793 at that time, I'll trust that you've already reconnected with Jon and gotten his permission :)

either that, or I'll already be dead, and I'll ask him myself.  

seriously, my guess is that 50 years from now, either TCP will be irrelevant (if not the whole Internet) or RFC 5378 will have been fixed.  and those two are not independent.

Keith

---

From: Sam Hartman <[email-masked]>
Date: Thu, 18 Dec 2008 17:28:28 -0500

>>>>> "Keith" ==   <[email-masked]> writes:

    Keith> tell you what - if by some very small chance (probably less
    Keith> than 1%) I'm still around 50 years from now and feel like
    Keith> revising RFC 793 at that time, I'll trust that you've
    Keith> already reconnected with Jon and gotten his permission :)
    Keith> either that, or I'll already be dead, and I'll ask him
    Keith> myself.

I tell you what.  I'll trust that Jon or his estate is not going to
sue us if we use his work in the IETF context to make new internet
standards.

Remember, we're discussing legalities here and for the most part US
civil law.  There are some things you decide are acceptable risks
simply because the chance someone with standing to do so will take
action against you are small enough that you stop caring.  It's not an
perfect world from an engineering standpoint, but guess what?  There
is not perfect compliance with our specs either.

So, honestly, Jon's text is just not something I'm worried about even today.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf