Network Working Group S. Josefsson
Internet-Draft October 23, 2007
Intended status: Informational
Expires: April 25, 2008
Guidelines for Free Standards in the IETF
draft-josefsson-free-standards-howto-01
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 April 25, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
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.
Josefsson Expires April 25, 2008 [Page 1]
Internet-Draft Guidelines for Free Standards in the IETF October 2007
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 . . . . . . . . . . . . . . . . . . 7
5.1. Why Not Use A Well-Known Free Copyright License? . . . . . 7
5.2. Why Isn't It Sufficient To Use A Free License For Code . . 8
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Josefsson Expires April 25, 2008 [Page 2]
Internet-Draft Guidelines for Free Standards in the IETF October 2007
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 April 25, 2008 [Page 3]
Internet-Draft Guidelines for Free Standards in the IETF October 2007
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
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
Josefsson Expires April 25, 2008 [Page 4]
Internet-Draft Guidelines for Free Standards in the IETF October 2007
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 documented is known to be patented, that may complicate the use
of the document 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
Josefsson Expires April 25, 2008 [Page 5]
Internet-Draft Guidelines for Free Standards in the IETF October 2007
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.
Josefsson Expires April 25, 2008 [Page 6]
Internet-Draft Guidelines for Free Standards in the IETF October 2007
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 would grant third parties
the necessary rights in order to use it in free software.
X grants a worldwide, non-exclusive, fully-paid, perpetual,
royaltee-free patent license to everyone for any purpose.
[XXX: Most likely, this section will be heavily modified based on
feedback.]
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]).
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:
Josefsson Expires April 25, 2008 [Page 7]
Internet-Draft Guidelines for Free Standards in the IETF October 2007
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
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.
Josefsson Expires April 25, 2008 [Page 8]
Internet-Draft Guidelines for Free Standards in the IETF October 2007
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
[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.
Josefsson Expires April 25, 2008 [Page 9]
Internet-Draft Guidelines for Free Standards in the IETF October 2007
[RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov,
S., and J. Perser, "Packet Reordering Metrics", RFC 4737,
November 2006.
[I-D.josefsson-ipr-notices]
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.
[ICEWEASEL]
Wikipedia, "Iceweasel",
WWW http://en.wikipedia.org/wiki/Iceweasel.
Author's Address
Simon Josefsson
Email: simon@josefsson.org
Josefsson Expires April 25, 2008 [Page 10]
Internet-Draft Guidelines for Free Standards in the IETF October 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Josefsson Expires April 25, 2008 [Page 11]