Subject: Re: RFC5378 alternate procedure (was: Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary)

From: John C Klensin <[email-masked]>
Date: Mon, 15 Dec 2008 23:12:18 -0500

Hi.

I've just reposted this draft as
draft-klensin-rfc5378var-01.txt.  I didn't removing the material
I indicated I was going to remove because this version follows
too quickly on the previous one.

There are only two sets of changes, but the first seemed
sufficiently important to be worth a quick update:

(1) Alfred Hoenes caught several places in which I had
transposed digits or otherwise fouled up RFC numbers to which I
was making reference.  This type of work is sufficiently
confusing without that sort of stupid problem, for which I
apologize -- I thought I had proofread it carefully enough but
obviously did not.  They have been fixed.

(2) I realized that it was necessary for completeness to
un-obsolete 3948 and 4748 if they were going to be referenced,
or material from them picked up and copied into, documents, so I
have inserted a paragraph to take care of that.

Anyone who has successful read the -00 version and understood it
can safely ignore this one.  Anyone who has not yet read -00, or
who tried to read it and was confused by the numbering errors,
may find this version more helpful.

Comments are, of course, welcome on either one.

     john

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

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 16 Dec 2008 09:53:45 +0100

Material comments:

- Section 3: RFC 5378 expected the date on which 5378 was effective to 
be set by the Trust (section 2.1), and explicitly did not want to cast 
into RFC stone the procedure by which the changeover date was determined.

- I disagree with the decision to allow *all* of a submission, including 
new text, to be 3978-boilerplated. As I've said before, my preferred 
resolution mechanism is to have a mechanism available (probably 
front-page disclaimer + details in the Contributors section) for listing 
pre-5378 sources from which material was copied without 5378 permission 
being granted by the authors.
I believe the continued production of material that is licensed under 
3978 only will be long-term harmful to the state of the IETF's IPR 
confusion.

                          Harald

---

From: John C Klensin <[email-masked]>
Date: Tue, 16 Dec 2008 13:18:42 -0500

(in the interest of efficiency, I'm going to respond to Harald's
and Simon's comments in a single note and pick up one of
Hector's remarks in the process)

Harald,

--On Tuesday, 16 December, 2008 09:53 +0100 Harald Alvestrand
<[email-masked]> wrote:

> Material comments:
> 
> - Section 3: RFC 5378 expected the date on which 5378 was
> effective to be set by the Trust (section 2.1), and explicitly
> did not want to cast into RFC stone the procedure by which the
> changeover date was determined.

I understand that.  I even believe that the WG decision in that
regard, reflected in 5378, was correct in that regard.   But we
have ended up in a situation in which reasonable people,
apparently even practicing attorney-type reasonable people,
disagree on the actual effective changeover date and its
validity.  Except as an example of "we don't do this at all
well" (see below), why that happened is not particularly
interesting compared to the importance of properly identifying
and solving, or at least working around, the problem.

> - I disagree with the decision to allow *all* of a submission,
> including new text, to be 3978-boilerplated. As I've said
> before, my preferred resolution mechanism is to have a
> mechanism available (probably front-page disclaimer + details
> in the Contributors section) for listing pre-5378 sources from
> which material was copied without 5378 permission being
> granted by the authors.
> I believe the continued production of material that is
> licensed under 3978 only will be long-term harmful to the
> state of the IETF's IPR confusion.

I tried to say this in the document, but obviously not clearly
enough.   I believe that the right long-term strategy is some
sort of hybrid in which earlier text is somehow grandfathered
and newer text falls under the newer rules.  That is desirable
not only for the reason you cite but because, as Simon points
out, 3978 has its own set of problems that we should not
perpetuate any longer or more than necessary.

_However_ there are two problems with a hybrid strategy.  The
first is that I see almost no chance that we could develop that
necessary model, plan, and documentation quickly and get it
right (see below).  I believe that, if 5378 is taken seriously
and is the only permitted posting mode after today, that a
number of document and WG efforts are simply going to come to a
halt until we get a workaround in place.   The "just use 3978
until we get this sorted out" model of the I-D is a proposal for
that (I hope temporary) workaround; it is not a suggestion for a
permanent solution.  

The second is an issue on which I think we need advice from the
Trustees and from Counsel and then time to consider and discuss
that advice.  To a first approximation, the IPR in a document
completely created under 5378 rules is extremely easy to
understand and administer: the Trust owns the thing and all
rights to use it, even for IETF development purposes, derive
from licenses granted by the Trust.  Similarly, and again to a
first approximation, the IPR in the document completely created
under 3978 or its predecessors is easy to understand and
administer: the IETF can use the document any way it needs/wants
to, anyone can copy, distribute, etc.,  and anyone with another
use must seek out the authors for permission.   

A document that contains both 3978 (or earlier) material and
5378 material is a much more complex proposition.   Obviously,
the Trust can't grant rights it doesn't have.  Probably a grant
from the Trust that says "you can do X with any part of the
document we control, but for anything else you have to have to
contact the authors, and we can't tell you which is which" is
the worst of both worlds... one in which anyone who is being
conservative will feel a need to obtain both a license from the
Trust _and_ licenses from the authors/ Contributors.   Does that
mean that, to do a hybrid document, we will have to label each
paragraph with its authorship/ 5378 status?   I don't know, and
that is where consultation with Counsel is needed.  One we get
those answers, we can start figuring out the tradeoffs and what
we _really_ want.    But I am certain we won't be able to figure
that out and get it right this week, or even this year.

Simon,

--On Tuesday, 16 December, 2008 15:03 +0100 Simon Josefsson
<[email-masked]> wrote:

>...
> Thanks for trying to do something about this problem.  I've
> read the -01 document.  It describes a solution that would be
> very far from a good copyright situation -- even further away
> than RFC 5378 alone, given that RFC 3978 is seriously flawed
> in some ways.  However, I think your draft is likely to be one
> of few approaches that can gain consensus quickly enough to be
> an effective solution to the problem you describe.  It could
> be a stop-gap measure for the next year or so, until better
> copyright policies can be developed.

That is really all I intend -- something that can get us out of
this hole, that could be adopted and implemented very quickly,
but is temporary until we can do something significantly better.

> There is one detail I disagree with rather strongly.  Section
> 7 suggests that the Trustees should prepare a replacement for
> BCP 78.  First, I don't think the Trustees have the necessary
> competences or resources to take on that huge effort.
> Further, there is a conflict of interest here: any policies
> written by the Trustees is likely to just give more rights to
> the IETF Trust That is the problem that caused this situation
> to begin with.  I don't believe the output would be
> representative of the needs of the wider IETF community.
> Instead, I suggest there should be a wider IETF effort to
> document the copyright policy that will serve the IETF
> better...

With the understanding that my goal is not to convince you to
change your mind, let me explain my reasoning.  

Whatever one believes about the content of the IETF's various
attempts at getting an IPR policy right, I believe that the one
clear conclusion that can be drawn from the several attempts to
shape a new policy since RFC 2026 was published in 1996 is that
we are not at all good at it.  We have a history of publishing
new policies and then saying "whoops, that isn't quite right" or
"whoops, didn't really mean that" -- a history that 5378 and
this problem with older documents now joins.   My recollection
is that 3978 itself was developed as a patch to a prior attempt.
I've got my hypotheses about why this keeps happening, you
probably have yours, and others who have thought about it have
their own.  But those hypotheses are ultimately less interesting
than the observation that it keeps happening and that our review
and checking processes, empirically, are not working.  

With that history, trying to do another document and policy
using the same WG model, inevitably subject to the same
strongly-presented interests from different groups, the same
levels of noise from amateur lawyers, and the same consequent
group exhaustion, and then expecting a significantly better
result would meet one of those classic definitions of insanity.
"A wider IETF effort" would be a good idea, but I don't think we
know how to make that happen in practice.   My interpretation of
our experience (repeated several times) is that there are a
fairly small number of people in the IETF who care passionately
about these issues, but not nearly enough of them to constitute
a "wider effort".   Virtually everyone else believes that they
have better ways to spend their time; or cannot defend time
spent on IETF IPR work to their employers; or have a profound
distaste for legal provisions, legal-style documents, and
lawyers; and just are not going to pay serious attention to
these issues until they get bitten by them (either within the
IETF or by having some attorney to whom they are answerable say
"you can't play under those rules").

If we could get review of these IPR documents of the same nature
and quality with which we try to review technical specifications
for security issues -- including thorough threat analyses and
discussions of how the documents would respond to those threats
-- then I don't believe we would have these continuing rounds of
problems.   Conversely, the observation that we continue to have
them is evidence that we aren't getting even careful review by
the wider IETF community.  If we can't get that review, then
expecting the wider community to actually develop a document
(and get it right) is, IMO, profoundly unrealistic.

In theory, what the last round of the IPR WG was supposed to do
was to produce a set of principles against which a more expert
team could construct a document for review by the WG that would
also stand legal review.  5378 (and 5377) are supposed to be the
final output of that process.  My hope is that the Trustees can
start with the principles, add in a (I hope now clear) message
that the IETF needs to pay much more attention to the handling
of older text, and then redo the "expert team" job, producing a
document that the wider IETF community, with the motivation of
this problem and less exhaustion than the WG had, can
successfully review.  If the principles are not clear enough at
this point, then that isn't going to work, but my assumption is
that we deal with that if and when we get to it.  I'm  not at
all sure that approach is going to work, but I'm pretty positive
that "spin up a WG and let it start over" will not.

If it fails because the principles are unclear, I don't,
personally, see any alternative to trying a WG again.   If I
were General Area AD, I would try to charter that WG with
directions to produce and publish a statement of principles and
then shut down.  I would forbid the direct reuse of as much as a
single paragraph from 5378 in that statement, not only to avoid
mixing up legal language with the principles but because I
believe that dragging some of that text and definitions is part
of what has gotten us into trouble (again).  Fortunately for
such a possible WG and its participants, I'm not General Area
AD, I'm not going to be General Area AD anytime soon, and my
approach to organizing these sorts of things is very different
from those used by Russ, Harald, Brian, or Fred even though we
often reach the same conclusions in the end.

> ...and hopefully such an effort can review some of the bigger
> pictures that were declared out of scope in the IPR WG.  One
> consideration would then be:
> 
> * Whether the two-phase construct with an IETF Trust is a good
> idea.   One alternative is to require contributors to release
> their work under   a liberal license that allows everyone to
> copy and modify it.  This   would avoid the liability issues
> that are inherent in the IETF Trust   construct.  This would
> save money for the IETF.  The license would be   significantly
> less complex.

We've tried that multiple times.  Different of us read the
community and consensus differently, but my own impression is
that the community has considered that idea and rejected it,
either completely or because it is impossible to reach agreement
about how liberal the license should be.  In that sense, the
clever new idea in 5378 is to use a license that mostly just
covers the IETF use and then level all of the other issues and
edge cases to the Trustees, rather than trying to reach a
community consensus about liberality of licensing, a consensus
that may not exist.

However, the fact that the desire to do that kind of review
exists, and exists strongly, reinforces my view that we need a
short-term workaround to permit us to do work while those more
significant issues are sorted out.

> I agree there are some situations were contributors doesn't
> find this model acceptable.  Just like there are exceptions
> in the current license, there could be a exception in the
> new license to allow exceptions for non-modifiable content.
> Compare how the GNU FDL license restricts certain parts of a
> manual to be modified freely.

While that idea may deserve further consideration, and probably
does, I stand by my conviction that an IETF WG isn't going to be
the way to get there... even while wishing that I am wrong.

And my short-term goal, again, does not depend on any of this.
It is to provide a viable workaround to the issues of old text
newer documents and to provide one on which we can agree quickly
enough to avoid significantly blocking work.

best,
      john