One document matched: draft-josefsson-free-standards-howto-01.xml

<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<?rfc compact="yes"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes" ?>

<rfc category="info" ipr="full3978"
     docName="draft-josefsson-free-standards-howto-01">

<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="October" year="2007"/>

  <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 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.</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 would grant third
	parties the necessary rights in order to use it in free
	software.</t>

      <t><figure>
	  <artwork>
          X grants a worldwide, non-exclusive, fully-paid, perpetual,
          royaltee-free patent license to everyone for any purpose.
	  </artwork>
	</figure>    
      </t>

      <t>[XXX: Most likely, this section will be heavily modified
	based on feedback.]</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>