Executive Summary

This Blog Article focuses on Software License Agreements and what you should consider and look for, before signing them.  Modifying these are often challenging, especially if you are dealing with an Industry Giant. At the same time, it is best to understand them and look for “Red Flags” where you may want to either negotiate a Clause, or walk away from the deal.

‍

Software License Types

Perpetual

You are purchasing the license to use the software on a permanent or perpetual basis. In addition to the license costs, there is an annual maintenance fee that is charged in order to keep the software updated with the latest version.

Perpetual Software Licenses can typically be Capitalized and amortized over the useful life of the software, typically 3 years.  If it is a Mission Critical system, such as an ERP System, a 5 year useful life might be applicable.  In addition, if you decide to Capitalize your purchase, you can also Capitalize some of the costs associated with implementing the application. Please work with your Auditor and Finance department to determine what can be Capitalized.

Client Considerations

• Under what conditions can this Perpetual License be revoked?
• If this is a Mission Critical system, is the Vendor willing to place the Source Code in Escrow? This is important, especially for smaller Vendors, who are more at risk of a business failure. And if they agree to this, then it needs to be specified how frequently the Source Code in Escrow is updated, as you don’t want to end up with 3 year old code that is of no use to you.

Subscription  (Local, SaaS / Cloud Hosted)

In this case you are leasing the software for a specific period of time (the Subscription Term), whether that is monthly, for a year, or multiple years.

In most cases, the Software will be accessed on a Cloud or Software as a Service (SaaS) hosted site. Examples of this include: SalesForce.com, NetSuite.com, HubSpot.com, Jira.com, etc.

However, there are Subscription licenses where the software is physically installed on local PC’s / Macs, or Corporate Data Centers. A good example of this is an Officer 365 License, where Microsoft Office can be installed locally, but it will only work if you renew your annual Subscription.

Maintenance and hosting fees are typically bundled automatically into the Subscription License Costs.

Client Considerations

• Since you do not Own the Software, you can not Capitalize a Subscription License. So, this becomes an Operating Expense line item on your budget.
• Is there a separate Support or Premium Support charge?
• What happens to your Data, when you decide to cancel the Subscription? Can you download it? And if so, what timeframe do you have in order to do this?
• Keep in mind that the Larger the System, the longer it will take to replace and migrate from one system to another. Don’t underestimate the amount of effort required to do this.
• If the Application is a Cloud or Software as a Service (SaaS) model, what is their guaranteed Application Uptime SLA, and are there any penalties for non-conformance. Ideally, you want to see at least a 99.9% SLA for Application Access & Processing.

Usage Based

This is a license that is based on how frequently you use it or the amount of usage.

Examples:

• Load & Stress Testing Tool - where you pay based on the number of synthetic users and length of the test.
• Transactions Processed - where you are charged based on how many transactions are processed within the platform. This also includes mass email systems and automated SMS Text messaging systems that send out tens of thousands of text.

Open Source

There are many different forms of a GNU Open Source License. All of them allow you to use the Software for Free, however:

• It may be limited in Functionality (a.k.a. Community Version), if you want the full features of the product then you have to purchase a license for the “Enterprise Version.”
• Changes you make to the Open Source Software, may be required to be published to the Community.
• And in very restrictive cases, any Custom Code that you build on top of the underlying Open Source product may be required to be published to the Community. This can make retaining Intellectual Property rights to your code, very difficult.

The bottom line is that while using Open Source code is very common and also cost effective, you need to read the licensing agreement very closely, especially if this is a Core part of your business.

‍

License Based On

Regardless of which type of License you acquire, the License itself may cover one or more of the following:

Server Based

This is a common model with large Enterprise class applications that are installed either in a Company’s Data Center or in a Cloud Environment, which the Client controls. This can take several different forms, and is often paired with some form of User Client Access License (CAL) as well.

• Per Production Server Instance
• Per Production Server by Core or Number of CPU’s
• Non Production Server Instances - normally have a significant discount, as they are used infrequently and typically only for testing and development.

Application Module

This is another common model used with large Enterprise call applications, whether hosted in a multi-tenant Cloud site, or installed in a local Data Center that the Client controls. Each module may have its own Price Point.

There may or may not be additional User CAL’s associated with this type of license.

Real World Example:  Custom ERP for an Industry

This particular Software Company charges all of their Clients by which Modules they want access to. Each Client can pick and choose the individual Modules of the ERP System that they want to specifically have access to. With this specific Software Company, they only charge their Clients on a per-Module basis and no additional per-User (CAL’s) are required.

• Buyer‍
• Request For Quotes
• Purchase Order
• Payables (A/P)
• Receiving

• Seller‍
• Quotes
• Sales Order
• Invoicing
• Receivables (A/R)
• Shipping
• Inventory Control
• Return to Manufacturing

• Salvage Operations
• ERP Integrations API
• Enhanced Reporting & Analytics

Per Named User

Every User of the system must have their own unique license, which is tied to the individual's name. Licenses cannot be shared among Users.

This is a fairly straight forward model. If you have 100 Named Users, then you need 100 Licenses.

Concurrent Users

This User License model is much more difficult to determine and predict from a budgetary standpoint.

Basically you are purchasing a Client Access License to the system, which can be shared by any number of Users of the system. However, the total number of Users of the system at any given point in time can only be up to and equal to the number of Concurrent Licenses that you have purchased.

Applications that use this model, will have a Governor, which prevents the N + 1 User from logging in, until such point that another User has logged off of the system.

For example, if you have purchased a 200 Concurrent User CAL, and there are 200 different Users currently Logged in. Then when User #201 tries to log in, they will receive an error message, basically stating that there are no User Licenses available at this time, please try again later.

The biggest challenge with this model is accurately predicting exactly how many Concurrent User CALs you actually need for normal business operations.

API / Software Development Kit (SDK)

Many Software Companies will charge a special License Fee for a Client’s Development team to access their Software Development Kit (SDK) and Public API’s.

The reason for this is that often Developers will have significantly more questions and require more support, than a typical User of the system.

In most cases, this is a Subscription License, but it could also include a Usage License (number of transactions processed).

‍

Maintenance and Support

In most cases there will be a separate Maintenance and Support Agreement.

Depending upon your specific needs and the criticality of the Application you may need Basic Support, Premium Support, or even Dedicated Support.

Fees for Basic Maintenance and Support should be no more than 20% of the base list price of the Software. This subtlety is important, as most Software Companies can discount the Software License price, but not the Support Agreement fees.

In addition, be careful of how frequently and by how much the Vendor can raise their Support and Maintenance Fees. As the Client, you want to limit these increases as much as possible, hopefully getting them close to the standard inflation rate on an annual basis.

‍

Regulatory Audits for Cloud / Hosted SaaS Application

When dealing with a Vendor who provides a Software Application that is Cloud base or a Hosted SaaS Application, you need to consider what type of Key Controls and Regulatory Compliance / Audits may be required.

Some examples include:

• SSAE 16 Type 2 Audit (annually) - if the Software is processing financial transactions that are “material” in nature.
• PII Compliance - when the Software is storing personal information about an individual that can identify who they are.
• HIPAA - when the Software is storing healthcare related information about an individual.
• PCI Compliance - when the Software is processing Credit Card Transactions.

External Audit Considerations (SSAE 16 Type 2 Audit)

As an example, if your Internal Audit department identifies that this Software is processing financial transactions that are material in nature, then you have two choices:

• Require the Vendor to conduct an External SSAE 16 Type 2 Audit (annually)‍
• Many Vendors will say that their Cloud Provider or Data Center has passed, so we can rely on their Audit, but this is not sufficient.
• This Audit must also include the Vendors internal software development and promotion processes to production:‍
• What key controls do they have in place?
• Who has access to the Production system?
• How is code tested?
• What security testing has been done?
• Etc.

• Alternatively, you can have your own Internal Auditing Team visit the Vendor’s location and go through the same process that is required for a SSAE 16 Type 2 Audit. This may be less expensive for the Vendor, but it is a very time consuming exercise.

‍

Conclusion

In this blog article, we have covered the most common types and categories of Software License Agreements, and what to consider. It is important to remember that any given Vendor may combine many of these together for the specific application they are selling Commercially. We also covered Maintenance and Support Agreements and also Regulatory Considerations.

We hope that you have enjoyed this article.

Thank you, David Annis Former CIO.