Comments on draft-ietf-ipr-outbound-rights-02.txt

[Simon Josefsson <simon at josefsson.org>]

Joel, all,

Comments on the entire document, quoted inline, below.

1.  Introduction

   Under the current operational and administrative structures, IETF
   intellectual property rights are vested in a trust administered by a
   board of trustees made up of the members of the IASA.

RFC 4371 says: "The Trustees of the IETF Trust are the members of the
IAOC", not the members of the IASA.  I don't know if this matters in
practice, though.

I also suggest to replace 'vested in a trust' with 'vested in the IETF
Trust', and include a reference to, e.g., RFC 4371.

   contributions, until it is superceded.
                                   ^
Typo, "superseded".

3. Purpose in Granting Rights

Generally, this section is very helpful for the understanding, thanks!

   The IETF's mission is to write documents that help make the internet
   work better (see [2] for more details.)

I suggest to change 'write' to 'produce', since it is actually not the
IETF itself who writes the documents, and to remove the word 'help'.
This is to make the text more consistent with RFC 3935:

,----
|  The goal of the IETF is to make the Internet work better.
| 
|  The mission of the IETF is to produce high quality, relevant
|  technical and engineering documents that influence the way people
|  design, use, and manage the Internet in such a way as to make the
|  Internet work better.  These documents include protocol standards,
|  best current practices, and informational documents of various kinds.
`----

   RFC. this is at best cumbersome, and often much worse than that.  It
        ^

Typo.

   publication.  Changes to the iETF documentation, and document
                                ^

Typo.

   As stated earlier, this document describes the IETFs desires in terms
   of granting rights to those who read or make use of material in IETF
   contributions.  This document does not specify what rights the IETF
   Trust receives from others in IETF contributions.  That is left to
   another document.  While care will be taken by both the working group
   and the IASA to see that sufficient rights are granted to the IETF
   trust in IETF contributions, it is also the case that the trust can
   not grant rights it has not or does not receive, and it is expected
   that policies will be in line with that fact.

That's true, but not the entire story.  It is possible for the inbound
rights to give rights to third parties directly.  Thus, it is possible
for the IETF to grant third parties rights that the IETF doesn't own
itself.

   Similarly, the text for pre-existing documents can not be changed.
   Nonetheless, to the degree it can, and without embarking on a
   massive effort, it is desirable if similar rights to those
   described below can be granted in older RFCs.

I suggest to remove 'and without embarking on a massive effort, '.  It
IS desirable if the same rights can be granted to older RFCs, full
stop. Practical considerations may affect whether it is worth the time
to invest in that massive effort, and I suspect it will never happen
on a full scale, but that doesn't change that the desire to do this is
present.

5.  Recommended Grants of Right to Copy

   The IETF grants rights to copy and modify parts of IETF contributions
   in order to meet the objectives described earlier.  As such,
   different circumstances and different parts of documents may need
   different grants.

I believe that having different licenses for different parts of RFCs
is a bad idea.  I don't think the document discuss the justification
for this decision.  This decision, which may seem minor, will have big
consequences to some organizations.  The Debian community will not be
able to distribute RFCs if the entire RFC isn't available under a
permissive license.

   This section contains subsections for each such
   different grant that is currently envisioned.  Each section is
   intended to describe a particular problem / situation / usage, to
   describe how that situation is recognizable, and to provide guidance
   to the IASA as to what rights the IETF would like to see granted in
   that circumstances, and what limitations should be put on such
   granting.  As stated above, the formulation of legal language for
   granting these rights (including the determination of how many sets
   of legal language are required is largely left to the IASA.
                                                             ^

Typo, a missing closing parenthesis.

   It is particularly noted that there has been a historical issue where
   it is difficult to fix legal wording and boilerplate if the direction
   defining that boilerplate is in an RFC, and then it turns out the
   wording needs modification.  As such, this document does not specify
   such wording.  Further, it is strongly recommended that all future
   RFCs on this topic refrain from defining the precises wording of
   boilerplate.  Similarly, legal issues of how to indicate usage
   restrictions are left to the IASA and legal consel to determine.

I wonder how this will actually work in practice.  Will there be an
RFC that says IETF contributors must conform to legal rules as
specified by <some URL> which can and will be modified at any time by
the IASA?  What are the appeal paths for IETF members who disagree
with the changes of the text that goes into every RFC?

While it has its problems, fixing the legal language in a
community-approved RFC, has the advantage that it re-use the consensus
checks of last calls, and preserve the appeal paths.

   In structuring these desires, it is to be kept in mind that the autor
   has not given up his copyright in granting rights to the IETF, and
   the IETF is not attempting to transfer or relinquish the rights it
   has.  The purpose is to enable to IASA to grant people the right to
   make copies of material in RFCs in ways that fit the goals of the
   IETF.  This discussion is also separate from the rights the IETF
   itself requires in documents to do its job, as those are not
   "outbound" rights.  It is expected that the rights granted to the
   IETF will be a superset of those copying rights we wish to grant to
   others.

There seem to be a hidden assumption here.  Having the inbound rights
document require that contributors directly grant rights to third
parties is a possibility.  I'd like to see more discussions on that,
both in the WG and in the document.  This goes against how RFC 3978
works -- according to Jorge, if I understand him correctly, section
3.3 of RFC 3978 give third parties the right to code directly from the
contributor, and not via the IETF.

5.2.  Rights Granted for Quoting from IETF Contributions

   There is rough consensus that it is useful to permit the quoting
   without modification of excerpts from IETF Contributions.  Such
   excerpts may be of any length and in any context.  Translation of
   quotations is also to be permitted.  All such quotations SHOULD be
   attributed properly to the IETF and the IETF document from which they
   are taken.

I suggest changing 'to the IETF' into 'to the contributor and/or the
IETF'.  Some documents may have been written completely by a single
contributor, without having reached any IETF consensus, and possibly
even with consensus against the document.  Having a suggestion to
attribute it as a work by the IETF would be unfortunate.

5.3.  Rights Granted for Implementing based on IETF Contributions

   IETF contributions often include components intended to be directly
   processed by a computer.  These may be ABNF definitions, XML Schemas
   or DTDs, MIBs, or even classical programming code.

I suggest to replace 'These may be' with 'Examples include', as it is
not clear that the list is not intended to be exhaustive (someone else
raised this concern earlier too).  I also suggest to add 'ASN.1
schemas' since that is frequently a problematic case.

   These are include for clarity and precision in specification.
                    ^
Typo, add 'd'.

   It is clearly beneficial, when such items are included in IETF
   contributions, to permit the inclusion of such code fragments in
   products which implement the contribution.  It has been pointed out
   that in several important contexts, use of such code requires the
   ability to modify the code.  One common example of this is simply
   the need to adapt code for use in specific contexts (languages,
   compilers, tool systems, etc.)  Such use frequently requires some
   changes to the text of the code from the IETF contribution.
   Another example is that code included in open source products is
   frequently licensed to permit any and all of the code to be
   modified.  Since we want this code included in such products, it
   follows that we need to permit such modification.  While there has
   been discussion of restricting the rights to make such
   modifications in some way, the rough consensus is that such
   restrictions are likely a bad idea, and are certainly very complex
   to define.

I believe the same argumentation holds for non-code portions as well.

   Firstly, the IASA should maintain, in a suitable, easily accessible
   fashion, a list of common RFC components which will be considered to
   be code.  To start, this list should include at least the items
   listed above, ABNF definitions, XML Schemas, XML DTDs, and MIBs.  The
   IASA would add to this list as it deems suitable or as it is directed
   by the IETF.

The list above also includes programming code.  I suggest to add both
programming code and 'ASN.1 schemas' here.

5.4.  Rights Granted for use of text from IETF Contributions

   There is no consensus at this time to permit the use of text from
   RFCs in contexts where the right to modify the text is required.  The
   authors of IETF contributions may be able and willing to grant such
   rights independently of the rights they have granted to the IETF by
   making the contribution.

   As such, in crafting legal language and boiler plate, the IASA is
   also asked to resolve and indicate how code segments of IETF
   documents, which can be extracted and subsequently modified, are to
   be indicated by authors and editors as distinct from text segments,
   which can be extract but not modified.

I suggest to add something along these lines:

   The IASA is also asked to resolve and indicate how authors who are
   willing to grant the same rights as for code to the entire document
   should indicate this.

Because I assume that the naive approach of using the IASA-recommended
"<code>"-markers will not be possible to put at the first and last
line of a document.  If there is a Best Current Practice on how to
achieve this, it would allow, e.g., the Debian community to ship those
RFCs that are licensed more permissively.

5.5.  Additional Licenses for IETF Contributions

   There have been contexts where the material in an IETF contribution
   is also available under other license terms.  The IETF wishes to be
   able to include content which is available under such licenses.  It
   is desirable to indicate in the IETF contribution that other licenses
   are available.  It would be inappropriate and confusing if such
   additional licenses restricted the rights the IETF intends to grant
   in the content of RFCS.

   However, the IETF does not wish to have IETF Contributions contain
   additional copyright notices and licenses, as that introduces a
   number of additional difficulties.  Providing the correct legal
   approach to such indications is left to the IASA, as all legal
   language is.  Specifically, additional text in the document, and any
   additional license referred to by permitted additional text MUST NOT
   in any way restrict the rights the IETF intends to grant to others
   for using the contents of IETF contributions.

This doesn't reflect the current "running code" on the copyright
notice issue.  I believe it would be useful to be able to include,
e.g., code under the revised BSD license in an RFC.  That require
adding a copyright notice.  Could you expand on what the 'additional
difficulties' are?  It appears as hand waving to me.

Thanks,
Simon

_______________________________________________
Ipr-wg mailing list
Ipr-wg at ietf.org
https://www1.ietf.org/mailman/listinfo/ipr-wg