On Mon, 20 Feb 89 19:44:04 GMT Eric Thomas (CERN/L3) said:
>8. Whenever  "significant functionality" is added  to the code, as  defined by
>   Eric  Thomas,  EARN  will  be  given   the  option  to  purchase  this  new
>   functionality,  at the  price defined  by Eric  Thomas and  subject to  the
>   limits of $nnnn/year and $mmmm/shipment. If  EARN accept, the new code will
>   be distributed to EARN as defined in clause 7. If EARN refuses, it will not
>   be made available  to EARN, and Eric  Thomas will not be  able to guarantee
>   that future "fix" shipments  will be usable "as is" on  the EARN version of
>   LISTSERV.
>
>* This is the clause that I find to be most problematic. The way it is written
>* it sounds like your typical class B  thriller blackmail, but if you write it
>* in another way EARN  will be able to demand fixes that do  not depend on new
>* features from me, and this is not acceptable to me. Any idea?
 
The only trick in making this part acceptable is finding values for nnnn and
mmmm which are acceptable to both parties.  That would limit EARN's cost for
a year, no matter how many separate bits of "significant functionality" Eric
decides to offer each year.  Of course, EARN may say that say that the highest
value they can accept for nnnn (and therefore mmmm) is $0, in which case this
whole plan falls apart.
 
What really concerns me is the possibility that some item of "significant
functionality" which EARN might choose to refuse would be necessary for
the network(s)wide integrity of LISTSERV, or might be a prerequisite for
something which must be uniform across all interconnected LISTSERVs.
Assuring that this category of "required" fixes can be installed with or
without any specific item of "significant functionality" would be an
additional burden, which neither Eric nor the EARN LISTSERV maintainer(s)
might be willing and able to support.  That would bring us to the parting
of the ways which we are fighting so hard to avoid.
 
--Mark