[Search] [pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02                                                      
Network Working Group                                       S. Josefsson
Internet-Draft                                            April 23, 2008
Intended status: Informational
Expires: October 25, 2008

               Guidelines for Free Standards in the IETF

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

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


   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.

Josefsson               Expires October 25, 2008                [Page 1]

Internet-Draft  Guidelines for Free Standards in the IETF     April 2008

Table of Contents

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

Josefsson               Expires October 25, 2008                [Page 2]

Internet-Draft  Guidelines for Free Standards in the IETF     April 2008

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

   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

Josefsson               Expires October 25, 2008                [Page 3]

Internet-Draft  Guidelines for Free Standards in the IETF     April 2008

   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]) 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

   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

Josefsson               Expires October 25, 2008                [Page 4]

Internet-Draft  Guidelines for Free Standards in the IETF     April 2008

   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], [RFC4398], [RFC4737]).

         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]) 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

   The first conclusion here is that readers will have to search the

Josefsson               Expires October 25, 2008                [Page 5]

Internet-Draft  Guidelines for Free Standards in the IETF     April 2008

   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

Josefsson               Expires October 25, 2008                [Page 6]

Internet-Draft  Guidelines for Free Standards in the IETF     April 2008

   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

   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

Josefsson               Expires October 25, 2008                [Page 7]

Internet-Draft  Guidelines for Free Standards in the IETF     April 2008

   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]).
   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 [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 [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] 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] that contained code licensed
   under the GNU Lesser General Public License [LGPL], but turned down

Josefsson               Expires October 25, 2008                [Page 8]

Internet-Draft  Guidelines for Free Standards in the IETF     April 2008

   the request.  An attempt to resolve this by altering the IETF rules
   were initiated in draft-josefsson-ipr-notices-00
   [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


   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.

Josefsson               Expires October 25, 2008                [Page 9]

Internet-Draft  Guidelines for Free Standards in the IETF     April 2008

7.  References

   [RFC3492]  Costello, A., "Punycode: A Bootstring encoding of Unicode
              for Internationalized Domain Names in Applications
              (IDNA)", RFC 3492, March 2003.

   [RFC3978]  Bradner, S., "IETF Rights in Contributions", BCP 78,
              RFC 3978, March 2005.

   [RFC3979]  Bradner, S., "Intellectual Property Rights in IETF
              Technology", BCP 79, RFC 3979, March 2005.

   [RFC4398]  Josefsson, S., "Storing Certificates in the Domain Name
              System (DNS)", RFC 4398, March 2006.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, October 2006.

   [RFC4737]  Morton, A., Ciavattone, L., Ramachandran, G., Shalunov,
              S., and J. Perser, "Packet Reordering Metrics", RFC 4737,
              November 2006.

              Josefsson, S., "RFC 3978 Update Regarding Additional
              Copyright Notices", draft-josefsson-ipr-notices-00 (work
              in progress), May 2006.

   [WHEELER]  Wheeler, D., "Make Your Open Source Software GPL-
              Compatible. Or Else.",
              WWW http://www.dwheeler.com/essays/gpl-compatible.html.

   [GPL]      FSF, "GNU General Public License",
              WWW http://www.gnu.org/licenses/gpl.html.

   [LGPL]     FSF, "GNU Lesser General Public License",
              WWW http://www.gnu.org/licenses/lgpl.html.

   [BSD]      UoC, "The revised BSD License",
              WWW http://www.opensource.org/licenses/bsd-license.php.

              Wikipedia, "Iceweasel",
              WWW http://en.wikipedia.org/wiki/Iceweasel.

Josefsson               Expires October 25, 2008               [Page 10]

Internet-Draft  Guidelines for Free Standards in the IETF     April 2008

Author's Address

   Simon Josefsson

   Email: simon@josefsson.org

Josefsson               Expires October 25, 2008               [Page 11]

Internet-Draft  Guidelines for Free Standards in the IETF     April 2008

Full Copyright Statement

   Copyright (C) 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

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

   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

Josefsson               Expires October 25, 2008               [Page 12]