Re: Last Call: 'IETF Rights in Contributions' to BCP

["C. M. Heard" <[e-mail]>]

On Thu, 7 Aug 2003, Scott Bradner wrote:

> > Just to make sure that I have not misinterpreted what's being said
> > here, my understanding is that it will change the rules set forth in
> > RFC 2026 10.4(C) in the following two ways, once
> > draft-ietf-ipr-submission-rights is published as RFC XXXX:
> 
> yes, but it does not change teh ways we have been doing things see:
> http://www.ietf.org/IESG/STATEMENTS/MIB-COPYRIGHT.txt

I was referring to Section 5.4 of draft-ietf-ipr-submission-rights
when I said "what's being said here".  That section does not talk
about MIB copyrights.

I am sorry to be repetitious, but it seems that I've failed to
communicate the points that I am concerned.  So please let me
try again.  What I said was that Section 5.4 of
draft-ietf-ipr-submission-rights changes the the rules set forth
in RFC 2026 10.4(C) as follows:

(a) all IETF Internet-Drafts and all RFCs published from them will
not contain the full copyright statement from RFC 2026 10.4(C) but
rather will contain the shorter notice shown in Section 5.4 of
draft-ietf-ipr-submission-rights;

(b) the requirement to include this notice now applies to _all_ IETF
Documents, not just "standards-related documentation" (to use the
phrase from RFC 2026).

Item (a) changes the wording of the full copyright statement from
what was in RFC 2026 10.4(C) but does not (as far as I can tell)
change the substance.  I'll assume for the purposes of this
discussion that the notice in Section 5.4 of
draft-ietf-ipr-submission-rights is equivalent to that in RFC 2026
10.4(C).

Item (b) is the thing I'm concerned with.  It changes the scope from
"all ISOC standards-related documentation" to "all IETF Documents".
It sure seems to me that this is a change from "running code".  As
I've understood it, the term "ISOC standards-related documentation"
wasn't intended to include standards developed by other
organizations that are published as Informational RFCs.  In actual
practice, such documents have _not_ contained the full full
copyright statement from RFC 2026 10.4(C), but have contained a
variant copyright that excludes the right to make derivative works
other than translations;  see RFC 3394 for an example.  However, if
such a document is submitted via a working group, it seems that
draft-ietf-ipr-submission-rights now requires it to have a copyright
notice that permits making derivative works for the purpose of
developing Internet standards.  That is what I was complaining
about.  I think it's a bug, and I think it needs to be fixed.

> > I also understand that this section does not NOT apply to RFC Editor
> > documents and that draft-ietf-ipr-submission-rights is deliberately
> > silent about requirements for copyright notices in such documents.
> 
> the RFC Editor will make their own rules about their documents

Good, then I understood that part correctly.

> > I'm not sure if the correct way to fix this is to tinker with the
> > "(required for all IETF Documents)" language in Section 5.4, or if
> > the definition of "IETF Contributions" needs to be revised to
> > exclude drafts containing external specifications that are intended
> > just to republish those specs as Information or Experimental RFCs,
> > even if said drafts are not submitted directly to the RFC Editor.
> 
> I expect that is not the way to deal with it - I would suggest 
> expanding the language in Sec 5.4 
>    Additional copyright notices are not permitted in IETF Documents
>    except in the case where the document is the product of a joint
>    development effort between the IETF and another standards development
>    organization.  Such exceptions must be approved on an individual   
>    basis by the IAB.
> 
> 1/ there needs to be an ISOC copyright on all RFC Editor-published docs
>    since the IETF/ISOC has a licence from teh authors (including the
>    other stds org if there is one) to publish the material and that
>    publishing has a copyright on it
> 
> 2/ but if the material is a republishing of some other stds organization's
>    material they also have a copyright on the material
> 
> 3/ but we do not want any random person to insist that they have their
>    own copyright statement on a doc juts because they maintain rights
> 
> I would suggest that we just expand the text to say:
> 
>    Additional copyright notices are not permitted in IETF Documents
>    except in the case where the document is the product of a joint
>    development effort between the IETF and another standards development
>    organization or the document is a republication of the work of another
>    standards organization.  Such exceptions must be approved on an 
>    individual basis by the IAB.

The problem is that this only mentions "additional copyright
notices" and makes no allowance for a _different_ copyright notice
that excludes the right to make derivative works (other than
translations).  That's fine for jointly-developed standards but not
for republications.

One other point ... it would seem quite odd to me for different
copyright rules to apply to documents that are republication of the
work of another standards organization based on whether the document
was submitted directly to the RFC Editor (so that it is an RFC
Editor Document) or via an IETF working group (so that it is an IETF
Document).  Currently the RFC Editor rule (per
draft-rfc-editor-rfc2223bis-06.txt) is:

      A specific request from the IAB is required before the RFC
      Editor can include a dual copyright, or for any other
      variation of the standard ISOC copyright notice.

which has the requisite flexibility.

I suppose one way out (without having potentially different rules
depending on submission route) is to require that documents which
republish the work of another standards organization be submitted as
RFC Editor Contributions, rather than via an IETF WG.  Maybe that's
the de-facto practice already and the bridge-mib WG is breaking new
ground in attempting to republish the IEEE 802.11X MIB by submitting
it as a WG draft (currently draft-ietf-bridge-8021x-02.txt).  I
don't know;  does anyone else?

Mike



_______________________________________________
Ipr-wg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ipr-wg