Guidelines for Free Standards in the IETF
draft-josefsson-free-standards-howto-02

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on October 25, 2008.

Abstract

This document discuss copyright and patents in standard documents from a free software perspective. The document contains instructions for document authors who wish to encourage and enable free software implementations of their standard. It can also be used as a check-list for document reviewers and patent license reviewers.

Table of Contents

1.  Introduction, or, What Is a Free Standard?
2.  Intended Audience
3.  Copyright Concerns
4.  Patent Concerns
    4.1.  What To Look For In A Patent Disclosure
    4.2.  Handling Submarine Patents
    4.3.  Example License Text
    4.4.  Non-assertion Claims
5.  Frequently Asked Questions
    5.1.  Why Not Use A Well-Known Free Copyright License?
    5.2.  Why Isn't It Sufficient To Use A Free License For Code
6.  Acknowledgments
7.  References
§  Author's Address
§  Intellectual Property and Copyright Statements

1.  Introduction, or, What Is a Free Standard?

A natural first question is "What is a free standard?". Unfortunately, we are not aware of any precise academic definition of a free standard. Basic criteras for free standards may include that the standard is available free of charge to anyone, or that it is possible to implement the standard by everyone.

We will not develop a clear definition of "free standard". Instead, we take a pragmatic and incremental approach. We observe problems that implementers and distributors have had with existing standards related to freedom aspects. We have drawn some conclusions from these observations, and we attempt to formulate these as guidelines, suitable for those who share these concerns.

There are two main problems when implementing standards: copyright licenses and patents.

Other areas, such as trademarks, are less problematic in practice. In particular, if the copyright license concern is resolved, any trademark concern can be solved by renaming the trademark word. A good example of this is [ICEWEASEL] (Wikipedia, “Iceweasel,” .).

This topic is complex and rapidly evolving. It is expected that this document will be revised when new IETF rules are approved, or when new concerns are brought up.

2.  Intended Audience

This document was written for authors and readers of IETF documents who are concerned with freedom issues. The document is written from the point of view that standards should be free to use and implement by everyone, which is a personal preference.

If you are the author of an IETF document, this document will recommend certain copyright-related additions to your document and hints on how to write a patent disclosure. This is intended to make it more likely that the document will be met positively by implementers, especially those in the free software community. That often leads to faster and wider implementations of your technology.

Readers of IETF documents need to be careful and aware of certain things (i.e., patents) that may affect the freedom of a document, and we give recommendations for what to look out for.

In some working groups, there is resistance against adopting encumbered technology. This document may be useful to serve as a check-list for reviewers, and can also provide background information for new members.

3.  Copyright Concerns

It is widely regarded as a problem when standards are not available publicly, or when they do not allow public distribution. A traditional example that has been regarded as a problem in the IETF community are ISO/ITU standards, which are available for a fee under the condition that you do not redistribute it. A reasonable requirements on a free standard is that it is possible to distribute to everyone for free.

Further rights may be needed to implement a standard. Sometimes, a standard contains instructions intended for machines, for example ASN.1 schemas, MIB modules, data tables. To include machine-readable parts of a standard into a free software implementation, which is a reasonable requirement on a free standard, the license has to permit modification of said part and be compatible with typical free software licenses.

If a goal with the standard is to facilitate the fastest spread and adoption of the standard, further rights to the document will help further that goal. For example, when text in the standard is used as starting point for documentation or educational material about the technology. A reasonable requirement here would then be that the entire document is available under a license compatible with typical free documentation and software licenses.

The IETF rules (see [RFC3978] (Bradner, S., “IETF Rights in Contributions,” March 2005.)) related to the copying license on the standards have a few problems. Some problems, such as the inability to redistribute RFCs by third parties, have been acknowledged and solutions are being worked on.

A basic problem is that IETF standard documents are not licensed in a way that make it possible to re-use the text of the standard in implementations (code or manuals).

For example, the Debian GNU/Linux distribution have rules that requires included material to be available under a license that permits modification and redistribution. IETF Standards documents fail this test, and consequently they are not distributed with Debian.

A serious problem is when standards contains code-like portions that are required to be included in conforming implementations. Examples include ASN.1 schemas and data tables. Revising the IETF rules to make this possible is underway in the IPR WG, although we have yet to see the license text that will be used.

To adress these problems, we suggest that authors place the following copying license in their documents. This license has been found compatible with free software licenses, and acceptable to some RFC authors ([RFC3492] (Costello, A., “Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA),” March 2003.), [RFC4398] (Josefsson, S., “Storing Certificates in the Domain Name System (DNS),” March 2006.), [RFC4737] (Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S., and J. Perser, “Packet Reordering Metrics,” November 2006.)).

      Regarding this entire document or any portion of it (including
      the pseudocode and C code), the author makes no guarantees and
      is not responsible for any damage resulting from its use.  The
      author grants irrevocable permission to anyone to use, modify,
      and distribute it in any way that does not diminish the rights
      of anyone else to use, modify, and distribute it, provided that
      redistributed derivative works do not contain misleading author
      or version information.  Derivative works need not be licensed
      under similar terms.

4.  Patent Concerns

A reasonable requirement on a free standard is that everyone is free to implement it. Patents may be used to restrict that right, and there are many examples where patented technology cannot be implemented widely.

The IETF rules (see [RFC3979] (Bradner, S., “Intellectual Property Rights in IETF Technology,” March 2005.)) demands that contributors notify the IETF when they submit, or even discuss, documents with patented technology (as far as the authors are aware of). Third parties are also encouraged to submit disclosures about patented technology in others' documents. (To understand the full policies, which are not easy to explain in a few sentences, the reader is kindly referred to RFC 3979.)

This process does not guarantee that all IETF documents will have no patent concerns. That was not the intention, and there are several documents with a complicated patent situation. One example is the standards-track use of the patented RSA public-key algorithm. Fortunately, the IETF process encourages and makes it easy to verify whether there are known patents for a particular document.

If a document contains technology that is known to be patented, it may complicate the use of the technology in free software environments, but it depends on the conditions placed by the patent owner.

The first conclusion here is that readers will have to search the online "IETF IPR Disclosure" page at <http://www.ietf.org/ipr/> for the document they are interested in.

4.1.  What To Look For In A Patent Disclosure

An alternative title for this section may be 'How To Write A Free-Software Friendly Patent Disclosure'.

Words to look for in a patent license is free-of-charge, world-wide, royaltee-free, perpetual and non-exclusive right to the patent.

Some patent disclosures demands that you to write to the patent owner and request a license. Such a clause leads to problems if a company goes away or won't respond to requests. Depending on the text used, it may even require that every user of the software is required to apply for a license. That is not feasible for free software, which is widely distributed to everyone. The recommendation here is that the license should grant rights directly to third parties.

Some patent licenses restricts how you can use the technology. This causes an incompatibility with many free software licenses, which says that no additional restrictions may be placed on the redistribution of the software. Further, free software is intended to be generally useful. If one field-of-use is restricted, that goes against the spirit of free software. The recommendation here is that patent licenses should not impose any additional restrictions before granting the rights.

A clause in the patent license that licensee's license to the patent is revoked when the licensee sue the patent holder for patent infringement does not limit the ability to implement a standard. Such clauses have been successfully used to protect the patent owner.

4.2.  Handling Submarine Patents

In some cases, patent disclosures are filed late in the process. It may after a WG has accepted a document, after it has been last-called, after it has been approved by the IESG, or even after it has been published as an RFC. We call such late notification of earlier patents as a submarine patent.

If the document has already been approved as an RFC, the published document itself cannot be modified. However, the documents' status on the standards track can be modified by publishing an approved document containing the reasons for doing so. If the patent disclosure is not considered to grant sufficient rights to third parties, it is recommended to consider alternative technologies and to write a document moving the RFC with patented technology off the standards track.

In the other situations, it is recommended that interested parties evaluate the patent disclosure and re-evaluate their earlier decision to accept, last-call or approve the document.

4.3.  Example License Text

Here is a simplistic patent license that appear to grant third parties the necessary rights in order to use it in free software.

  Subject to the terms and conditions of this License, X
  hereby grants to You a perpetual, worldwide,
  non-exclusive, no-charge, royalty-free, irrevocable
  (except as stated in this License) patent license for
  patents necessarily infringed by implementation (in whole
  or in part) of this specification. If You institute patent
  litigation against any entity (including a cross-claim or
  counterclaim in a lawsuit) alleging that the
  implementation of the specification constitutes direct or
  contributory patent infringement, then any patent licenses
  for the specification granted to You under this License
  shall terminate as of the date such litigation is filed.

[XXX: Based on https://datatracker.ietf.org/ipr/941/ which has received some positive but limited reviews from a free software perspective. More review is necessary to reliably label this as free software friendly.]

4.4.  Non-assertion Claims

Some patent licenses are not really patent licenses at all, but promises not to assert the claims in the patent. These promises, if they are kept, should be sufficient for free implementations of the standard. However, there is a legal loop-hole that the patent owner may simply not chose keep the promise. It can be unclear whether the original promise is legally binding.

If the non-assertion claim is written in the form of a patent license, that would avoid the potential loop-hole. It can add value if the claim states explicitly that it is perpetual and cannot be revoked.

Naturally, you should confirm that whoever give this claims is entitled to speak on behalf of the patent owner.

It is recommended to ask whoever gives non-assertion claims to rewrite them in the form of a patent license. That would make it more clear that the statement is actually legally binding.

5.  Frequently Asked Questions

5.1.  Why Not Use A Well-Known Free Copyright License?

This question is a common comment that is worth discussion. It is widely accepted that it is preferable to use a widely accepted free license instead of crafting new text (see for example [WHEELER] (Wheeler, D., “Make Your Open Source Software GPL-Compatible. Or Else.,” .)). All of the widely used free software licenses that are based on copyright, and require that the copyright notice are preserved. For example, the clause 1 of the BSD license (UoC, “The revised BSD License,” .) [BSD] says:

    Redistributions of source code must retain the above
    copyright notice, this list of conditions and the
    following disclaimer.

Further, clause 1 of the GNU General Public License (FSF, “GNU General Public License,” .) [GPL] says:

   You may copy and distribute verbatim copies of the
   Program's source code as you receive it, in any medium,
   provided that you conspicuously and appropriately publish
   on each copy an appropriate copyright notice and
   disclaimer of warranty; keep intact all the notices that
   refer to this License and to the absence of any warranty;
   and give any other recipients of the Program a copy of
   this License along with the Program.

However, the IETF rules disallow such additional copyright notices in documents. [RFC3978] (Bradner, S., “IETF Rights in Contributions,” March 2005.) section 5.4 says:

    Additional copyright notices are not permitted in IETF
    Documents except in the case where such document is the
    product of a joint development effort between the IETF
    and another standards development organization or the
    document is a republication of the work of another
    standards organization.  Such exceptions must be
    approved on an individual basis by the IAB.

This rule has not been followed in practice, and makes it impossible to re-use widely approved licenses. The IAB was contacted to grant an exception on one document [RFC4648] (Josefsson, S., “The Base16, Base32, and Base64 Data Encodings,” October 2006.) that contained code licensed under the GNU Lesser General Public License (FSF, “GNU Lesser General Public License,” .) [LGPL], but turned down the request. An attempt to resolve this by altering the IETF rules were initiated in draft-josefsson-ipr-notices-00 (Josefsson, S., “RFC 3978 Update Regarding Additional Copyright Notices,” May 2006.) [I‑D.josefsson‑ipr‑notices] but have not gained any traction so far.

5.2.  Why Isn't It Sufficient To Use A Free License For Code

It has been suggested that the copyright license could be separated to cover code and text separately. The intention is supposedly that the IETF would use a free and GPL/BSD-compatible license for code, but not for the text portion.

We argue that this solution is sub-optimal, and in particular it would prevent scenarios including the following:

1. Excerpts from RFCs included in source code comments. This is a common example, many free IETF implementations embed excerpts from the RFC text in source code comments.
2. Teaching material derived from RFC texts. University teacher may want to modify RFCs to illustrate a point and as an implementation exercises, and include the resulting work in freely available online course material.
3. Material used in manuals or online help ("man" pages) may include protocol overviews (such as in SASL) or API function documentation (such as in GSS-API). For example, several vendors, including FreeBSD and Sun, have shipped a man page for getaddrinfo that is derived from RFC 2133.
4. Wider distribution of RFCs. The Debian operating system have license guidelines regarding the content, and unless the entire text is licensed in a free fashion, a document cannot be included (even as documentation) in the distribution.
5. Development of protocol extensions. When protocols evolve, that is sometimes done by creating a modified version of an existing implementation to experiment with how well the idea works. Having to send every version intended for re-distribution to the IETF slows down experiments.

We recommend strongly to use the same license to both code and text.

6.  Acknowledgments

TBA

Special acknowledgment is given to Joost van Baal, Markus Demleitner, Nathanael Nerode, Nikos Mavrogiannopoulos, and Wytze van der Raay of Stichting NLNet who supported our earlier efforts in this direction.

7. References

Author's Address

Full Copyright Statement

Copyright © The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.