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
|
