Software Licensing and Upgrades

You buy and deploy servers to run software. When you install software, the creator of the software or the distributor holds a copyright and a license to the software that binds you in some way to the manner in which you can use the software. In essence, a license is an enforceable contract. Licenses bestow upon you certain rights and permissions but require your compliance with their terms. When you buy a commercial software package or get a server with software installed, you are given a copy of the software's EULA (end-user license agreement).

EULAs run the range of providing free use of the software to restricting the use of the software so that it runs only on one processor on the system it was purchased for and installed on. EULAs are often transferable, but as the industry moves from a perpetual license based on a single purchase to a subscription service model, EULA terms of use are constantly shifting. If you actually sit down and read through the legalese of some of these EULAs, you'll see that they contain all manner of restrictions of use. Some EULAs actually restrict the content that you can use or data you can collect with the software. It is unclear how much of any particular EULA is actually enforceable in the courts.

Note

For a contrarian view of EULAs, see the article on the Electronic Frontier Foundation's website, at www.eff.org/wp/eula.php.

License Types

You'll find that licenses make the following types of demands on you for compliance:

• Per-processor or per-system usage license Microsoft Windows XP Professional and Windows Server 2003 have a license that lets you install them on a two-processor system (dual packages). If you add additional processors, you need additional licenses.

• Client licenses Many client/server software systems require not only a license for the server software but licenses for the clients that connect to the server. Messaging systems such as Domino and Exchange are examples of this type of dual-system license structure.

• Per-user license Each user accessing the software needs to have his or her own account. Subscriptions, research access, and accounting software often requires a per-user license.

• Connection licenses A connection license allows for a particular number of simultaneous connections to a server. In some instances, each connected client requires a connection license, but in most cases, a company purchases a pool of connection licenses. When one client closes a session, the connection is returned to the pool for use; this is similar to the kinds of leases that DHCP offers. Enterprise databases often use connection licenses.

• Upgrade license These sorts of licenses search your system for a previous version, and if one is found, they install the upgrade.

• Academic license Many companies discount software sold to schools and students. Academic licenses require that you validate your academic connection.

• Downgrade and transfer licenses A downgrade license lets you purchase a current version of a piece of software, such as Windows XP, and use that license to run Windows 98 instead. A transfer license is a license granted to someone else that you either sell or donate your software to. Transfer licenses sometimes require formal application to the vendor.

• Open source licenses An opens source license allows you to use the software however you see fit, royalty free. You are even allowed to modify the source code, provided that you publish any changes you make in the source code for others to see. A very substantial pool of open source enterprise software for servers is available.

• Free license Freeware provides royalty-free use of the software but most often restricts any changes you make to the software's code. You use the software usually at your own risk.

• Shareware Shareware is not freeware; it is more aptly described as "trialware." Most shareware either times out without being purchased and registered or restricts your feature set until you purchase the product.

License Management Software

Regardless of the individual terms of any license, it is important to monitor your licenses. If you give your best effort to stay in compliance with your software vendor's terms, you should be able to pass any compliance audit. The licenses that are software instances are fairly straightforward to inventory, but the licenses that bind software to a particular hardware instance are more difficult and may need to be monitored with a software management utility such as LANDesk, Altiris, or Microsoft MOM.

If you think that licensing is a rat's nest, you are not alone. You may have some luck manually managing compliance when you have a few servers and clients. However, when you reach dozens or hundreds of systems, the task is not cost-effective or accurate enough to do manually.

Whatever software you install on your server, you need to monitor your license compliance for all installed commercial software. Many enterprise server software packages, such as Microsoft Terminal Server, Citrix MetaFrame, Oracle, and so on, come with their own license compliance utilities. Some operating systems can even be inventoried with tools from their developers. Figure 20.1 shows an example of SQL Server's license compliance tool. However, for the most part, license compliance across a range of software and systems involves so many of these kinds of tools (when they exist) that using them individually is a truly thankless task.

Figure 20.1. The Microsoft Terminal Server license compliance tool helps you manage your compliance for remote session connections in Microsoft Windows servers.

Note

Software license compliance is too complex and time-consuming a task to do by using manual methods. You should use a network management solution to do this task and regularly run the software and spot-check the results to see if they are accurate.

There is a large category of software on the market today that you can use to inventory your hardware and software. The most popular packages are entire software management suites, such as LANDesk, Altiris, and Novell ZENworks, which specialize in not only network systems management but also in application deployment. Each of these products has an associated asset management module or tool offered as an option in the suite.

In addition, all the large enterprise frameworks, such as Hewlett-Packard OpenView, IBM Tivoli, and CA Unicenter TNG have products in the license management area. However, this category of software is actually quite large, and there are simpler and cheaper network software programs that you can use to help you with license management if you don't want to employ a framework solution. Commercial solutions range in their utility from simply inventorying the software that runs on each system to matching software characteristics with a licensing database to determine compliance. You can also employ a consulting firm to assay your license compliance and help you manage it.

Upgrades

At some point all software products are upgraded. Software programs are like sharks: They must constantly move forward to the next version or die. This is as true for operating systems as it is for server applications. Part of any deployment, therefore, must take into account how upgrades will be handled as they occur.

Consider that operating systems and application software get revised every two to three years. Any large deployment during its natural course is going to have to make some decisions about which version(s) of software to deploy. There is a high probability that one or more key software components will need to be upgraded. The following are the essential factors that need to be considered in deciding which software version to deploy:

• Stability and reliability

• Life cycle and life span

• Features

• Costs

• System requirements

How you rate these different factors depends on your situation as well as the application(s) involved. Stability and reliability are especially important because they lower management costs. Also, a long life cycle and life span are primary considerations when it comes to calculating a system's return on investment. Features, costs, and system requirements are factors that don't tend to be as important, provided that they don't negatively affect the project to any great extent. Of course, your lists and rankings may be rather different from this and may vary from application to application.

Generally, when an application has been revised a number of times, as is the case with many enterprise applications on the market, it has reached a point where it is stable and has a mature feature set. Chances are that OurWebServer version 8.0 isn't going to be all that much different from OurWebServer version 7.0. In such a case, you might not wait for a beta version of version 8.0 to appear before beginning your development. For an application that does not have a long revision history or for any major operating system revision, it is important that you do your testing on the most advanced form of the software that you can get access to. You should be aggressive in pursuing the latest operating system versions because doing so provides the longest life cycle for any server deployment and, more importantly, is your best bet in order to secure your systems against current threats.

Chances are that whatever versions you choose for your software, whatever versions you test, and whatever versions you deploy, you are going to be faced with software upgrades further down the line. Most organizations tend to be very conservative in installing upgrades beyond operating system patches to their server deployments. You have to give some measure of faith that your operating system vendor won't break your system with the latest patch, although sometimes that does happen. If you are installing an operating system patch, you should do so in a manner that lets you uninstall the patch if needed. Most operating systems provide an uninstall patch feature. If your operating system doesn't have an uninstall routine, then you should find a patch manager to use or utilize a snapshot backup utility that allows you to return your server's operating system to the state it was in before it was upgraded.

Tip

The Golden Rule of software upgrades is to take small steps and evaluate.

Application upgrades are another story entirely. Most organizations with large investments in optimizing an application for a server platform are very conservative about moving their application to a new version. Studies that measure the percentage of servers that are migrated from an older version to a newer version reveal that usually fewer than 50% of application servers are migrated for most applications. If an application's new version requires a new file format or extensive data reorganization, or if it requires significant code rewriting, often the migration percentages are lower than 20%. Most organizations opt to live with what they have and do a fresh server deployment rather than upgrade their software in place.

It's really best to think of an in-place software upgrade as a fresh deployment anyway. If you intend to migrate to a new version and can run a pilot to uncover any of the issues involved, it may make sense to do so. A pilot for migration works best when one of your working application servers can be upgraded in place and then used going forward for a representative set of users. If the new version of the application doesn't interoperate with the older version of the application, then you probably should try a migration but seek to test a fresh deployment.