By Keli Johnson Swan
Scott & Scott

Responding to a software audit can be an arduous, expensive, and time-consuming process for a company. The remediation process to close compliance gaps may vary slightly depending on whether the audit is initiated the software publisher itself or outsourced to an agency such as BSA| The Software Alliance (“BSA”) or the Software & Industry Information Association (“SIIA”).

Because many companies are weary from the time and expense incurred during the course of the audit, some do not take the remediation process seriously. The following are tips for remediation to ensure the post-settlement obligations are met and the release of liability is secured.

1) Determine the best license for each use case. Smaller companies prefer to purchase original equipment manufactuer (“OEM”) licenses for operating systems and other software on a case-by-case basis. However, larger corporations may choose to take advantage of bulk purchases by entering into site or enterprise agreements directly with the software publisher, which may offers discounts and other benefits. Regardless of which purchase option a company uses, it is important to ensure that each license covers the specific use case for the installed software.

2) Ensure subscription software is renewed. Some software publishers are moving to a subscription licensing model instead of a perpetual license. A perpetual license grants a user the right to use the software forever, as long as it is in accordance with the license agreement. However, a subscription typically must be maintained in order to continue to use the software. If a company misses a renewal, it may create a compliance gap if the user continues to install and use the software. There are very few instances (such as some Microsoft developer licenses) that allow the software to continue to be used after the subscription expires, but generally all subscriptions must be active in order to be compliant with the license agreement.

3) Avoid cutting corners and purchasing discounted software. A sizeable portion of software sold on online auction sites is not legitimate. Software auditors typically assume that all software sold for less than 90% of its MSRP value is counterfeit or being illegally sold or transferred. It is important to purchase from reputable, authorized resellers in order to avoid paying additional penalties in future audits. Some software publishers offer a list of authorized vendors on their web sites.

These are just a few issues to consider when completing post-audit software remediation. It is crucial to properly remediate any compliance gaps to secure the release of liability and protect against future audits. If in doubt, contact an attorney experienced in software licensing and copyright infringement matters.

Software attorney Robert J. Scott will give real world examples of what happens when software audits wind up in court when he presents a 60-minute  complimentary webinar Wednesday, Nov. 2, 2016, beginning at 11 a.m. CST.

“Software audits have become routine as publishers have proven that compliance claims get customers’ attention more than sales proposals,” Scott & Scott LLP says on its website. “Most software license disputes are settled out of court, but what happens when you cannot negotiate a settlement with the publisher or one of its trade associations (BSA | The Software Alliance, The Software & Information Industry Association) because the settlement demands are too high? Software attorney Robert J. Scott will give real world examples of what happens when software audits wind up in court.”

In this session attendees will learn the following issues:

• Use of declaratory judgment actions
• Venue rules for copyright cases
• Choice of law issues
• Calculation of damages under copyright laws
• Individual liability for copyright infringement
• Burden shifting in copyright cases
• Electronic discovery issues
• Mediation strategy

Register for the webinar.

By Keli Johnson Swan
Scott & Scott LLP

In a civil copyright infringement claim, many users of copyrighted material are surprised to learn that once the copyright owner has demonstrated that it owns a copyright in the work, the burden shifts to the copyright user to demonstrate that it had the right to use the work in the way it was using it. For copyrighted software use, this means that not only must the user have a valid license, the use case must fall within the scope of the license terms. Software publishers actively protect their copyrighted material by pursuing audits of its consumers either directly or through entities such as BSA|The Software Alliance, or the Software & Information Industry Association (“SIIA”).

There are two vital steps to proving a consumer is innocent of copyright infringement.

1. Providing proof of purchase documentation for the license.

The license agreement itself often provides the authority for the publishers to audit any consumer of its product, but there are usually little or no guidance in the license agreement for what proof will be acceptable in a license review. This is further complicated by the fact that the BSA and SIIA issue their own set of audit standards when investigating potential compliance gaps.

In order to demonstrate a license to use software that is acceptable to the BSA and SIIA in an audit, the consumer must provide a copy of an entitlement that shows the date purchased, price paid, software version and title, quantity, and the company name. Many consumers do not keep accurate records of software purchases, particularly for products that are very old. The auditing entity will presume there is no license unless the user can provide documentation of its license, regardless of the age of the software installed.

However, there are different types of documentation that may be used to prove ownership of a license, including, but not limited to:

a. Customer purchase history reports from vendors such as CDW and Dell;
b. Dell Service Tag Reports;
c. E-mail confirmations for software purchases;
d. Microsoft Licensing Statement;
e. Adobe Licensing Statement;
f. Autodesk Licensing Statement;
g. Software publisher agreements (ex. Microsoft EA);
h. Autodesk serial numbers (if registered correctly);
i. Hardware purchases with OEM operating systems or Microsoft Office software; or
j. Software registration confirmations.
It is always helpful to acquire a report from a vendor if possible to acquire a purchase history, or alternatively, a licensing statement from the publisher itself.

2. Demonstrating compliance with license terms.

In addition to providing evidence its licenses, a consumer often must demonstrate that it has complied with the terms of the license agreement for the software installed. For example, some Home or Student versions software specifically restricts commercial use, so if a business has these versions installed and is using it to generate revenue, the license is invalid because the use case is outside the scope of the license grant.

There are more complicated use cases that also violate the terms of license agreements, ranging from geographic restrictions, installing software on affiliate or related entities’ machines without approval, installing software on servers, or installing software on hosted servers without the appropriate licenses.

In order to avoid potential copyright infringement claims and monetary penalties, it is prudent for consumers to conduct regular internal audits, consistently retain all software purchase records, and closely evaluate the use cases to ensure compliance with the relevant license agreements.

By Stephen F. Pinson
Scott & Scott, LLP

In a previous blog, I spoke about what an indemnification provision is and how it operates. In this blog, I will discuss questions that licensors and licensees should ask when negotiating an indemnification provision within a software contract: (1) what are the licensor’s objectives in the indemnification section, (2) what are licensee’s objectives in the indemnification section, (3) what is a checklist of elements and questions that should be negotiated in a indemnification section, and (4) what is a general checklist of provisions that should be included in a indemnification section.

(1) Licensor’s objectives in an indemnification section

The licensor’s (software vendor) objective is to protect itself from any claims resulting from the licensee (business) from breaching the license grant. For example, if the licensee modifies the software contrary to the license grant, then the software vendor may be exposed to third-party claims. The licensor often will seek indemnification from those types of claims through the indemnity clause called “IP Indemnity.”

On the other hand, another objective of the licensor is to indemnify the least amount of loss or liability possible. For some contracts, and indemnification section will not exist for a licensor to indemnify, and for others it will be detailed and extensively negotiated. Usually, a licensor at the very minimum will indemnify for intellectual property infringement for its own liability.

(2) Licensee’s objectives in an indemnification section

Alternatively, the licensee is looking to be protected from third-party lawsuits for intellectual property infringement resulting from a situation where the licensor has intellectual property (typically software code) that infringes on the property of someone else (third-party claimant). In this scenario, the licensee is also infringing on the rights of the third party and can be sued for infringement. For this reason, the licensee would want to seek protections in the indemnification provision.

(3) Checklist of questions that should be asked when negotiating a warranty section on performance warranties:</bold

Consider the following negotiation elements when drafting, negotiating or entering into a contract with an indemnity provision:
1. Applicability – Who is indemnifying whom? Is the indemnification mutual or unilateral?
2. Scope of Indemnity – What is the scope of the indemnification? Will the Indemnitor indemnify/reimburse for losses, defend (a duty to provide a defense), or hold harmless (bar claims against the Indemnitee)?
3.Nature of covered claims – What risks of doing business under the contract are being indemnified, i.e., inter-party claims based on breach of representation, warranty, or other contractual obligation, third party claims based on product liability, infringement, fraud, or negligence, governmental claims based on regulatory matters, or other specified claims such as: personal injury, property damage, economic loss, and attorneys’ fees and costs of defense?
4. Exceptions – Are there any exceptions to indemnification such as taking control of the claim? Or not causing the indemnifying circumstances such as not modifying code?
5. Limitations – Should there be a monetary limit on the extent of the indemnity? If so, the limitation should bear a reasonable commercial relationship to the contract. Is there a limitation as to the time a party can bring an indemnification claims (i.e., within a 6 months, 1 year, etc.)? Is there a limitation on the amount that can be recovered for an indemnified claim in the Limitation of Liability (i.e., preferably a licensee will want an exclusion where the limitation of liability does not apply and damages are uncapped)? Or, does the contract include a provision requiring coverage of certain risks by insurance such that the indemnity is limited to the amount of the insurance coverage (i.e. contractual liability insurance)?
6. Procedure – Does the indemnity provision specific procedural requirements for recovery, like submitting a claim within a certain time period, of follow certain procedures to submit a claim for Indemnitee? Is there a duty to mitigate any portion of the claim before submitting it to the Indemnitor?
7. Exclusivity of remedies – Do the terms of the contract determine whether the Indemnitor is obligated to reimburse the Indemnitee for a particular claim, and if so, when? Does the contract clearly express an intent to indemnify a party against its own negligence, and if so does it make sense under the circumstances?
8. Review other corresponding provisions in the contract – Does the indemnification provision harmonize with the warranty and limitation of liability section in the contract? Does the insurance section of the contract harmonize with the indemnity section? Are there enough insurance limits for this type of claim scenario for the licensor? Is the limitation of liability uncapped for intellectual property claims for the licensee?

(4) Provisions that should be included in a typical Indemnification section:
Licensor Provisions:
Licensor will defend, indemnify and hold harmless licensee for third party intellectual property infringement.
Licensor will pay all costs and damages awarded.
Conditions – Licensor’s obligations for indemnification are conditioned on the following:
(a) Licensee notifying Licensor promptly in writing of such action.
(b) Licensee giving Licensor sole control of the defense or settlement thereof.
(c) Licensee cooperating with Licensor in such defense.
Exclusions – Licensor will have no liability if the following occurs:
(a) any use of the Software not in accordance with the Agreement
(b) any modification of the Software made by any person other than Licensor.
Entire Liability – This is the entire liability of licensor and exclusive remedy.

Licensee Provisions:

Licensor will defend, indemnify and hold harmless licensee for third party intellectual property infringement.
If Licensee’s continued use of the Software is restricted or prohibited as a result of any such infringement, Licensor shall, at Licensee’s option and at no charge to Licensee:
(a) secure for Licensee the right to continue using the Software
(b) modify or replace the infringing components of the Software so that they are non-infringing
(c) refund to Licensee all amounts paid by Licensee for the Software.
Exclusions – Licensor will not be obligated to indemnify Licensee to the extent of the infringement claim based upon:
(a) use of the Software in breach of this Agreement
(b) any modification of the Software made by Licensee (other than at Licensor’s direction)
Defense of Third-Party Suits – Licensee will notify Licensor of third party suits promptly. If licensee tenders claim to Licensor, Licensor will have right and obligation to defend such claim. Once Licensor assumes defense of a Claim, it will be conclusively presumed that Licensor is obligated to indemnify Licensee. No settlement of a Claim will be binding on Licensee without Licensee’s prior written consent

*This is not an exhaustive list of provisions

Remember, an indemnification section is a specialized risk transfer section within a software contract. It is crucial to understand it and to successfully negotiate it to prevent unwanted risk. It is always important to seek advice from experienced legal counsel in order to understand all the risks involved when negotiating these types of provisions in a software contract.

By Christopher Barnett
Scott & Scott LLP

On July 28, Oracle announced that it had entered into an agreement to acquire NetSuite for approximately $9.3 billion. NetSuite was founded in 1998 and is one of the very first, enterprise-level, cloud-services providers, delivering various, hosted enterprise resource planning (ERP), customer relationship management (CRM), e-commerce and professional services automation (PSA) solutions to its customers.

Oracle and NetSuite have a long relationship, though that relationship in the past may not have been apparent to NetSuite’s customers. Early in its history, NetSuite received $125 million in initial financial backing from Oracle founder Larry Ellison, and the Ellison family owned nearly half of NetSuite’s common stock as of 2014. NetSuite also traditionally has been based on an infrastructure that is reliant on Oracle Database.

However, with Oracle now set to formally acquire the company, NetSuite’s customers soon may notice some pretty significant changes, at least on the purchasing and contracting side. Oracle sells its existing cloud services generally subject either to its standard-form Cloud Services Agreement (CSA) or to a cloud-services schedule to its standard-form Master Agreement (OMA). Both the CSA and the OMA contain terms that are notoriously pro-Oracle in many important respects, including confidentiality protections, limitations of liability and audits. By contrast, NetSuite’s current Terms of Service document takes a more balanced approach, including:

• Identifying all electronic data or information submitted to and stored in the NetSuite service as “Confidential Information,” subject to the agreement’s non-disclosure provisions.
• Excluding indemnification obligations from the agreement’s limitation of liability and subjecting confidentiality claims to double the monetary liability cap applied to other kinds of claims.
• No audit rights in favor of NetSuite.

Once NetSuite’s formal assimilation into Oracle’s cloud services business is complete, we would expect to see Oracle insist on applying the standard-form CSA or OMA to new or extended NetSuite service orders.

Current NetSuite customers therefore should work closely with their legal counsel to scrutinize the terms of their current NetSuite agreements in advance of any new or renewal NetSuite orders. Those efforts will better equip them to seek appropriate amendments to the CSA or the OMA in the event that Oracle refuses to process the orders under the legacy agreements. In addition, companies that may be considering getting started with NetSuite in the future may want to consider saving a copy of the current NetSuite Terms of Service (available publicly with other, service-specific terms at the above link), so that they can remain mindful of the terms that have historically applied to NetSuite’s offerings.

Regardless of whether the publisher is Microsoft, Adobe, Autodesk, Oracle, IBM or any of their trade groups including the BSA | The Software Alliance, Robert Scott of Scott & Scott LLP sees common issues.

In a new online publication, he identifies some of those common issues, which include audit effective date, scope, discovering the installations, identifying proof of licenses, interim confidentiality / 408 agreements, calculating financial exposure, what constitutes a good settlement, and confidentiality.

On the issue of scope, Scott writes: “Narrowing the scope of a requested audit is one of my first priorities in a software audit case. I like to think of scope in a number of different ways all with an eye toward narrowing the number of devices to be investigated as much as possible at the outset of the case. Scope limitations could be to certain business units or affiliates, certain geographic locations, certain products, certain purchasing agreements. Winning the scope battle is an early success factor in an audit case.”

Read the article.

By Stephen F. Pinson
Scott & Scott, LLP

Indemnification is a very important provision in a software agreement. It transfers legal risk between contracting parties, and the indemnification provision acts like an insurance policy for future lawsuits where a contracting party is sued by a third-party to the contract. Because this provision is a risk transfer mechanism, it is crucial to understand it and to successfully negotiate it to prevent unwanted risk.

Before we jump into how to negotiate an indemnification provision, there are some basic definitions that need to be understood:

• An Indemnitee is a contracting party who is entitled to be indemnified.
• On the other hand, an Indemnitor promises to defend, indemnify, and hold harmless the Indemnitee against liability from a third person, or against loss resulting from liability.
• A third-party is a person or entity that is not a party to the original contact, but who sues one of the contracting parties.

So how does an indemnification provision operate? Typically, an indemnification provision is triggered when a third-party to the contract brings a claim against one of the contracting parties (i.e., contracting party vs. third-party claimant). Very rarely, is it triggered when there is a direct party claim (i.e., contracting party vs. contracting party). At its core, an indemnification provision allows the party who is responsible for liability (the Indemnitee) to transfer his loss or liability to another party who will represent them in court (the Indemnitor), and pick up the litigation costs and liability from a third-party who bring a lawsuit against the Indemnitee.

One of the major pitfalls in negotiating an indemnification section is contained in the structure of the contract provision itself and the intent of the software licensor. Many contracts include boilerplate language, thus, contract negotiators must develop a systematic way to review the language and then develop a strategy to address the indemnification section for their side of the deal. To do this, the parties must first understand the risks involved with a particular software license and negotiate for the specific risk type.

The best way to put this into action is to review the indemnification section and put the language into more concrete roadmap to negotiate the contract by asking the following questions: (1) what are the licensor’s objectives in the indemnification section, (2) what are licensee’s objectives in the indemnification section, (3) what is a checklist of elements and questions that should be negotiated in a indemnification section, and (4) what is a general checklist of provisions that should be included in a indemnification section.

I will discuss each one of these questions in upcoming blogs.

Remember, an indemnification section is a specialized risk transfer section of a software contract. It is crucial to understand it and to successfully negotiate it to prevent unwanted risk. It is always important to seek advice from experienced legal counsel in order to understand all the risks involved when negotiating these types of provisions in a software contract.

Anyone who has purchased a product online or downloaded software for a computer, tablet or mobile device has likely encountered “browsewrap” and “clickwrap” agreements, write Carolyn S. Toto and Kimberly Buffington on Pillsbury Winthrop Shaw Pittman‘s Social Media & Games Law Blog.

In the article, they write, “Such agreements are the bread and butter of companies that sell or license products or provide services via websites or web applications. Clickwrap agreements require a user to affirmatively click a button to affirm his or her assent to the agreement’s terms, whereas with a browsewrap agreement, the user’s assent to the agreement’s terms is inferred from the user’s use of the website. (Often, the terms of a browsewrap agreement are accessible from a hyperlink placed on one or more webpages of the company’s website.)”

The discuss a few recent cases that have addressed what exactly constitutes a valid, legally binding and enforceable contract.

Read the article.

By Keli Johnson Swan
Scott & Scott LLP

Photo by Lending Memo

Sometimes a company receives notices of audits from many publishers or trade associations at the same time. Often this is because multiple agencies have received confidential reports from the same informant. If a current or previous employee contacts both the Software & Information Industry Association (“SIIA”) and BSA|The Software Alliance (“BSA”), the company may face an audit from both of these entities at the same time, or in close proximity to one another.

Once a software audit inquiry is initiated, it can be difficult to convince the auditor to disengage. However, there are a few important tips to cope with an SIIA audit after a BSA audit.

1.Identify the date of the request
Typically, the first entity to request an audit has priority over the second. Therefore, if you receive a BSA audit demand prior to the SIIA audit demand, you may request that the SIIA stand down while you complete the initial audit.

2. Identify the software publishers involved
While the SIIA may be convinced to disengage from auditing any overlapping software publishers, the attorney representing the SIIA may insist on a concurrent audit of any software publishers that are not BSA members.

The initial audit letter from both the BSA and SIIA should identify which software publishers are within the scope of the audit. It is crucial to compare the letters and determine which, if any, publishers overlap and request that these are excluded from the second audit.

3. Get a release of liability from the original audit
The most important provision in a settlement agreement to resolve copyright infringement claims is the release of liability provision. In the event that a company determines that it has a license deficiency for any software products and is required to pay a penalty for alleged copyright infringement, it is critical that the company obtains a release of liability for all deficient software.

This provision will prevent the second auditors from seeking damages for the same software installations. If in doubt, a company should retain counsel experienced in resolving and negotiating software audits.

Google won a jury verdict that ends Oracle’s claim to a $9 billion slice of the search giant’s Android phone business, reports The Washington Post.

“Oracle contended that Google needed a license to use its Java programming language to develop Android, the operating system in 80 percent of the world’s mobile devices,” writes Joel Rosenblatt. “Jurors in a federal court in San Francisco rejected that argument Thursday and concluded that Google made fair use of the code under copyright law.”

Stakes were high for Google. A loss could have given more weight to software copyrights and to spur litigation to protect those added rights. “Oracle — which started the trial at an advantage with the judge explaining that it had already been established that Google had infringed Oracle’s copyrights — plans to appeal, although legal experts said overturning a jury verdict will be difficult,” according to the report.

Read the article.

By Christopher Barnett
Scott & Scott LLP

Most software audits pertaining to products licensed under perpetual licenses (such as licenses acquired under a Microsoft Select Agreement, MPSA or (usually) Enterprise Agreement) incorporate a snapshot-in-time approach, where licenses owned generally are compared to deployments identified through data collected about current-state product deployments. In contrast, audits pertaining to products licensed under a Microsoft Services Provider License Agreement (SPLA) incorporate a strong historical-use element. Since SPLA pricing is based on a monthly reporting model, SPLA audits look at historical usage during the period covered by an audit (often, three years or more), and then compare that historical usage to a licensees’ historical usage reports.

And that historical-usage element is where almost all SPLA licensees routinely fall short.

Most companies licensing software under SPLA simply do not keep records regarding their usage quantities for past months. Microsoft’s license agreements typically contain requirements to “keep accurate and complete records relating to all use and distribution” of Microsoft’s software, but most businesses simply do not make the connection between that obligation and their monthly reporting procedures. As a result, there is a gaping hole in data collection for most SPLA audits.

The SPLA gives Microsoft the right to presume that unreported use identified during an audit month began at the commencement of the end-user relationships associated with that unreported use, unless a licensee can reasonably demonstrate a different scope and duration. This is where an element of creativity often can bridge the gap to a successful SPLA-audit resolution.

In the absence of historical data, Microsoft and its auditors often are willing to consider alternative approaches for estimating historical usage. For example, if the missing historical data pertain to products licensed per user, then one option could be to estimate changes in user license requirements over time based on changes in the licensee’s monthly revenue for the corresponding period. Alternatively, it may be appropriate to estimate historical usage by comparing usage to reporting for the audited month, and then applying the same ratio to reported quantities for previous months. User account creation dates also often are a relevant data point for these purposes.

For products licensed per processor or per core, it often makes sense to use a combination of resource-creation dates and records regarding past changes to the environment. For example, if the licensee can demonstrate through e-mails or other sources of information when it deployed additional infrastructure or server products over time, those records may be used to identify the earliest dates for which certain products should have been reported during the audit period.

In our experience, Microsoft’s auditors often are willing to consider different sources of information, but their preference always will be for the explanations that are supported by the most evidence. The stronger the factual basis for arguing in favor of a particular outcome, the better the odds of a successful resolution. In contrast, the more a licensee effectively asks Microsoft to trust it regarding past usage, the more doubtful those odds become.

Of course, the very best way to address the risks associated with SPLA audits is to plan for them. A standard part of any SPLA licensee’s reporting procedures should be to save an archive of historical usage reports generated by auditable inventory tools. For software and hardware deployments, those tools include System Center, MAP Toolkit, and Lansweeper, among others. Additional sources of information include RVTools (for VMware virtualization data) and Active Directory queries (for information regarding the Organizational Units and Security Groups to which authorized users belong). Well prepared SPLA licensees should be in the habit of preparing their monthly reports accurately and on time based on up-to-date deployment information and then saving that information every month, so that it never becomes necessary to determine the most appropriate, creative approach for filling data gaps.

By Keli Johnson Swan
Scott & Scott LLP

Companies with complex corporate structures sometimes encounter difficulties with properly licensing software for all of the related entities, affiliates, and subsidiaries, even if a software asset management program is in place. Even if a company purchases all necessary licenses for its affiliates or subsidiaries, it is possible that a software publisher may make a claim of copyright infringement if the license agreement does not allow sharing or transferring licenses between entities. Even when companies have central procurement departments to acquire and license software, there are still potential risks.

Some software license agreement terms specifically prohibit sharing software across entities without permission from the publisher. For example, Autodesk’s current License and Services Agreement specifically prevents a company from sharing licenses with subsidiaries and affiliates. Other software publishers’ license agreements contain similar provisions.

If a company needs to have the ability to share licenses across legal entities, the company must review the software license agreement and determine whether the company may share licenses between its affiliates. If not, the next step is to negotiate the language for affiliates and subsidiaries into the appropriate license or services agreement.

Companies that enter into more complex agreements with software publishers potentially have the bargaining power to specifically define the “customer” or “licensee” to include affiliates, joint ventures, and subsidiaries. The definitions section of a license agreement is very important in determining whether the company may share licenses.

Additionally, it is important to identify whether any geographical restrictions prevent licensing sharing between other entities. Some software is restricted for use in the territory it was purchased, which may be problematic for global corporations.

Although many software vendors now offer services for software asset management, it is important to consult with legal counsel experienced in technology and software licensing to navigate complex licensing agreements.

By Christopher Barnett
Scott & Scott LLP

Recent weeks have seen a number of news reports and announcements indicating that the Next Big Thing for audits – financial audits, at least, for the time being – is the use of artificial intelligence technologies to facilitate the analysis of large volumes of data in the context of audit-related activities. KPMG’s recent announcement was particularly noteworthy from my perspective, because it indicated that the audit firm would be deploying IBM’s Watson “cognitive computing technology” to KPMG’s professional services offerings. According to the announcement:

One current initiative is focused on employing supervised cognitive capabilities to analyze much larger volumes of structured and unstructured data related to a company’s financial information, as auditors ‘teach’ the technology how to fine-tune assessments over time. This enables audit teams to have faster access to increasingly precise measurements that help them analyze anomalies and assess whether additional steps are necessary.

IBM is, of course, one of KPMG’s biggest software-auditing clients. Big Blue regularly entrusts enterprise-level audit projects to the firm for project-management, data-collection and data-analysis responsibilities.

All of these recent reports mention that the AI technologies currently are being contemplated for use in connection with financial audits. However, it is not at all difficult to imagine the same or similar tools being put into use in connection with software audits, which for larger organizations also can require auditors to process vast quantities of deployment and usage information. In that context, KPMG’s and IBM’s announcement is potentially troubling.

Auditors like KPMG and Deloitte typically characterize their roles in software audits as being independent collectors and analyzers of data. From this writer’s past experience, such assurances do not always seem to align with the standard operating procedures for many audits, where doubts of all degrees almost always are resolved in favor of the software publishers paying the auditors’ bills. However, that concern would be compounded if, in the future, auditors were to merely feed deployment data into an AI tool developed by the publisher of the products being audited and to then transmit the output to IBM. Under those circumstances, the auditors arguably would be nothing more than project planners and button-pushers.

Furthermore, we increasingly are seeing auditors insist on broad rights to “access” their customers’ computers during audits, and we also have started to see indications that some publishers may be moving toward requiring the use of specific tools to measure usage during audits. Companies need to realize that any such access or tool-deployment rights in publishers’ favor almost certainly would run counter to licensees’ best interests. Such terms must be avoided at all costs.

It will be very interesting to see in coming years how new developments in technology change the scope of software audits and processes they entail.

One of the most critical and important contracts a startup can focus on, and do correctly, is to properly license IP from a university so that it can be commercialized going forward, according to a video prepared by Peter Buckland of Wilmer Cutler Pickering Hale and Dorr LLP.

He explains that a common question he hears from entrepreneurs is about how to work with technology that they created at their universities, going forward in a commercial endeavor.

“In most cases, anyone that is in anyway being paid by a university to do research, the university owns that research and for many of the universities we work with in this area, whether it’s Stanford or Cal or others, they’re all pretty in tune with their mandate, which is to commercialize that technology,” he says in the video. And the best way to do that, he adds, is to partner with the people who created that technology.

Watch the video.

By Christopher Barnett
Scott & Scott LLP

Companies that have long relationships with Microsoft know that the company’s form licensing agreements have steadily evolved over time, and typically for the worse. If software licensing can be said to have any “natural laws,” certainly the First Law could be paraphrased to something like: “If you agree to an inch, be prepared to give a mile.” So it is with Microsoft’s standard-form Services Provider License Agreement (SPLA).

The most recent iterations of the SPLA include a handful of noteworthy changes, relative to the forms that many current SPLA licensees may have signed at the beginning of their relationships with Microsoft. Those changes include the following:

• End User License Terms (EULTs) now apply to all end users.
  In the past, the EULTs – a form end-user license agreement for SPLA providers to include in their customer contracts – were necessary only in connection with services that included Client Software or Redistribution Software. All other end user agreements needed to include terms that aligned with a laundry list of requirements that was set forth in the SPLA. The laundry list now is gone, and all end user agreements now must incorporate the EULTs. As a result, all SPLA providers will need to be familiar with the EULTs and will need to be prepared to incorporate them into their customer agreements.
• No limitation of liability when defending Microsoft.
  The new SPLA now expressly provides that the standard, mutual limitation-of-liability included in the Microsoft Business and Services Agreement (the master agreement to which the SPLA is attached) no longer applies to a licensee’s duty to defend Microsoft against certain third-party claims. Thus, a SPLA licensee could have effectively unlimited exposure arising from such claims. That state of affairs may be inconsistent with a licensee’s internal insurance or risk-management policies.
• Extensive new audit rights for Microsoft.
  The most troubling new developments pertain to audits. The audit clauses in all of Microsoft’s license agreements has become more and more burdensome for licensees over recent years, and the new SPLA forms are no exception. Past SPLAs said very little regarding audits, leaving most of the parties’ audit-related obligations to be defined by the MBSA. However, the new forms contain language broadly obligating licensees to provide Microsoft’s software auditors with “access to all servers running the Products,” without defining what that “access” entails. In addition, in some forms Microsoft has incorporated extensive, new provisions related to “anti-corruption” policies, recordkeeping and audits. Those anti-corruption audits theoretically would be limited to confirming a licensee’s compliance with the new SPLA’s anti-corruption requirements. However, those requirements include an obligation to maintain an accounting system that would enable Microsoft to probe every aspect of a licensee’s finances related to SPLA.

Prospective and renewal SPLA licensees with bargaining power should seriously consider mounting a determined effort to seek appropriate amendments to the above (and other) terms in the new SPLA form. Absent appropriate amendments, companies providing hosting services may want to think about organizing their infrastructures and business models to minimize or eliminate their reliance on SPLA licensing.

By Stephen Pinson
Scott & Scott, LLP

Limitation of Liability ranks as one of the most important contract provisions in a software contract. The limitation of liability limits each party’s liability for all sorts of harm. A software provider’s liability is usually limited to the amount of fees paid to the vendor or a fraction thereof. The risk in not negotiating these terms is that the licensee is capped at the amount of damages. A “cap” is the aggregate upper limit for direct damages associated with a party’s liability. The cap on liability can be a specific dollar amount, but in many contracts the “cap” is tied to the amounts paid for the products or services purchased. This cap may not equate to the actual amount of harm of the licensee. Therefore, successfully negotiating a limitation of liability becomes the key point in finalizing the contract. But, what exactly are the pitfalls when negotiating a limitation of liability, and how do you successfully navigate them?

One of the major pitfalls in negotiating a limitation of liability is contained in the structure of the contract provision. Many contracts include boilerplate limitation of liability language. Thus, contract negotiators must develop a systematic way to review the language and then develop a strategy to address the liability concerns for their side of the deal. To do this, the parties must first understand the risks involved with a particular deal and negotiate for the specific risk type.

The best way to put this into action is to review the boilerplate language and put the language into more concrete roadmap to negotiate the contract by asking the following questions: (1) what damage provisions are typically included in the limitation of liability, (2) what damages will be capped, (3) what claims will be carved-out of the contract (or excluded from the limitation of liability) that will not have a cap, and (4) what type of insurance should be negotiated.

Included and Excluded Provisions:

The following is a list of commonly included “boilerplate” exclusion of damages language in a limitation of liability section of a contract:

* Incidental damages
*Special damages
*Consequential damages
*Exemplary Damages
*Punitive Damages
*Loss of use, data, profits, business, goodwill, or opportunity costs
*Computer failure or malfunction
*Costs, expenses or other losses

Capped & Uncapped Damages:

The following is a brief list of common limitation of liability damages, and whether they are capped, uncapped, or subject to insurance from the perspective of the software publisher.

*Negligence – Capped
*Personal injury – Not Capped
*Physical property damage – Insurance coverage
*Lost Data subject to failure of adequately having an onsite backup solution – Capped
*Lost profits – Capped
*Lost revenue – Capped
*Consequential damages – Capped
*Infringement of intellectual property – Not capped because they are considered direct damages
*Gross Negligence, willful misconduct, and fraud – Not Capped

Carve-outs:

For those damages that are considered capped to the amount of products of services offered, a successful negotiator will seek to carve these provisions out of the contract by making exceptions to the limitation of liability, making them subject to insurance for different claims scenarios:

*Breach of obligations to comply with laws
*Breach of the parties confidentiality or confidential information / materials
*Breach of data security or privacy obligations
*Indemnification obligations
*Intellectual property infringement
*Gross negligence, willful misconduct, and fraud
*Violations of certain terms to the agreement or payment schedules
*Claims subject to insurance
*Claims for death or personal injury
*Any other forms of liability which by law cannot be limited or excluded

Insurance:

The following is a brief list of insurance provisions that could be negotiated in a software or services contract in excess of the cap for the different types of claims scenarios. Individual and aggregate limits must be negotiated for the types of risks involved:

*Automobile Liability
*General Commercial Liability
*Umbrella Liability Insurance
*Workers’ Compensation
*Employer’s Liability Limits
*Network Security and Privacy Liability
*Professional Liability Insurance, Errors and Omissions, including Cyber Liability
*Data Breach, Data Loss, Regulatory Response
*Evidence of Insurance Policies

Remember, it is always important to seek advice from experienced counsel when negotiating a limitation of liability provision in software and service contracts to make sure the risks are adequately assessed and your interests are protected.

By Keli Johnson Swan
Scott & Scott LLP

Autodesk, like many other software publishers, is now offering subscription-based licenses instead of perpetual licenses. Customers tend to find the flexibility of subscription-based licensing appealing because those licenses allow for growth and changing work environments.

However, the license terms have specific conditions and requirements for installation and use of the software, specifically related to the rights to use older versions. The following are a few helpful suggestions to ensure that the software remains properly licensed and in compliance with the Previous Version Rights pursuant to the subscription license agreement.

1. Downgrades are limited to specific versions.

There are two ways to qualify for downgrade rights – a subscription license or purchasing Autodesk maintenance. Since Autodesk is gradually moving toward a subscription-only model for many of its products and phasing out maintenance, it is important to understand subscription licensing requirements in order to avoid any potential copyright infringement claims relating to noncompliance.

Autodesk provides a specific list of the prior versions eligible for downgrade rights, which may be found here. If a customer chooses to install a prior version and does not have maintenance or a perpetual license for the older version, the version installed must be on the list issued by Autodesk.

2. Specific serial numbers are required to install prior versions.

Once a customer identifies that a prior version is eligible for installation, it must obtain through its Autodesk account a previous version serial number. This is important because if a customer is faced with an audit, it must have the correct serial number for the prior version or risk incurring a penalty for noncompliance.

3. Maintain an accurate inventory of the serial numbers and versions installed to avoid noncompliance issues during an audit.

Routine self-audits should be administered periodically to uninstall any prior versions for which a customer no longer has a license. These installations should be identified and checked against Autodesk’s current list of eligible software for downgrades. Additionally, it is important for the customer to ensure that it obtains the proper serial numbers for each previous version of Autodesk products installed.

Even if a customer owns a license and has the right to downgrade the software, without the proper serial number, Autodesk may seek monetary damages and claim copyright infringement violations. Customers should familiarize themselves with Autodesk’s most recent license requirements in order to avoid any potential copyright infringement claims.

While everyone knows of the need to comply with contractual terms in software licenses (and elsewhere), the salient point in this context, is that under several recent cases, failure to do so with respect to a license for copyrighted  material (which is usually applicable to software), allows the pursuit in federal court for claims for infringement damages under the Copyright Act and related items, such as attorney fees, according to an article from FisherBroyles and published on Lexology.com.

“This is in addition to traditional contract damages, which may be non-existent or difficult to prove,” the article says.

Kimberly Dempsey Booher, Susan M. Freedman, R. Mark Halligan, Martin B. Robins and Alan S. Wernick contributed to the article.

Read the article.

In a Scott &amp; Scott webinar, partner Julie Machal-Fulks will discuss some of the challenges that organizations encounter when trying to ensure compliance with their IBM license agreements. The one-hour event will be Wednesday, Jan. 20, 2016, beginning at 11 a.m. CST.

Because IBM products like WebSphere, DB2, Tivoli, Informix, and Lotus Notes are expensive, and companies cannot easily or quickly verify compliance, the risks associated with IBM licensing can be severe, the firm says. For example, if a company is trying to license under IBM’s Sub-Capacity license rules and fails to adhere to all of the requirements, IBM often demands enough licenses to cover the full capacity of the computers on which the software is installed.

In some instances, the costs associated with non-compliance can be tens of millions of dollars. Proper licensing is critical to avoid unexpected liabilities.

The following topics will be covered in the webinar:

• Licensing obligations for IBM software
• Determining what agreements govern the relationship
• Sub-Capacity Licensing
• ILMT
• Virtualization and Load Balancing
• How IBM acquisitions affect licensing
• Audits

Register for the webinar.