Subject: Re: One copyright issue or Two?

From: Simon Josefsson <[email-masked]>
Date: Thu, 08 Dec 2005 18:54:31 +0100

"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

---

From: Florian Weimer <[email-masked]>
Date: Thu, 08 Dec 2005 23:53:08 +0100

>          determine if such differences with RFCXXXX (if they exist)

Okay, what about this one:

| For legal reasons, we must include the following warning notice in
| this specification:
| 
|   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.
|
| However, as far as we know, the present specification is fully
| interoperable with RFCXXXX.

Does this really make sense?  Suppose you combine multiple RFCs, do
you need to add a warning for each one?