4cf3186345
one central place, now that the finished ones are POLICY, and others such as Foundations / Privacy are closely held. git-svn-id: http://svn.cacert.org/CAcert/Policies@567 14b1bab8-4ef6-0310-b690-991c95c89dfd
395 lines
11 KiB
HTML
395 lines
11 KiB
HTML
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
|
|
|
<html>
|
|
<head><title>CAcert - 3rd Party Vendor -- Licence and Disclaimer </title></head>
|
|
<body>
|
|
|
|
<h3> -1. TO BE FIXED </h3>
|
|
|
|
|
|
<center> <b> D R A F T </b> </center>
|
|
|
|
<p> <i>
|
|
This is DRAFT-V0.02.
|
|
</i></p>
|
|
|
|
<ul><li><i>
|
|
th: firefox/thunderbird/evolution/etc distribute things
|
|
but also to distributors eg Fedora, Ubuntu, etc. Who on there term
|
|
redistribute it. This recursion should that be explicit in this
|
|
disclaimer and license?
|
|
What to do about multi-tier distributors,
|
|
is this agreement with primary or end distributor or all of them?
|
|
Mozilla => KDE => Evolution.
|
|
</i></li><li><i>
|
|
pg: I think the 3pv should define "USE" and "RELY" in a preamble
|
|
(or somewhere else at the beginning)
|
|
Perhaps even specifically declare the difference between USE and RELY
|
|
The other things are more or less clear in general,
|
|
but USE and RELY and its special meaning should be defined
|
|
</i></li><li><i>
|
|
pg: 1.4 Agreement in Spirit
|
|
It doesn't clearly indicate that this is only in respect to cert stuff.
|
|
Also, why are we policing the redistributors?
|
|
</i></li><li><i>
|
|
Practically everything else...
|
|
These are just scattered ideas and have not been exposed to criticism yet...
|
|
</i></li></ul>
|
|
|
|
<hr>
|
|
|
|
|
|
<h3> <a name="0"> 0. </a> Preliminaries </h3>
|
|
|
|
|
|
<h4> <a name="0.1"> 0.1 </a> Background </h4>
|
|
|
|
<p>
|
|
Being that,
|
|
</p>
|
|
|
|
<ul><li>
|
|
CAcert is a Certificate Authority ("the CA"),
|
|
</li><li>
|
|
the CA offers a free certificate service to its subscribers,
|
|
</li><li>
|
|
for the direct benefit and RELIANCE of its Community of signed-up users,
|
|
</li><li>
|
|
and where possible, of some indirect benefit and USE to other general users
|
|
(or end-users) of the Internet;
|
|
</li></ul>
|
|
|
|
<p>
|
|
And that,
|
|
</p>
|
|
|
|
<ul><li>
|
|
the end-user has a choice in client software (such as browsers and email clients),
|
|
</li><li>
|
|
such software offers features which are wholly or partly
|
|
based on use of certificates,
|
|
</li><li>
|
|
which may include the certificates of the CA
|
|
and/or of any other certificate authority,
|
|
</li><li>
|
|
the end-user may have strictly limited possibilities to choose or
|
|
control the usage made of certificates,
|
|
</li><li>
|
|
and that it may not be economic nor reasonable for software
|
|
to provide for a high degree of choice and control over certificates,
|
|
</li></ul>
|
|
|
|
<p>
|
|
And that, in offering the USE of certificates to the end-user,
|
|
</p>
|
|
|
|
<ul><li>
|
|
the CA has no direct relationship with the the end-user,
|
|
</li><li>
|
|
it is not economic nor reasonable to expect such a
|
|
direct relationship,
|
|
</li><li>
|
|
by way of an open, indirect offering,
|
|
the CA provides its
|
|
<a href="http://www.cacert.org/policy/NRPDisclaimerAndLicence.php">
|
|
Non-Related Persons -- Disclaimer and Licence</a>
|
|
for the end-user ("NRP"), in which
|
|
<ul><li>
|
|
the CA disclaims liability to NRPs,
|
|
</li><li>
|
|
the CA offers a free licence to USE to all NRPs,
|
|
</li><li>
|
|
the CA specifically does not permit the NRPs to RELY,
|
|
</li></ul>
|
|
</li></ul>
|
|
|
|
<p>
|
|
And that,
|
|
</p>
|
|
|
|
<ul><li>
|
|
<b>you are a third party vendor or distributor of software for end-users</b>
|
|
("the Vendor"),
|
|
</li><li>
|
|
the Vendor offers a free distribution of root certificates ("root list"),
|
|
within client software,
|
|
</li><li>
|
|
that in choosing the Vendor's software,
|
|
the end-user would enter into an
|
|
End-User Licence Agreement ("EULA") with the Vendor,
|
|
</li><li>
|
|
the Vendor has the primary and only direct relationship with the end-user,
|
|
</li></ul>
|
|
|
|
<p>
|
|
We both, CA and Vendor, agree that,
|
|
</p>
|
|
|
|
<ul><li>
|
|
we are committed to providing a
|
|
free and USABLE way to benefit from cryptography,
|
|
</li><li>
|
|
we are committed to the security of our respective communities,
|
|
</li><li>
|
|
the design, custom and history of the public key infrastructure
|
|
("the PKI") creates risks and liabilities
|
|
for inappropriate RELIANCE by the end-user,
|
|
</li><li>
|
|
it is not economically possible nor reasonable
|
|
to provide a free, open and unconstrained service
|
|
that can be RELIED upon by end-users.
|
|
</li></ul>
|
|
|
|
|
|
<h4> <a name="0.2"> 0.2 </a> Parties </h4>
|
|
|
|
With the above understanding, the following Licence and Disclaimer is offered
|
|
by CA to Vendor.
|
|
|
|
<h4> <a name="0.3"> 0.3 </a> Terms </h4>
|
|
|
|
<p>
|
|
Terms used in this agreement are as defined in the
|
|
<a href="http://svn.cacert.org/CAcert/RegisteredUserAgreement.html">
|
|
CAcert Community Agreement</a>.
|
|
</p>
|
|
|
|
|
|
<h3> <a name="1"> 1. </a> Agreement and Licence </h3>
|
|
|
|
<h4> <a name="1.1"> 1.1 </a> Agreement </h4>
|
|
|
|
<p>
|
|
You and CAcert both agree to the terms and conditions in this agreement.
|
|
The relationship between the CA and the Vendor is based on this agreement.
|
|
Your agreement is given by your distribution of the root within your
|
|
distribution of your root list.
|
|
</p>
|
|
|
|
<h4> <a name="1.1"> 1.2 </a> Other Agreements </h4>
|
|
|
|
<p>
|
|
The relationship between the Vendor and the end-user is based on Vendor's own agreement
|
|
("end-user licence agreement" or EULA).
|
|
Generally, the Vendor offers the EULA to the end-user
|
|
in the act of distributing the software and roots.
|
|
</p>
|
|
|
|
<p>
|
|
The relationship between the CA and the end-user is based on CA's
|
|
Non-Related Persons -- Disclaimer and Licence
|
|
("<a href="http://www.cacert.org/policy/NRPDisclaimerAndLicence.php">NRP-DaL</a>").
|
|
This Licence follows the style of popular open source licences,
|
|
in that it is offered to an unknown audience, without a necessary
|
|
expectation for explicit agreement by the end-user,
|
|
because of the methods and restrictions of delivery.
|
|
</p>
|
|
|
|
<h4> <a name="1.3"> 1.3 </a> Licence to Distribute </h4>
|
|
|
|
<p>
|
|
CA offers this licence to permit Vendor to distribute CA's roots
|
|
within Vendor's root list to Vendor's end-users.
|
|
</p>
|
|
|
|
<h4> <a name="1.4"> 1.4 </a> Agreement in Spirit </h4>
|
|
<p>
|
|
Vendor agrees to make EULA compatible and aligned with the CA's NRP-DaL.
|
|
Specifically, the EULA must:
|
|
</p>
|
|
|
|
<ul><li>
|
|
disclaim all liability,
|
|
</li><li>
|
|
offer free licence to USE, and
|
|
</li><li>
|
|
deny permission to RELY under this EULA;
|
|
</li></ul>
|
|
|
|
<p>
|
|
all with respect to the root list
|
|
(including root keys, certificates,
|
|
and related cryptographic and security software).
|
|
</p>
|
|
|
|
<h4> <a name="1.5"> 1.5 </a> Agreement in Practice </h4>
|
|
|
|
<p>
|
|
Where agreement is explicitly sought from the end-user
|
|
they will be offered and agree to:
|
|
</p>
|
|
|
|
<ul><li>
|
|
CA's NRP-DaL,
|
|
where the NRP-DaL and EULA are not in contradiction,
|
|
<i>OR</i>
|
|
</li><li>
|
|
only your EULA,
|
|
where the spirit of the NRP-DaL is preserved
|
|
within the EULA.
|
|
</li></ul>
|
|
|
|
<p>
|
|
Vendors are encouraged to ship the NRP-DaL with their software,
|
|
and make available means for the end-user to further
|
|
examine the NRP-DaL.
|
|
<br><i>Note, document this elsewhere in FAQ</i>.
|
|
</p>
|
|
|
|
<h4> <a name="1.6"> 1.6 </a> Fair and Non-Discriminatory </h4>
|
|
|
|
<p>
|
|
Vendor agrees to make available CA's root key
|
|
in a fair and non-discriminatory way to Vendor's end-users.
|
|
<br><i>Note, document this elsewhere in FAQ</i>.
|
|
</p>
|
|
|
|
<h3> <a name="2"> 2. </a> Disclaimer </h3>
|
|
|
|
<h4> <a name="2.1"> 2.1 </a> All Liability </h4>
|
|
|
|
<p>
|
|
Vendor's relationship with end-users creates risks, liabilities
|
|
and obligations due to the end-user's permitted USE of the certificates,
|
|
and potentially through other activities such as inappropriate
|
|
and unpermitted RELIANCE.
|
|
</p>
|
|
|
|
<p>
|
|
We in general DISCLAIM ALL LIABILITY to each other and to the end-user.
|
|
</p>
|
|
|
|
|
|
<h4> <a name="2.2"> 2.2 </a> Monetary Limits on Liability </h4>
|
|
|
|
<p>
|
|
Notwithstanding the general disclaimer on liability above,
|
|
we agree that, to the extent that CAcert is reasonably
|
|
represented to the Vendor's end-user by the software
|
|
as being the Certificate Authority, at the events and
|
|
circumstances of question,
|
|
liability of CAcert is strictly limited to be 1000 euros.
|
|
This is the same limit of liability that applies to each
|
|
member of the CAcert Community.
|
|
</p>
|
|
|
|
<p>
|
|
To the extent that the CA is not reasonably represented
|
|
to the end-user, we agree that any liability is limited
|
|
to the lowest of agreed liabilities of all CAs for all
|
|
roots shipped by the Vendor, and 1000 euros.
|
|
</p>
|
|
|
|
<h3> <a name="3"> 3. </a> Legal Matters </h3>
|
|
|
|
<h4> <a name="2.3"> 3.1 </a> Law </h4>
|
|
|
|
<p>
|
|
The Choice of Law is that of NSW, Australia.
|
|
</p>
|
|
|
|
<h4> <a name="2.4"> 3.2 </a> Dispute Resolution </h4>
|
|
|
|
<p>
|
|
We agree that all disputes arising out
|
|
of or in connection to this agreement
|
|
and the root key of the CA
|
|
shall be referred to and finally resolved
|
|
by Arbitration under the
|
|
Dispute Resolution Policy of the CA
|
|
(DRP => COD7).
|
|
The ruling of the Arbitrator is binding and
|
|
final on CA and Vendor alike.
|
|
</p>
|
|
|
|
<p>
|
|
We further agree, as a single exception to DRP,
|
|
that the single Arbitrator may be chosen from outside
|
|
the CAcert Community.
|
|
</p>
|
|
|
|
<h4> <a name="3.x"> 3.3 </a> CAcert Community Agreement </h4>
|
|
|
|
<p>
|
|
The CA also offers a CAcert Community Agreement (CCA).
|
|
The CCA replaces the NRP-DaL and this present agreement
|
|
for those parties that accept it.
|
|
</p>
|
|
|
|
<p>
|
|
If a Community member is also an end-user, then the provisions
|
|
of the CCA will replace all elements of the CA's NRP-DaL,
|
|
and will dominate this present agreement.
|
|
</p>
|
|
|
|
<p>
|
|
Acceptance alone of this present agreement by the Vendor
|
|
does not imply that Vendor is a Community User/Member.
|
|
</p>
|
|
|
|
<hr>
|
|
|
|
<p>
|
|
The following parts are not part of the above licence,
|
|
but may shed light.
|
|
</p>
|
|
|
|
<h3> <a name="faq"> Z. </a> FAQ </h3>
|
|
|
|
<h4> <a name="Z.1"> Z.1 </a> Notes on Liability </h4>
|
|
|
|
<p>
|
|
Liability agreement between CA and Vendor
|
|
suggests that the end-user be presented with the name of the CA.
|
|
This is useful for identifying the particular characteristics
|
|
of the CA, and accepts that all CAs are different.
|
|
Each CA has its ways of checking, its relevent laws, and its
|
|
particular view as to the interests of the end-user.
|
|
</p>
|
|
|
|
<p>
|
|
The Vendor should present the name of the CA so as to inform
|
|
the end-user of what can be known.
|
|
In the event that the Vendor does not present the CA,
|
|
the CA is taking on all the risk and liability that the
|
|
CA is equivalent to others, which can only be rationally
|
|
measured as the <i>lowest-common-denominator</i>, that is,
|
|
the lowest of the liabilities that is accepted across all
|
|
CAs that are shipped by the CA.
|
|
This would generally be zero.
|
|
</p>
|
|
|
|
<p>
|
|
If the CA has been presented to the end-user, the end-user
|
|
is able to discriminate.
|
|
In this case, it is reasonable for the CA to offer to share
|
|
the liability, and to accept some limit
|
|
to that liability.
|
|
</p>
|
|
|
|
<p>
|
|
Always remembering that this is strictly within the
|
|
relationship with the Vendor.
|
|
As there are millions and one day, billions of users, and as
|
|
the software and the certificates are free, the liability
|
|
to the end-user must be disclaimed totally.
|
|
In other words, set to zero.
|
|
</p>
|
|
|
|
<h4> <a name="Z.2"> Z.2 </a> Reasonably Shown </h4>
|
|
|
|
<p>
|
|
To reasonably show the name of the CA is undefined,
|
|
as security user interfaces currently are not representative
|
|
of reasonable descriptions, and the area is an open research
|
|
topic (sometimes known as "usable security").
|
|
</p>
|
|
|
|
<p>
|
|
A reasonable man test is known in law, and selects someone
|
|
who would be the reasonable person who would use the software.
|
|
This might hypothetically examine whether a majority of
|
|
random users would have "got it" when presented with the
|
|
same information, however this is not quite how it is tested
|
|
in law; instead, it is more of a gut-feeling.
|
|
</p>
|