WorkShop Installation and Licensing Guide: B - General Licensing Information

# General Licensing Information | # B |

Customers benefit from the concurrent license model in the following ways:

- Software is available to any user on any computer on a network because licenses are not tied to a specific computer.

- Development team use is more cost effective, especially for those software products that receive only casual use.

- It allows for internal tracking of tool use. Additional purchases can be based on demonstrated need instead of guesswork.

- Internal software audits are easier and more accurate.

## FLEXlm Licensing

Sun, like over 700 other Unix® software application vendors, has chosen FLEXlm to provide a flexible network license manager. Sun believes that FLEXlm is the de facto standard for software-enabled licensing.

### FLEXlm Components

FLEXlm has four major components:

- License manager daemon (for example, `lmgrd.ste`)

- Vendor daemon (for example, `suntechd`)

- Elementary license files

- Application (for example, WorkShop Compiler C++)

### How Network Licensing Works

Somewhere on your network a license manager daemon monitors requests for access to Sun software. The computer running the daemon is called the license server. Requests come from product servers. A product server is any computer on which a product is installed.

When you start a product or an application, the application looks in the license file for the name of the license server and contacts the daemon on that server. The license server has another license file that includes the number of rights to use (RTUs) for each licensed product and the passwords for those products. If a license token is available, use of the application is granted. If a license token exists but is not currently available (for example, if other users have checked out all the license tokens), you will be put into a queue.

The license manager daemon handles communication between the application and the vendor daemon. The vendor daemon, which also runs on the license server, tracks which users have licenses for a given product, how many licenses are checked out, and how many licenses are currently available.

As described above, as many as three computers may be involved in using Sun products: a development computer, a product server, and a license server. Note that a single computer can serve two or more of these functions at the same time. For example, it is not uncommon for a small installation to have one computer export the application, the C compiler for example, and simultaneously act as the license server. In this case, this computer is considered both the product server and the license server. Another common configuration is for each user to have a local copy of a compiler on her or his own computer and share licenses from a central license server. This may offer users improved performance.

## How Many License Servers Should You Use?

There are three possible license server configurations:

- Single independent server configuration

- Multiple independent server configuration

- Redundant server configuration

Sun strongly recommends the use of independent servers, either single or multiple, for simplicity of installation and maintenance. However, whenever a single independent server is mentioned in this document, the information applies to a redundant server configuration as well.

For additional information about when to use each configuration, refer to "A Licensing Strategy Guide" on page B-68."

Single Independent Server Configuration

The single independent server configuration suits companies where the developers, license server, and product server are fairly close together on the network. This configuration is the default and the easiest to install and maintain.

##### Single Independent Server Configuration Example

To illustrate how a single independent server configuration works, consider a situation where Linda, a C++ developer, wants to recompile her program. She is working from her desktop machine epcot. She mounts a copy of the WorkShop Compiler C++ from the machine, tools. There is only one license server on her network, lic1 which brokers the 10 RTUs her department purchased.

Typical Process for Getting a License in a Single License Server Configuration

When Linda starts a compile of her program, the WorkShop Compiler C++ on tools sends a request to lic1 for a license token. If lic1 has a token available, then the request is granted and Linda's compile completes. In the event that all 10 tokens are already in use by other developers in Linda's group, she is automatically put in a queue and will be granted a token as soon as one is released by any one of the other users.

Multiple Independent Server Configuration

You can use two or more independent servers in a multiple independent server configuration, where users can obtain a license token from any one of the servers.

This scenario is most common for medium to large software development environments distributed over a network. Distributing the total number of license tokens purchased among multiple license servers increases the likelihood that at least some license tokens will always be available. Of course, just as with single independent license servers, any license tokens served by computers that are offline are unavailable until those machines are returned to the network.

While you can have any number of independent servers, we recommend finding a balance between the two extremes of centralizing all your license tokens on one server, and dispersing license tokens to many servers (to each developer, for example). By placing license servers strategically throughout your network, you maximize the responsiveness of license requests and minimize the administrative overhead.

A multiple independent server configuration may allow you to enjoy a discount by buying a larger quantity of RTUs while at the same time offering the flexibility to install licenses in a configuration you choose. For example, you could buy 100 RTUs and distribute them over 10 independent servers with 10 license tokens each.

##### Multiple Independent Server Configuration Example

To illustrate how a multiple independent server configuration works, we'll expand on the example we began earlier with our C++ developer, Linda. Just as before, she is trying to recompile her program. She is still working from her desktop machine, epcot, and she has mounted a copy of WorkShop Compiler C++ from the machine, tools. Two license servers have been put in service on her network lic2 and lic3, in addition to the default server, lic1, each with 10 license tokens. Figure B-2 illustrates her configuration.

When Linda starts a compile of her program, WorkShop Compiler C++ on tools sends a request to lic1 for a license token. If lic1 has a token available, then the request is granted and Linda's compile completes. But suppose that all 10 of the license tokens on lic1 are already in use by other developers in Linda's group. In that case, tools automatically looks for a token on lic2 and, if that fails, lic3. In the unlikely event that none of the three servers has license tokens available, Linda will be queued on lic1, where she will get the first available token.

Typical Process for Getting a License in a Multiple Independent License Server Configuration

Redundant Servers

A redundant server configuration enables you to have three servers managing the same set of license tokens, in essence acting as one logical server. This configuration requires that a simple majority of redundant license servers be operative and able to contact each other; if such is not the case, none of the license tokens will be available. Therefore, a three server configuration requires that two servers must be available for any tokens to be available. The main advantage of redundant servers is an increased likelihood that if any tokens are available, then all tokens will be available; the cost is additional administration.

At any given time, one of the redundant servers is the master server: the server that actually issues license tokens and, thus, has a heavier processing load. If the master server becomes unavailable, then the next available "peer" in the configuration becomes the master server.

Use of this configuration should be limited to special situations where its advantages outweigh the increased complexity of installation and maintenance.

##### Redundant Server Configuration Example

With the example we used earlier, we'll illustrate how a redundant server configuration works. Just as before, Linda is trying to recompile her program. Again, she is working from her desktop machine, epcot, and she has mounted a copy of WorkShop Compiler C++ from the machine, tools. Linda's system administrator has set up a redundant server configuration on her network; lic1 is the master server and lic2 and lic3 are alternate servers. The redundant server configuration brokers the 30 license tokens Linda's group purchased.

When Linda starts a compile of her program, WorkShop Compiler C++ mounted from tools sends a request to lic1 for a license token. The server, lic1, first checks for the presence of lic2. If lic2 is not found, then it looks for lic3. If either lic2 or lic3 is found and a license token is available, then the request is granted and Linda's compile completes. But suppose that all 30 license tokens are already in use by other developers in Linda's group; in that case, Linda would be put in a queue where she will get the first available license token. In the unlikely event that lic1 can find neither lic2 nor lic3 (for example, if both machines were down for repairs), no license tokens will be available. If lic1 is down but lic2 and lic3 are functional, all license tokens will be available.

Typical Process for Getting a License in a Redundant License Server Configuration

## A Licensing Strategy Guide

Following are some strategies for deploying your product and license servers. None of the companies mentioned actually exists; these are merely representative illustrations that may help you plan a productive, easy-to-maintain development environment.

### Example 1: Single Independent Server Configuration:
Joe's Number-Crunching Shop

Joe runs a small, successful business developing scientific applications. He has 10 Sun workstations running the latest release of Solaris 2.x and has purchased eight RTUs for WorkShop IPETM and six RTUs for the C compiler. Since Joe's resources are limited, he is having the NFSTM server, sampson act as both his license server and his product server. Since the NFS server is a file server everyone uses as a common work area, Joe has not even upgraded it to Solaris 2.x. Figure B-4 illustrates Joe's network.

The machine, sampson, is a good choice to serve Joe's license tokens because it is a reliable machine that is neither upgraded nor rebooted frequently. Joe recognizes that any trouble with sampson would be noticed immediately since the common development area is stored there. Lastly, Joe appreciates that license administration adds minimal overhead to sampson's normal system administration requirements.

Using an NFS Server as a License Server

### Example 2: Multi -Platform Environment:
Marble Entertainment

Marble Entertainment develops and markets video games for the Solaris computing environment. Recently Marla, the lead developer for their newest game, decided to port Marble's code to Solaris for Intel. This made her marketing department, as well as her management, extremely happy because she showed that the port would be an amazingly simple effort using Sun's language systems. Marble purchased a Pentium computer and Sun Visual WorkShop C++. Marla installed the Sun Visual WorkShop C++ locally on her Intel machine, added her license passwords to her existing SPARC-based license server delight, and was ready to recompile. Figure B-5 illustrates Marble's network.

Using an Intel Computer as a Product Server and a SPARC Platform License Server

### Example 3: Multiple Independent Server Configuration:
Coyote Financial Services

Coyote Financial Services is a financial services broker. Because of the nature of the company's business, it is essential that at least some of its WorkShop Compiler C and license tokens always be available. In addition, they have purchased WorkShop IPE/TeamWareTM and WorkShop Compiler C++. They have three large servers, bull, bear, and crash, that will be license servers, among their other duties, and two other servers, dollars and cents, will be product servers. Figure B-6 illustrates Marble's network.

Multiple Independent License Servers Supporting Two Separate Product Servers

By splitting its license tokens between bull, bear, and crash, Coyote maximizes the chances that at least some WorkShop Compiler C tokens will always be available. In the event that a license server is unavailable, Coyote has also taken the precaution of putting the three license servers on different sub-nets and power supplies. Coyote considered a redundant server configuration but preferred a multiple independent server configuration because the company would rather have at least some license tokens at all times rather than all tokens most of the time.

## License Certificate Information

### Certificate Denominations

License certificates for WorkShop products are issued in denominations of 1, 10, 25, and 100 RTUs.

### Divisibility of Multiple RTU License Certificates

Sun offers the ability to split multi-RTU license certificate denominations into multiple passwords (sometimes referred to as "making change"). This means that you are not required to install all of the RTUs on a multi-pack certificate (10, 25, or 100 denominations) on a single license server. Customers can enjoy a volume discount on these larger denominations as well as the flexibility to install licenses in the configurations and locations they choose.

Also, if you misplace a certificate that was once registered, you do not have to worry. Simply call your local Sun License Center and provide identifying information such as company name, address, and so on. The Sun License Center operators can also look up previous transactions using license server hostname and hostid.

### Getting Upgrades

New major releases of software (2.x to 3.x, for example) usually require new licenses and passwords. Sun may, on occasion, release a minor upgrade that operates with the existing password. This is usually to enable rapid distribution of critical fixes to software. These patches and "dot-dot" releases (3.0 to 3.0.1, for example) will work with the same password. Patches are available through your Sun Authorized Support Provider and sometimes through your Sun Authorized Reseller. Upgrades are usually made available through your reseller.

### Adding Rights for Additional Licenses

An additional password is required each time you add additional RTUs to an existing license file on the same computer for the same version of a product. For example, if you have a password that authorized five users for WorkShop Compiler C++ 4.2 on the computer called magickingdom, and you wish to add support for five more concurrent users, you would need to add a new incremental password authorizing five additional users.

RTUs for additional users are acquired through authorized Sun resellers; Sun License Center cannot handle sales transactions.

### Changing License Servers

If you need a new password because you are upgrading or repairing your license server, contact the same Sun License Center that you originally contacted for your original password. You are allowed two moves of a license from one license server to another per calendar year. Sun may grant additional moves at its discretion. Moves are recorded and subject to audit. At the time of the request, the License Center operator will require written confirmation that the old license data file (or password) has been deleted.

Thanks to network or floating licensing, no changes are necessary for client moves, only for license server moves. Changes to hostnames are also inconsequential and can be made directly in the license file without invalidating the licenses.

### Start of Warranty

Sun provides a 90-day free replacement for any product for which parts are missing, the media is unreadable, or the Proof of License Certificate is missing or incorrect. This warranty period starts from the time you receive the Sun product. Sun resellers may offer additional services for products acquired through them. Contact them directly for details.

All returns should be handled through your reseller. Contact your reseller for their Return Materials Authorization (RMA) procedure.

## Network License Questions and Answers

| #### Does licensing affect the programs I write?

No, network licensing, as described in this document, will not affect your programs in any way; it only comes into play when you use Sun products, not when you or anyone else executes programs you have written. Runtime libraries that you are "licensed" to redistribute as part of your product are included with Sun products.

| #### To what is a license tied? What defines a user?

For Sun WorkShop and Sun development tools, "`username@x-display`" defines a user. Users are different from each other if they differ by name of the user or x-display/computer. For WorkShop Compiler language systems, username defines a user.

| #### What locks my licenses to my license server? For example, what if I want to change the hostname?

Licenses are tied to the license server via the hostid. You are free to change the hostname at anytime without notifying Sun. This will require minor modifications to your license server which are documented in the Sun software installation guide. These changes should take less than 10 minutes to complete.

| #### What if I need to move my license passwords from one license server to another?

Sun allows you are two moves of a license password from one license server to another per calendar year free of charge. Moves are recorded and subject to audit.

| #### Is network licensing difficult to install?

While there are additional installation steps for software with license assurance versus software without, the task is not daunting. The installation manual guides you step by step through the process of both installing the license server and making transparent the addition of new clients to that server. While the time it takes to obtain your password will vary depending on the methods you choose to correspond with the License Distribution Center, the installation of a license server itself usually adds no more than from 10 to 15 minutes to the installation process; no additional time is required for adding a new client.

| #### Do I need to become root (superuser) to get access to the software, that is, to become a client?

You do not need to become root to gain access to Sun products once they are installed on a product server. You only need to have the product server included in your path (that is, the product server must be mountable by the client machines). Generally this can be established without becoming root. Installing new passwords will generally require superuser access.

| #### Will I need to make modifications to the license data file when I add a new machine or user to the network?

No. Nothing special needs to be done to set up new clients unless you wish to provide them with special rights, such as reserving licenses for them.

| #### If I already have a FLEXlm license server for a non-Sun product. Can I add Sun product passwords to the server? Do I need two separate servers?

A FLEXlm license server can serve license tokens for any software product that has FLEXlm as its network licensing component.

| #### Will there be conflicts if I install Sun software or a Sun license manager on a machine already running the same license management software, FLEXlm?

Sun uses FLEXlm by Globetrotter Software for the licensing component of our software packages. There should be no potential for conflict with other license management software. If a license server is serving two or more products that include different versions of FLEXlm, Globetrotter Software recommends using the latest release of FLEXlm's "`lmgrd,`" or license manager daemon, with the compatibility mode enabled. This should minimize the potential for problems.

For example, if you are running a desktop publishing package that uses FLEXlm and a Sun compiler each vendor will have shipped you an "`lmgrd.ste`" daemon. Consult the installation documentation for a version number of the daemon provided by that vendor and install the latest version.

| #### May I make copies of Sun software and distribute them on my network?

Yes. You are not prohibited from making any number of copies of Sun products and distributing them over your company's network. One of the benefits of network licensing is that you may have as many local "product servers" as you like and make use of a central license server. Of course, you cannot modify or administer Sun products in any way that defeats the FLEXlm licensing protection without violating your agreement with Sun.

| #### Can my license server be on a different subnet? How about a different domain?

Yes. Your license server, product server and development computer can be in different domains or on different subnets. Of course, you will probably achieve better performance if you locate them closer together than if they are across a continent. For best performance, Sun suggests using multiple independent server pools when possible to deploy license tokens reasonably close to where they will be used.

| #### If a license server can be in a different domain, is it possible for someone outside my organization to access our licenses?

Most institutions take reasonable security precautions by placing a "firewall" between themselves and the outside world. If such measures are in place you are in no danger of having your licenses "borrowed" by trespassers. If your organization chooses not to take such preventive measures, then you can limit access to licenses to specific people in your organization through FLEXlm itself. This will prevent unauthorized use of your investment.

| #### How quickly are my licenses available for use by another user after I quit using a Sun product?

For WorkShop products, the license token is available immediately after you have quit the last tool. WorkShop Compiler and Sun language systems offer you the option of retaining a token for a period of time after the last compile completes. This allows you to ensure that a developer debugging her project has a license token available as she does successive compiles. The default is to release a compiler token five minutes after the last compile completes, with the option to set it to almost zero. Sun 2.0 and 2.0.1 products have patches available that offer the same functionality.

| #### What happens when no license is available?

With WorkShop tools, if no license token is available, a pop-up window is displayed with an appropriate message. You can quit the program or tell it to try again for a token.

With WorkShop language systems, if no license token is available, your request is placed in a queue. When a license token becomes available, the compiler runs. If you do not want your request to be queued, you can start the compiler with the `-noqueue` option. If you use this option and no token is available, the compiler returns immediately with a message that no tokens were available and exits. For all compilers, the `-``xlicinfo` option shows the quantity of licenses available, the quantity checked out, and your place in the queue.

The license system administrator can reserve licenses for particular users, computers, groups, or displays. When a license is reserved, it is always "locked" for one of the "types" listed above. System administrators can also restrict licenses to a particular group of users and can name specific users who are not allowed to check out licenses.

| #### What happens when a computer crashes while it has a license?

If you have checked out a license token and your machine crashes, the token will be tied up until the next refresh time, which should come along in a few minutes. Then the token will be freed. The system administrator of the license server can also use the license tool `lmremove` to free the license immediately if necessary. The `lmremove` option requires root access to the license server.

| #### I have 200 engineers at my company. How many licenses (RTUs) should I purchase?

The quantity of RTUs needed to support a certain number of users is dependent on the frequency and schedule of use. In some situations, a large number of users who make infrequent use of a compiler can be effectively supported by a relatively small number of compiler licenses, for example, to compile public domain programs. In other situations, there may be heavy and consistent use of these products.

Consider the analogy of carpenters. For a group of carpenters framing a house, some things--like a table saw--require only occasional use and can be shared by all; however, every carpenter probably needs a hammer. If these same carpenters were building furniture, perhaps the best way to maximize each carpenter's productivity would be to provide each with the tools they need to do their work.

The rule of thumb you should use to ensure the productivity of your professional programming staff during peak development periods is to assume each full-time programmer needs one RTU per product.

| #### With previous releases of Sun products, I needed to license each computer, regardless of whether or not the software had simultaneous use. How do "floating" licenses differ?

The incorporation of network licensing in Sun's family of products provides you with both purchasing flexibility and cost savings because you only need to plan for enough licenses to satisfy the maximum number of simultaneous users. A conservative approach is to estimate one full license for each full-time developer. Infrequent users may be adequately supported by sharing licenses.

| #### What control do I have over who can and cannot use a license? For example, I do not want another department making use of licenses that I acquired, and need, for my department.

The license server allows you to specify who can and cannot use the software. You can even reserve licenses for particular users to ensure that critical software is always available for them. These and other options are easily set in the `daemon_options` data file.

| #### How can I obtain a demo password?

Sun has a promotional program called "Try and Buy." Try and Buy lets you evaluate any or all of the Sun family of products for 30 days free of charge or obligation. You can contact your reseller to receive a Try and Buy kit. However, Try and Buy is not the only way to evaluate Sun products. If you have already purchased a Sun product and you realize you need help with some new problem--source code version control and release integration for example, you might want to consider Sun WorkShop TeamWare 2.0. Since you already have the media, all you need is a demo password.

Demo licenses are good for 30 days, and serve an unlimited number of concurrent licenses. The License Center operator will require the same information as for a permanent, or "perpetual," non-expiring license.

| #### Can I get a password when I place an order for a product?

If you are a new customer, you can call Sun MicrosystemsTM Computer Corporation, SunExpressTM, or another authorized reseller to order Sun products. Having placed an order, you will then receive the Proof of License Certificate packaged with the product, which you will use when calling the Sun License Center to get a password. At present, password distributors do not provide sales services. As a special service to its customers, a reseller (on its own initiative) may take care of the password transaction for you. Contact your reseller about this service.

| #### Can my X86 computer serve SPARC product licenses and vice versa?

Yes, normally the hardware platform of your license server is not relevant to what licenses you can serve from that server. However, Sun usually ships the latest stable release of FLEXlm with its products. Because releases on different platforms are asynchronous, the versions of the license manager may, from time to time, differ. In such cases, Globetrotter Software recommends running the latest version of the license manager when the license managers contained in two products differ. Occasionally this creates an incompatibility and a given platform may not be capable of acting as a license server for another platform. One alternative in this case is to switch all of your licenses to whichever platform can support both platforms. In most cases, this is the best way to minimize the burden on your system administrator or manager by centralizing your licenses. Sun realizes that this may cause some customers inconvenience and will try to minimize the chances of this.

| #### Which version of the Solaris operating environment can my license server run? For example, I have a computer running Solaris 1.x (SunOS 4.x) that I would like to use as a license server but I want to develop with compilers for Solaris 2.x (SunOS 5.x). Is this a problem?

No. However, Sun recommends that you choose your license server carefully. The best choices include machines that are stable and unlikely to undergo frequent software upgrades--especially the system software. Poor choices also include computers in test labs and computers that require frequent rebooting.

| #### Can I split licenses for various products included in Sun WorkShop products between multiple license servers?

Sun WorkShop was designed to offer customers a complete development environment for maximum value. You cannot "split" the separate product licenses among multiple license servers. However, as always, your product servers can be separate from your license server, and you are free to place different component products of Sun WorkShop wherever you like. Sun WorkShop can be, of course, run by a redundant server configuration.

| #### If I have a password for FORTRAN release n.x. will I need to get a new password for FORTRAN release n.x.+1?

In nearly every case, new releases of software require new passwords. Sun may, on occasion, release an upgrade that operates with the existing password, for example, to enable rapid distribution of critical fixes to software.

| #### If I have licenses for an old version of a Sun product, 2.0.1 for example, and I obtain 3.0 licenses, can I use these licenses interchangeably with both versions?

No. As with most major upgrades, Sun 2.0.1 license passwords do not enable 3.0 products and 3.0 license passwords do not enable 2.0.1 products. License passwords for 2.0.1 and 3.0 can coexist on the same license server, but they are not interchangeable. For example, if you own 10 RTUs for WorkShop Compiler FORTRAN 2.0.1 and you obtained 10 new RTUs for WorkShop Compiler FORTRAN 3.0, 10 concurrent users could run each version of the product, but not an 11th concurrent use of either.

| #### May I invoke multiple compiles while only using one license?

Yes. You can invoke multiple compiles using only one license token provided you do so as the same unique Unix user, that is, using the same value for username. See "To what is a license tied? What defines a user?" on page B-73.

| #### What about running software on a multiprocessor machine? Will my compilers use a license for each processor? That is, does a four-processor machine require four licenses to run a compile?

A multiprocessor machine is considered a single computer. A single license token is just as suitable for a multiprocessor computer as it is for a single-processor computer.

| #### I am using a "distributed make" product that allows me to make use of multiple machines on my network. May I use just one WorkShop Compiler license since one user is doing all of the "work"?

Yes. WorkShop Compiler language systems are licensed to username to accommodate just this sort of use.

| #### If Sun compilers are licensed to username may I make a generic user account called guest or Sun, for example and have all the developers at my company login as the same user and just use one license or right to use (RTU)?

No. This would violate the legal agreement you entered into when you purchased your Sun product. That agrement requires you to use a unique Unix username for the software.

| #### May I use multiple compilers, say WorkShop Compiler C and WorkShop Compiler FORTRAN, while using only one license between the two of them?

No. Each separately licensed product requires its own license and license token. In the situation described, you need a WorkShop Compiler C license password to run WorkShop Compiler C, and you need a WorkShop Compiler FORTRAN license token to run WorkShop Compiler FORTRAN.

| #### Does each of the tools in WorkShop require its own license?

No. Assuming you are running as the same user on a single x-display, you may use as many WorkShop tools simultaneously as you like. While WorkShop is composed of many tools, including the Debugger, ClassBrowser, and SourceBrowser, it is configured to share a single WorkShop IPETM license token.

| #### Are SPARC and Intel Platform licenses and license tokens interchangeable?

No. Sun products for the Intel Platform and for SPARC are separate products and are licensed separately.

| #### If I have a single RTU for WorkShop, may one user run SourceBrowser while another user simultaneously runs Debugger?

No. A single WorkShop IPE RTU allows only a single user of WorkShop IPE regardless of the mix of tools. It is the access to WorkShop IPE that is licensed, not each tool.

| #### What can I do to retain my ability to check out software in the case where the machine running the software license server goes down?

Assuming the product server is available from another machine, you can configure your license server in one of two ways:

- Configure your independent servers in a server pool

- Use a redundant server configuration.

| #### Are there any restrictions to the number of machines that can issue licenses for a single product?

You may have any number of independent servers or logical redundant servers (that is, several servers acting as one local redundant server setup). However, each redundant server configuration must consist of three computers.

| #### Why does a redundant server configuration require three servers? Can I have five? Why not two?

In FLEXlm's parlance, the "redundant server" concept does not provide a "mirror" backup as you find in the worlds of relational databases or fault-tolerant file servers. However, this is more than just a limitation of FLEXlm's technology. Conceptually, the intent and purpose of software enabled licensing would be defeated if servers did not have to be in constant contact with each other during operation. For example, let us suppose that this limitation were lifted. You have installed a two redundant server configuration and a problem arises on the network connecting the respective buildings housing each license server. Each license server would provide 100 % of the licenses in this "failure" mode adding up to 200 % of the licenses you had paid for. Without even being aware of it, you are suddenly in violation of your license agreement with your software vendor.