Proposal and Specifications for Licensing Schemes

Work package WP4, Deliverable D4.2

Version 1.0

Dominique Petitpierre (ISSCO), Dawn Murphy (MTL)

Executive Summary

Work package 4 of the MLIS DicoPro project covers the exploration and assessment of possible dictionary distribution and licensing schemes. This document proposes the licensing schemes which will be used in the first implementation of DicoPro, and outlines the functional specifications needed for those licensing schemes. An earlier document, D4.1 Exploration of Licensing Schemes, explored the various possibilities for licensing schemes and the issues which had to be considered when selecting a licensing scheme.

1.1 Background to this document

Work package 4 Licensing Schemes of the DicoPro project has explored the possible licensing schemes for the DicoPro software and dictionaries, as well as various issues surrounding the licensing schemes such as security of the software and lexical data. A previous report D4.1 Exploration of Licensing Schemes detailed the various possibilities and discussed the issues involved. Two meetings have been held between the organisations participating in this work package in August and October 1998 to discuss and decide on the best method for licensing DicoPro. The current report presents a proposal for the licensing schemes selected at the last meeting, and the functional specifications for adapting the DicoPro software to cater for these licensing schemes.

1.2 Structure of this document

This document is divided into four sections. The first section is this introduction. The second section outlines the proposal for the chosen licensing schemes. The third and fourth sections provide the immediate requirements and functional specifications for adapting the software to the licensing schemes.

2. Proposal for licensing schemes

It has been decided by the DicoPro partners that it is not necessary to restrict the licensing to one particular scheme but that it would be possible to offer a choice of licensing scheme to users, to account for different methods of usage. Schemes involving electronic payment were rejected on the ground that firstly, this would involve too much adaptation of the software, and secondly, the payment technology is not yet mature enough or accepted by DicoPro's potential user base.

2.1 Target users

DicoPro will be aimed at three sets of target users:

1. Language professionals or students with constant need for technical dictionaries

2. Non-language professionals within large organisations with frequent need for general dictionaries

3. Non-language professionals within large organisations with occasional need for general dictionaries

The rationale for targeting these users will be discussed in D11.1 Exploitation Plan.

2.2 Selected licensing schemes

These are the licensing schemes which have been chosen to cater for these types of user:

2.2.1 Option 1: Unlimited licence for n number of users

This will be for users who have a constant need for either the technical or general dictionaries, and are prepared to pay a high price for the initial licence fee in order to have unlimited use. The only restriction will be on the number of concurrent users. This is a traditional way of licensing software, and is already more user-friendly than many software packages which are tied to specific workstations.

2.2.2 Option 2: Time limited licence for n number of users

This option allows frequent users to budget a more manageable price per month, per six months or per year.

2.2.3 Option 3: Pay per use

This option is particularly attractive to the occasional user as they pay only for actual use. The basic unit of cost are defined in relation to basic operations requested by the end-user. In one scheme, pay before use, the customer buys credits in advance for a certain number of basic operations. In the case of pay after use, the provider requests usage statistics at periodic intervals and bills accordingly. Payment is made off-line.

The query model is the following:

1. The end-user sends to the server a query search(K,I,D,n) which specifies a query with search key K in the index I of a dictionary D, with a maximum of n answers. The server returns a partial result as a list of the first n corresponding answers A₁,A₂,...,A_n, where each answer A_i has a short representation that is displayed on the user's screen (usually an entry's headword). If there is no answer (unsuccessful search) then the result list is empty.

2. The user may request the next n answers following A_n: nextanswers(A_n,n) and the server will return a new list of possible answers A_n+1.,A_n+2,...,A_n+n

3. If for that kind of search, the answers correspond to lexical entries or portions thereof, the user may request to display the entry associated to an answer A_i: getentry(A_i) and the server will return E the content of the desired entry.

Different pay per use schemes can be devised by assigning a basic unit cost to one of these operations:

1. for each request search(K,I,D,n) (pay per search). The unit cost can be set according to the index I and dictionary D. Variant: the search is not counted if the result list is empty.

2. for each short answer A_i displayed on the end-user's screen (pay per hit). The unit cost can be set according to the index I and dictionary D.

3. for each entry E displayed on the end-user's screen (pay per view). The unit cost can be set according to the dictionary D.

3. Software Adaptation Requirements

3.1 Option 1: Unlimited licence for n number of users

For this option, the software must be provided with a method for restricting the number of concurrent users.

3.2 Option 2: Time limited licence for n number of users

For this option, the software must be provided with:

1. a method for restricting the number of concurrent users

2. a method for blocking use of the software after a period of time

3. a method for warning the user that the time period is running out

4. a method for informing the user that the time period has run out, with details of how the licence can be renewed

3.3 Option 3: Pay per use

For this option, the software must be provided with:

1. a method for counting the number of hits made

2. a method for informing the user how many hits they have left / have already obtained

3. a method for warning the user that they only have a certain number of hits left

4. a method for informing the user that they have run out of hits, with details of how more hits can be purchased

4. Functional Specifications

4.1 Introduction

4.1.1 Assumptions

No protection scheme can offer complete security, just like any locked door can be opened given sufficient means and expertise. The licensing schemes described in this document aim at deterring relatively simple attempts at cheating the licence, and are designed to cause minimal annoyances to the customer, i.e. the focus is on user friendliness. Given a (paper) legal contract as backup this should be enough in the contexts targeted by this project: corporate intranets.

Thus the following assumptions are made:

1. The DicoPro server and client code will not be tampered with by the customer. In particular, portions of the code will not be replaced or changed, and the program will not be disassembled or reverse engineered.

2. No communication occurs with a machine outside the intranet (after receiving the licence file which can take place via e-mail).

3. No extra hardware devices need to be installed on the server or client machines (e.g., dongle, smart card).

4. Persistent information can be stored and recovered by the server and client programs.

4.1.2 Terminology and notation

The following gives a summary of the terminology and notation used in the rest of the document. It does not attempt to explain concepts which are standard in cryptography (c.f. Schneier 1996¹, Wayner 1996² or SET³)

A message is any data, represented as a string of bytes, that needs authentication or protection.

hash(X) is the result of applying some hash function (MD5, SHA or other) to the message X, i.e. to obtain a digest of X.

crypt(K,X) is the result of encrypting the message X with key K, with some encryption function (DES, RSA or other) .

decrypt(K,X) is the result of decrypting the message X with key K.

In a public key cryptography system the encrypting and decrypting keys are different: X = decrypt(K_p, crypt(K_s,X) where K_p is the public key corresponding to the secret (or private) key K_s.

sign(K,X) is the signature of the string of bytes X obtained by crypt(K,hash(X)).

Thus, in a public key cryptography system, verifying a signature S of a message X made with the secret key K_s (i.e. S=sign(K_s,X)) is to check that decrypt(K_p,S) = hash(X).

The client is the program running on the end-user machine, i.e. the interface through which the end-user makes queries in dictionaries.

The server is the program running on the server machine which handles queries from the clients.

The provider is the publisher or its representative who provides a lexical resource to the customer.

4.2 Methods common to all schemes

4.2.1 Authenticating the licence parameters

Licence parameters, such as the maximum number of simultaneous users, or the date at which the licence expires, are stored in a file on the server. This file is originally created by the provider for a particular dictionary. In order to protect the parameters against tampering, the file is signed with the private key of the provider. I.e. in our terminology the licence parameters form the message L and a signature S=sign(P_s,L) , where P_s is the provider's secret key, is appended to the file. Whenever the licence file is consulted, the server verifies the signature by checking decrypt(P_p,S) = hash(L) where P_p is the providers public key. If this is verified then the server can be reasonably sure that the licence parameters have not been changed (it depends on the strength of the signature algorithm).

For flexibility and convenience, the name of the algorithms used for calculating the signature (hash and crypt/decrypt) are stored in the licence parameter file, as well as the provider's public key (P_p).

4.2.2 Identifying the server

In general, a licence will be granted for running the server on a specific machine on the intranet: certain licence parameters will identify the authorised machine. Possible candidates for identifiers are:

1. internet address (symbolic or numeric) - is an intrinsic property of a machine in an intranet. In principle, two machines cannot have the same internet address. Given the proper authority, it can be assigned to any machine in the intranet, thus providing flexibility in case the server has to be moved to another machine because of a failure.

2. ethernet address - This is the id of the network interface hardware. It is in principle unique in the world and cannot be easily faked. A machine may have more than one network interface if it acts as a router. In the case of a network interface on a card, the id can be transferred to another machine by physically moving the card to the new machine (which has to be compatible). On the other hand a faulty card cannot be replaced by another one with the same id.

3. host id or mother board serial number - Transferring the id to another machine of the same type may be possible by moving the EPROM on which it is stored. This id or serial number could be faked or copied by reprogramming an EPROM (not very easy).

4. hard disk serial number - Is transferable by moving the disk. This serial number could be faked or copied by reformatting the disk (not very easy).

To make it more difficult to fake an identity, many of these identifiers can be used together. The internet and ethernet addresses have an advantage over the serial numbers in that the uniqueness of the number is enforced on the intranet, respectively on a subnet, by the very protocols (TCP/IP, ethernet) they are used by.

The internet address and ethernet addresses can be double checked by looking up the system tables where they are stored for use in other functions of the server machine. Also, a connection loop (the server connecting to itself) can check that the addresses are valid. In addition, the internet address can be checked by asking the clients to confirm it (i.e. the client, when requested by the server sends the internet address of the server as seen from its location). This protection does not work if the clients run on the same machine as the server, or if the clients are forced to connect through a proxy.

On the same subnet, one can detect two servers running with the same licence by sending broadcast messages containing the licence identifiers. For example, when a server starts up it broadcasts its identity, and if it receives a reply from an already running server it terminates: only the first server started with that identity may continue running (or to penalise the unauthorised user, in cases where it cannot happen by accident, all running servers are told to stop without discrimination). This protection is limited to the subnet that propagates broadcast messages.

Another usage for such identifiers is to use them independently or in combination as the seed of a random number generator, in order to provide the server with a secret encryption key unknown to the site manager who installs the program (assuming no disassembling is occurring). This key would be unique to this specific server. For example, if the lexical data need to be encrypted, it could be done by the provider with such a unique key derived from known identifiers. Caveat: the generating algorithm and software implementation has to be kept secret.

4.2.3 Identifying the client

The same identifiers as for the server machine can be used for identifying client machines. In addition in the case of multi-user machines (UNIX, Windows NT Terminal Server Edition), the server might need to distinguish between different instances of the client running on the same machine. The distinguishing identifier might be an internet port number in case multiple queries are done in the same connection session, or it could be the process number of the client program (less likely to be reused quickly, and persistent across connections). The user id might also be used but is not discriminating in the case of common guest user id. An alternative, more portable solution is to use a random number as client instance identifier. It needs to be able to discriminate among clients sharing the same machine identifiers (for example start-up time in very small time units).

4.2.4 Encrypting the client-server protocol

In order to avoid licence sensitive information carried in the client-server protocol being tampered with, this information has to be encrypted. It can be done without causing much delay with a simple one time pad encryption, based on a secret key shared by the client and server. The secret key can be computed on the basis of a combination of identifiers (c.f. 4.2.1 Authenticating the licence parameters). Again, the key generation code needs to be kept secret.

4.3 Option 1: Limiting the number of simultaneous users

Here are three ways to consider simultaneous access:

1. List of machines:
   A licence parameter specifies a list of authorised client machines. Only the clients running on these machine can connect to the server. If only the internet address is used as an identifier, to allow for legitimate changes (e.g. machine upgrade), the site manager could bypass the protection by changing quickly (automatically) the client machines' addresses. In this case the server could identify the changes by checking the ethernet address and delay (e.g. by a few hours) accepting connection from a new machine. But this scheme does not work on multi user client machines.

2. Simultaneous sessions:
   The client interface would force the end-user to "open" a dictionary as a separate operation before queries are possible in that dictionary until the end-user "closes" the dictionary, thus defining a session. The server would grant access to a dictionary only if the number of simultaneous sessions is not exceeded. Besides the fact that an end-user could block access to a dictionary by forgetting to close a dictionary, the problem with this scheme is that, to be user friendly, the interface might have some automation facilities such as macros or scripts which could be used to make very short sessions of just one query very easy. Slowing down artificially the open or close operations would not be user friendly.

3. Time frame:
   A maximum of different clients is allowed during a particular time frame (e.g. 10 minutes, one hour or one day). The server keeps a list of recently active clients and does not allow new clients if the list is full. Clients that have been inactive for longer than the time frame are removed from the active list, leaving room for new clients. The clients should not have the opportunity to give a command to leave the active list (essentially falling back to the sessions case).

DicoPro will implement the best of these schemes, the time frame scheme, (c.f. pseudo code in annexe 6.2 Option 1: Limiting the number of simultaneous users).

4.4 Option 2: Limiting the duration of the licence

In this scheme a licence parameter specifies the expiration date of the licence. The server checks that date at start-up and at periodic intervals and terminates if it is expired, i.e. if the current date is beyond the expiration date.

One could circumvent this by setting back the server machine's clock. It is unlikely on a machine used for other purposes because it would cause problems with other functions. But it might work on a dedicated machine. To allow for a better control, the licence start date can be added in the licence parameters, and the server can record periodically in a file how long it has run in total together with a time stamp. Thus the server would track more closely the passing of time (only the time the server is not running is potentially not tracked) and eventually the licence would still expire (possibly later than due). In order to avoid the case where the server is restarted just before the time stamp is recorded, the interval between such recording could be random, possibly very short (e.g. one minute) but on average long enough to not slow down the server.

But this scheme can be defeated by backups: even if the timing data stored by the server is encrypted, its exact state can be restored (e.g. every night) by the site manager from a copy made at an early stage (e.g. the first day). So this scheme should be reinforced by other measures. For example:

1. If the system call to obtain the date has been tampered with, the server could check whether other programs on the same machine see a different current date by inspecting publicly accessible parts of the computer. In particular it can cause an entry in a log file, and then compare the current date as returned by the system call with the modification date of the log file or the time stamp recorded by the logging process.

2. Clients running on different machines can communicate their current date. Some tolerance interval can be provided for slightly differing times and for the cases where the time zone is not set correctly. This control scheme would force the unauthorised user to set the date back on all the client machines: potentially annoying.

3. The time tracking information can also be stored on the clients (a bit like a Web browsers cookie), and can be checked whenever it is transmitted back during a query. The unauthorised user would then be forced to clean up or restore backups on all clients as well.

4. If the Network Time Protocol (NTP⁴) is being used, which is frequent on a large intranet, the server can use NTP to assert the time from another source (a local NTP time server different from the server machine). If a NTP time server is running on a machine that is accessible from both the inside and outside of the intranet (DNS or proxy), the internet address of that machine could be given as a licence parameter. The reference date used by the server would then be checkable by the provider at any moment.

The pseudo code specification in the annex (6.3 Option 2: Limiting the duration of the licence) shows the basic checking algorithm outlined above and the implementation of a selection of reinforcement measures.

4.5 Option 3: counting operations

In this scheme, the server counts the number of basic operations (associated to a unit cost) requested by clients. In the case of pay before use the licence file has certain parameters specifying the maximum allowed number of each type of operation, and the server stops accepting requests from clients when the maximum is reached. In the case of pay after use, the state of the counter is transmitted to the provider at the end of each period of time (e.g. each month) which then bills the customer accordingly. Since the state of the counter has to be saved across server restarts, the problem of its protection is similar to the case where the server tracks the passing time: the state of the counter is saved periodically to a file, signed with the server's internal secret key to avoid tampering, together with a time stamp to avoid reusing old files. The verification of the validity of such a file is thus the same as verifying the validity of the time stamps (c.f. 4.4 Option 2: Limiting the duration of the licence), with the same problems (the clock can be reset and an old backup copy can be reused), and the same prevention measures (check the time against a different source, save the counters on the clients). The implementation is thus a trivial addition to the one described in 6.3 Option 2: Limiting the duration of the licence.

4.6 Possible improvements

If some restrictions mentioned above in 4.1.1 Assumptions are lifted, then improved protection schemes can be devised. Since these schemes will not be implemented in the scope of this project they are only briefly sketched.

4.6.1 Smart cards and dongles

The level of protection will be improved if data can be stored on removable specialised hardware such as dongles and smart cards, which are more difficult to tamper with than data on a hard disk. In particular an older copy of the data cannot be restored on the device hence forcing the unauthorised user to fake the transmission protocol between the server and the device. For example the periodic time stamps (cf. 4.4 Option 2: Limiting the duration of the licence) or the usage counter (cf. 4.5 Option 3: counting operations) could be stored.

If the device is programmable, it can implement an encryption or signature algorithm with a secret key that is never accessible on the server machine (i.e. the secret key resides in a protected area of the device that cannot be read or written from the server machine). Identification of the server machine can be replaced by the identification of the device, giving more flexibility to install the server on any machine while preventing multiple running instances. This identification may be implemented in the following way: the server sends a random message M to the device which returns M_c where M_c = crypt(D_s,M). This is verified by checking that decrypt(D_p,M_c) = M, where D_s and D_p are the secret and public keys associated to the device. In this way, the transmission protocol cannot be faked, because the message M is never the same and the secret key D_s is not accessible.

4.6.2 Communication with an external site

If communication with a computer outside the intranet is allowed, it can be used for checking the time with a neutral, agreed upon, time reference source (c.f. 4.4 Option 2: Limiting the duration of the licence): One licence parameter specifies a publicly accessible NTP time server outside the intranet, agreed upon by both parties. In that case there is no need of a local NTP time server.

Also, if the provider maintains a licence service, the server may check periodically with this service that it is entitled to run by requesting a signed authorisation message. This way, the provider could better check that a particular licence is not used in different (non conspiring) locations because it is more difficult to fake internet addresses. To handle the cases where the communication channel is slow (e-mail) or temporarily unavailable (licence service down), the server would be allowed to run for a certain period of time before receiving the authorisation. If this period is long enough, e.g. one day or more, then the case is similar to the limited time licence, and unauthorised use is possible by reusing backups. If it is short, e.g. one hour or less, then the annoyances caused by restarting the server from a backup copy at such short intervals would probably deter the unauthorised user, but then the risk of down time due to communication problems is much higher.

5. Abbreviations

DES Data Encryption Standard1

DNS Domain Name Service (or Server)

EPROM Erasable Programmable Read-Only Memory

JCA Java Cryptography Architecture6

JCE Java Cryptography Extension5

MD5 Message Digest 5, hash algorithm designed by Ron Rivest1

NTP Network Time Protocol4

RSA Rivest, Shamir, Adleman (names of the creators of that public key cryptography algorithm)1

SET Secure Electronic Transaction3

SHA Secure Hash Algorithm1

6. Annexe: specifications in pseudo-code

The code below is written with the Java syntax. However it isn't compilable as is, because some parts are undefined (described only in comments) or because it makes references to non declared objects. In both cases it should nevertheless be sufficient to understand the intended meaning of the code. Also, it is expected that the implementation will differ from this code, in particular in order to handle multiple dictionary licences, and to have platform dependant code.

The code follows the guidelines of the Java Cryptography Extension (JCE⁵), and the Java Cryptography Architecture (JCA⁶).

6.1. Code used by all schemes

// Code common to all licensing schemes

import java.security.PublicKey;
import java.security.Signature;
import javax.crypto.Cipher;


// =============================================================
public class Licence extends Object {

// Maximum lag between system time and control time. eg. one
// minute:
static private long tolerance = ;
static private PublicKey provider_key;
// signature of the licence:
static private byte licence_signature[];
// algorithm used to sign the licence:
static private String sign_algorithm;
// licence content that was signed:
static private byte licence_message[];
static private String licence_file_path;

static public long start_time;
static public long end_time;
static public long total_time_used;
static public long last_time_stamp;
static public max_user;
static public interval;

private void parse_file(String file_path) {
// open the file and read the licence parameters
// and close the file
}

public long checked_current_time() {
private long current_time;
private long control_time;

// Get the current time from a different source than the
// clock For example: cause an entry to be logged in the
// log file, then get the "last modified" date of the
// log file and convert to a normalised value
// (control_time).
// Get the system time and convert to a
// normalised value (current_time). Assume that both
// control_time and current_time derive from the same
// clock; thus control_time should be before
// current_time.
if (control_time > current_time) {
// current_time has been tampered with: return bad
// value
current_time = 0;
}
else {
if (current_time - control_time > tolerance ) {
// current_time has been tampered with: return
// bad value
current_time = 0;
}
}
return (current_time);
}

public long unchecked_current_time() {
private long current_time;

// get the system time and convert to a normalised value
// (current_time).
return(current_time);
}

public boolean initialise(String licence_file_name,
PrivateKey user_key) {

licence_file_path = licence_file_name;
// Read the various licence values including the
// provider's public key "provider_key", the algorithms
// used for signing and encrypting "sign_algorithm" and
// "crypt_algorithm" the licence signature
// "licence_signature":
parse_file(licence_file_name);

// initialise a decryption object for the right
// algorithm:
Cipher ciph_obj = Cipher.getInstance(crypt_algorithm);
// provide the decrypting key
ciph_obj.init(Cipher.DECRYPT_MODE,
(PrivateKey) user_key);
// perform the decryption
byte[] decrypted_signature
= ciph_obj.doFinal(licence_signature);
// initialise a signature object for the right
// algorithm:
Signature sign_obj
= Signature.getInstance(sign_algorithm);
// provide the public key:
sign_obj.initVerify((PublicKey) provider_key);
// calculate the signature:
sign_obj.update(licence_message);
// compare the signature with the one read from the
// file, returns false if the file has been tampered
// with:
return (sign_obj.verify(decrypted_signature));
}

public void store_param(String identifier,
long value) {
// Encrypt the value with the secret internal key.
// Open the parameter file.
// Replace the encrypted value in the file.
// Close the file.
}

public long fetch_param(String identifier) {
// Open the parameter file.
// Read the encrypted value in the file.
// Close the file.
// Decrypt the value with the secret internal key.
// return value
}

public boolean check_oneself() {
// do some tricks with
// hostid, etheraddress, IP address, name
// check with opening a connection to oneself
// asking the DNS if there is one
// using a system call to get the arp statistics
// return false if there is a mismatch
}
}

6.2 Option 1: Limiting the number of simultaneous users

// Spec in pseudo-code.

// Done during server initialisation

// fetch from the licence file the interval of time considered
// for simultaneity:
interval = licence.interval;
// fetch from the licence file the maximum number of simultaneous
// users, > 0 :
max_users = licence.max_users;
// "allowed" is an object recording a list of pairs
// <user identification,time stamp>, initially empty.


// Done whenever a client identified by "user_id" requests an
// operation.

// Fetch the current time:
now = current_time();
// if the user is already allowed it can proceed
if (allowed.exists(user_id) {
allowed.update_time_stamp(user_id,now);
access_granted = true;
}
else {
// if the maximum number of users is not reached, a new user
// can be allowed
if ( allowed.size() < max_users) {
access_granted = true;
allowed.add(user_id,now);
}
else {
// If the oldest operation in the allowed list was
// recorded within the simultaneity interval then the
// maximum allowed capacity is used.
age = now - allowed.oldest_timestamp();
if ( age < interval ) {
// The new user is not allowed. If none of the
// allowed users perform an operation, the new user
// will have to wait until now + (interval - age) to
// be allowed
access_granted = false;
}
else {
// The entry with the oldest time stamp is considered
// expired and is replaced by the new allowed user
allowed.remove_oldest();
allowed.add(user_id,now);
access_granted = true;
}
}
}

6.3 Option 2: Limiting the duration of the licence

// Limited time licence

// Spec in pseudo-code.

// =============================================================
// Done during server initialisation


time_tolerance = ; // value corresponding to 13 hours in internal
// units. 12 hours will allow connections from clients with a
// wrong time zone setting, with an extra hour tolerance for a
// wrong clock (behind or ahead).

// location of licence file corresponding to the dictionary:
licence_file_name = "some_path";
if (! licence.initialise(licence_file_name)) {
licence_valid = false;
}
else {
start_time = licence.start_time;
end_time = licence.end_time;
total_time_used = licence.total_time_used;
last_time_stamp = licence.last_time_stamp;
server_started = licence.checked_current_time();

if ( start_time > server_started // licence not yet valid
|| end_time < server_started // licence expired
|| last_time_stamp > server_started // clock was changed
|| start_time + total_time_used > end_time // idem
) {
licence_valid = false;
}
else {
licence_valid = true;
last_time_stamp = server_started;
// update time stamp in licence file:
licence.last_time_stamp(last_time_stamp);
}
}
// =============================================================

// =============================================================
// Done at periodic intervals (like every hour, or at random) and
// at server shutdown
now = licence.checked_current_time();
if ( start_time > now // clock was changed while server was running
|| server_started > now // idem
|| last_time_stamp > now // idem
|| end_time < now // licence expired while server was running
) {
licence_valid = false;
}
else {
total_time_used = total_time_used + (now - last_time_stamp);
if (start_time + total_time_used > end_time) {
// clock was changed at some point
licence_valid = false;
}
else {
licence_valid = true;
last_time_stamp = now;
// update times in licence file:
licence.update_times(total_time_used,last_time_stamp);
}
}
// =============================================================


// =============================================================
// Done whenever a client requests an operation "client_time" is
// the current time on the client machine

// Use unchecked current time to avoid slowing down answer to
// client.
time_difference = licence.unchecked_current_time() - client_time;
if ( time_difference < 0 ) {
time_difference = - time_difference;
}
if ( time_difference <= time_tolerance ) {
access_granted = true;
else {
// Either server or client has a very wrong time
// Assume it is the client which is wrong
access_granted = false;
}
// =============================================================

7. References