You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
cacert-policies/Agreements/3PVDisclaimerAndLicence.html

425 lines
12 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> w o r k -- i n -- p r o g r e s s</b> </center>
<p> <i>
This is wip-V0.03.
</i></p>
<ul><li><i>
What to do about multi-tier distributors:
th: firefox/thunderbird/evolution/etc distribute things
but also to distributors eg Fedora, Ubuntu, etc. Who on their terms
redistribute it. This recursion should that be explicit in this
disclaimer and license?
is this agreement with primary or end distributor or all of them?
Mozilla => KDE => Evolution.
</i></li><li><i>
This agreement is with vendors that choose not to be Members.
Is now made explicit.
What about vendors who choose to be Members?
</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
<br><b> OK, done.</b>
</i></li><li><i>
pg: 1.4 Agreement in Spirit
It doesn't clearly indicate that this is only in respect to cert stuff.
<br><b> extra line added "all with respect to...".</b>
</i></li><li><i>
Also, why are we policing the redistributors?
<br> <i>the roots and certs are CAcert responsibility.</i>
</i></li><li><i>
pg: not clear that this applies or does not apply to Member-vendors.
<br><b> it is in now, in one of the bullet points.</b>
</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.2"> 0.2 </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
("Members"),
</li><li>
where possible, of some indirect benefit and USE to other general users
("end-users") of the Internet;
</li></ul>
<p>
And that,
</p>
<ul><li>
the end-user has a choice in 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 or opaque
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 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><li>
the Vendor chooses not to be a Member of CAcert,
</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>
<b><a name="d_reliance" id="d_reliance">RELIANCE</a></b>.
A Member's act in making a decision,
including taking a risk,
in whole or in part based on the certificate.
</p>
<p>
<b><a name="d_use" id="d_use">USE</a></b>.
The event of allowing a certificate to participate
in a protocol, as decided and facilitated by the user's software.
In general, no significant input is required of the user.
</p>
<p>
Other 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 its relationship to end-users
compatible and aligned with the CA's NRP-DaL.
Specifically, the Vendor 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 may be offered and agree to:
</p>
<ul><li>
CA's NRP-DaL,
<s>where the NRP-DaL and EULA are not in contradiction,</s>
<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>