ietf
[Top] [All Lists]

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

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

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

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

Bob Braden

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

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

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

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

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

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

FTR, httpbis is on hold until this is resolved.

....Roy
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>