Network Working Group B. Carpenter
Internet-Draft Univ. of Auckland
Intended status: Informational November 5, 2007
Expires: May 8, 2008
Considering availability of free software when evaluating Draft
Standards
draft-carpenter-ipr-patent-frswds-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 May 8, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This draft responds to a request for input by the IPR WG Chair. It
proposes that the IETF's criteria for evaluating Draft Standard
specifications should preferably include the availability of free
software.
Carpenter Expires May 8, 2008 [Page 1]
Internet-Draft Free software at DS November 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Changed environment . . . . . . . . . . . . . . . . . . . . . . 3
3. Possible change in IETF criteria . . . . . . . . . . . . . . . 4
4. Charter objective . . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . . . 8
Carpenter Expires May 8, 2008 [Page 2]
Internet-Draft Free software at DS November 2007
1. Introduction
The IPR working chair has requested input addressing:
o What contributors think has changed since the last IPR WG
evaluation of patent policy.
o What changes in overall direction they think the WG should
address.
o What the charter for this activity should look like.
This draft is a response to that request, specifically addressing the
criteria for advancement of specifications from Proposed Standard to
Draft Standard.
2. Changed environment
In recent years, while patent law and the motivations of patent
holders have not changed significantly, large sections of the
software business have moved towards a free software model based on a
variety of open source licenses. Furthermore, there are at least two
camps in the IT industry, those who oppose the very existence of such
software, and those who have embraced it in their way of developing
commercial products and services.
Patent holders therefore offer a wide variety of conditions when it
comes to licensing patents alleged to be infringed by software
implementing open standards. The available patent licenses vary
widely, from essentially free of restriction at one end to
traditional royalty-based conditions at the other. Even patent
licenses intended to be friendly to open-source software often
contain reciprocity clauses (to protect the patent-holder against
unreasonable licensing conditions from other patent-holders), or a
requirement for all implementors to register their use of the patent
in some way.
At the same time, open source licenses vary widely, from saying
little or nothing about patents at one end to requiring open source
distributors to warrant the absence of royalties at the other.
This range of conditions, both for patent licenses and for open
source licenses, makes it essentially impossible for the IETF to
devise rules that satisfy all parties:
o patent-holders who stick to a traditional, royalty-based approach
to patents and feel threatened by the existence of free software;
o patent-holders who are friendly to open source software but need
to defend themselves against others who aren't;
Carpenter Expires May 8, 2008 [Page 3]
Internet-Draft Free software at DS November 2007
o open source advocates whose basic quarrel is with the existence of
patents affecting software in the first place.
The importance of free software and of open source licenses was much
less when the current IETF IPR regime was instituted by [RFC2026].
Amendments since then [RFC3979] have not changed anything in this
respect. As a result, there is now a recurrent difficulty in IETF
discussions of specifications where patent disclosures have been made
and there is interest in open source implementations.
3. Possible change in IETF criteria
When [RFC2026] was developed, a key insight was that the IETF should
never put itself in the position of making judgements about the
applicability of patents or about the reasonable and non-
discriminatory nature of patent licenses. Any such judgements are
left to the courts; if the IETF made such judgements it would expose
itself (and its participants) to court action. Therefore, the IETF
process only requires contributors to disclose relevant patents (and
applications) reasonably and personally known to them, and requires
the IETF to publish those disclosures. The IETF makes use of such
disclosures in deciding whether to adopt a particular technology, but
without passing judgement on them.
However, there is one point where the IETF indirectly considers
whether IPR conditions have had a practical or empirical effect.
[RFC2026] says:
4.1.2 Draft Standard
A specification from which at least two independent and interoperable
implementations from different code bases have been developed, and
for which sufficient successful operational experience has been
obtained, may be elevated to the "Draft Standard" level. For the
purposes of this section, "interoperable" means to be functionally
equivalent or interchangeable components of the system or process in
which they are used. If patented or otherwise controlled technology
is required for implementation, the separate implementations must
also have resulted from separate exercise of the licensing process.
Elevation to Draft Standard is a major advance in status, indicating
a strong belief that the specification is mature and will be useful.
Thus, the IETF makes no judgement about the merits of patent claims
or licenses; it judges by objectively observed results.
Carpenter Expires May 8, 2008 [Page 4]
Internet-Draft Free software at DS November 2007
A straightforward and robust way to favor free (and presumably open
source) implementations of IETF protocols is simply to rewrite the
first sentence above as:
A specification from which at least two independent and interoperable
implementations from different code bases have been developed, of
which at least one is preferably available as free software, and
for which sufficient successful operational experience has been
obtained, may be elevated to the "Draft Standard" level.
This leaves open the question of what exactly is "free" software.
[I-D.josefsson-free-standards-howto] discusses how IETF documents may
be written to favor free software, without attempting a precise
definition. The present proposal takes the same approach. By
including the word "preferably" it indicates that in making its
judgement whether the criteria for Draft Standard status have been
met, the IESG should give added weight to the availability of free
software, without rigidly defining the term.
This is an extremely simple change to the IETF's empirical approach
to advancement along the standards track, which will encourage the
provision of interoperable free software, without damaging the IETF's
proven methodology and without involving the IETF in legal
interpretations of either patent licenses or open source licenses.
It does not prevent standards advancing for which there are only
proprietary implementations, since it only expresses a preference.
4. Charter objective
A possible IPR WG charter objective to deal with this would be:
- A short document (BCP) updating RFC 2026 to add the requirement
that the implementations evaluated for advancement of a specification
to Draft Standard should preferably include at least one free
software implementation.
The author of this draft does not in fact support this, since a
change to the basic standards process of RFC 2026 seems completely
out of scope for the IPR WG.
An alternative objective would be a process experiment [RFC3933] to
try this change for a while (probably at least two years to obtain
significant results).
A final approach would be to conclude that no formal change to RFC
Carpenter Expires May 8, 2008 [Page 5]
Internet-Draft Free software at DS November 2007
2026 is required, but for the IESG to simply indicate its intention
to follow the suggested approach in future.
5. Security Considerations
This document has no direct impact on the security of the Internet.
6. IANA Considerations
This document requests no action by the IANA.
7. Acknowledgements
The basic idea of this draft comes from an email sent by Sam Hartman.
It has been modified as a result of useful discussion on the IETF and
IPR mailing lists.
This document was produced using the xml2rfc tool [RFC2629].
8. References
8.1. Normative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
8.2. Informative References
[I-D.josefsson-free-standards-howto]
Josefsson, S., "Guidelines for Free Standards in the
IETF", draft-josefsson-free-standards-howto-01 (work in
progress), October 2007.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC3933] Klensin, J. and S. Dawkins, "A Model for IETF Process
Experiments", BCP 93, RFC 3933, November 2004.
[RFC3979] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3979, March 2005.
Carpenter Expires May 8, 2008 [Page 6]
Internet-Draft Free software at DS November 2007
Author's Address
Brian Carpenter
Department of Computer Science
University of Auckland
PB 92019
Auckland, 1142
New Zealand
Email: brian.e.carpenter@gmail.com
Carpenter Expires May 8, 2008 [Page 7]
Internet-Draft Free software at DS November 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).
Carpenter Expires May 8, 2008 [Page 8]