On Wed, 25 Nov 1992 07:42:13 EST  Scott Ophof
<[log in to unmask]> had said:
>Definition:
>  LISTSERV   Eric's implementation of the concept of a list manager.
>  LISTEARN   Turgut's implementation of a list manager that tries to
>             be as much like LISTSERV as possible, in the *correct*
>             and fair sense.  (Turgut/Eric, correct me if needed)
 
  LISTEARN    EARN's implementation of a list manager that was originally
              licensed by EARN from Eric Thomas, which is developed mainly
              along the requests from EARN NCCs and users in general.
              However, it is true that we *do* spend considerable time
              trying to stay compatible, I am sure Eric does too.
 
>BTW, whether the name "LISTSERV" enjoys legal protection or not is
>imho totally irrelevant; laws are just a subset of the morals/ethics
>of a culture.
 
Right -- EARN was not allowed to use the LISTSERV name for its server,
according to the legal agreement signed by it, and Eric. I think the
VM userid of LISTSERV was allowed to stay for the sake of users.
 
>What upsets me most in the whole issue of LISTSERV and "listserv"s
>is the enormous waste of time, energy, system resources in trying to
>design (in)compatible "listserv"s, when it would have been so much
>neater, cleaner, more useful to have all that manpower get together
>and create a single "listserv" for as many opsyses as possible and
>as compatible as possible with LISTSERV(/LISTEARN).
 
I agree with that -- It's always easier to stay compatible if there
is ONE version floating around. Not only easier, but more productive
too - instead of devoting several groups of people, one from each
organization, there could be one group working on a common server.
This goes to Listserv vs. Listearn too, not only listserv vs. Unix-serv.
(gosh,did I just say that?)
 
>Whereas LISTSERV tries to reduce resource-use in an overall sense...
Right - mainly bandwidth.
 
>Heck, the whole idea behind TCP/IP etc. is to obviate the need to
>have everything available locally, isn't it?
 
I think that's the idea behind "good connectivity" - not only behind TCP/IP.
 
Keep up the work, -turgut