<!doctype linuxdoc system>
<!--
- $Id: egate.sgml,v 1.1 1995/07/03 12:58:17 adam Exp $
+ $Id: egate.sgml,v 1.11 1996/08/09 15:42:12 adam Exp $
-->
<article>
-<title>Email/Z39.50 gateway guide
-<author>Europagate, 1995
-<date>$Revision: 1.1 $
+<title>Email/Z39.50 gateway guide
+<author>Europagate, 1996 <htmlurl url="http://europagate.dtv.dk"
+ name="http://europagate.dtv.dk">
+<date>$Revision: 1.11 $
<abstract>
This document describes a Email server that provides access to the
Z39.50 protocol.
<sect>Introduction
<p>
-This document describes how to compile, install and setup the
-Email server (ES) software. It does not address the internal design of
-the software.
+This document describes an email server (ES) system developed
+within the <htmlurl url="http://europagate.dtv.dk" name="EUROPAGATE">
+project. The first part of this document
+serves as an administrators guide, while the second part is a
+follow-up on the Design deliverable (WP4.1) that outlines the
+deviations from the design. Also, the second part contains
+a quick overview of the source code.
-<sect>Before you begin
+The software distribution also includes a Web to Z39.50 gateway. Refer
+to the web.txt documentation about installation on this gateway.
+
+<sect>Installation
<p>
An ANSI C compiler is required in order to compile the ES software.
-The ES can use either CNIDR's zdist package or the YAZ package from
+The ES can use either CNIDR's Zdist package or the YAZ package from
Index Data to interface the Z39.50 protocol. So you need to obtain
-either of these first.
+one of these first.
-The Zdist package can be found in:
+The zdist package can be found in:
-<url url="ftp://ftp.cnidr.org/pub/NIDR.tools/zdist/zdist102b1-1.tar.Z" >
+<htmlurl
+url="ftp://ftp.cnidr.org/pub/NIDR.tools/zdist/zdist102b1-1.tar.Z"
+ name="ftp://ftp.cnidr.org/pub/NIDR.tools/zdist/zdist102b1-1.tar.Z">
-The zdist doesn't support result-set references. Also, it has a few
-bugs — see the file zdist.es.patch for details.
+The zdist package doesn't support result-set references. Also, it has a few
+bugs. Therefore we've included a patch <tt/zdist.patch/ which fixes
+some of these bugs.
+Run patch in the directory above <tt/zdist102b1-1/:
+<verb>patch <zdist.path</verb>
+The ES server only depends on <tt>libz3950.a</tt> so you only need
+to build the zdist software in the directory <tt/libz3950/.
-YAZ can be found in:
+YAZ can be found at the FTP host:
-<url url="ftp://ftp.algonet.se/pub/index/yaz/">.
+<htmlurl url="ftp://ftp.indexdata.dk/index/yaz"
+ name="ftp://ftp.indexdata.dk/index/yaz">
-The ES also use GNU's regex package to parse regular expressions.
+The ES also uses GNU's regex package to parse regular expressions.
The ES has been tested with regex-0.12. Some systems, such as Linux,
-comes with the regex package preinstalled.
+come with the regex package preinstalled.
-<sect>Compilation
-
-<p>
Unpack <tt>egate.tar.gz</tt> and edit the top level <tt/Makefile/. Specify
-where the GNU regex package is located and specify whether you use
-YAZ or zdist. One some systems, you may have to set the <tt/NETLIB/ as
-well.
+where the GNU regex package is located by setting the variables <tt/REGEXOBJ/
+and <tt/REGXINC/.
-You may wish to set <tt/CC/ and <tt/CFLAGS/ in your shell, since these
-will affect the compilation — these are not set in the <tt/Makefile/.
+A little further down the <tt/Makefile/ you find a section called
+<tt/Common settings/ where you specify the location of either YAZ or zdist.
+On some systems, you may have to set the <tt/ELIB/ as well to link with
+BSD socket libraries.
-Now, type <tt/make/.
+If you intend only to compile the Email server and not the Web server
+you don't have to worry about the section entitled <tt/WWW gateway settings/.
-<sect>Installation
+The shell variables <tt/CC/ and <tt/CFLAGS/ are used by the
+<tt/Makefile/ so you may set these in your shell before you start
+compiling.
+
+Now, type <tt/make email/.
<p>
-If the compilation was successful, you should install the software.
-Edit the <tt/Makefile/ and set the LIBDIR to the installation
+If the compilation succeeds, you should install the software in some
+standard location.
+Edit the <tt/Makefile/ and set EMAILLIBDIR to the installation
directory. Since, the ES is executed by the mail system, and not by a
user, this directory shouldn't be globally executable.
-When satisfied, type <tt/make install/.
+When satisfied, type <tt/make install.email/.
-Three executables are installed in LIBDIR:
+Three executables are installed in EMAILLIBDIR:
<descrip>
<tag/eti/ The email transport interface. This program receives
incoming mail, identifies the user, and delivers the mail request
you create a special user and group for the ES software. In this case
you should use <tt/chmod/ to and set the 'set user ID on execution'
bits on the executable files and give that user read/write/execute
-permissions in LIBDIR.
+permissions in EMAILLIBDIR.
The mail system needs to know about the ES. Pick some name that serves
as the ES user and edit <tt/aliases/ used by your mail system (usually
<tt>es:"|/usr/local/lib/es/eti </tt><em>options</em><tt>"</tt>
-In this example the mail user name was <tt/es/ and the LIBDIR was
+In this example the mail user name is <tt/es/ and the EMAILLIBDIR is
<tt>/usr/local/lib/es</tt>.
The ES system can operate with or without the monitor. When using
the monitor the number of simultanous running kernels can be
-controlled. If the <tt>eti</tt> program is started with option
-<tt>--</tt> it will operate without the monitor.
+controlled. If the <tt>eti</tt> program is started with
+two dashes (<tt>--</tt>) it will operate without the monitor and
+the options specified after the two dashes are transferred to the
+kernel.
-<sect1>With the monitor
+<sect1>Running with the monitor
<p>
The monitor must be running at all times in this mode. You should
The eti sets current directory to the path specified by option <tt>-c</tt>.
-<sect1>Without the monitor
+<sect1>Running without the monitor
<p>
In this mode you should never start the monitor.
<tag><tt>-l </tt>log</tag> The log file. If absent stderr is used.
<tag><tt>-d</tt></tag> Turns on debugging.
<tag><tt>-c </tt>dir</tag> Sets current directory to dir.
+<tag><tt>-H</tt></tag> Help message.
<tag><tt>--</tt></tag> Indicates that the eti program should contact the
-kernel (and not the monitor. All options are this one are transferred
+kernel (and not the monitor. All options after this one are transferred
to the kernel
-<tag><tt>-H</tt></tag> Help message.
</descrip>
<sect1>monitor
<sect>Managing the system
+<sect1>Summary of files
<p>
-<sect1>Files
-
-<p>
To maintain the ES you need to know the files it uses. These are:
<descrip>
<tag>*.res</tag> Resource files with several settings that control
how the system operates, such as definition of targets, messages, etc.
-<tag>lang.*.res</tag> Resource file for a particular langauge.
<tag>*.bib</tag> Bib-1 attribute mapping files. These files describe
the mapping between CCL and the RPN query.
-<tag>user.db</tag> Database of users. Only the eti process access
+<tag>user.db</tag> Database of users. Only the eti process accesses
this file.
<tag>user.*.r</tag> Resource file for a user — accessed by the kernel
— only created when the user uses the <tt>def</tt> command.
</descrip>
The ES system is mostly managed by resource files. The following
-resource files are enclosed with the ES:
+are example resource files that comes with the ES:
<descrip>
<tag><tt>default.res</tt></tag> General resource with reasonable defaults.
This file is read by the monitor and the kernel.
<tag><tt>lang.dk.res</tt></tag> Resource file for danish conversation.
</descrip>
-<sect1>General resources
+<sect1>Resources
<p>
-Most general resources can be found in default.res. Some of the
-resources may be changed (overridden) by the user, while others may be
-overriden by individual target defintions.
+Most general resources should be set in the file <tt>default.res</tt>.
+Some of the resources may be changed (overridden) by the user, while
+others may be overridden by individual target defintions.
+The complete scenario is depicted below:
+<tscreen><verb>
+ +-------------+
+ | default.res |
+ +-------------+
+ | +--------------+
+ |<---------| "target.res" |
+ | +--------------+
+ |
+ | +--------------+
+ |<---------| user.x.res |
+ | +--------------+
+ |
+ | +--------------+
+ |<---------| "lang.res" |
+ | +--------------+
+ |
+ | +--------------+
+ |<---------| "override" |
+ | +--------------+
+ result
+</verb></tscreen>
-<p>
-The following table lists general resources:
+The following describes the general resources:
<descrip>
-<tag>gw.reply.mta</tag> Name of MTA program.
+<tag>gw.reply.mta</tag> Name of MTA program — default
+ <tt>/usr/lib/sendmail</tt>.
<tag>gw.reply.tmp.prefix</tag> Prefix of temporary files used by the ES.
<tag>gw.reply.tmp.dir</tag> Name of directory with temporary files.
<tag>gw.marc.log</tag> If this resource is specified, retrieved MARC
records will be appended to this file.
-<tag>gw.timeout</tag> Idle time before the kernel exists. When the
- kernel exists, the Z39.50 persistency layer will reconnect when
+<tag>gw.timeout</tag> Idle time before the kernel exits. When the
+ kernel exits, the Z39.50 persistency layer will reconnect when
necessary.
<tag>gw.resultset</tag> If this setting is 1, the Z39.50 client will
- use named result sets. If 0, the Z39.50 will always use Default as
- result-set name.
+ use named result sets. If 0, the Z39.50 system will always use
+ <tt/Default/ as result-set name.
<tag>gw.persist</tag> If this setting 1, the persistency is enabled;
disabled otherwise.
<tag>gw.max.process</tag> This settings is the maximum number of
database record in ISO2709 format. If 0, the ES will use the
record type.
<tag>gw.default.show</tag> Default number of records to retrieve and display
- when using the show command. This setting may be changed by the user.
+ when using the show command. This setting may be changed by the user
+ with the <tt>def defaultshow</tt> command.
<tag>gw.max.show</tag> This setting specifies the maximum number of
records the user may retrieve in one show command — default 100.
<tag>gw.autoshow</tag> Number of records to retrieve in a find
- command — default 0. This setting may be changed by the user.
+ command — default 0. This setting may be changed by the user by
+ the <tt>def autoshow</tt> command.
<tag>gw.display.format</tag> Default display format. This setting may
- be changed by the user.
+ be changed by the user by the <tt>def f</tt> command.
<tag>gw.language</tag> Current language. This setting may be
-changed by the user.
+changed by the user with the <tt>def lang</tt> command. When the
+ langauge is set to something, say x, then the resource gw.lang.x
+ should hold a name of a resource file read by the kernel.
+<tag>gw.lang.<em/x/</tag> Specifies name of resource file for
+ language <em/x/.
+<tag>gw.target.<em/name/ </tag> Name of resource file of target
+ <em/name/.
+<tag>gw.portno</tag> Z39.50 target port number — default 210.
+<tag>gw.hostname</tag> Z39.50 target host name.
+<tag>gw.bibset</tag> Name of file with Bib-1 attribute mapping.
+<tag>gw.databases</tag> Available databases on target.
+<tag>gw.description</tag> Description of a target. This message
+ is returned to the user when the connection is established with the
+ target.
+<tag>gw.account</tag> Z39.50 Authentication string — default
+ empty (i.e. none).
+</descrip>
+
+<sect1>Messages
+
+<p>
+There are several resource settings that deal with language
+dependencies. These fall into the following categories that
+depend on the resource name prefixes:
+<descrip>
+<tag>gw.msg</tag> Miscellaneous messages.
+<tag>gw.err</tag> Error messages.
+<tag>gw.bib1.diag.<em/no/</tag> Diagnostic error message indicated by
+ <em/no/.
+<tag>gw.help</tag> Help/description of various commands.
+<tag>ccl.command</tag> CCL command names.
+<tag>ccl.token</tag> CCL tokens names.
+</descrip>
+
+Refer to the sample files, <tt>default.res</tt>, <tt>lang.uk.res</tt>
+and <tt>lang.dk.res</tt> for all available settings.
+
+<sect1>Target definitions
+
+<p>
+To add a target definition called <em/mytarget/ you need to make a resource
+entry in <tt>default.res</tt> called <tt>gw.target.</tt><em>mytarget</em>.
+The value of this resource is the name of a resource file — for
+example <em>mytarget</em><tt>.res</tt>. The resource file should at least
+define the resources: <tt/gw.hostname/, <tt/gw.databases/ and
+<tt/gw.description/. You might also consider specifying
+<tt/gw.account/, <tt/gw.bibset/, <tt/gw.resultset/ and <tt/gw.portno/
+in the target resource file. The user only needs to use the command
+<tt>target </tt><em>mytarget</em> to use the target. Also, since we
+already specified database names, the user doesn't need to use the
+<tt/base/ command.
+
+<sect1>CCL to RPN mapping
+
+<p>
+The mapping between CCL-queries and RPN are stored in files —
+normally with the suffix <tt>.bib</tt>. We will refer these
+files as bibset-files. You might consult the file <tt/default.bib/
+to see an example of such file.
+
+The mapping is necessary because targets usually only support a little
+subset of the Bib-1 attribute set and because the CCL qualifiers
+(field names) are not standardized. A bibset-file is specified
+by the <tt/gw.bibset/ resource.
+
+Column zero of a bib-file line either hold a hash character (<tt/#/)
+indicating a comment in which case the rest of the line is
+ignored; or a CCL qualifier.
+
+The name of the CCL qualifier is up to you. However, the special
+qualifier name <tt/term/ applies to the case where no qualifier
+is specified in CCL. The CCL qualifier is
+followed by one or more mapping specifications. A mapping
+specification takes the form:
+
+<em/type/<tt/=/<em/value/<tt/,/<em/value/...
+
+The type is simply one of the six Bib-1 attribute query types:
+<descrip>
+<tag/u/ Use attribute. Value is an integer.
+<tag/t/ Truncation attribute. Value is an integer; or the
+ value is a combination of:
+ <descrip>
+ <tag/l/ This character indicates that the CCL parser should allow
+ left truncation (2) if indicated by a <tt/?/ on the left side
+ of a term.
+ <tag/r/ This character indicates that the CCL parser should allow
+ right truncation (1) if indicated by a <tt/?/ on the right side
+ of a term.
+ <tag/b/ This character indicates that the CCL parser should allow
+ both left and right (3) truncation indicated by a <tt/?/ on both
+ left and right side of a term.
+ <tag/n/ This character indicates that the CCL parser should announce
+ no truncation (100) if no truncation was specified.
+ </descrip>
+<tag/p/ Position attribute. Valus is an integer.
+<tag/s/ Structure attribute. Value is an integer; or the
+ value is <tt/pw/ in which case the CCL parser announces word (2) or
+ phrase (1) depending on the number of adjacent terms.
+<tag/r/ Relation attribute. Value is an integer; or the value is
+ <tt/o/ in which case, the CCL parser will select <em/less than/,
+ <em/less than or equal/, ... <em/greater than/ — depending on
+ the relation specified in CCL.
+<tag/p/ Position attribute. Value is an integer.
+</descrip>
+
+Consider these bibset-lines:
+<tscreen><verb>
+term t=l,r,b s=pw
+au= u=1 t=l,r,b s=pw
+date u=30 r=o
+</verb></tscreen>
+The first line describes the mapping in when no qualifiers are
+present, as in:
+<tscreen><verb>
+find foo bar?
+</verb></tscreen>
+In this case the right truncation is enabled and the structure is
+<em/phrase/.
+
+The second line is used in this search:
+<tscreen><verb>
+find au=andersen
+</verb></tscreen>
+where the use attribute is <em/author/ and the structure is <em/word/.
+
+The third line is used in:
+<tscreen><verb>
+find date>1990
+</verb></tscreen>
+where the use attribute is <em/date/ and the relation is <em/greater than/.
+
+<sect>Implementation
+
+<p>
+The implementation of the email server includes all the modules described
+in the design deliverable.
+
+The work was roughly carried out as follows:
+<enum>
+<item>The logging facilities and resource management utilities were
+ implemented — virtually all other modules depend on these
+ modules.
+<item>A minimal ES was implemented — including a high-level
+ API to the Z39.50 sub-system and a CCL parser with a few
+ commands, such as FIND and SHOW. This version displayed MARC
+ records in a raw format. This version served as base for the URP.
+<item>The first version of the MARC display formatting tool, FML,
+ was implemented and included in the ES.
+<item>The ETI program was implemented along with the IPC
+ (interprocess communication) utilities based on FIFOs. Facilities
+ to keep connections alive (to Z39.50 targets) was implemented.
+ To identify a user, a file-resident symbol table (small database) was
+ implemented which maps a email username to a unique integer (email userid).
+<item>The protocol persistency was implemented and more CCL commands
+ were added.
+<item>The monitor program was implemented.
+</enum>
+
+The following sections cover the most important modules in the ES and
+deviations from the design.
+
+<sect1>Z39.50 Interface layer
+
+<p>
+The design report specified that the Zdist toolkit from CNIDR would
+be used in the ES to provide access to the Z39.50 protocol. The package
+was choosen bacause it is easy to use and, more important, we felt
+that the API would be reasonably stable and supported.
+
+Nevertheless it turned out that CNIDR choose to change the API
+completely around January 1995 and announced a new version
+called zdist102b1-1.
+
+<em>Note: As of this date the newest version of Zdist is still
+zdist102b1-1. CNIDR seems to concentracte on their Isite package
+which also includes a Zdist package presumably similar to the
+standalone Zdist package</em>
+
+During the work with the Zdist package a few bugs were discovered.
+Fortunately, they could be solved within a few days. We also
+discovered that the package lacks result-set references.
+We posted the bug fixes to Kevin Gamiel who is responsible for
+the package but we didn't get responses. So, eventually, we weren't
+satisfied with the package after all.
+
+In February some of us began the development of a new Z39.50 package
+called YAZ — in retrospect somewhat motivated by the
+experiences with existing Z39.50/SR toolkits.
+
+To support result-set references we chose to incorporate a YAZ
+interface in the ES also. And we designed and implemented a
+simple high-level Z39.50 origin API that supported both Zdist and YAZ.
+
+The protocol persistency module was implemented on top of
+the high-level API and not on top of Zdist. The obvious
+advantage is that the persistency module is not tied to one
+particular Z39.50/SR package.
+
+Persistency information stored for each user is simply:
+<itemize>
+<item>hostname and port number.
+<item>authentication string
+<item>selected database(s)
+<item>next result set number
+<item>next result set position
+<item>result set information
+</itemize>
+
+Information about each result set includes:
+<itemize>
+<item>name
+<item>size (number of hits)
+<item>database(s)
+<item>query
+</itemize>
+
+A persistency file is removed each time a new target is selected.
+It is our experiences that the persistency files are very small.
+
+<sect1>CCL
+
+<p>
+The CCL was implemented as described in the design. A CCL utility
+was made as a separate module which implements a tokenization
+package and a parser which translates from FIND to RPN. The
+data structure used to represent the RPN query is also used in
+Z39.50 search API on top of YAZ or Zdist.
+
+The CCL parser is quite configurable. Token names can be redefined to
+one or more names (aliases). Also, the specification of mapping
+between CCL field names (qualifiers) and Bib-1 attributes can be
+specified in either the C API or a file.
+
+Although the Z39.50 system in the ES uses the Bib-1 attribute set, the
+CCL parser itself is not tied to Bib-1.
+
+<sect1>FML
+
+<p>
+The FML system is used to handle the presentation of MARC
+records. There are some deviations to the design report, however.
+The most important changes are:
+<itemize>
+<item>The <tt/expr/ function is not implemented. Instead arithmetic
+operators <tt/plus/, <tt/minus/, <tt/mult/ and <tt/div/ are
+implemented. Also relational operators <tt/gt/, <tt/lt/ ... are
+implemented.
+<item>The <tt/lindex/ function is called <tt/index/ and it is a binary
+operator where the left operand is the list and the right operand is
+the index integer.
+<item>The MARC extraction routines are not implemented.
+Instead, a MARC record is transferred as an argument
+to a formatting-routine (in list notation). The formatting
+routine then extracts fields from the list by list/string
+manipulation functions.
+<item>A new statement, <tt/bin/, is implemented to define
+binary operators (functions).
+</itemize>
+
+<sect1>IPC
+
+<p>
+As described in the design, FIFOs are used to communicate between
+the ETI, monitor and kernel. The ES can run without the monitor,
+however. The primary reason for the presence of the monitor was
+to assure that the kernel releases the resources used by the
+persistency layer. But, since the persistency layer did turn out to
+use virtually no disk space at all, there was no point in starting
+a kernel process to remove its files — hence this facility
+was not implemented. The only purpose of the monitor is to keep the
+number of running kernels at a maximum level and even that
+is probably useless since most unices will swap kernel processes
+out anyway.
+
+The idle time
+before a kernel exits and saves its persistency file is not
+controlled by the monitor. Saving the persistency file and
+keeping it is usually a good approach — even when a
+user doesn't reference/show old result-sets since the user
+has a notion of <em/current target/ and database.
+
+<sect1>Source
+
+<p>
+In this section a short description of each source module is
+given. Each module is implemented in a separate sub directory.
+Any public headers are located in the <tt/include/ directory.
+
+<descrip>
+<tag/res+log/ is an implementation of the logging system
+and the resource management sub system. Note that the
+resource module depends on the logging facility. Logging
+is implemented in <tt>gw-log.c</tt> and <tt/gw-log.h/. The
+file <tt>gw-log-test.c</tt> is small test program for the
+logging system. The core of the resource management is implemented
+in <tt>gw-res.c</tt>. The files <tt>gw-res-bool.c</tt> and
+<tt>gw-res-int.c</tt> implement two utility routines &mdash
+on top of the resource management. The header file
+<tt>gw-resp.h</tt> is a private header file and <tt>gw-res.h</tt>
+is a public header file.
+
+<tag/ccl/ implements CCL to RPN mapping and a tokenization
+ utility for other CCL commands. The mapping function is
+ implemented in <tt>cclfind.c</tt>. Qualifiers are handled in
+ <tt>cclqual.c</tt> while reading of qualifier mappings from a
+ file is implemented in <tt>cclqfile.c</tt>. Scanning is implemented
+ in <tt>ccltoken.c</tt>. String utilities, which might be changed if
+ other character sets are needed, is implemented in
+ <tt>cclstr.c</tt>. Table of error messages is implemented in
+ <tt>cclerrms.c</tt>.
+
+<tag/util/ implements various utilities:
+ <descrip>
+ <tag>MARC utility</tag> implemented in <tt>iso2709</tt>...
+ <tag>Database utility</tag> implemented in <tt>gw-db.[ch]</tt>. This
+ utility is used to map a user (email) to an integer.
+ <tag>String queue utility</tag> implemented in <tt>strqueue.[ch]</tt>. This
+ utiltiy is used to queue incoming mail in the ETI, kernel and
+ the monitor.
+ <tag>Pretty printer</tag> implemented in <tt>ttyemit.[ch]</tt>
+ — used by the URP.
+ <tag>FIFO IPC utiltiy</tag> implemented in <tt>gip*.[ch]</tt> —
+ used by the ETI, kernel and monitor.
+ </descrip>
+
+<tag/fml/ implements FML. The top level functions are implemented
+ in <tt>fml.c</tt>, <tt>fmlcall.c</tt> and <tt>fmlcalls.c</tt>.
+ Scanning is implemented in <tt>fmltoken.c</tt>.
+ Memory management is implemented in <tt>fmlmem.c</tt>.
+ Arithmetic operators are implemented in <tt>fmlarit.c</tt>.
+ String manipulation functions are implemented in <tt>fmlstr.c</tt>.
+ Relational operators are implemented in <tt>fmlrel.c</tt>.
+ List maniuplations are performed in <tt>fmllist.c</tt>.
+ FML symbol table management is implemented in <tt>fmlsym.c</tt>.
+ Conversion from ISO2709 to list notation is implemented in
+ <tt>fmlmarc.c</tt>.
+
+<tag/zlayer-zdist/ implements the high-level Z39.50 API on top
+ of Zdist. This task is implemented in <tt>zaccess.c</tt>. The
+ public header file is called <tt>zaccess.h</tt>.
+
+<tag/zlayer-yaz/ implements the high-level Z39.50 API on top
+ of YAZ. This task is implemented in <tt>zaccess.c</tt>. The
+ public header file is called <tt>zaccess.h</tt>.
+
+<tag/kernel/ implements the ETI, kernel and monitor. The kernel
+ itself is implemented in <tt>main.c</tt>, <tt>urp.c</tt> and
+ <tt>persist.c</tt>. The ETI is implemented in <tt>eti.c</tt> and
+ the monitor is implemented <tt>monitor.c</tt>.
</descrip>
+<sect>LICENSE
+
+<p>
+ Copyright © 1995-1996, the EUROPAGATE consortium (see below).
+
+ The EUROPAGATE consortium members are:
+
+<itemize>
+<item>University College Dublin
+<item>Danmarks Teknologiske Videnscenter
+<item>An Chomhairle Leabharlanna
+<item>Consejo Superior de Investigaciones Cientificas
+</itemize>
+
+ Permission to use, copy, modify, distribute, and sell this software and
+ its documentation, in whole or in part, for any purpose, is hereby granted,
+ provided that:
+
+ 1. This copyright and permission notice appear in all copies of the
+ software and its documentation. Notices of copyright or attribution
+ which appear at the beginning of any file must remain unchanged.
+
+ 2. The names of EUROPAGATE or the project partners may not be used to
+ endorse or promote products derived from this software without specific
+ prior written permission.
+
+ 3. Users of this software (implementors and gateway operators) agree to
+ inform the EUROPAGATE consortium of their use of the software. This
+ information will be used to evaluate the EUROPAGATE project and the
+ software, and to plan further developments. The consortium may use
+ the information in later publications.
+
+ 4. Users of this software agree to make their best efforts, when
+ documenting their use of the software, to acknowledge the EUROPAGATE
+ consortium, and the role played by the software in their work.
+
+ THIS SOFTWARE IS PROVIDED "AS IS" AND WITHOUT WARRANTY OF ANY KIND,
+ EXPRESS, IMPLIED, OR OTHERWISE, INCLUDING WITHOUT LIMITATION, ANY
+ WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+ IN NO EVENT SHALL THE EUROPAGATE CONSORTIUM OR ITS MEMBERS BE LIABLE
+ FOR ANY SPECIAL, INCIDENTAL, INDIRECT OR CONSEQUENTIAL DAMAGES OF
+ ANY KIND, OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA
+ OR PROFITS, WHETHER OR NOT ADVISED OF THE POSSIBILITY OF DAMAGE, AND
+ ON ANY THEORY OF LIABILITY, ARISING OUT OF OR IN CONNECTION WITH THE
+ USE OR PERFORMANCE OF THIS SOFTWARE.
+
</article>
projects / egate.git / blobdiff