--On Tuesday, 16 December, 2008 22:08 -0500 "Joel M. Halpern"
<jmh(_at_)joelhalpern(_dot_)com> 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
...
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.
...
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf