From c8c4de25b8b37a4656ac5d7f52c6c601103eaf0a Mon Sep 17 00:00:00 2001
From: Ian Grigg <iang@cacert.org>
Date: Sun, 21 Dec 2008 11:58:15 +0000
Subject: [PATCH] some of the easier criticisms have been addressed. This still
 needs to address the core issue of how far the CA has to clearly represent
 its liability position.

git-svn-id: http://svn.cacert.org/CAcert/Policies@1113 14b1bab8-4ef6-0310-b690-991c95c89dfd
---
 Agreements/3PVDisclaimerAndLicence.html | 65 ++++++++++++++++++-------
 1 file changed, 47 insertions(+), 18 deletions(-)

diff --git a/Agreements/3PVDisclaimerAndLicence.html b/Agreements/3PVDisclaimerAndLicence.html
index 6229746..d1e281d 100644
--- a/Agreements/3PVDisclaimerAndLicence.html
+++ b/Agreements/3PVDisclaimerAndLicence.html
@@ -10,27 +10,38 @@
 <center> <b> w o r k -- i n -- p r o g r e s s</b> </center>
 
 <p> <i>
-This is wip-V0.02.
+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 there term
+    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?
-    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>
+    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...
@@ -41,8 +52,7 @@ This is wip-V0.02.
 
 <h3> <a name="0"> 0. </a>  Preliminaries </h3>
 
-
-<h4> <a name="0.1"> 0.1 </a>  Background </h4>
+<h4> <a name="0.2"> 0.2 </a>  Background </h4>
 
 <p>
 Being that,
@@ -53,10 +63,11 @@ Being that,
   </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,
+    for the direct benefit and RELIANCE of its Community of signed-up users
+    ("Members"),
   </li><li>
-    and where possible, of some indirect benefit and USE to other general users
-    (or end-users) of the Internet;
+    where possible, of some indirect benefit and USE to other general users
+    ("end-users") of the Internet;
 </li></ul>
 
 <p>
@@ -64,7 +75,8 @@ And that,
 </p>
 
 <ul><li>
-    the end-user has a choice in client software (such as browsers and email clients),
+    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,
@@ -72,11 +84,12 @@ And that,
     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
+    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,
+    to provide for a high degree of choice and control over certificates;
 </li></ul>
 
 <p>
@@ -112,13 +125,15 @@ And that,
     ("the Vendor"),
   </li><li>
     the Vendor offers a free distribution of root certificates ("root list"),
-    within client software,
+    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>
@@ -149,7 +164,20 @@ 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
+<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>
@@ -194,8 +222,9 @@ within Vendor's root list to Vendor's end-users.
 
 <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:
+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>
@@ -215,13 +244,13 @@ and related cryptographic and security software).
 <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:
+Where agreement is explicitly sought from the end-user,
+they may be offered and agree to:
 </p>
 
 <ul><li>
     CA's NRP-DaL,
-    where the NRP-DaL and EULA are not in contradiction,
+    <s>where the NRP-DaL and EULA are not in contradiction,</s>
     <i>OR</i>
   </li><li>
     only your EULA,