Re: New version of my proposal posted

[Simon Josefsson <jas at extundo.com>]

Black_David at emc.com writes:

> Simon,
>
>> 2) Examples of problems has been listed for problem #1, i.e., that BCP
>>    78 disallow derivative works that were permitted under RFC 2026.  I
>>    also expanded slightly on the discussion regarding this problem.
>>    Being able to take portions of RFCs, modify them and send to the
>>    RFC errata appear to be another example, but I didn't have time to
>>    add it.
>
> I talked to one of EMC's lawyers about this.  The lawyer suggests that
> any automatic grant of copyright for anyone to make derivative works be
> limited a specific field of use, namely implementation of the original
> unmodified RFC from which the text was derived.

David,
That appear to be what RFC 2026 said (in "and derivative works that
[...] assist in its implmentation [sic] may be prepared, copied [...]
without restriction of any kind").  RFC 3978 removed that right.

> This addresses all five of the examples in your draft while clearly
> blocking someone who makes a minor incompatible change to the RFC,
> as the incompatibility places the result outside the field of use,
> hence blocking the automatic grant of copyright (which is the
> desired outcome).

This argument sound compelling, and in a perfect world, it might work.

However, I see two problems here.  The first is philosophical, and the
second is practical.

Philosophical: I believe granting the right to modify RFCs lead to a
   better working Internet, and better standards, in the long run.
   The reason is that people can build on past protocols and make
   minor changes to adapt it to their needs, and make a product.  If
   the implementation gain market shares, it may eventually be useful
   to standardize the protocol in IETF, but standardizing shouldn't be
   required before deploying a product that include a modified
   protocol description.  Historically, implementations preceded IETF
   standardization, and from the protocols I'm involved in, this is
   often the case.

Practical: RFCs are frequently ambiguous and sometimes they even
   contain errors or internally inconsistent descriptions.  A recent
   example is the Unicode 3.2 NFKC algorithm which IDN is using.  When
   implementing a RFC, it is sometimes necessary to make an
   interpretation of the text, because it is not fully specified.  I
   believe implementers must have the right to make these
   interpretations, without consulting a IETF consensus on what the
   correct interpretation is, before deploying their product.  Waiting
   for the IETF to revise and update a RFC before they can finish
   implementing their product is ridiculous.

I wouldn't agree that the RFC 2026 license fully solve the problems
listed in my draft.  It may solve many practical instances of the
problems, but not all.

> The right to reproduce and distribute an RFC without modification
> should remain unlimited.

Right.  I don't anyone dispute that.

> Beyond this, for situations like the one I described in a previous
> message, I prefer Scott's approach of acquiring sufficient rights to
> enable the IESG to permit derivative works outside the IETF when that
> is the proverbial "right thing to do".

As far as I understand -- there is a lack of public information about
the relationship between the IETF and the IPR Trust -- the IESG
doesn't have that right either.  Only the IAOC members will have that
right, because they control the IPR Trust.  See
<http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg01603.html>,
specifically:

,----
| The Trustees will be the members of the IAOC.
...
| The Trust (acting through the Trustees) shall have the right to grant
| licenses for the use of the Trust Assets on such terms, as the Trustees
| deem appropriate; provided, however, that the Trust shall not grant any
| license that would be deemed a transfer of ownership or abandonment of any
| Trust Assets under applicable law.
| 
| Initial contributed IPR shall be (as far as the parties' rights extend):
| 
| -   Trademarks
| -   Domain names
| -   Current databases, mailing lists, web pages, working group
|     and IESG materials
| -   Current I-Ds and RFCs
| -   Rights in extracted historical data (records of past meetings,
|      past I-Ds and RFCs and their processing history)
`----

I also note that this would include past I-Ds and RFCs, which if I
understood Jorge correctly, would be legally questionable.  It doesn't
seem like the IPR Trust would have the rights to grant others rights
to past I-Ds or RFCs.

Regards,
Simon

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