One document matched: draft-josefsson-free-standards-howto-02.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<!--
-- Copyright (C) 2007, 2008 Simon Josefsson.
-- 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.
--
-->
<?rfc compact="yes"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes" ?>
<rfc category="info" ipr="full3978"
docName="draft-josefsson-free-standards-howto-02">
<front>
<title>
Guidelines for Free Standards in the IETF
</title>
<author initials="S." surname="Josefsson" fullname="Simon Josefsson">
<organization></organization>
<address>
<email>simon@josefsson.org</email>
</address>
</author>
<date month="April" year="2008"/>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction, or, What Is a Free Standard?">
<t>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.</t>
<t>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.</t>
<t>There are two main problems when implementing standards:
copyright licenses and patents.</t>
<t>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
<xref target="ICEWEASEL" />.</t>
<t>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.</t>
</section>
<section title="Intended Audience">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Copyright Concerns">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>The IETF rules (see <xref target="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.</t>
<t>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).</t>
<t>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.</t>
<t>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.</t>
<t>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 (<xref target="RFC3492" />,
<xref target="RFC4398" />, <xref target="RFC4737" />).</t>
<t><figure>
<artwork>
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.
</artwork>
</figure>
</t>
</section>
<section title="Patent Concerns">
<t>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.</t>
<t>The IETF rules (see <xref target="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.)</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<section title="What To Look For In A Patent Disclosure">
<t>An alternative title for this section may be 'How To Write A
Free-Software Friendly Patent Disclosure'.</t>
<t>Words to look for in a patent license is free-of-charge,
world-wide, royaltee-free, perpetual and non-exclusive right
to the patent.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Handling Submarine Patents">
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Example License Text">
<t>Here is a simplistic patent license that appear to grant
third parties the necessary rights in order to use it in free
software.</t>
<t><figure>
<artwork>
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.
</artwork>
</figure>
</t>
<t>[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.]</t>
</section>
<section title="Non-assertion Claims">
<t>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.</t>
<t>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.</t>
<t>Naturally, you should confirm that whoever give this claims
is entitled to speak on behalf of the patent owner.</t>
<t>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.</t>
</section>
</section>
<section title="Frequently Asked Questions">
<section title="Why Not Use A Well-Known Free Copyright License?">
<t>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 <xref target="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 <xref target="BSD">BSD license</xref>
says:</t>
<t><figure>
<artwork>
Redistributions of source code must retain the above
copyright notice, this list of conditions and the
following disclaimer.
</artwork>
</figure>
</t>
<t>Further, clause 1 of the <xref target="GPL">GNU General
Public License</xref> says:</t>
<t><figure>
<artwork>
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.
</artwork>
</figure>
</t>
<t>However, the IETF rules disallow such additional copyright
notices in documents. <xref target="RFC3978" /> section 5.4
says:</t>
<t><figure>
<artwork>
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.
</artwork>
</figure>
</t>
<t>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
<xref target="RFC4648"/> that contained code licensed under
the
<xref target="LGPL">GNU Lesser General Public License</xref>,
but turned down the request. An attempt to resolve this by
altering the IETF rules were initiated
in <xref target="I-D.josefsson-ipr-notices">
draft-josefsson-ipr-notices-00</xref> but have not gained any
traction so far.</t>
</section>
<section title="Why Isn't It Sufficient To Use A Free License For Code">
<t>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.</t>
<t>We argue that this solution is sub-optimal, and in particular
it would prevent scenarios including the following:</t>
<t><list style="numbers">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</list></t>
<t>We recommend strongly to use the same license to both code
and text.</t>
</section>
</section>
<section title="Acknowledgments">
<t>TBA</t>
<t>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.</t>
</section>
</middle>
<back>
<references title="References">
<?rfc include="reference.RFC.3492.xml"?>
<?rfc include="reference.RFC.3978.xml"?>
<?rfc include="reference.RFC.3979.xml"?>
<?rfc include="reference.RFC.4398.xml"?>
<?rfc include="reference.RFC.4648.xml"?>
<?rfc include="reference.RFC.4737.xml"?>
<?rfc include="reference.I-D.josefsson-ipr-notices.xml"?>
<reference anchor="WHEELER">
<front>
<title>Make Your Open Source Software GPL-Compatible. Or Else.</title>
<author initials="D." surname="Wheeler" fullname="D. Wheeler">
</author>
</front>
<seriesInfo name="WWW"
value="http://www.dwheeler.com/essays/gpl-compatible.html" />
</reference>
<reference anchor="GPL">
<front>
<title>GNU General Public License</title>
<author initials="" surname="FSF" fullname="Free Software Foundation">
<organization></organization>
<date month="June" year="1991" />
</author>
</front>
<seriesInfo name="WWW"
value="http://www.gnu.org/licenses/gpl.html" />
</reference>
<reference anchor="LGPL">
<front>
<title>GNU Lesser General Public License</title>
<author initials="" surname="FSF" fullname="Free Software Foundation">
<organization></organization>
<date month="February" year="1999" />
</author>
</front>
<seriesInfo name="WWW"
value="http://www.gnu.org/licenses/lgpl.html" />
</reference>
<reference anchor="BSD">
<front>
<title>The revised BSD License</title>
<author initials="" surname="UoC" fullname="University of California">
<organization></organization>
</author>
</front>
<seriesInfo name="WWW"
value="http://www.opensource.org/licenses/bsd-license.php" />
</reference>
<reference anchor="ICEWEASEL">
<front>
<title>Iceweasel</title>
<author initials="" surname="Wikipedia" fullname="Wikipedia">
<organization></organization>
</author>
</front>
<seriesInfo name="WWW"
value="http://en.wikipedia.org/wiki/Iceweasel" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-21 18:54:58 |