分享
 
 
 

RFC3979-Intellectual Property Rights in IETF Technology

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

Network Working Group S. Bradner, Ed.

Request for Comments: 3979 Harvard University

BCP: 79 March 2005

Obsoletes: 3668

Updates: 2028, 2026

Category: Best Current Practice

Intellectual Property Rights in IETF Technology

Status of this Memo

This document specifies an Internet Best Current Practices for the

Internet Community, and requests discussion and suggestions for

improvements. Distribution of this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (2005).

Abstract

The IETF policies about Intellectual Property Rights (IPR), sUCh as

patent rights, relative to technologies developed in the IETF are

designed to ensure that IETF working groups and participants have as

much information about any IPR constraints on a technical proposal as

possible. The policies are also intended to benefit the Internet

community and the public at large, while respecting the legitimate

rights of IPR holders. This memo details the IETF policies

concerning IPR related to technology worked on within the IETF. It

also describes the objectives that the policies are designed to meet.

This memo updates RFC 2026 and, with RFC 3978, replaces Section 10 of

RFC 2026. This memo also updates paragraph 4 of Section 3.2 of RFC

2028, for all purposes, including reference [2] in RFC 2418.

Table of Contents

1. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 2

2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4

3. Contributions to the IETF. . . . . . . . . . . . . . . . . . . 6

3.1. General Policy . . . . . . . . . . . . . . . . . . . . . 6

3.2. Rights and Permissions . . . . . . . . . . . . . . . . . 6

4. Actions for Documents for which IPR Disclosure(s) Have Been

Received . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

4.1. No Determination of Reasonable and Non-discriminatory

Terms. . . . . . . . . . . . . . . . . . . . . . . . . . 7

5. Notice to be Included in RFCs. . . . . . . . . . . . . . . . . 8

6. IPR Disclosures. . . . . . . . . . . . . . . . . . . . . . . . 8

6.1. Who Must Make an IPR Disclosure? . . . . . . . . . . . . 9

6.2. The Timing of Providing Disclosure . . . . . . . . . . . 9

6.3. How Must a Disclosure be Made? . . . . . . . . . . . . . 11

6.4. What Must be in a Disclosure?. . . . . . . . . . . . . . 11

6.5. What Licensing Information to Detail in a Disclosure . . 12

6.6. When is a Disclosure Required? . . . . . . . . . . . . . 12

7. Failure to Disclose. . . . . . . . . . . . . . . . . . . . . . 12

8. Evaluating Alternative Technologies in IETF Working Groups . . 13

9. Change Control for Technologies. . . . . . . . . . . . . . . . 14

10. Licensing Requirements to Advance Standards Track Documents. . 14

11. No IPR Disclosures in IETF Documents . . . . . . . . . . . . . 14

12. Security Considerations. . . . . . . . . . . . . . . . . . . . 15

13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15

13.1. Normative References . . . . . . . . . . . . . . . . . . 15

13.2. Informative References . . . . . . . . . . . . . . . . . 15

14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15

15. Editor's Address . . . . . . . . . . . . . . . . . . . . . . . 16

Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17

1. Definitions

The following definitions are for terms used in the context of this

document. Other terms, including "IESG," "ISOC," "IAB," and "RFC

Editor," are defined in [RFC2028].

a. "IETF": In the context of this document, the IETF includes all

individuals who participate in meetings, working groups, mailing

lists, functions and other activities which are organized or

initiated by ISOC, the IESG or the IAB under the general

designation of the Internet Engineering Task Force or IETF, but

solely to the extent of such participation.

b. "IETF Standards Process": the activities undertaken by the IETF in

any of the settings described in 1(c) below.

c. "IETF Contribution": any submission to the IETF intended by the

Contributor for publication as all or part of an Internet-Draft or

RFC (except for RFC Editor Contributions described below) and any

statement made within the context of an IETF activity. Such

statements include oral statements in IETF sessions, as well as

written and electronic communications made at any time or place,

which are addressed to:

o the IETF plenary session,

o any IETF working group or portion thereof,

o the IESG, or any member thereof on behalf of the IESG,

o the IAB or any member thereof on behalf of the IAB,

o any IETF mailing list, including the IETF list itself, any

working group or design team list, or any other list

functioning under IETF auspices,

o the RFC Editor or the Internet-Drafts function (except for RFC

Editor Contributions described below).

Statements made outside of an IETF session, mailing list or other

function, that are clearly not intended to be input to an IETF

activity, group or function, are not IETF Contributions in the

context of this document.

d. "Internet-Draft": temporary documents used in the IETF and RFC

Editor processes. Internet-Drafts are posted on the IETF web site

by the IETF Secretariat and have a nominal maximum lifetime in the

Secretariat's public Directory of 6 months, after which they are

removed. Note that Internet-Drafts are archived many places on

the Internet, and not all of these places remove eXPired

Internet-Drafts. Internet-Drafts that are under active

consideration by the IESG are not removed from the Secretariat's

public directory until that consideration is complete. In

addition, the author of an Internet-Draft can request that the

lifetime in the Secretariat's public directory be extended before

the expiration.

e. "RFC": the basic publication series for the IETF. RFCs are

published by the RFC Editor and once published are never modified.

(See [RFC2026] Section 2.1)

f. "RFC Editor Contribution": An Internet-Draft intended by the

Contributor to be submitted to the RFC Editor for publication as

an Informational or Experimental RFC but not intended to be part

of the IETF Standards Process.

g. "IETF Internet-Drafts": Internet-Drafts other than RFC Editor

Contributions. Note that under Section 3.3(a) the grant of rights

in regards to IETF Internet-Drafts as specified in this document

is perpetual and irrevocable and thus survives the Secretariat's

removal of an Internet-Draft from the public directory, except as

limited by Section 3.3(a)(C). (See [RFC2026] Sections 2.2 and 8)

h. "IETF Documents": RFCs and Internet-Drafts except for Internet-

Drafts that are RFC Editor Contributions and the RFCs that are

published from them.

i. "RFC Editor Documents": RFCs and Internet-Drafts that are RFC

Editor Contributions and the RFCs that may be published from them.

j. "Contribution": IETF Contributions or RFC Editor Contributions

k. "Contributor": an individual submitting a Contribution

l. "Reasonably and personally known": means something an individual

knows personally or, because of the job the individual holds,

would reasonably be expected to know. This Wording is used to

indicate that an organization cannot purposely keep an individual

in the dark about patents or patent applications just to avoid the

disclosure requirement. But this requirement should not be

interpreted as requiring the IETF Contributor or participant (or

his or her represented organization, if any) to perform a patent

search to find applicable IPR.

m. "Implementing Technology": means a technology that implements an

IETF specification or standard.

n. "Covers" or "Covered" mean that a valid claim of a patent or a

patent application in any jurisdiction or a protected claim, or

any other Intellectual Property Right, would necessarily be

infringed by the exercise of a right (e.g., making, using,

selling, importing, distribution, copying, etc.) with respect to

an Implementing Technology. For purposes of this definition,

"valid claim" means a claim of any unexpired patent or patent

application which shall not have been withdrawn, cancelled or

disclaimed, nor held invalid by a court of competent jurisdiction

in an unappealed or unappealable decision.

o. "IPR" or "Intellectual Property Rights": means patent, copyright,

utility model, invention registration, database and data rights

that may Cover an Implementing Technology, whether such rights

arise from a registration or renewal thereof, or an application

therefore, in each case anywhere in the world.

2. Introduction

In the years since RFC 2026 was published there have been a number of

times when the exact intent of Section 10, the section which deals

with IPR disclosures has been the subject of vigorous debate within

the IETF community. This is because it is becoming increasingly

common for IETF working groups to have to deal with claims of

Intellectual Property Rights (IPR), such as patent rights, with

regards to technology under discussion in working groups. The aim of

this document is to clarify various ambiguities in Section 10 of

[RFC2026] that led to these debates and to amplify the policy in

order to clarify what the IETF is, or should be, doing.

IPR disclosures can come at any point in the IETF Standards Process,

e.g., before the first Internet-Draft has been submitted, prior to

RFC publication, or after an RFC has been published and the working

group has been closed down; they can come from people submitting

technical proposals as Internet-Drafts, on mailing lists or at

meetings, from other people participating in the working group or

from third parties who find out that the work is going or has gone

on; and they can be based on granted patents or on patent

applications, and in some cases be disingenuous, i.e., made to affect

the IETF Standards Process rather than to inform.

RFC 2026, Section 10 established three basic principles regarding the

IETF dealing with claims of Intellectual Property Rights:

(a) the IETF will make no determination about the validity of any

particular IPR claim

(b) the IETF following normal processes can decide to use technology

for which IPR disclosures have been made if it decides that such

a use is warranted

(c) in order for the working group and the rest of the IETF to have

the information needed to make an informed decision about the use

of a particular technology, all those contributing to the working

group's discussions must disclose the existence of any IPR the

Contributor or other IETF participant believes Covers or may

ultimately Cover the technology under discussion. This applies

to both Contributors and other participants, and applies whether

they contribute in person, via email or by other means. The

requirement applies to all IPR of the participant, the

participant's employer, sponsor, or others represented by the

participants, that is reasonably and personally known to the

participant. No patent search is required.

Section 1 defines the terms used in this document. Sections 3, 4 and

5 of this document address the intellectual property issues

previously addressed by Section 10 of RFC 2026. Sections 6 thru 12

then explain the rationale for these provisions, including some of

the clarifications that have been made since the adoption of RFC

2026. The rules and procedures set out in this document are not

intended to modify or alter the IETF's current policy toward IPR in

the context of the IETF Standards Process. They are intended to

clarify and fill in procedural gaps.

A companion document [RFC3978] deals with rights (such as copyrights

and trademarks) in Contributions, including the right of IETF and its

participants to publish and create derivative works of those

Contributions. This document is not intended to address those

issues.

This document is not intended as legal advice. Readers are advised

to consult their own legal advisors if they would like a legal

interpretation of their rights or the rights of the IETF in any

Contributions they make.

3. Contributions to the IETF

3.1. General Policy

In all matters of Intellectual Property Rights, the intent is to

benefit the Internet community and the public at large, while

respecting the legitimate rights of others.

3.2. Rights and Permissions

3.2.1. All Contributions

By submission of a Contribution, each person actually submitting the

Contribution, and each named co-Contributor, is deemed to agree to

the following terms and conditions, on his or her own behalf, and on

behalf of the organizations the Contributor represents or is

sponsored by (if any) when submitting the Contribution.

A. The Contributor represents that he or she has made or will

promptly make all disclosures required by Section 6.1.1 of this

document.

B. The Contributor represents that there are no limits to the

Contributor's ability to make the grants, acknowledgments and

agreements herein that are reasonably and personally known to the

Contributor.

C. If the Contribution is an Internet-Draft, this agreement must be

acknowledged, by including in the "Status of this Memo" section on

the first page of the Contribution, the appropriate notices

described in Section 5 of [RFC3978].

4. Actions for Documents for which IPR Disclosure(s) Have Been Received

(A) When any Intellectual Property Right is disclosed before

publication as an RFC, with respect to any technology or

specification, described in a Contribution in the manner set

forth in Section 6 of this document, the RFC Editor shall ensure

that the document include a note indicating the existence of such

claimed Intellectual Property Rights in any RFC published from

the Contribution. (See Section 5 below.)

(B) The IESG disclaims any responsibility for identifying the

existence of or for evaluating the applicability of any IPR,

disclosed or otherwise, to any IETF technology, specification or

standard, and will take no position on the validity or scope of

any such IPR claims.

(C) Where Intellectual Property Rights have been disclosed for IETF

Documents as provided in Section 6 of this document, the IETF

Executive Director shall request from the discloser of such IPR,

a written assurance that upon approval by the IESG for

publication as RFCs of the relevant IETF specification(s), all

persons will be able to oBTain the right to implement, use,

distribute and exercise other rights with respect to Implementing

Technology under one of the licensing options specified in

Section 6.5 below unless such a statement has already been

submitted. The working group proposing the use of the technology

with respect to which the Intellectual Property Rights are

disclosed may assist the IETF Executive Director in this effort.

The results of this procedure shall not, in themselves, block

publication of an IETF Document or advancement of an IETF

Document along the standards track. A working group may take

into consideration the results of this procedure in evaluating

the technology, and the IESG may defer approval when a delay may

facilitate obtaining such assurances. The results will, however,

be recorded by the IETF Executive Director, and be made available

online.

4.1. No Determination of Reasonable and Non-discriminatory Terms

The IESG will not make any explicit determination that the assurance

of reasonable and non-discriminatory terms or any other terms for the

use of an Implementing Technology has been fulfilled in practice. It

will instead apply the normal requirements for the advancement of

Internet Standards. If the two unrelated implementations of the

specification that are required to advance from Proposed Standard to

Draft Standard have been produced by different organizations or

individuals, or if the "significant implementation and successful

operational experience" required to advance from Draft Standard to

Standard has been achieved, the IESG will presume that the terms are

reasonable and to some degree non-discriminatory. (See RFC 2026,

Section 4.1.3.) Note that this also applies to the case where

multiple implementers have concluded that no licensing is required.

This presumption may be challenged at any time, including during the

Last-Call period by sending email to the IESG.

5. Notice to be Included in RFCs

The RFC Editor will ensure that the following notice is present in

all IETF RFCs and all other RFCs for which an IPR disclosure or

assertion has been received prior to publication.

Disclaimer of validity:

"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."

6. IPR Disclosures

This section discusses ASPects of obligations associated with IPR

disclosure.

This document refers to the IETF participant making disclosures,

consistent with the general IETF philosophy that participants in the

IETF act as individuals. A participant's obligation to make a

disclosure is also considered satisfied if the IPR owner or the

participant's employer or sponsor makes an appropriate disclosure in

place of the participant doing so.

6.1. Who Must Make an IPR Disclosure?

6.1.1. A Contributor's IPR in his or her Contribution

Any Contributor who reasonably and personally knows of IPR meeting

the conditions of Section 6.6 which the Contributor believes Covers

or may ultimately Cover his or her Contribution, or which the

Contributor reasonably and personally knows his or her employer or

sponsor may assert against Implementing Technologies based on such

Contribution, must make a disclosure in accordance with this Section

6.

This requirement specifically includes Contributions that are made by

any means including electronic or spoken comments, unless the latter

are rejected from consideration before a disclosure could reasonably

be submitted. An IPR discloser is requested to withdraw a previous

disclosure if a revised Contribution negates the previous IPR

disclosure, or to amend a previous disclosure if a revised

Contribution substantially alters the previous disclosure.

Contributors must disclose IPR meeting the description in this

section; there are no exceptions to this rule.

6.1.2. An IETF Participant's IPR in Contributions by Others

Any individual participating in an IETF discussion who reasonably and

personally knows of IPR meeting the conditions of Section 6.6 which

the individual believes Covers or may ultimately Cover a Contribution

made by another person, or which such IETF participant reasonably and

personally knows his or her employer or sponsor may assert against

Implementing Technologies based on such Contribution, must make a

disclosure in accordance with this Section 6.

6.1.3. IPR of Others

If a person has information about IPR that may Cover IETF

Contributions, but the participant is not required to disclose

because they do not meet the criteria in Section 6.6 (e.g., the IPR

is owned by some other company), such person is encouraged to notify

the IETF by sending an email message to ietf-ipr@ietf.org. Such a

notice should be sent as soon as reasonably possible after the person

realizes the connection.

6.2. The Timing of Providing Disclosure

Timely IPR disclosure is important because working groups need to

have as much information as they can while they are evaluating

alternative solutions.

6.2.1. Timing of Disclosure Under Section 6.1.1

The IPR disclosure required pursuant to section 6.1.1 must be made as

soon as reasonably possible after the Contribution is published in an

Internet Draft unless the required disclosure is already on file.

For example, if the Contribution is an update to a Contribution for

which an IPR disclosure has already been made and the applicability

of the disclosure is not changed by the new Contribution, then no new

disclosure is required. But if the Contribution is a new one, or is

one that changes an existing Contribution such that the revised

Contribution is no longer Covered by the disclosed IPR or would be

Covered by new or different IPR, then a disclosure must be made.

If a Contributor first learns of IPR in its Contribution that meets

the conditions of Section 6.6, for example a new patent application

or the discovery of a relevant patent in a patent portfolio, after

the Contribution is published in an Internet-Draft, a disclosure must

be made as soon as reasonably possible after the IPR becomes

reasonably and personally known to the Contributor.

Participants who realize that a Contribution will be or has been

incorporated into a submission to be published in an Internet Draft,

or is seriously being discussed in a working group, are strongly

encouraged to make at least a preliminary disclosure. That

disclosure should be made as soon after coming to the realization as

reasonably possible, not waiting until the document is actually

posted or ready for posting.

6.2.2. Timing of Disclosure Under Section 6.1.2

The IPR disclosure required pursuant to section 6.1.2 must be made as

soon as reasonably possible after the Contribution is published in an

Internet Draft or RFC, unless the required disclosure is already on

file. Participants who realize that the IPR will be or has been

incorporated into a submission to be published in an Internet Draft,

or is seriously being discussed in a working group, are strongly

encouraged to make at least a preliminary disclosure. That

disclosure should be made as soon after coming to the realization as

reasonably possible, not waiting until the document is actually

posted or ready for posting.

If a participant first learns of IPR that meets the conditions of

Section 6.6 in a Contribution by another party, for example a new

patent application or the discovery of a relevant patent in a patent

portfolio, after the Contribution was published in an Internet-Draft

or RFC, a disclosure must be made as soon as reasonably possible

after the IPR becomes reasonably and personally known to the

participant.

6.3. How Must a Disclosure be Made?

IPR disclosures are made by following the instructions at

http://www.ietf.org/ipr-instructions.

6.4. What Must be in a Disclosure?

6.4.1. The disclosure must list the numbers of any issued patents or

published patent applications or indicate that the claim is based on

unpublished patent applications. The disclosure must also list the

specific IETF or RFC Editor Document(s) or activity affected. If the

IETF Document is an Internet-Draft, it must be referenced by specific

version number. In addition, if the IETF Document includes multiple

parts and it is not reasonably apparent which part of such IETF

Document is alleged to be Covered by the IPR in question, it is

helpful if the discloser identifies the sections of the IETF Document

that are alleged to be so Covered.

6.4.2. If a disclosure was made on the basis of a patent application

(either published or unpublished), then, if requested to do so by the

IESG or by a working group chair, the IETF Executive Director can

request a new disclosure indicating whether any of the following has

occurred: the publication of a previously unpublished patent

application, the abandonment of the application and/or the issuance

of a patent thereon. If the patent has issued, then the new

disclosure must include the patent number and, if the claims of the

granted patent differ from those of the application in manner

material to the relevant Contribution, it is helpful if such a

disclosure describes any differences in applicability to the

Contribution. If the patent application was abandoned, then the new

disclosure must explicitly withdraw any earlier disclosures based on

the application.

New or revised disclosures may be made voluntarily at any time.

6.4.3. The requirement for an IPR disclosure is not satisfied by the

submission of a blanket statement of possible IPR on every

Contribution. This is the case because the aim of the disclosure

requirement is to provide information about specific IPR against

specific technology under discussion in the IETF. The requirement is

also not satisfied by a blanket statement of willingness to license

all potential IPR under fair and non-discriminatory terms for the

same reason. However, the requirement for an IPR disclosure is

satisfied by a blanket statement of the IPR discloser's willingness

to license all of its potential IPR meeting the requirements of

Section 6.6 (and either Section 6.1.1 or 6.1.2) to implementers of an

IETF specification on a royalty-free basis as long as any other terms

and conditions are disclosed in the IPR disclosure statement.

6.5. What Licensing Information to Detail in a Disclosure

Since IPR disclosures will be used by IETF working groups during

their evaluation of alternative technical solutions, it is helpful if

an IPR disclosure includes information about licensing of the IPR in

case Implementing Technologies require a license. Specifically, it

is helpful to indicate whether, upon approval by the IESG for

publication as RFCs of the relevant IETF specification(s), all

persons will be able to obtain the right to implement, use,

distribute and exercise other rights with respect to an Implementing

Technology a) under a royalty-free and otherwise reasonable and non-

discriminatory license, or b) under a license that contains

reasonable and non-discriminatory terms and conditions, including a

reasonable royalty or other payment, or c) without the need to obtain

a license from the IPR holder.

The inclusion of licensing information in IPR disclosures is not

mandatory but it is encouraged so that the working groups will have

as much information as they can during their deliberations. If the

inclusion of licensing information in an IPR disclosure would

significantly delay its submission it is quite reasonable to submit a

disclosure without licensing information and then submit a new

disclosure when the licensing information becomes available.

6.6. When is a Disclosure Required?

IPR disclosures under Sections 6.1.1. and 6.1.2 are required with

respect to IPR that is owned directly or indirectly, by the

individual or his/her employer or sponsor (if any) or that such

persons otherwise have the right to license or assert.

7. Failure to Disclose

There are cases where individuals are not permitted by their

employers or by other factors to disclose the existence or substance

of patent applications or other IPR. Since disclosure is required

for anyone submitting documents or participating in IETF discussions,

a person who does not disclose IPR for this reason, or any other

reason, must not contribute to or participate in IETF activities with

respect to technologies that he or she reasonably and personally

knows to be Covered by IPR which he or she will not disclose.

Contributing to or participating in IETF discussions about a

technology without making required IPR disclosures is a violation of

IETF process.

8. Evaluating Alternative Technologies in IETF Working Groups

In general, IETF working groups prefer technologies with no known IPR

claims or, for technologies with claims against them, an offer of

royalty-free licensing. But IETF working groups have the discretion

to adopt technology with a commitment of fair and non-discriminatory

terms, or even with no licensing commitment, if they feel that this

technology is superior enough to alternatives with fewer IPR claims

or free licensing to outweigh the potential cost of the licenses.

Over the last few years the IETF has adopted stricter requirements

for some security technologies. It has become common to have a

mandatory-to-implement security technology in IETF technology

specifications. This is to ensure that there will be at least one

common security technology present in all implementations of such a

specification that can be used in all cases. This does not limit the

specification from including other security technologies, the use of

which could be negotiated between implementations. An IETF consensus

has developed that no mandatory-to-implement security technology can

be specified in an IETF specification unless it has no known IPR

claims against it or a royalty-free license is available to

implementers of the specification unless there is a very good reason

to do so. This limitation does not extend to other security

technologies in the same specification if they are not listed as

mandatory-to-implement.

It should also be noted that the absence of IPR disclosures is not

the same thing as the knowledge that there will be no IPR claims in

the future. People or organizations not currently involved in the

IETF or people or organizations that discover IPR they feel to be

relevant in their patent portfolios can make IPR disclosures at any

time.

It should also be noted that the validity and enforceability of any

IPR may be challenged for legitimate reasons, and the mere existence

of an IPR disclosure should not automatically be taken to mean that

the disclosed IPR is valid or enforceable. Although the IETF can

make no actual determination of validity, enforceability or

applicability of any particular IPR claim, it is reasonable that a

working group will take into account on their own opinions of the

validity, enforceability or applicability of Intellectual Property

Rights in their evaluation of alternative technologies.

9. Change Control for Technologies

The IETF must have change control over the technology described in

any standards track IETF Documents in order to fix problems that may

be discovered or to produce other derivative works.

In some cases the developer of patented or otherwise controlled

technology may decide to hand over to the IETF the right to evolve

the technology (a.k.a., "change control"). The implementation of an

agreement between the IETF and the developer of the technology can be

complex. (See [RFC1790] and [RFC2339] for examples.)

Note that there is no inherent prohibition against a standards track

IETF Document making a normative reference to proprietary technology.

For example, a number of IETF Standards support proprietary

cryptographic transforms.

10. Licensing Requirements to Advance Standards Track IETF Documents

RFC 2026 Section 4.1.2 states: "If patented or otherwise controlled

technology is required for implementation, the separate

implementations must also have resulted from separate exercise of the

licensing process." A key word in this text is "required." The mere

existence of disclosed IPR does not necessarily mean that licenses

are actually required in order to implement the technology. Section

4.1 of this document should be taken to apply to the case where there

are multiple implementations and none of the implementers have felt

that they needed to license the technology and they have no plausible

indications that any IPR holder(s) will try to enforce their IPR.

11. No IPR Disclosures in IETF Documents

IETF and RFC Editor Documents must not contain any mention of

specific IPR. All specific IPR disclosures must be submitted as

described in Section 6. Specific IPR disclosures must not be in the

affected IETF and RFC Editor Documents because the reader could be

misled. The inclusion of a particular IPR disclosure in a document

could be interpreted to mean that the IETF, IESG, or RFC Editor has

formed an opinion on the validity, enforceability, or applicability

of the IPR. The reader could also be misled to think that the

included IPR disclosures are the only IPR disclosures the IETF has

received concerning the IETF document. Readers should always refer

to the on-line web page to get a full list of IPR disclosures

received by the IETF concerning any Contribution.

(http://www.ietf.org/ipr/)

12. Security Considerations

This memo relates to IETF process, not any particular technology.

There are security considerations when adopting any technology,

whether IPR-protected or not. A working group should take those

security considerations into account as one part of evaluating the

technology, just as IPR is one part, but there are no known issues of

security with IPR procedures.

13. References

13.1. Normative References

[RFC2026] Bradner, S., "The Internet Standards Process -- Revision

3", BCP 9, RFC 2026, October 1996.

[RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in

the IETF Standards Process", BCP 11, RFC 2028, October

1996.

[RFC2418] Bradner, S., "IETF Working Group Guidelines and

Procedures", BCP 25, RFC 2418, September 1998.

[RFC3978] Bradner, S., Ed., "IETF Rights in Contributions", BCP 78,

RFC 3978, January 2005.

13.2. Informative References

[RFC1790] Cerf, V., "An Agreement between the Internet Society and

Sun Microsystems, Inc. in the Matter of ONC RPC and XDR

Protocols", RFC 1790, April 1995.

[RFC2339] The Internet Society and Sun Microsystems, "An Agreement

Between the Internet Society, the IETF, and Sun

Microsystems, Inc. in the matter of NFS V.4 Protocols", RFC

2339, May 1998.

14. Acknowledgements

The editor would like to acknowledge the help of the IETF IPR Working

Group and, in particular the help of Jorge Contreras of Hale and Dorr

for his careful legal reviews of this and other IETF IPR-related and

process documents. The editor would also like to thank Valerie See

for her extensive comments and suggestions.

Editor's Address

Scott Bradner

Harvard University

29 Oxford St.

Cambridge MA, 02138

Phone: +1 617 495 3864

EMail: sob@harvard.edu

Full Copyright Statement

Copyright (C) The Internet Society (2005).

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 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.

Acknowledgement

Funding for the RFC Editor function is currently provided by the

Internet Society.

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有