--On Wednesday, 17 January, 2007 07:32 -0500
"Contreras, Jorge"
<Jorge.Contreras 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-wgietf.org
https:/
/www1.ietf.org/mailman/listinfo/ipr-wg
|