--On Wednesday, 17 December, 2008 13:05 -0800 Dave CROCKER
<dhc2(_at_)dcrocker(_dot_)net> 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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf