Re: Patented RFC Code

[John C Klensin <john-ietf at jck.com>]

--On Wednesday, 17 January, 2007 07:32 -0500 "Contreras, Jorge"
<Jorge.Contreras at wilmerhale.com> wrote:

>> "Can I take code from a RFC and use it
>> in free software?" 
> 
> Under the current rules, if it is patented, 
> you will need a license from the patent owner.
> 
> Also under the current rules, if the Contributor
> has a patent covering the software, he/she is
> required to disclose the patent.  These
> disclosures are posted at
> https://datatracker.ietf.org/public/ipr_disclosure.cgi.
>...

Let me add one observation here, without advocating either a
change in policy (or not) or extended further discussion right
now.

In general, the IETF patent policy more or less assumes the
possibility of patents on the technology underlying a standard
and _perhaps_ necessary to practice it.  Now I think we are
talking about patents that specifically cover specific code or
data formats that actually appears in an RFC and that is
necessary to implement it.  Under the current model, where the
IETF can (and should) consider the nature of patent claims and
the state of licensing promises and disclosures in deciding
whether or not to standardize a particular technology, a WG
would be, IMO, insane to define a standard by copying patented
technologies or text directly into an RFC.   If nothing else,
doing so would not add value: one might as well write an RFC
that says "if you are interested in doing this in an
IETF-standard way, read the following patents and then go beg
the patent holder for a license".

I think this points out two things:

(1) During these oft-repeated debates about standards whose
obvious implementations involve encumbered technology, we keep
losing sight of the fact that nothing in the rules _requires_ a
WG to do that.  The policy merely creates the possibility of a
WG (and the IETF) making a choice to standardize something
encumbered.  It certainly does not eliminate the possibility of
declining to create a standard because the only options are
encumbered.  I believe we have made the choice to do nothing
when faced with "encumbered or nothing" in the past.  I would
hope that an individual (non-WG) submission for the standards
track that required encumbered technology, especially encumbered
technology from which the submitter stood to benefit, would be
treated, at best, with extreme skepticism.

The current policy doesn't require that we standardize
encumbered technology, it merely broadens our options.  Speaking
personally, I'd prefer to see a lot more complaints during WG
deliberations or, if necessary, at Last Call that point out that
there are encumbering technologies involved in a draft under
consideration and arguing more strongly for either un-encumbered
approaches or that standardization isn't useful enough given the
encumberances.  I would expect such arguments to be very
powerful against a definition that contained embedded code with
associated patent claims.

(2) IMO, all of this should strongly reinforce the importance of
standardizing results and observable behavior and not particular
methods and processes.   While that principle doesn't help much
in the case of data structures like MIBs, in general, while it
may be easier to write a standard in terms of code examples, or
even pseudo-code, than to do so in terms of descriptive text
that can be implemented in multiple ways, the latter is almost
always to be preferred, both to permit innovation and to reduce
vunerability of the standard itself to patent issues.

Just my opinion.
    john


_______________________________________________
Ipr-wg mailing list
Ipr-wg at ietf.org
https://www1.ietf.org/mailman/listinfo/ipr-wg