Simon Josefsson wrote:
I disagree. The IETF policies around patents mention "use" as well
as "implementation". Thus, a license that permit "implementation"
but not permitting "use" should generate similar scrutiny and
discussion. It poses the same problem for actual users.
I strongly disagree with a notion that just because someone grants a
patent license for "implementation" that the IETF community has to
consider the patent situation around the technology as irrelevant.
Use of technology goes beyond "implementation". This is
acknowledged in the IETF policy documents. Compare, e.g., RFC 3979
and in particular the definition of the term "Covers".
I also disagree with the claim that the draft is unencumbered. I
don't follow how you reach that conclusion from the patent
disclaimer. You quoted only one paragraph out of several, and the
other paragraphs are the ones that encumber use of the protocol. It
may be your interpretation that the draft is unencumbered, but
everyone get the same opportunity to make their own interpretation.
As implementer of the technology, and having consulted with legal
aid, I have made another interpretation.
<speaking as an individual, not wearing any hats>
Well, it's good to remember that there are *lots* of patents about
larger systems that include IETF protocols (e.g., TLS, HTTP, MPLS,
Mobile IP, or RADIUS) as components. What's claimed to be novel (and
covered by the patent) is not the IETF protocol as such, but the
combination: using the protocol(s) in certain environment in
particular way to solve something. And of course there are lots of
implementation technique patents where what's claimed to be novel
(and covered by the patent) is some particular way of implementing
the protocols (e.g. better performance than "obvious" implementations).
Usually these types of patents are *not* disclosed to the IETF, since
the protocol as such is not covered by the patent.
In fact, my guess would be that we probably don't have *any* IETF
protocols where someone has not patented using protocol A in bigger
system B in way C to solve D (where B+C+D is something that the RFC
did not describe, so it could be non-obvious and novel). If we
required that IETF protocols must not have any such "field of use
restrictions" (where using the protocol in certain way could be
encumbered), we would not publish any protocols at all.
My reading of RedPhone's IPR disclosure 1026 is that they claim to
have a patent application about a larger system that includes
tls-authz as one part, and uses it in particular way. If you want to
build a system matching the numbered list 1..4 in the disclosure
(RedPhone's description of what they claim is covered), then you
would have to consider this IPR disclosure.
However, I think there are many more good uses for tls-authz that
do *not* match items 1..4. Just because someone has filed a patent
application on some rather obscure combination of B+C+D should not
prevent others from using the protocol for things not covered by
that application. Thus, I support publishing this as an RFC (either
Informational or Standards Track).
(BTW, I think it's pretty clear that RedPhone didn't get the
process right here. Some have claimed they did this knowingly with
malicious intent, others have attributed it more to carelessness
and ignorance -- I would say we can't really know without doing
a Vulcan mind meld :-) Either way, I think we should consider
the draft's technical merits and IPR situation *now*, and not
put too much weight on the history.)
Best regards,
Pasi
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf