On Copying Conditions
Simon Josefsson <jas@extundo.com>

The case for going further than RFC 2026.

Compatibility with free software licenses.

Examples of disallowed “good” uses.

Fear of non-official RFCs.

My proposed license text.

Practical problems today

Debian GNU/Linux cannot include RFCs because the license is considered non-free.

Debian's Free Software Guidelines: http://www.debian.org/social_contract#guidelines

Presumably, Debian would also remove all excerpts from RFCs in software, although no effort to identify all RFC excerpts has been started yet.

Practical problems today

FreeBSD 6.0 remove RFC excerpts from documentation because they fear the IETF license may not permit this use.

getaddrinfo(3), getnameinfo(3), ...

http://www.freebsd.org/releases/6.0R/relnotes-i386.html#DOC

The origin was OpenBSD.

Itojun discussed the issue with IAB. He noticed KAME/Solaris was re-using RFC text in man pages.

RFC 3667 was the then-current license.

Brought to the attention of the IPR WG, which should solve it in 3978, unclear if that happened.

Practical problems today (continued)

Extracting and adapting material from RFCs in source code and source code comments.

In free software, the license typically require that the text must be modifiable.

Apache, Samba, LibIDN, GnuTLS, OpenSSL, BIND, GNU SASL...

Incorporating large tables of data in software.

For example, StringPrep code points and MIME charset names.

GNU Libidn, IBM ICU, VeriSign XCODE, ...

ASN.1 schemas are adapted for use with particular ASN.1 compilers. Heavy modifications, with no intended wire changes.

Practical problems today (continued)

Source code or header files in RFCs. Frequently modified after adaption.

SHA-1, getaddrinfo, Punycode (IDN), SCTP checksum algorithm, ...

Material incorporated into manuals or online help. Frequently modified, to adapt to the target audience.

Other useful usages
where a “field of use” permission would not work

University teacher want to use text material from RFCs in a network course. The modification MAY result in an incompatible protocol.

Develop incompatible behaviour derived from deployed protocols and implementations.

Protocol extensions are typically developed this way. For example, NSEC3 breaks DNSSEC but there are three experimental implementations. Experiments using these software provide feedback to the WG.

My proposed license text

c. The Contributor grants third parties the right to copy and

distribute the Contribution, with or without modification, in

any medium, without royalty. The IETF requests that any

citation or excerpt of unmodified text reference the RFC or

other document from which the text is derived. If the text is

modified in any way other than translation, any claim of

endorsement by the IETF or status within its document series

must be removed.

Fear of non-official RFCs

Problem: Mallory modify a RFC and then claim their modified protocol is a product of the IETF.

Questionable whether this is a practical problem.

Restricting copying conditions does not prevent this threat. Anyone can write a document, not inherited from an RFC, and claim it is an IETF document.

Consequently, restrictive copying conditions is not the proper tool to solve this problem.

Moreover, we have other tools to mitigate this problem, e.g., trademark laws.

IPR WG Charter

A reminder for those of you who didn't read the WG charter:

“If there consensus of the working group for a different IPR policy than the one described in RFC 2026, the working group will seek to amend its charter to make it clear that it is changing the status quo.”

As far as I can tell, no such consensus has been established.

BCP 78 License

a. To the extent that a Contribution or any portion thereof is

protected by copyright and other rights of authorship, the

Contributor, and each named co-Contributor, and the organization

he or she represents or is sponsored by (if any) grant a

perpetual, irrevocable, non-exclusive, royalty-free, world-wide

right and license to the ISOC and the IETF under all intellectual

property rights in the Contribution:

...

RFC 2026 License

Copyright (C) The Internet Society (date). All Rights Reserved.

This document and translations of it may be copied and furnished to

others, and derivative works that comment on or otherwise explain it

or assist in its implmentation may be prepared, copied, published and

distributed, in whole or in part, without restriction of any kind,

provided that the above copyright notice and this paragraph are

included on all such copies and derivative works. However, this

document itself may not be modified in any way, such as by removing

the copyright notice or references to the Internet Society or other

Internet organizations, except as needed for the purpose of developing

Internet standards in which case the procedures for copyrights defined

in the Internet Standards process must be followed, or as required to

translate it into languages other than English.

The limited permissions granted above are perpetual and will not be

revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an

"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING

TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT

NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN

WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF

MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Missing from BCP 78

Right to make the derivative works permitted by RFC 2026.

My goal here: going further than RFC 2026, to align with needs from the free software community.

The right to distribute unmodified RFCs:

Addressed in Scott's -01 draft, after I raised this issue. Word crafting still required.

My proposal solve this issue through license text.

2005-11-03T20:26:49