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 @@
w o r k -- i n -- p r o g r e s s
-This is wip-V0.02.
+This is wip-V0.03.
-
+ 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.
+
-
+ This agreement is with vendors that choose not to be Members.
+ Is now made explicit.
+ What about vendors who choose to be Members?
-
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
+
OK, done.
-
pg: 1.4 Agreement in Spirit
It doesn't clearly indicate that this is only in respect to cert stuff.
+
extra line added "all with respect to...".
+ -
Also, why are we policing the redistributors?
+
the roots and certs are CAcert responsibility.
+ -
+ pg: not clear that this applies or does not apply to Member-vendors.
+
it is in now, in one of the bullet points.
-
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.
0. Preliminaries
-
- 0.1 Background
+ 0.2 Background
Being that,
@@ -53,10 +63,11 @@ Being that,
-
the CA offers a free certificate service to its subscribers,
-
- 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"),
-
- 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;
@@ -64,7 +75,8 @@ And that,
-
- 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),
-
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,
-
- 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,
-
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;
@@ -112,13 +125,15 @@ And that,
("the Vendor"),
the Vendor offers a free distribution of root certificates ("root list"),
- within client software,
+ within software,
that in choosing the Vendor's software,
the end-user would enter into an
End-User Licence Agreement ("EULA") with the Vendor,
the Vendor has the primary and only direct relationship with the end-user,
+
+ the Vendor chooses not to be a Member of CAcert,
@@ -149,7 +164,20 @@ by CA to Vendor.
-Terms used in this agreement are as defined in the
+RELIANCE.
+ A Member's act in making a decision,
+ including taking a risk,
+ in whole or in part based on the certificate.
+
+
+USE.
+ 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.
+
+
+
+Other terms used in this agreement are as defined in the
CAcert Community Agreement.
@@ -194,8 +222,9 @@ within Vendor's root list to Vendor's end-users.
1.4 Agreement in Spirit
-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: