hartmans-ietf@xxxxxxx 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf