As you know, tomorrow will be the last day of free (CREN-sponsored) LISTSERV maintenance for CREN sites. Of course, most of the sites now receiving free maintenance will be renewing their contracts, but, from a legal perspective, we are not supposed to deliver updates until we receive the POs. Thus, today and tomorrow are the last days we can deliver an update to everyone without having to worry about which PO has and has not arrived. Ordinarily we would not want to deliver any update just before the end of a maintenance period, but we have a small and critical fix to deliver to everyone. It has been running on production for several months on many core servers, and has no pre- or co-requisite. We are so sure that there will be no problem that we are willing to guarantee that we will fix any problem resulting from the application of this fix, at no charge. In fact, all you would have to do to back out is restore a single file, LSVBITFD MODULE, from your backups. We will provide a copy at no charge to anyone who needs it; actually, it is one of the files that are freely available from all the LISTSERVs. The reason we feel this fix is so critical is that it is required in order to fully exploit the emerging LISTSERV-TCP/IP backbone. While version 1.8a includes all the necessary code, it was released 3 months before LISTSERV-TCP/IP (LTCP), and as a result this code had not been tested in an actual production environment. Unfortunately, a bug crept into this new code, rendering it unusable in any network with 3 or more LTCP servers (this is why it was not detected during development). The good news is that the bug is in one of the standalone modules, which can be easily replaced without including any pre-requisite. This also means that sites running a later beta fix will be able to install this FIX18AT on top of their current system, without removing any of the code they are testing. Many LISTSERV sites have decided to leave BITNET in July and migrate to LTCP, either on VM or together with a migration to unix or VMS. Some of these sites are high-volume backbone servers. Once they have migrated to LTCP, only LTCP-exploitive servers will be able to use them for DISTRIBUTE delivery and other backbone functions, such as list of lists registration. While a LTCP server can deliver jobs to a regular NJE server, NJE servers which are not LTCP-exploitive will not talk to the LTCP servers, other than to answer requests coming from them. That is, non-exploitive servers do not know about the existence of the other LTCP servers, nor do they know how to include them in topological calculations. All they can do is reply to a request from an LTCP server, should one be received. Concretely, the difference between a vanilla 1.8a server and an LTCP-exploitive one is that the latter can be sent a copy of the new INTPEERS NAMES file with the Internet-only servers, which automatically activates LTCP-exploitation. Without FIX18AT or equivalent, you get a CMS abend if you try that. The benefits of LTCP-exploitation are quite straightforward. Without LTCP-exploitation, a LISTSERV site that migrates to LTCP is gone. As far as your LISTSERV is concerned, this is just the same as if the machine in question had been shut down permanently. So when a major backbone site migrates to LTCP, you will get more RSCS and SMTP traffic on your machine. For a backbone site in your immediate vicinity, you might even see an order of magnitude increase. Another aspect is that, while the LTCP servers will regularly send you list of list updates, your server will weed them out with equal regularity, on the assumption that they come from a node that was removed from BITNET but whose RSCS link was not taken down. Such nodes can send to any BITNET address, but cannot be replied to, and LISTSERV does not want any unreachable address in its list of lists. This means your users will not be able to subscribe to lists hosted on LTCP servers unless they send the command to the correct server, or to an LTCP-exploitive server. Because we are concerned about the impact that a major LTCP migration might have on the BITNET core, and to avoid unnecessary user confusion that would be detrimental to both LTCP and LNJE sites, L-Soft has decided to deliver, on an exceptional basis, a free 1.8a + FIX18AT upgrade to all 1.7f sites, and in particular to the 120-odd CREN sites that could not sift through the overly complicated CREN/L-Soft paperwork on time, provided of course that this can be done with a reasonable level of legal safety. Needless to say, our lawyers did not like the idea one bit. It turned out that we cannot simply go ahead and deliver 1.8a to everyone without running the risk that 1.8a might turn into shareware. The explanation is of the kind that ordinary mortals cannot understand, but it has to do with the fact that the update is free, and would be sent to just about anyone, as opposed to people we have a joint study or other agreement with. That is, it is a gift to a large body of people, and there are annoying precedents which could work against us. We could make dummy joint studies with everyone, but that would create a lot of paperwork when the intent is to eliminate all paperwork so that we can ship right now. Instead we were advised to attempt to use the CREN/L-Soft contract for this purpose, as this is a clean sale. We can deliver to all the beneficiaries listed in Schedule A without any risk of turning 1.8a into shareware, since we have received payment from CREN for this update. All we would have to do is declare ourselves satisfied with some e-mail document in lieu of maintenance agreement, and advance everyone to Licensed Member. We would be taking a certain risk by providing maintenance without any written agreement, but with only a few days to go this is a risk we would be willing to take. Unfortunately, this is not possible because section 4 of the CREN/L-Soft agreement uses the word "executed". If it had said "agreed", we would have been able to advance everyone on our own, just as we do when we receive a suitable written maintenance agreement. The intent of the CREN/L-Soft contract is clearly to get 1.8a to everyone, with the paperwork being just an annoying obstacle for L-Soft's protection. If the contract had said "agreed", nobody could have claimed that we were not following its intent or letter by simply advancing everyone. It is up to L-Soft to decide how much legal protection it wants for this maintenance, and if we think an e-mail agreement is good enough, that is our problem - the risk is on our side. But since the contract says "executed", we would be violating the letter of the contract if we just declared that we are happy with an e-mail agreement. And given our relationship to the other party of that contract, we simply cannot afford breaching it. This, of course, is only a problem if CREN objects to a suitable amendment. So we formally asked CREN yesterday whether they would be willing to amend the contract to allow us to advance all the sites listed in Schedule A, with or without written maintenance agreement. As expected, they asked us to give them some time to think it over, and presumably to discuss the issue with their attorney. We expect that CREN will accept to amend the contract, both because of the clear benefits to CREN members and in particular to the core sites, and because delivering without any written agreement is what they had originally wanted us to do. So, hopefully, we will be able to start exploiting the LTCP backbone a few weeks from now. Eric