Re: "Field of Use" approach to allowing RFC text modifications

[Simon Josefsson <jas at extundo.com>]

Black_David at emc.com writes:

> This is a change I am proposing to BCP 78 - it allows anyone to make
> modifications to the RFC in support of an implementation that qualifies
> as an implementation of the original RFC.

Right.  I think that is a good idea, and a step in the right
direction.  The problem I see is that it is complicated to define
"qualify as an implementation of the original RFC".

There are situations where implementations deviate from the RFC, to
fix real problems or to make optimizations.  If the changes prove
useful, they will sooner or later end up documented in a IETF
standard.  I believe this is how most changes to historic protocols
such as DNS or SMTP was developed.  The protocol documents usually
came after implementations has started using a certain behavior.

Since I see no serious problem in liberating the copying conditions
further, and several advantages, I have proposed to move further than
your proposal.

>> If the matter is security sensitive, waiting weeks (not to speak of
>> the months that a RFC Errata take to publish) is not workable.  While
>> you could solve that problem by speeding up the process, I think the
>> principle here is flawed.  That's why I'm arguing for reverting to the
>> RFC 2026 copying conditions, or even improving them to be compatible
>> with free software licenses and policies, when we are re-visiting this
>> area anyway.
>
> This is silly.  The RFC Editor's errata process needs to be fixed.

I'm not arguing against that.  Of course the RFC errata process should
be fixed.  I'm saying that fixing the RFC Errata won't solve
everything.

>> > The place where I part company with this philosophy is the desire to
>> > make RFC modifications outside the IETF.  IMHO, the right approach to
>> > doing the sort of thing described here is to make the modifications to
>> > the RFC and submit the result as an Internet-Draft, taking advantage of
>> > the fact that unlimited derivative works are allowed within IETF.  As
>> > long as the new Internet-Draft uses the unrestricted boilerplate, the
>> > text should then be usable in the fashion desired, but must (correctly)
>> > be cited as coming from the Internet-Draft.
>> 
>> Please re-read my draft, and in particular the example usages.  We are
>> talking about modifications that are done to adapt the RFC text into a
>> particular manual or (in the case of ASN.1 compilers or C header
>> files) a particular environment.
>
> Please reread my "field of use" proposal at the top of the email.  It
> allows all 5 examples in your draft without permission from the IETF
> or notice to the IETF in any form.

Without seeing a specific license text proposal, I can't agree.  There
are many subtleties in crafting such license text, and it may turn out
that some aspect of my examples would not be permitted with your
license text.

>> It is particularly bad to use restrictive copying conditions to
>> prevent frauds because of the consequences that has for free software
>> developers.
>
> I believe that the "field of use" proposal grants most if not all the
> rights that open software developers need, including the 5 examples in
> your draft.  What isn't covered?

1) When incorporating material into a free software product, the
   license typically permit further modifications without
   restrictions.  I think users should have the right to take my IDN,
   SASL, Kerberos 5 etc implementations, modify them and experiment
   with the result to see if it works or not.  This may involve
   protocol incompatible modifications.  I believe this is how
   protocols are evolved.  Take for example the current work done in
   the DNSEXT WG on NSEC replacements.  There are patches available
   for the DNS server BIND that implement the NSEC3 proposal.  Those
   patches break DNSSEC RFC conformance.

2) I received this example from a University teacher.  He wanted to
   have the right to adapt RFCs for his course material.  This may
   involve modifications that are not compatible with the IETF
   protocol, but are useful to illustrate something for the student.

Without seeing your proposed license text, it is impossible to tell
what things are not covered.  These are two examples that came to
mind.

>> > b) Actual errors need to be reported as errata, even though the RFC
> Editor
>> > 	has not been doing a good job on these lately.  Once the RFC Editor
>> > 	publishes a correction as an errata, the correction then falls
>> > 	under the unlimited distribution of the unmodified RFC (i.e., it
>> > 	no longer counts as a "derived work").
>> 
>> Right.
>> 
>> You are forgetting about modifications that are not essential to the
>> protocol, and that are not interesting for the IETF.  Such
>> modifications can be substantial, yet they are uninteresting to the
>> IETF.  These modifications can be made because an ASN.1 schema had to
>> be rewritten to be compatible with a particular ASN.1 compiler.  Etc.
>
> If it's a technical change, it needs to be an errata.  Your claim that
> editing the ASN.1 does not constitute a technical change has been
> disputed on this list - please find a better example if you want to
> continue to make this argument.

Huh??

I have explained that all free Kerberos 5 implementations include
heavily modified ASN.1 schemas.  You can download them yourself and
look at the changes if you don't believe me.  None of the
modifications modify the wire protocol.  This example has certainly
not been disputed.  The same apply to GSS-API header files and IDN
code point tables too.

However, I agree that your proposed license change may permit these
usages.

Regards,
Simon

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