Simon, Thanks, I'm glad you thought the license was helpful: > 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! I want to speak informally and just kick some ideas around right now. So, disclaimer, For this and other posts to this IETF email list, please understand that I'm speaking for myself and not as an agent of RedPhone Security. Ok. You raise two problems: > 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. Problem 1 seems solvable to me, but I'd like more input. For 2, My goal is this exchange: Manufacturer: "We're requesting the General Use License from RedPhone Security. In exchange, we promise not to implement (or on a per-release basis: we did not implement) the PAS Functions." Each Manufacturer needs to take responsibility only for "his" own actions; any subsequent Manufacturer (alters the code in a way that may or may not be material to the PAS Functions) either voids the license or inherits it or requests their own license -- but that's not "your" problem. A Manufacturer will develop code, test the functionality and release the software. At each of these steps it should be pretty clear if the software being developed, tested and released violates the PAS Functions. ..Doubly clear if the function of the software is to make use of X509 certificates which are marked with a "critical" policy that identifies RedPhone Security (a hard-coded OID ending in .23106 will likely show up in the software). I think a free software provider/clearinghouse could choose to not go beyond the RedPhone Security General Use License with no problem. In the event that some third party contributor made a code contribution "back" to the provider that violated the PAS Functions, simply classify that code-contribution as "buggy" -- and choose to not roll that contribution up into any release. I can imagine a case where a user of free software chooses to start with free software and then obtain a PAS License from RPS and become Manufacturer2. Then the score would be: Manufacturer1: GUL, Manufacturer2: PASL, and both would remain true to their commitments -- no problems. The only problem would be if Manufacturer2 contributed PAS Functions back to Manufacturer1 and then Manufacturer1 rolled those functions in (and tested and released them) under GUL. Back to question 1, I guess the question for me is, Who is making the promise to RedPhone Security? How the promise is communicated is not the main issue. If the preferred OpenSSL approach is to put a legal stuff into comments atop source files which are published for anyone to see, that may be more effective than sending one postcard. This may also help (somewhat) the "on installation" question. If one Manufacturer only releases (presumably tested) source code, then "on installation" for source code could simply be comments atop the source code file. What I want to accomplish is fair warning to downstream users / Manufacturers, so that we can help users steer clear of accidental GUL violations. In summary, for (1) I'd like more input. RPS "will provide" a GUL upon request, by snail mail or electronically. The question I have is how an open source provider might prefer to make that request with its associated promise about PAS Functions -- once and for all, or from time to time, etc. This question could be sorted out on a per-license basis, but I think consistency would be preferable. For (2) I'd like each Manufacturer/User to stand on his or her own two feet. If "you" made or used the PAS Functions, "you" need a license. Otherwise, say "you" didn't under the GUL. No Manufacturer under the GUL should be responsible for implementations of PAS Functions that they did not develop, test and/or release. Thanks for your response Simon. Best regards, --mark _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf