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

@@ -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.2"> 0.2 </a>  Background </h4>
-<h4> <a name="0.1"> 0.1 </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
+    where possible, of some indirect benefit and USE to other general users
-    (or end-users) of the Internet;
+    ("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.
+Vendor agrees to make its relationship to end-users
-Specifically, the EULA must:
+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
+Where agreement is explicitly sought from the end-user,
-they will be offered and agree to:
+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,