Black Duck will present a complimentary webinar reviewing the past year’s legal developments in open source software.

The event will be on Wednesday, Jan. 17, 2018, at 11:30 a.m. Eastern time.

Two of the leading open source legal experts, Karen Copenhaver, partner at Choate Hall & Stewart and counsel for the Linux Foundation, and Mark Radcliffe, partner at DLA Piper and general counsel for the Open Source Initiative, will lead the discussion.

This annual review will highlight the most significant legal developments related to open source software in 2017, including:

• Current litigation
• An open source security update
• Blockchain and its forks
• Software Package Data Exchange (SPDX) and OpenChain
• GDPR
• And more

Register for the webinar.

By Christopher Barnett
Scott & Scott LLP

It is common for software solution providers to use third-party products to support the functionalities those providers have developed for their solutions. For example, a network-monitoring solution may incorporate IBM Cognos functionality, or an accounting solution may incorporate a Microsoft SQL Server database. Increasingly, in today’s market, those solutions are hosted over the Internet, and many software publishers maintain licensing models targeted to solution providers operating in that space (such as Microsoft’s Services Provider License Agreement, or SPLA). However, many businesses still prefer on-premises solutions for their business-critical IT solutions, and vendors of those solutions need to be able to accommodate those preferences.

The two principal options for those vendors are:

1. Reselling or otherwise separately procuring on their customers’ behalf the appropriate kind and quantity of licenses to support the third-party software components incorporated in their solutions, and then deploying the solutions and all required third-party components on the customers’ networks, OR

2. Shipping a complete solution to their customers, with all required third-party components embedded at the factory.

In most cases, the first option is relatively simple to incorporate into the procurement process. However, it often may entail more up-front labor and service charges, since the vendor typically will need to support intensively (if not manage) the implementation of all solution components at customers’ locations. For that reason, many vendors are understandably interested in a more turn-key approach, where they can simply ship a packaged product to their customers and then support the implementation remotely. Unfortunately, most off-the-shelf license agreements pertaining to those third-party software components do not allow a solution provider to redistribute the software to end users for a fee. For that, it usually is necessary to enter into a market-specific ISV or royalty agreement.

Under that kind of an agreement, the vendor obtains the right to embed and redistribute specified software components for use in connection with specified solutions, in return for a fee that is typically calculated based on the number of units shipped or the number of users provisioned to use the solution. In theory, that kind of an agreement seems to be reasonable and appropriate, but, as so often is the case, the Devil lurks in the details:

• Narrow Usage Restrictions – In most cases, software licensed under an embedding agreement may be used exclusively in connection with the vendor’s solution and for no other purposes whatsoever. In practice, this may mean that the vendor needs to build its solution to prevent non-compliant usage, which in some cases may be incompatible with how the solution is designed. If that is the case, then the vendor would need to include similarly narrow usage restrictions in its agreements with its customers, and those terms may not be warmly received by prospective customers’ legal departments.

• Defined User Agreements – On that point, the embedding agreements also may include a laundry list of terms that the vendor is required to include in its customer agreements. Those terms almost always are written to be maximally protective of the software publishers’ interests and almost never are particularly palatable to end users. However, absent an amendment to the embedding agreement, the vendors must consider them to be non-negotiable when discussing transactions with new customers.

• Audit Nightmares – Worst of all, many embedding agreements contain audit-rights clauses that give the software publishers not only the right to conduct audits of vendors’ records and facilities, but also the right to audit the vendors’ customers’ compliance with the license terms. Some of those agreements also give the publishers the right to extract licensing fees and audit costs from those customers in the event that non-compliant usage is discovered. In practice, this means that vendors must draft their customer agreements to permit similarly broad and far-reaching audit activity. However, effectively preventing serious or perhaps irreparable damage that could result to the vendor-customer relationship following such an audit is an extremely difficult goal to achieve in any customer agreement.

For all of the above reasons, vendors considering any kind of royalty ISV or other embedding agreement need to carefully scrutinize the terms of such agreements and then carefully consider whether they are willing and capable of satisfying all of the obligations those agreements typically entail. If there is any doubt, it may be far more sensible to undertake a more labor-intensive licensing strategy than to invite the sort of lost business and licensing exposure that can result from non-compliance with controlling agreements.

Christopher Barnett
Scott & Scott

There are many good reasons that businesses often cite in seeking to transition their IT operations to a vendor-delivered Cloud environment.

It’s scalable.

It’s more reliable and secure than what the business may be able to deliver for itself.

It’s (often) cheaper than keeping the environment in-house.

Then there’s this one:

“All I have to do is pay a monthly fee, so no stressing over software-licensing rules.”

Not quite.

In many cases, it is true that, where the vendor is providing licensing for software products to be used in the company’s Cloud, the licensing requirements that are directly applicable to the company may be significantly reduced. Often, the only requirements that remain are things like: “don’t copy or reverse-engineer the hosted software,” or “don’t provide third parties with access to the hosted software.” Pretty easy.

However, even though some of the more technical requirements may no longer be the company’s contractual obligation, the vendor’s failure to adhere to them can cause trouble.

For example, a Cloud vendor may propose offering hosted virtual desktops-as-a-service (DaaS) running the Microsoft Windows operating system. Unfortunately, Microsoft currently offers only two options for DaaS service providers:

1. DaaS through the Microsoft Services Provider License Agreement (SPLA) via the Microsoft Windows Server Operating System, or

2. DaaS through Dedicated Outsourcing using your customer’s Microsoft Volume Licensing agreement.

Option 1 is incompatible with the proposed services, because it entails use of desktop “experience” functionality included in the Windows Server operating system, not the Windows operating system itself. That leaves Option 2. However…

Option 2 also usually is problematic, because “Dedicated Outsourcing” in Microsoft-speak means that the physical server infrastructure used to deliver the DaaS services must be dedicated exclusively to the company receiving those services and must not be used by any other customers of the DaaS vendor. Spinning up one or more new, physical servers for each customer often is something that many DaaS providers simply cannot afford to do.

Of course, if the vendor messes up in licensing its hosting environment, that is primarily going to be the vendor’s problem. When Microsoft discovers the compliance problem, then it likely will look to the vendor to remedy the problem, not to the recipients of the vendor’s services. However, our experience is that SPLA audit exposure in particular can be very significant and occasionally even financially crippling. If a vendor builds a service model around a misunderstanding of fundamental licensing concepts, then the remedy sought by Microsoft following an audit could jeopardize the vendor’s business operations. The result could be a discontinuation of the DaaS services, a need to transition to another provider within a short window, and, potentially, unexpected and permanent service interruption.

Businesses therefore need to develop and to maintain a working knowledge of software-licensing rules, even if they are not going to be directly responsible for adhering to those rules within the context of a hosted-service relationship. Contract language related to warranties, indemnification and limitation of liability may help to mitigate some of the risk associated with inadequately licensed hosting environments, but a better bet would be to go into a vendor relationship knowing that the services to be delivered do not, on their face, violate applicable licensing policies.

Writing a comprehensive software contract is challenging, especially when you’re dealing with a large, complex deployment, writes Paul Korzeniowski in a commentary published by InformationWeek.

“Crafting comprehensive requirement documents, monitoring the licensing terms, and being aware of potential gotchas will help ensure a contract works for you, your business, and the vendor with which you’ve chosen to engage. It’s important for you to start the procurement process by outlining the desired features of a software system in a requirements document. Knowing which features are important to your business, and which are not, is vital to the process,” he explains.

The article describes how CIOs need to understand where potential contract potholes lie and steer around them.

Read the article.

By Christopher Barnett
Scott & Scott LLP

Each of the major software publishers has one or two tricks up its sleeve – tricks that often are missed by licensees – affecting how its server products may be used in virtualized environments. For example, Microsoft SQL Server requires a minimum of four core licenses per vCPU, even if the actual number of vCPUs allocated to a VM is less than four. Oracle offers even more pitfalls for the unwary, in that it strictly – some would say unreasonably – limits and defines the specific virtualization technologies that may be used to license its products based on virtual resources (as opposed to host resources).

Falling somewhere between those two extremes is IBM.

IBM allows a wide array of its products to be licensed on a “sub-capacity” basis, and it also allows for a wide array of virtualization and processor technologies to be used to support sub-capacity-licensed virtualization environments. Moreover, while its Processor Value Unit (PVU) framework entails processor-specific PVU values to be used in licensing calculations, it does not apply an arbitrary minimum number of licenses that must be purchased for VMs as opposed to physical servers.

However, what it does require is that the licensee (1) deploy and use the IBM License Metric Tool (ILMT) in the virtualized environment to measure the resources allocated to the VMs running its products and (2) run at least quarterly reports out of ILMT to track that usage over time. The ILMT requirement is where most businesses get into trouble with IBM’s PVU licensing.

In the face of that failure, it is not uncommon for businesses to try to turn the ILMT requirements against IBM. They may argue that the sub-capacity requirements were not properly incorporated into the agreements or not clearly communicated to the licensee, and, thus, that those requirements do not apply to the licensee. The big problem with this line of argument – other than the facts that IBM would reject it out of hand and that a business would face significant challenges convincing a court to accept it – is that the default licensing requirement for all IBM products licensed based on Value Units, PVUs, or other processor capacities is – and always has been – full capacity. If the sub-capacity requirements in the contract were somehow defective, then the business would be left with no choice other than to license its servers to their full, physical capacities.

Therefore, in the event of an audit, instead of attacking the contracts directly, it makes more sense to look at other aspects of the ILMT-deployment process and the relationship with IBM to see if there may be other defenses against the ILMT requirement. Here are three examples:

(1) It really is IBM’s fault. Sometimes, prior to an audit, a business will have signed an agreement with IBM for implementation services related to one or more sub-capacity-licensed products. If, in that agreement, IBM expressly or even impliedly undertook any responsibility to ensure that the products being deployed were correctly licensed – and then failed to deploy ILMT as part of the implementation project – then it may be possible to obtain a concession with regard to adverse audit findings affecting those products. Again, however, what is typically needed here is an agreement with IBM and not merely an authorized IBM reseller. If a reseller failed to deploy ILMT as part of such a project, IBM may agree to deeper discounts or other pricing concessions during negotiations to resolve the audit findings, but it typically will not agree to concede the findings altogether.

(2) ILMT Does Not Work. ILMT is not an easy product to deploy or to use, and many businesses experience technical problems in attempting to implement it. If an audited company can show that it has tried to use ILMT and has sought assistance in getting the tool to work, then it may be possible to secure concessions with regard to adverse audit findings. However, the likelihood of success for this line of argument will be heavily dependent on the facts of each case. When did the company first try to deploy ILMT? Was it for the complete virtualization environment or just for one IBM product? Was IBM support contacted regarding the problem? What problems were reported regarding ILMT implementation? How diligent has the business been in working with support to resolve the problem? All of the above questions would be relevant to determining whether and to what extent any ILMT-deployment problems could affect the outcome of an IBM audit.

(3) Sub-Capacity Levels Never Were Exceeded. Even if IBM never undertook any responsibilities for ILMT deployment and the licensee wholly failed to even try to install the tool, there is a third, potential option for avoiding adverse audit findings associated with that failure – historical reporting. If the audited business can produce historical, system-generated reports demonstrating (1) that the processor resources allocated to VMs running PVU-licensed products are and have been definitively capped and not subject to any automated augmentations based on system demands, and (ideally) (2) that historical usage of sub-capacity licensed products has not exceeded licensed levels, then it may be possible to avoid adverse findings associated with an ILMT deficiency. However, in our experience, relatively few businesses are able to produce historical reporting that satisfies IBM’s requirements. In addition, even in the best cases, the outcome may be discounts or other pricing concessions and not alterations to the audit findings. Absent a separate agreement signed by IBM, no business should count on any non-ILMT reporting to satisfy IBM as being an acceptable substitute to the ILMT requirement described in IBM’s license agreements.

Finally, it is important to keep in mind that even if any or all of the arguments above is successful, IBM still will insist that the audited company deploy ILMT going forward as a condition of settlement. Thus, if a decision has been made to reject ILMT under any circumstances, it may be necessary to formulate a different strategy for contending with the adverse audit findings.

IBM audits always are very fact-intensive exercises, and no two ever are exactly the same. Companies facing unexpected licensing shortfalls identified during an audit should consult with counsel or knowledgeable licensing advisors to determine whether the above arguments – or any other arguments – may help to mitigate the exposure associated with those shortfalls.

As the year comes to a close, many software publishers and trade associations with calendar year accounting are resolving as many outstanding software audits as possible, writes Keli Johnson Swan in the Software Audit Blog on the website of Scott & Scott. Companies currently engaged in a software audit may be able to negotiate favorable resolutions to their audit matters.

The following are a few tips to reach an amicable resolution by the end of the year:

1) Finalize audit results and locate entitlement information. In many instances, smaller companies that are targets of software audits have trouble dedicating resources to quickly audit its network and obtain proof of purchase documentation. However, if a company is interested in a quick resolution, it may be advantageous to dedicate the necessary resources to finalize the audit now in order to potentially settle by the end of the year.

2) Formulate a settlement strategy. If a company is unable to locate the proof of purchase documentation for all of its software, it will likely be required to pay a penalty for any deficiencies in order to obtain a release of liability from the auditing entity. Once a company receives a settlement demand for the copyright infringement damages, it is important to formulate a strategy with the necessary officers or shareholders in order to enter into negotiations with the auditing entity. Agreeing upon a settlement strategy facilitates negotiations and streamlines the process to reach a quicker resolution.

3) Do not compromise on key issues simply to settle by December 31st. Often software publishers encourage targeted companies to reach a resolution by the end of the year, and may offer purportedly discounted settlement payments. However, it is important to look closely at the terms and the settlement payment in order to avoid agreeing to unfavorable settlement provisions. Some companies chose to forego a confidentiality provision in order to save money on the settlement payment. Often these companies are surprised and dismayed when a press release is issued by the auditing entity, disclosing the terms of settlement and naming the company.

Negotiating a settlement is an important process and it is critical to understand the terms of the agreement. If in doubt, contact an attorney experienced in software licensing and copyright infringement matters.

By Christopher Barnett
Scott & Scott LLP

Microsoft is in the process of transitioning many of its volume-licensing customers from the Select Plus Agreement to the new Microsoft Products and Services Agreement (MPSA). (More information on the transition framework is available here.)

A notable difference between the Select Plus Agreement and the MPSA is that the MPSA is self-contained and is not signed subject to a master agreement, such as a Microsoft Business and Services Agreement (or its predecessor, the Microsoft Business Agreement). Under Select Plus (and still under the Microsoft Enterprise Agreement), most of the important, substantive legal terms associated with the licensing relationship were contained in the MBA/MBSA. Those terms included Microsoft’s duty to defend against certain third-party claims, limitations of liability, and governing law, among others. They also included Microsoft’s audit rights.

Unfortunately for Select Plus customers, though consistent with Microsoft’s notorious habit of steadily making its agreements less and less advantageous for its customers, the audit terms contained in the MPSA are significantly more onerous and markedly less reasonable than were the corresponding terms in past master agreements. A comparison of the MPSA terms to the terms in an MBA (which still remain in effect for many Microsoft customers) reveals the following:

1. Under the MBA, Microsoft could initiate an audit only during the term of a license agreement and for one year thereafter. There is no such limitation in the MPSA. The practical effect of that difference may be somewhat less significant for MPSA customers than it would be, for example, for Enterprise Enrollment customers, since the MPSA has no defined term. Nevertheless, if an MPSA customer were to decide in the future that it wanted to cancel the MPSA, the audit rights in the MPSA would remain in effect in perpetuity. (It is worth mentioning that Microsoft’s current MBSA also contains no time limitation on audits, so Enterprise Agreement customers face the same problem under the default terms.)

2. Under the MBA, Microsoft’s auditors were required to be subject to “a confidentiality obligation.” We often have relied on that language in advising our clients to obtain non-disclosure agreements with auditors before the commencement of audit activity. There is no corresponding language in the body of the MPSA.

3. Under the MBA, Microsoft was required to provide advance notice of audits, which had to be conducted during normal business hours and “in a manner that does not interfere unreasonably with [the customer’s] operations.” There are no such requirements in the body of the MPSA.

4. The MPSA requires the customer to “promptly provide any information reasonably requested by the independent auditors retained by Microsoft in furtherance of the verification, including access to systems running the Products.” There was no such specificity in the MBA, and there certainly was no requirement for the customer to provide “access” to its computer systems. Especially for licensees in heavily regulated industries, that term may conflict directly with applicable obligations related to IT security.

5. The MPSA indicates: “Additional details about the [audit] process are included in the Licensing Manual.” The Licensing Manual is defined as “the statement published by Microsoft (updated from time to time) at the Licensing Site. The Licensing Manual includes details about the processes supporting this Agreement.” The Licensing Manual (currently available here) includes the notice, confidentiality and “unreasonable interference” audit terms that, as noted above, otherwise are missing from the body of the MPSA. However, the MPSA states: “…Microsoft may change the…Licensing Manual from time to time, subject to the terms of this Agreement.” The MPSA does not contain any stated limitations on Microsoft’s right to change the Licensing Manual. Therefore, the durability of the procedural audit protections noted in the MPSA is wholly subject to Microsoft’s discretion.

6. Finally, under the MBA, in the event that “material unlicensed use” was found, the licensee was required to purchase any necessary licenses at retail rates. Under the MPSA, that purchase must be made at 125% of prices then available to the licensee. That upcharge could lead to significantly higher compliance costs following an audit. (Bear in mind that Microsoft typically does not accept uninstalling software as an acceptable remedy for unlicensed usage – license purchases almost always are required.)

In my opinion, the MPSA’s audit language is wholly unacceptable. Before accepting the agreement, my recommendation would be to insist on amendments addressing the above concerns. However, many current Select Plus customers with agreements that now are set to be terminated may find that they have little leverage to demand any changes to the default terms. Since the MPSA does not require a three-year purchasing commitment (like an Enterprise Agreement), Microsoft may have little up-front incentive to negotiate reasonable and appropriate revisions to the agreement terms.

Finally, the above concerns related to audit terms are in addition to indemnification and limitation-of-liability language in the MPSA that also may be inadequate, especially if the customer has plans to invest heavily in Microsoft’s Online Services offerings (e.g., Office 365 and Azure).

Current Select Plus customers need to carefully weigh their licensing needs and alternatives before moving forward with any significant expenditures under an MPSA.