"Mark Brown" <mark@xxxxxxxxxxxxxxxxxxxx> writes: >> 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. Hi Mark! I believe I understand what you are trying to achieve here. It looks like a clean separation, but the problems are in the details. Below I'm speaking only from my point of view as a developer, independent contractor and software company. Others may of course have different opinions, and I would encourage more developers to share their thoughts. That would give you a more broad picture of the kind of problems you are likely to encounter. A basic problem is that you are not likely to get free software projects to request and agree with your GUL at all. This is related to problem (1). If you would rewrite your license to grant the rights to everyone without any need to contact you, that would solve this problem. It would be useful if you could explore with your lawyers if it is actually easy for you to avoid problem (1). I'm wondering what exactly the requirement for implementers to "request" this license from you gives you. Your text suggest that you will never refuse to grant the rights in your license to someone who ask, is that right? If so, what problem would there be in granting the rights immediately to everyone, without a need to request it from you? Is your reason that you want to know who is using your IPR, and open up a communication channel with them? To solve that concern, you could write a request that everyone is requested, but not legally required, to get in touch with you. That would get you into contact with the majority that is positive about talking with you, and you wouldn't need to hear from people who doesn't want to talk with you. Replacing the need to request a license from you with a requirement to place a comment in header files to make things clear to end users may be acceptable, possibly barring the problem in the next paragraph. This is basically the same as giving the rights directly to everyone, without a need to contact you. So it seems you have already started leaning towards that solution. (It is important that you do not require that the comment is placed in all "advertising material", or similar, or you will run into the problem that the original BSD license had with GPL-compatibility.) Another basic problem is that free software projects may not be able to agree to your field-of-use limitation in (2) and at the same time be compatible with license such as the GNU General Public License. Thus they would never be able to implement tls-authz even without any support for PAS under your license. I am not certain of this, but I could ask the Free Software Foundation's lawyers about this -- they are the copyright holder of GnuTLS which implements tls-authz without PAS today, and can speak authoritatively about this. Finally, here is another problem to consider: Your patent isn't valid in the entire world. You will run into situations where a manufacture is not bound or affected by your license. Only end-users or re-distributors in some countries will be affected. I believe this is the case for GnuTLS, I developed the tls-authz functionality in Sweden and as far as I can tell your patent isn't valid here. I see no reason to request or agree with the GUL. You may want to offer a license not only to manufacturers, but to end-users or re-distributors. This makes the licensing situation much more complex. At the end of the day, I think you won't get many advantages from your current license compared to a license that would give everyone the right to use your technology for any purpose as long as they don't sue you. Compare the licenses, linked to by others in this thread, from Microsoft, Nokia, etc. I believe that if your license is not regarded as liberal enough to grant free implementations (and that doesn't seem unlikely given the discussions on this list), people will standardize alternative technology that solves the same problem. If that happens, you won't even have the protection in revoking licenses of your IPR to companies that sue you. Best Regards, Simon _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf