idnits 2.17.1 draft-carpenter-ipr-patent-frswds-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 265. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 276. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 283. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 289. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 5, 2007) is 6017 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-josefsson-free-standards-howto-01 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 3979 (Obsoleted by RFC 8179) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Carpenter 3 Internet-Draft Univ. of Auckland 4 Intended status: Informational November 5, 2007 5 Expires: May 8, 2008 7 Considering availability of free software when evaluating Draft 8 Standards 9 draft-carpenter-ipr-patent-frswds-01 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 8, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This draft responds to a request for input by the IPR WG Chair. It 43 proposes that the IETF's criteria for evaluating Draft Standard 44 specifications should preferably include the availability of free 45 software. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Changed environment . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Possible change in IETF criteria . . . . . . . . . . . . . . . 4 52 4. Charter objective . . . . . . . . . . . . . . . . . . . . . . . 5 53 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 54 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 55 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 56 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 58 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 Intellectual Property and Copyright Statements . . . . . . . . . . 8 62 1. Introduction 64 The IPR working chair has requested input addressing: 65 o What contributors think has changed since the last IPR WG 66 evaluation of patent policy. 67 o What changes in overall direction they think the WG should 68 address. 69 o What the charter for this activity should look like. 71 This draft is a response to that request, specifically addressing the 72 criteria for advancement of specifications from Proposed Standard to 73 Draft Standard. 75 2. Changed environment 77 In recent years, while patent law and the motivations of patent 78 holders have not changed significantly, large sections of the 79 software business have moved towards a free software model based on a 80 variety of open source licenses. Furthermore, there are at least two 81 camps in the IT industry, those who oppose the very existence of such 82 software, and those who have embraced it in their way of developing 83 commercial products and services. 85 Patent holders therefore offer a wide variety of conditions when it 86 comes to licensing patents alleged to be infringed by software 87 implementing open standards. The available patent licenses vary 88 widely, from essentially free of restriction at one end to 89 traditional royalty-based conditions at the other. Even patent 90 licenses intended to be friendly to open-source software often 91 contain reciprocity clauses (to protect the patent-holder against 92 unreasonable licensing conditions from other patent-holders), or a 93 requirement for all implementors to register their use of the patent 94 in some way. 96 At the same time, open source licenses vary widely, from saying 97 little or nothing about patents at one end to requiring open source 98 distributors to warrant the absence of royalties at the other. 100 This range of conditions, both for patent licenses and for open 101 source licenses, makes it essentially impossible for the IETF to 102 devise rules that satisfy all parties: 103 o patent-holders who stick to a traditional, royalty-based approach 104 to patents and feel threatened by the existence of free software; 105 o patent-holders who are friendly to open source software but need 106 to defend themselves against others who aren't; 108 o open source advocates whose basic quarrel is with the existence of 109 patents affecting software in the first place. 111 The importance of free software and of open source licenses was much 112 less when the current IETF IPR regime was instituted by [RFC2026]. 113 Amendments since then [RFC3979] have not changed anything in this 114 respect. As a result, there is now a recurrent difficulty in IETF 115 discussions of specifications where patent disclosures have been made 116 and there is interest in open source implementations. 118 3. Possible change in IETF criteria 120 When [RFC2026] was developed, a key insight was that the IETF should 121 never put itself in the position of making judgements about the 122 applicability of patents or about the reasonable and non- 123 discriminatory nature of patent licenses. Any such judgements are 124 left to the courts; if the IETF made such judgements it would expose 125 itself (and its participants) to court action. Therefore, the IETF 126 process only requires contributors to disclose relevant patents (and 127 applications) reasonably and personally known to them, and requires 128 the IETF to publish those disclosures. The IETF makes use of such 129 disclosures in deciding whether to adopt a particular technology, but 130 without passing judgement on them. 132 However, there is one point where the IETF indirectly considers 133 whether IPR conditions have had a practical or empirical effect. 134 [RFC2026] says: 136 4.1.2 Draft Standard 138 A specification from which at least two independent and interoperable 139 implementations from different code bases have been developed, and 140 for which sufficient successful operational experience has been 141 obtained, may be elevated to the "Draft Standard" level. For the 142 purposes of this section, "interoperable" means to be functionally 143 equivalent or interchangeable components of the system or process in 144 which they are used. If patented or otherwise controlled technology 145 is required for implementation, the separate implementations must 146 also have resulted from separate exercise of the licensing process. 147 Elevation to Draft Standard is a major advance in status, indicating 148 a strong belief that the specification is mature and will be useful. 150 Thus, the IETF makes no judgement about the merits of patent claims 151 or licenses; it judges by objectively observed results. 153 A straightforward and robust way to favor free (and presumably open 154 source) implementations of IETF protocols is simply to rewrite the 155 first sentence above as: 157 A specification from which at least two independent and interoperable 158 implementations from different code bases have been developed, of 159 which at least one is preferably available as free software, and 160 for which sufficient successful operational experience has been 161 obtained, may be elevated to the "Draft Standard" level. 163 This leaves open the question of what exactly is "free" software. 164 [I-D.josefsson-free-standards-howto] discusses how IETF documents may 165 be written to favor free software, without attempting a precise 166 definition. The present proposal takes the same approach. By 167 including the word "preferably" it indicates that in making its 168 judgement whether the criteria for Draft Standard status have been 169 met, the IESG should give added weight to the availability of free 170 software, without rigidly defining the term. 172 This is an extremely simple change to the IETF's empirical approach 173 to advancement along the standards track, which will encourage the 174 provision of interoperable free software, without damaging the IETF's 175 proven methodology and without involving the IETF in legal 176 interpretations of either patent licenses or open source licenses. 177 It does not prevent standards advancing for which there are only 178 proprietary implementations, since it only expresses a preference. 180 4. Charter objective 182 A possible IPR WG charter objective to deal with this would be: 184 - A short document (BCP) updating RFC 2026 to add the requirement 185 that the implementations evaluated for advancement of a specification 186 to Draft Standard should preferably include at least one free 187 software implementation. 189 The author of this draft does not in fact support this, since a 190 change to the basic standards process of RFC 2026 seems completely 191 out of scope for the IPR WG. 193 An alternative objective would be a process experiment [RFC3933] to 194 try this change for a while (probably at least two years to obtain 195 significant results). 197 A final approach would be to conclude that no formal change to RFC 198 2026 is required, but for the IESG to simply indicate its intention 199 to follow the suggested approach in future. 201 5. Security Considerations 203 This document has no direct impact on the security of the Internet. 205 6. IANA Considerations 207 This document requests no action by the IANA. 209 7. Acknowledgements 211 The basic idea of this draft comes from an email sent by Sam Hartman. 212 It has been modified as a result of useful discussion on the IETF and 213 IPR mailing lists. 215 This document was produced using the xml2rfc tool [RFC2629]. 217 8. References 219 8.1. Normative References 221 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 222 3", BCP 9, RFC 2026, October 1996. 224 8.2. Informative References 226 [I-D.josefsson-free-standards-howto] 227 Josefsson, S., "Guidelines for Free Standards in the 228 IETF", draft-josefsson-free-standards-howto-01 (work in 229 progress), October 2007. 231 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 232 June 1999. 234 [RFC3933] Klensin, J. and S. Dawkins, "A Model for IETF Process 235 Experiments", BCP 93, RFC 3933, November 2004. 237 [RFC3979] Bradner, S., "Intellectual Property Rights in IETF 238 Technology", BCP 79, RFC 3979, March 2005. 240 Author's Address 242 Brian Carpenter 243 Department of Computer Science 244 University of Auckland 245 PB 92019 246 Auckland, 1142 247 New Zealand 249 Email: brian.e.carpenter@gmail.com 251 Full Copyright Statement 253 Copyright (C) The IETF Trust (2007). 255 This document is subject to the rights, licenses and restrictions 256 contained in BCP 78, and except as set forth therein, the authors 257 retain all their rights. 259 This document and the information contained herein are provided on an 260 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 261 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 262 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 263 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 264 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 265 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 267 Intellectual Property 269 The IETF takes no position regarding the validity or scope of any 270 Intellectual Property Rights or other rights that might be claimed to 271 pertain to the implementation or use of the technology described in 272 this document or the extent to which any license under such rights 273 might or might not be available; nor does it represent that it has 274 made any independent effort to identify any such rights. Information 275 on the procedures with respect to rights in RFC documents can be 276 found in BCP 78 and BCP 79. 278 Copies of IPR disclosures made to the IETF Secretariat and any 279 assurances of licenses to be made available, or the result of an 280 attempt made to obtain a general license or permission for the use of 281 such proprietary rights by implementers or users of this 282 specification can be obtained from the IETF on-line IPR repository at 283 http://www.ietf.org/ipr. 285 The IETF invites any interested party to bring to its attention any 286 copyrights, patents or patent applications, or other proprietary 287 rights that may cover technology that may be required to implement 288 this standard. Please address the information to the IETF at 289 ietf-ipr@ietf.org. 291 Acknowledgment 293 Funding for the RFC Editor function is provided by the IETF 294 Administrative Support Activity (IASA).