This new version is  better than the first one from the  point of view of
my requirements, but I still see a few problems/ambiguities:
 
1. It  is very, very  difficult to define what  is an "update  which adds
   significant  new function".  It is  the  kind of  things your  average
   lawyer can  discuss for months.  Definitely not  the kind of  things I
   want to go into.  An easy solution would be for me  to decide how much
   EARN should  pay for each  update, based  on its contents.  Although I
   have said several times that I  am more interested in taking the money
   away from  EARN as a  matter of principle than  in getting it  into my
   pocket, the  EARN people who  would sign the  check have no  reason to
   believe  me  and  could  see  this  as  a  way  for  me  to  exert  an
   uncontrollable amount  of financial pressure on  the organization, and
   would find this  absolutely unacceptable. And I'm afraid  I would have
   to agree with them. However it is clear that if EARN wants to get code
   (be it base code or updates) from  me, EARN must either pay or be nice
   with its volunteers. Since EARN is not nice, EARN has to pay.
 
2. Could  you clarify exactly  who would write  the code updates  and who
   installs them? From what I understand,  I would be the one writing the
   updates for everybody (please correct me if I misunderstood); EARN and
   BITNET  would run  the  exact  same code.  The  problem  is that  this
   conflicts with the fact that EARN support is provided by someone else,
   ie how can I fix a problem which has been reported to another person?
 
3. Because of (2), and still assuming  I am the one writing all the code,
   this other  person would have to  forward bug reports to  me *OR* EARN
   would not be allowed to submit  bug reports. In the former case, since
   most notes  I get are  bug reports or  "bug reports" (as  in "LISTSERV
   erases all  files from  its 192  minidisk before  it logs  off!!!"), I
   would still  be doing a  significant amount of  work for EARN.  In the
   latter case,  EARN people  would have  to reproduce  the problem  on a
   non-EARN server to  be able to get it fixed,  which is ridiculous (but
   not  much  more  than  having  to split  the  backbone  for  political
   reasons).
 
4. Who maintains PEERS NAMES? If the  backbone is to remain as it is now,
   there must be a unique PEERS  NAMES file for EARN and non-EARN servers
   alike.  I  could  maintain  the non-EARN  entries,  whereas  the  EARN
   employee would  process EARN  update requests and  send me  an updated
   version of the EARN entries every other week, for example.
 
5. What  happens when someone  from EARN  requests an improvement  to the
   code? I  assume this request  has to be sent  to the EARN  employee in
   charge of LISTSERV. But then what does he do with it? Should he filter
   them and forward a selection to me? What if I refuse to implement it?
 
Eric