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

["todd glassey" <[e-mail]>]

This particular issue is one I have brought up any number of times and that
is how the IETF takes formal notice of anything, since to notice the IETF
one MUST convey copyrights to ISOC that in most instances the noticing party
wont own. Here again we have an issue since the IETF would be liable for
publishing anything that someone else held IP rights to or copyright of.

This is NO different though than the IETF's [publishing submittals for which
the submitting party does not own the publication rights.

Todd Glassey

----- Original Message ----- 
From: "C. M. Heard" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Sent: Wednesday, July 30, 2003 11:58 AM
Subject: Re: Last Call: 'IETF Rights in Contributions' to BCP


> On Mon, 28 Jul 2003, The IESG wrote:
> > The IESG has received a request from the Intellectual Property
> > Rights WG to consider the following Internet-Drafts as BCP.
> > o Intellectual Property Rights (IPR): 'IETF Rights in Contributions'
> >     <draft-ietf-ipr-submission-rights-06.txt>
> >     BCP
> ...
> > File(s) can be obtained via
> >
http://www.ietf.org/internet-drafts/draft-ietf-ipr-submission-rights-06.txt
>
> An issue has come up on the [e-mail] mailing list in
> connection with draft-ietf-bridge-8021x-02.txt that makes it seem to
> me that the submissions-rights draft does not adequately deal with
> republication of standards from other SDOs as informational RFCs,
> particularly when MIB modules are involved.  I'm not sure if such a
> case has actually arisen before.  For background on the discussion
> see http://www1.ietf.org/mail-archive/working-groups/bridge/current/
>
> First, in Section 5.4, "Copyright Notice (required for all IETF
> Documents)", it says:
>
>    (Normally placed at the end of the IETF Document.)
>
>       "Copyright (C) The Internet Society (year). This document is
>       subject to the rights, licenses and restrictions contained in RFC
>       XXXX and except as set forth therein, the authors retain all their
>       rights."
>
>    [note to the RFC Editor - XXXX above to be replaced with the number
>    of this document]
>
>    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.
>
> It seems to me that this does not adequately cover the cases where a
> proprietary specification or a standard that is the product of
> another SDO is being republished in an informational RFC.  In many
> if not most such cases the RFCswill require a copyright notice that
> does not grant the right to create derivative works (or, as per the
> second comment below, grants only very limited rights).  Note that
> such a variant copyright (without the right to produce derivative
> works) has appeared in many such works in the past (RFC 3394 being
> the most recent one that I could find).  Also, it seems to me
> unreasonable that the copyright notice in such an RFC could not
> (even with IAB approval) mention the organization that originally
> produced the specification that is being republished and that
> retains change control over it.
>
> The second issue has specifically to do with MIB or PIB modules that
> are included an informational RFC of this sort ... the
> IEEE8021-PAE-MIB in draft-ietf-bridge-8021x-02.txt being an example.
> Now, Section 5.2 (entitled "Derivative Works Limitation") says what
> needs to be done in an Internet-Draft if a contributor wants to
> disallow derivative works except for extraction of a MIB or PIB
> module:
>
>    If the Contributor desires to eliminate the IETF's right to make
>    modifications and derivative works of an Contribution (other than
>    translations), one of the two the following notices may be included
>    in the Status of memo section of an Internet-Draft and included in a
>    published RFC:
>
>    a. "This document may not be modified, and derivative works of it may
>       not be created, except to publish it as a RFC and to translate it
>       into languages other than English."
>
>    b. "This document may not be modified, and derivative works of it may
>       not be created."
>
>    In the cases of MIB or PIB modules and in other cases where the
>    Contribution includes material that is meant to be extracted in order
>    to be used, the following should be appended to statement 5.2 (a) or
>    5.2 (b):
>
>       "other than to extract section XX as-is for separate use."
>
>    Notice 5.2(a) is used if the Contributor intends for the Contribution
>    to be published as a RFC.  Notice 5.2(b) is used along with the
>    Publication Limitation in Section 5.3 when the Contributor does not
>    intend for the Contribution to be published as a RFC.
>
> So far, so good.  For draft-ietf-bridge-8021x-02.txt notice 5.2 (a)
> with the extra statement appended would probably be appropriate.
> However, the extra statement would need to need to find its way into
> the Full Copyright Statement in the published RFC, and I didn't see
> a mechanism in the submission-rights draft for this to happen.
>
> A third issue is that the abbreviated notice for MIB and PIB modules
> in Section 5.6 does not seem to seem to be entirely appropriate for
> a MIB or PIB module for which the IETF does not own change control.
> The submission-rights draft says:
>
>    a. in MIB modules, PIB modules and similar material commonly
>       extracted from IETF Documents, except for material that is being
>       placed under IANA maintenance, the following abbreviated notice
>       shall be included in the body of the material that will be
>       extracted in lieu of the notices otherwise required by Section 5:
>
>          "Copyright (C) <year> The Internet Society.  This version of
>          this MIB module is part of RFC XXXX;  see the RFC itself for
>          full legal notices."
>
> Specifically, it does not seem reasonable to me to require mention of
> ISOC but not to allow mention of the organization that originally
> produced the MIB module and that retains change control over it.  In
> fact, I would think that the nature of the copyright notice in the MIB
> module (and even whether there is one) should probably be determined
> by the party that is granting permission to republish it;  after all,
> the abbreviated copyright notice covers a derivative work (the
> extracted MIB module), not the RFC from which it was extracted.
>
> My apologies for not bringing up these issues before.  The truth is
> that they did not occur to me until now.
>
> Mike Heard
>
>
> _______________________________________________
> Ipr-wg mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ipr-wg


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