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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf