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

From: [email-masked]
Date: Mon, 07 Nov 2005 20:35:39 +0000

-------------- Original message ----------------------
From: Simon Josefsson <[email-masked]>
> [email-masked] 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.

This assumes that no one would want to patent a derivative work of an IETF standard. One of the key flaws in the IETF's Process is that it doesn't mandate how the IP is used in its standards and that opens the possibility that someone could in fact patent IETF derivatives... and not have those fold back into the ITEF.

> 
> 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.

Amen to that.

> 
> >> > 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ipr-wg

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

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 07 Nov 2005 22:01:14 +0100

[email-masked] writes:

> This assumes that no one would want to patent a derivative work of
> an IETF standard. One of the key flaws in the IETF's Process is that
> it doesn't mandate how the IP is used in its standards and that
> opens the possibility that someone could in fact patent IETF
> derivatives... and not have those fold back into the ITEF.

While I would be happy to discuss patent licenses, I think we should
separate these two issues.  I will focus on copying conditions and the
license we grant to third parties with respect to copyright.  I see
these two issues as orthogonal.

Thanks,
Simon