[Tinyos-alliance] IETF process

[Matt Welsh]

Hi folks,

I had a chance to talk with Scott Bradner today, who is involved with
the IETF and is the author of the IETF's IP process documents
(RFC3978 and RFC3979).

There are two issues that the IETF deals with: copyrights on Internet
Drafts and RFC documents, and patents. I'll do my best to explain them
as he tells it. Note that I may have some details wrong as I have not
checked this against the language in the RFCs mentioned above.

---

COPYRIGHTS on IETF docs are held by the individual that writes the
document. The copyright owner gives the IETF the right to publish the
document as an RFC and also to make derivative works *within the IETF
process*. That means that an RFC that defines a network protocol, say,
can be extended by another IETF participant (and eventually produced as
a new RFC), but third parties are not allowed to produce derivative
works.

Note that anyone can produce an implementation of an RFC (even one that
is not 100% faithful to the standard), since an implementation is not
considered a 'derivative work'. 

Note that the IETF does not mostly deal with source code. However, there
is pseudocode as well as 'real' source code contained in IETF documents.
RFC3978 explicitly gives permission for implementers to extract that
source code and compile it. Note that making any modifications or
redistributing that code, however, would constitute making a derivative
work of the RFC, and is therefore disallowed.

---

PATENTS -- RFC3979 generally describes how IETF deals with intellectual
property rights (IPR) that companies or individuals might have in IETF
documents. 

The basic model that the IETF uses is that participants (meaning:
someone who speaks at a meeting or contributes to a mailing list, not
someone who simply attends a meeting) must disclose any IPR that they
have, their employer has, or that they know another participant has.
An IPR disclosure details which patents (or patent applications) may
impact the technology being considered. 

[It is worth noting that the W3C requires that standards they produce
have no IPR claims. Scott says that this is a big problem, since there
is no good way to know whether someone has a patent on something, and
the W2C has been burned by third parties claiming patent rights on
something in a W3C standard. The IETF, in contrast, does not disallow
IPR in its standards process.]

Working groups can then take this IPR into consideration, and they
typically shy away from technology that is encumbered by IPR. However,
the IETF does not disallow an RFC that would, for example, require an
implementer to license patent rights from a company. Scott gave the
example of IP header compression for cell phones, all of the proposals
for which came with IPR. Because the implementers tend to be other cell
phone companies, they are used to paying license fees to one another for
this kind of technology. 

Note that owners of IP rights are *encouraged* (but not required) by the
IETF to provide a license that gives implementers the right to implement
an RFC without paying royalties. 

Keep in mind that third parties (non-participants) may still have IP
rights in RFC documents produced by the IETF, since third parties are
not bound by this disclosure requirement. That means that Joe Schmo with
a patent on something in RFC XXXX could sue someone to implements that
RFC. Obviously this is something that the IETF wants to avoid, but in
some sense it is really unavoidable. 

The IP disclosures for each RFC are found on the web and are not
included in the RFCs themselves, since once an RFC is published it never
changes. It is up to an implementer of an RFC to get up-to-the-minute
status of any IP disclosures associated with the RFC by checking the web
site.

----

PROPOSAL FOR THE TINYOS ALLIANCE: We may wish to consider a process in
which companies are allowed to contribute to TinyOS, but anything that
gets included in the TinyOS source code or as part of a standards
document (should we produce those) either (a) is unencumbered by IP
claims or (b) has a license for royalty-free use, implementation,
distribution, etc. of any associated IPR. This would exclude
contributions that necessitate users or implementers to get a license
from the IP holder, which seems to be consistent with an "open source"
model. I am not sure how workable this is, but wanted to put that out
there.

Matt