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

From: [email-masked]
Date: Mon, 7 Nov 2005 14:28:41 -0500

NB: Changed subject line to make it clear what this is about.

> [email-masked] writes:
> 
> > Simon,
> >
> >> > 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 [to] a specific field of use, namely implementation of the
original
> >> > unmodified RFC from which the text was derived.

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.

> >> However, I see two problems here.  The first is philosophical, and the
> >> second is practical.
> >
> > I disagree with an important aspect of the philosophy, and believe that
> > the practical issue is actually not a problem in practice because it's
> > based on the (IMHO incorrect) assumption that clarifications and
> > corrections require a new RFC.
> 
> I have not assumed that.
> 
> Clarifications and corrections do, however, require contacting the
> IETF and publishing the update.
> 
> 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.

> If the modifications are non-essential for the IETF -- i.e., removing
> a column in a table with forward references -- then I believe it would
> be flooding the I-D editor with work to publish every minor
> modification I make to RFCs when I incorporate them into my manual.

I agree - the "field of use" proposal allows this without asking the
IETF for anything, or telling the IETF that anything's been done.

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

> I can make a script that will send the I-D editor a copy of my GSS-API
> header file whenever it is modified in my CVS repository.  I doubt the
> IETF would find any value in that.  Yet, it appears to be the
> consequence of what you propose.

No, it is definitely not.  If the *implementation* meets the protocol
requirements of the RFC, then the "field of use" scope for modifying the
*text* of the RFC allows the implementer to make any text modifications
needed for documentation, source code, etc.
> 
> > There are two crucial results from this that do not occur when the RFC
> > is modified outside IETF:
> > (1) The IETF then knows about the modification up front.  The technical
> > 	community involved might even be able to improve on the
> > modification.
> 
> Again, the modifications I'm talking about include non-essential
> modifications, to adapt the work for a particular environment.  Why
> are such modifications useful to publish in the IETF?

Those modification would not need to be published.  What needs to be
published are actual technical changes to the protocol, especially
those that affect interoperability.

> > (2) Users of the software are not misled into believing that the
> > 	modified implementation conforms to/complies with the original RFC.
> > The latter is fairly important, as engaging in that sort of misleading
> > behavior (saying something is an implementation of the RFC when it is
> > not) is usually called "fraud".  It's certainly fine to describe the
> > new Internet-Draft as (in the draft author's opinion) an improvement to
> > the original RFC.
> 
> I strongly disagree that copying conditions should regulate this.  I
> think you are inventing arguments here.  If somebody would imply their
> modified work is a work of the IETF, that is fraud and should be dealt
> with as such.  Liberating copying conditions will not lead to a free
> haven for fraudsters.  These are two orthogonal issues.

We have to agree to disagree on this point.  The absence of legal right
to use the text is a much more powerful tool to stop bad behavior and
make things right.

> We have already explained that copying conditions do not protect
> against this scenario anyway.  Anyone can write a specification and
> claim it is the work of the IETF without basing their effort on an
> existing RFC.  I don't believe copying conditions are the legal
> instrument you want to use here.

If I write a specification from scratch and claim that it's RFC nnnn,
it's easy to discover that it isn't.  If I make minor modifications
to that RFC, it's much harder.

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

> >> 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.
> >
> > There are actually two different situations here:
> > a) Interpretations, clarifications, etc. would be within the "field of
use"
> > 	of implementation of the original RFC, and hence would be covered
> > 	under the proposed automatic grant of copyright.
> 
> Which grant are you talking about here?  BCP 78 does not include
> anything like that.  RFC 2026 did.

See start of this message.
 
> > 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.  

> > In neither case would a revised and/or updated RFC (and the time
involved
> > in getting it published) be required.
> 
> I don't believe I have claimed that it would be required.
> 
> Concluding, I don't think you have shown that restrictive copying
> conditions further the goals of the IETF.  I believe permitting
> modifications of the RFCs, even beyond what RFC 2026 permit, would be
> a good thing in the long run.  The dangers that have been expressed --
> that someone claim their modified RFC is the real thing -- can be
> dealt with, and has been dealt with for decades within the software
> industry.  You can't take someone's software, modify and claim that it
> is the original author's work.

This is an exercise in strawman demolition.  I am not arguing for the
current "restrictive copying conditions", but rather for a "field of
use" approach to liberalizing them.  Please spend a little more time
understanding my emails before jumping to this sort of conclusion.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

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

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 07 Nov 2005 21:09:08 +0100

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

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

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

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

> 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