The Free Software Foundation and the GNU Project oppose publication
of "Transport Layer Security (TLS) Authorization Extensions"
(draft-housley-tls-authz-extns) as a proposed standard. We do not
think that RedPhone Security's 1026 disclosure filing provides
sufficient assurance to free software users that they will not be
considered in violation of RedPhone's patent.
In response to a previous RedPhone patent disclosure, GnuTLS removed
its support for these authorization extensions. The updated
Licensing Declaration does not provide assurance sufficient for
GnuTLS to restore this support, and the same unfortunately holds
true for any other software maintained by the GNU Project.
The Licensing Declaration starts out right:
> RedPhone Security hereby asserts that the techniques for sending
> and receiving authorizations defined in TLS Authorizations
> Extensions (version draft-housley-tls-authz-extns-07.txt) do not
> infringe upon RedPhone Security's intellectual property rights
> (IPR).
However, it is then followed by an important caveat:
> The values provided in, and the processing required by the
> authorizations ("authz_data" in the Protocol Document) sent or
> received using the techniques defined in TLS Authorizations
> Extensions are not specified in the Protocol Document. When an
> implementation generates the authorizations or processes these
> authorizations in any of the four ways described below, then
> this practice may be covered by RedPhone Security's patent
> claims.
It appears that RedPhone's disclaimer covers software developers who
implement the standard in a vague sense, but not the people who then
actually use that software. A patent disclaimer must clearly cover
both developers and users to be acceptable. Furthermore, the caveat
is not written exclusively, leaving the door open for further
claims. It does not say that the four ways described are the *only*
practices that may be covered.
RedPhone's assurance that it will "grant licenses for such uses in a
fair and nondiscriminatory manner" does not address the problems
raised by their assertion, because software users cannot be expected
to place trust in a company's judgment of what constitutes fair or
nondiscriminatory. No company should be vested with the power to
make case-by-case licensing decisions about who can and who cannot
use or implement a standard, and users regardless should not have to
pay for permission to use Internet standards.
We know that the IETF and IESG largely share our view that
patent-encumbered standards are unacceptable. We believe that the
process has twice now reached the proper conclusion -- the draft has
been rejected as a standard. Please do not allow this decision to be
negated. If RedPhone is serious about providing a patent assurance
sufficient to cover both writing and using software that implements
these authorization extensions, the FSF would be happy to work with
them on drafting text that makes this intent clear.
On a broader note, we'd like to suggest that the IETF consider the
impact of of patents and copyrights on proposed standards
specifically and separately, instead of under the umbrella of IPR or
"intellectual property." The term lumps together disparate areas of
law and inaccurately frames questions then discussed as analogous to
questions about property rights over physical objects -- a framing
that suits companies who wish to extend the influence of their
copyrights and patents. It also has the effect of including other
laws in the discussion which don't actually pertain to the question
of who can use the standard. The term has unfortunately become
widespread, but a community as concerned and responsible with
language as the IETF should take leadership in this area and reject
its use.
Thank you for the opportunity to comment on these issues. We
recognize that the volume of mail generated by our announcement
about this issue to the free software community may be causing
inconvenience, but causing inconvenience was not the point of that
call. In our reading of the comments that have been sent so far from
the free software community, the majority of them are from people
who work in related areas and have taken time to think through and
express their concerns. We hope the IETF will consider each comment
on its individual merit, and if the volume of mail is interfering
with that process, consider providing in the future a separate
address for comment that is not the general mailing list. Our goal
and our encouragement to the public is to participate in the process
according to the directions provided, not to spoil it.
--
Sincerely,
The Free Software Foundation
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf