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