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