Subject: Re: One copyright issue or Two?

From: [email-masked]
Date: Thu, 08 Dec 2005 20:27:10 +0000

Simon - the problem is that the abandonment of those controls implies that the IETF no longer controls those IP's, and that is the issue which would blow up in a Court.

Todd Glassey
 -------------- Original message ----------------------
From: Simon Josefsson <[email-masked]>
> "Powers Chuck-RXCP20" <[email-masked]> writes:
> 
> > Simon,
> >
> > Although I have yet to see anything in your arguments which indicates
> > that normative RFC text _must_ be used to document code, it is apparent
> > that you feel that it would be impossible to not do so. Therefore, on
> > that we must simply agree to disagree.
> 
> Ok.
> 
> I urge you to take a look of free implementations of some IETF RFCs.
> 
> Free implementations quote the RFCs in several places.  I claim that
> removing all existing excerpts, and erasing the long-standing
> tradition among developers to quote RFCs in source code and manuals,
> is practically impossible.
> 
> Further, I don't understand what removing the excerpts, or the
> tradition, would contribute to.  These excerpts are a good thing.
> That's why I propose that IETF should change its copying conditions to
> align with reality.  I believe it is the right thing to do.
> 
> > However, to the text of your proposal:
> >
> >>     c.  The Contributor grants third parties the irrevocable
> >>         right to copy, use and distribute the Contribution, with
> >>         or without modification, in any medium, without royalty,
> >>         provided that unauthorized redistributed modified works
> >>         do not contain misleading author, version, name of work,
> >>         or endorsement information.  This specifically implies,
> >>         for instance, that unauthorized redistributed modified
> >>         works must not claim endorsement of the modified work by
> >>         the IETF, IESG, IANA, IAB, ISOC, RFC Editor, or any
> >>         similar organization, and remove any claims of status as
> >>         an Internet Standard, e.g., by removing the RFC
> >>         boilerplate.  The IETF requests that any citation or
> >>         excerpt of unmodified text reference the RFC or other
> >>         document from which the text is derived.
> >
> >    This is a start, but does not go nearly far enough in notifying
> > downstream users that changes have been made, and that caveat emptor is
> > now a necessary rule for use, since we cannot assume that those
> > producing the modified works in question will adequately document where
> > their implementation differs from that of the RFC, risking harm to the
> > unwary adopter of their work. Therefore, I believe that is should be
> > amended as such:
> >
> >      c.  The Contributor grants third parties the irrevocable
> >          right to copy, use and distribute the Contribution, with
> >          or without modification, in any medium, without royalty,
> >          provided that unauthorized redistributed modified works
> >          do not contain misleading author, version, name of work,
> >          or endorsement information, and that the following text
> >          is included in any subsequent distribution:
> >
> >          "Warning: This text describes a derrivative of the
> >          standard defined in RFCXXXX; the reader should be warned
> >          that this modified work may not operate in a way that is
> >          compatible with the protocol defined in RFCXXXX, and that
> >          using this modified work could result in incompatability
> >          with RFCXXXX, and thus fail to interoperate properly with
> >          compliant implementations of RFCXXX. Therefore, the reader
> >          is strongly urged to carefully review this documentation
> >          and the code it accompanies, to determine where this
> >          implemention is potentially incompatible with RFCXXX, and
> >          determine if such differences with RFCXXXX (if they exist)
> >          are acceptable."
> >
> >          In addition, any unauthorized redistributed modified
> >          works must not claim endorsement of the modified work by
> >          the IETF, IESG, IANA, IAB, ISOC, RFC Editor, or any
> >          similar organization, and remove any claims of status as
> >          an Internet Standard, e.g., by removing the RFC
> >          boilerplate.  The IETF requests that any citation or
> >          excerpt of unmodified text reference the RFC or other
> >          document from which the text is derived.
> >
> >    This would allow anyone who wanted to take and run with the RFC text
> > to do so, while ensuring that the bar for "improving" the standard
> > originally defined in the RFC (and thus potentially harming
> > interoperability) would be high enough that those wishing to make the
> > change would need to have a solid reason for doing so, and would need to
> > convince those who might use their code that they had good reason to
> > make the changes, and to clearly identify where those changes have been
> > made. Call it the IETF warning label...
> 
> I don't object directly to this proposal, one practical observation:
> 
> Adding the above quote to every small excerpt of RFC text in an
> implementation seem unnecessary.
> 
> For example, in my DIGEST_MD5 implementation, the code may look like:
> 
>   /* This directive MUST appear exactly once if "auth-conf" is
>      negotiated; if required and not present, authentication fails.
>      If the client recognizes no cipher and the server only advertised
>      "auth-conf" in the qop option, the client MUST abort the
>      authentication exchange.  */
>   if (r->qop == DIGEST_MD5_QOP_AUTH_CONF && !r->cipher)
>     return -1;
>   if (r->qop != DIGEST_MD5_QOP_AUTH_CONF && r->cipher)
>     return -1;
> 
> The comment is a quote from the DIGEST-MD5 draft.
> 
> I believe the IETF may suggest that I should add a reference to the
> DIGEST-MD5 draft in my document, but adding the above warning label
> seem non-productive.  My implementation is intended to be a compliant
> implementation.
> 
> But I think there is room to move ahead with your approach, if we can
> make some minor adjustments.  I believe simply removing all references
> to IETF etc is sufficient.  If you believe adding a "warning label"
> would be required, we could continue to discuss the actual text.
> 
> I'll forward this idea to debian-legal as well, to see if they have
> some objections to this approach.  I can't recall any existing open
> source license that use this approach, the only thing I can recall is
> requests for "avoid calling the product the same and clearly label all
> files as being modified by you".
> 
> >    IMO this would also solve the "Fake RFC" problem, assuming that those
> > wishing to fake an RFC would follow the copyright rules in the first
> > place.
> 
> I think we need to assume that.  If someone is not following the
> rules, he can anything anyway.  Legal actions can be used against
> people not following the license.
> 
> >    In addition, by the way, you must ensure that the "Contributor" is
> > listed among those who from whom the author of the modified work cannot
> > claim endorsement from; one of the primary concerns from some I have
> > talked to regarding this issue is that they make a contribution to an
> > IETF standard, and then someone else takes their text, reuses it in
> > modified form, and claims that it is from, or endorsed by, the original
> > contributor. Therefore, you cannot limit the list to only the IETF and
> > related organizations; it has to include the original contributor as
> > well.
> 
> Ah, well spotted!  I agree.  Thank you, I have incorporated this.
> I'll post the updated license text in a separate post.
> 
> Thanks,
> Simon
> 
> >
> > regards,
> >
> > Chuck
> >
> >
> >
> >> -----Original Message-----
> >> From: Simon Josefsson [mailto:[email-masked]] 
> >> Sent: Monday, November 21, 2005 3:46 PM
> >> To: Powers Chuck-RXCP20
> >> Cc: [email-masked]
> >> Subject: Re: One copyright issue or Two?
> >> 
> >> 
> >> "Powers Chuck-RXCP20" <[email-masked]> writes:
> >> 
> >> >> Secondly, the text of RFCs is widely used inside comments in
> >> >> source code.  This is example 1 in my draft.  Several free 
> >> >> software projects do this today (Apache, Samba, ...).
> >> >> 
> >> >> I have not gotten the impression that how RFCs are used in
> >> >> open source projects is something the IETF want to forbid.  I 
> >> >> believe it would be better to harmonize the legal text with 
> >> >> how IETF standards are used.
> >> >
> >> > I don't think anyone wants to, or has even implied that 
> >> they want to, 
> >> > forbid the legal use of RFCs in open source projects. But simply 
> >> > pointing to folks who _may_ have been using that text in 
> >> violation of 
> >> > IETF copyrights and saying "you have to let them keep doing 
> >> it" is not 
> >> > really the right approach to solving the problem, IMO.
> >> 
> >> There is no legal use of RFCs in open nor closed source 
> >> projects today.  Third parties have NO rights whatsoever to 
> >> RFCs.  Third parties are not granted a right to copy and 
> >> distribute RFCs, even unmodified, according to RFC 3978.
> >> 
> >> >> Example 1 and 5 in my draft is about this.  RFC text is
> >> >> useful as commentary in source code or documentation.  To 
> >> >> adapt the commentary for a specific audience, you need the 
> >> >> right to make modifications to it.
> >> >> 
> >> >> Compare the getaddrinfo man page in Solaris.  I think Sun
> >> >> made good decision by using the RFC text there, and that the 
> >> >> IETF should support that behaviour.  Using the RFC text 
> >> >> minimize accidental errors introduced by a re-write.  They 
> >> >> have a standard for how man pages should look, so they had to 
> >> >> modify the text in some ways.  That's fine too.  But there 
> >> >> are no legal rights granted to permit that now. That's a problem.
> >> >
> >> > I understand that RFC text can be useful in documentation; 
> >> but again, 
> >> > that doesn't mean that is it essential, e.g. "that is the only 
> >> > possible way to document my code" - is it a nice to have, it is 
> >> > awfully convenient to use, but being restricted from modifying RFC 
> >> > text would not prevent anyone from documenting their code, 
> >> whether it 
> >> > conformed with an IETF protocol or not.
> >> 
> >> This belittle the point of standardization in the first 
> >> place.  The reason for standardizing something in the IETF is 
> >> that it should promote a better Internet.  Making it possible 
> >> for implementers to use the text in their products further that goal.
> >> 
> >> If the license permit fake RFCs, that can be dealt with 
> >> separately, and it has -- please read my latest license text 
> >> -- so this is not a good argument for disallowing 
> >> redistribution of modified works.
> >> 
> >> >> > and therefore risking all of the potential harm, to both the IETF
> >> >> > process and to interoperability, that I believe could ensue.
> >> >> 
> >> >> I believe the fear here is mis-placed.  The open source
> >> >> community permit free modifications, and while there 
> >> >> certainly has been forks, none of them indicate that there is 
> >> >> any long-term harm for the Internet.  Quite the contrary, the 
> >> >> major forks (e.g., OpenBSD) contribute to a better working 
> >> Internet.
> >> >
> >> > Having dealt with interoperability issues in standards for a long 
> >> > time, I believe there is significant risk in forking of IETF 
> >> > protocols, particularly if the normative text of an RFC can 
> >> be used to 
> >> > document the changes, but with no obligation to clearly 
> >> state how the 
> >> > revised code differs from the original implementation. We must 
> >> > remember that there are those to whom a lack of interoperability is 
> >> > desirable, for a variety of business and tehcnology reasons, and 
> >> > giving them the ability to make their variants appear more 
> >> valid does 
> >> > not seem prudent to me, if it risks reducing the value of the work 
> >> > being done in the IETF.
> >> 
> >> Nobody wants to permit fake RFCs.  Can you describe a 
> >> realistic scenario in which someone could create a derivative 
> >> work of an RFC that is permitted through my latest license text:
> >> 
> >>     c.  The Contributor grants third parties the irrevocable
> >>         right to copy, use and distribute the Contribution, with
> >>         or without modification, in any medium, without royalty,
> >>         provided that unauthorized redistributed modified works
> >>         do not contain misleading author, version, name of work,
> >>         or endorsement information.  This specifically implies,
> >>         for instance, that unauthorized redistributed modified
> >>         works must not claim endorsement of the modified work by
> >>         the IETF, IESG, IANA, IAB, ISOC, RFC Editor, or any
> >>         similar organization, and remove any claims of status as
> >>         an Internet Standard, e.g., by removing the RFC
> >>         boilerplate.  The IETF requests that any citation or
> >>         excerpt of unmodified text reference the RFC or other
> >>         document from which the text is derived.
> >> 
> >> If you can't find a loophole in that text that permit fake 
> >> RFCs, I don't believe it is fair to use it as an argument to 
> >> forbid a free source compatible license for IETF Contributions.
> >> 
> >> > Alas, I still haven't seen any arguments which contradict 
> >> my point - 
> >> > that it is easy and convenient to use the RFC text for 
> >> documentation, 
> >> > but it is not _essential_ to do so in order to document one's code.
> >> 
> >> We have been over this many times.  The explanation is that 
> >> to be able to include excerpts from an RFC in free software 
> >> products, e.g. in source code, the right to make modification 
> >> must be granted, otherwise it is incompatible with both the 
> >> BSD and GPL license.
> >> 
> >> If we do not grant the right to adapt portions of RFCs in 
> >> products, all RFC excerpts will have to be modified from free 
> >> software implementations.  That is a huge task that would 
> >> work against the goals of the IETF; to permit a smoother 
> >> running Internet.
> >> 
> >> > In fact, I am not against using RFC text for documenting 
> >> > implementations of RFC protocols. I am, however, very 
> >> concerned that 
> >> > allowing the free use _and modification_ of normative text could 
> >> > result in incompatible implementations of IETF protocols 
> >> with no clear 
> >> > indication that what has been implemented is no longer 
> >> interoperable.
> >> 
> >> I don't disagree.  The license above is meant to prevent that 
> >> situation.  Could you try to improve it to make sure what you 
> >> are worried about cannot happen?
> >> 
> >> Thanks,
> >> 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: Thu, 08 Dec 2005 22:29:09 +0100

I don't follow what you mean.  The free software community publish a
large amount of written documentation, probably comparable to or more
than what the IETF publish.  The free software community use similar
copying conditions as the conditions that I propose, without any
serious problems as far as I'm aware.  I believe it would benefit the
IETF to use similar conditions.