hartmans-ietf(_at_)mit(_dot_)edu writes:
The authors asked for a week delay while they prepared a new IPR
disclosure. That disclosure seems to have hit the IETF servers
Ah, good. For easy reference, the new IPR disclosure is available
from:
https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=833
From a proprietary perspective, it appears to be a rather permissive
license. It seems to be one of the better ones that I have read
relative to the other licenses in the IETF IPR disclosure list. Kudos
to Mark!
However, if I understand the license correctly, it seems incompatible
with free software licenses. The RedPhone license contains:
"1. General Use License"
"Upon request, RedPhone Security will provide a worldwide,
nonexclusive, fully-paid, perpetual, royalty-free patent license to
manufacturers who (a) implement the Protocol, (b) acknowledge this
general use license as described in Schedule B, and (c) refrain
from implementing any Protected Assurance System Functions defined
and listed below. This general use license granted to
manufacturers also flows down to sublicensees and users, to permit
end users of these systems (including both client and server
components) to use the Protocol, provided those users do not use
the system as a Protected Assurance System (PAS) as defined in
Schedule A without obtaining an End User License."
There are two problems here:
1) Requires that vendors 'request' the license. It would be
better if the license was given directly to third parties without
any action required by the third parties.
2) The restriction of field-of-use (i.e., cannot be used with
PAS) is incompatible with free software norms: implementations
must be usable for any purpose as long as the license is
followed, and several free software licenses does not permit
restrictions like this.
Studying problem 2) in more detail for some common licenses:
1) Section 6 of the GPL and section 10 of the LGPL which says:
"You may not impose any further restrictions on the recipients'
exercise of the rights granted herein."
http://opensource.org/osi3.0/licenses/gpl-license.php
http://opensource.org/osi3.0/licenses/lgpl-license.php
2) Section 2.1 of the Mozilla 1.1 License:
"The Initial Developer hereby grants You a world-wide,
royalty-free, non-exclusive license, subject to third party
intellectual property claims:
...
(b) under Patents Claims infringed by the making, using or
selling of Original Code, to make, have made, use, practice,
sell, and offer for sale, and/or otherwise dispose of the
Original Code (or portions thereof).
http://opensource.org/osi3.0/licenses/mozilla1.1.php
3) Section 3 of the Apache 2.0 License:
http://opensource.org/osi3.0/licenses/apache2.0.php
I stopped looking at licenses after that, but I'm sure similar
problems can be found with other licenses. These are licenses that
widely adopted TLS implementations are distributed under.
Thus, it seems that this license may allow some proprietary vendors to
implement tls-authz, but it prevents free software vendors to provide
a GPL/LGPL/Mozilla/Apache/etc implementation because the RedPhone
license is incompatible with these free software licenses.
I don't believe this was the intention. Mark, would you like to
comment? I am inclined to believe that Mark's license is more
consequence of lack of understanding how free software licensing
works, rather than bad-faith against free software.
Perhaps there is some use of an informational document that explains
how IPR disclosures needs to be written in order to be free software
friendly. Mark, others, would such a document be helpful when trying
to write an IPR disclosure?
At this point, I think I'm bringing up a generic concern which also
affects many other drafts with IPR disclosures than Mark's. It is
somewhat unfair to Mark to have to go through all these discussions
because the IETF doesn't have fully functioning procedures and/or
guidelines on this. Still, since this document is a good example of
patented technology aiming at the standards track, with a license
incompatible with free software licenses, and I believe the IETF
should discuss the problem -- as a general problem, not just for
Mark's document -- further.
/Simon
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf