Interestingly, though, there’s also a fair amount of tech company divestiture going on. A good example is eBay’s recent spin-out of PayPal. The former bought the latter for US$1.5 billion in July 2002 — at the time considered a very hefty sum for an online payment company.
Thirteen years later, on its first day of trading as a separate company, PayPal’s shares closed at US$41.63, valuing the company at a cool US$50.8 billion. All that on the strength of 169 million customers in 200 countries.
The rationale for the PayPal divestiture was several-fold, but one important reason was to let the company take flight without being held back by eBay and its different business model. This is a familiar refrain. Years ago IBM spun out Toronto-based Celestica, which is now a global electronics manufacturing company. When it was an IBM division, building hardware products for Big Blue, it tried to secure meaningful manufacturing contracts from IBM’s competitors — but this was difficult to do given the frequent conflicts of interest between the prospective customer and IBM. It was only after Celestica was hived off as a separate entity that it began to undertake work for third parties that simply would not consider becoming customers of IBM.
Today, Celestica is a global custom tech manufacturer, with operations and customers around the world – but its headquarters is still in Toronto. Its spin-out from IBM has been a good news story for the Canadian tech sector.
> Splitting the Business(es)
If the rationale for tech divestiture is usually straightforward, the commercial, legal and contractual dynamics of the spin-out deal can be quite complex. First, there’s the difficult exercise of separating the intellectual property.
Obviously where there are patents or software code that are used exclusively in one or other business, it’s a simple “either/or” decision: whichever post-divestiture entity is the sole user of the particular IP prior to the split simply gets an assignment of it and owns it going forward. So much IP today, however, overlaps both businesses and is used by both. In that case, the ownership is typically lodged with one entity, and the other is granted a sophisticated license. But the licence terms can be tricky.
One sticking point is often the degree of exclusivity in the IP being given to the divested entity by the company keeping ownership. On the one hand, the entity being spun out needs a solid tenure in the IP if it hopes to stand a chance in the harsh light of day of international IP wars (especially in the all important US market, where patents are the thermonuclear weapons of the modern era). On the other hand, the company continuing as the IP owner doesn’t want to inadvertently create a menacing competitor in the former affiliate.
So these licensing negotiations, coupled with complex restrictive covenants, can be finicky indeed. I had one a while back in the so-called “Fintech” space (a contraction for “financial technology” — essentially, tech products and services aimed at facilitating financial transactions). A core definition in the negotiations became “banking,” and one party wanted exclusivity in the “banking sector.” You would think that would be a fairly straightforward matter. Well, you would be wrong.
The term “banking” was fairly straightforward 30 years ago, and was essentially associated with deposit taking institutions. Today? Nowadays it’s a very amorphous concept. For example, if banking includes the transfer of money, which it surely does, then what about all the money transfer services that exist today — are they “banks” as well? You see where this is going. Bottom line, in today’s app-infused business world, particularly in B2C commerce, a phrase like “banking” is actually fiendishly difficult to define for purposes of a post-divestiture non-compete covenant.
> Joint Ownership
Sometimes the entity being divested believes its rationale for owning the applicable software code is as strong as the soon-to-be former affiliate; that is, the entity being spun out is not satisfied merely with a licence (which, after all, is only a contract right and is susceptible to contract breach, and is not as strong or enduring as a property right). As a result, the negotiations drag on, and each side digs in its heels, insisting it should have ownership of the IP, and the other only a licence.
On more than one such occasion, I have cut this Gordian knot by using the concept of “joint ownership.” This is a fascinating vehicle in the software world. Each entity is given the same property ownership right to the underlying IP to the full extent afforded by the Copyright Act, without having to account to the other party. In practical terms, each party has its own copy of the software and goes on its own, separate way.
Over time, however, each party makes its own modifications and additions to its respective copy of the IP; so, eventually, the two “clones” of the software product (which started as exact look-a-likes) diverge and become, in some cases, quite unrecognizable from each other.
The upshot of the joint-ownership mechanism, though, is that a much stronger interest (than merely a “licence”) is given to the divested entity, and this in turn has sometimes been the difference-maker in the deal: if the only option on the table was a licence to the divested entity, either the deal would not have closed, or at a materially different valuation. Therefore, for these sorts of finicky, delicate situations, keep in mind joint ownership — a handy tool indeed in the right circumstances.
> Transition Services
It is often the case that the entity being spun out cannot support itself from an administrative perspective for some period of time after the closing of the divestiture. Frequently, for example, there are complex IT systems and databases that the entity is reliant on, but that cannot be immediately replicated for the new, stand-alone entity.
This is often the situation even when the division being spun out is being acquired by a friendly acquirer. For example, all the databases of the spun-out entity run on Oracle, while the buyer is an SAP shop. So, bottom line, the spun-out entity will need to rely on its old affiliate to support it with Oracle-related services (so-called “transition services”) until arrangements can be made to transition over to the SAP environment. This raises some key questions.
An important one is, what should be the duration of these services? The short answer is, it varies, depending on just how long it takes to do a careful, prudent transfer. You don’t want to rush things — but neither do you want to prolong the interim relationship. For example, the supplier of the services wants them to end in three months, while the divested entity, just to be on the safe side, wants nine months.
One way to solve this conundrum is to provide for nine months, but to have a material price hike for the services at three months and six months. This will serve as a meaningful incentive for the services recipient to transition off the supplier just as soon as possible. If, however, the spun-out entity truly needs the extra time, it remains available at a cost.
Here’s another critical question: what is the appropriate quality benchmark for the services? The divested entity will argue for commercial terms, with performance metrics – what are often called “Service Level Agreements” – the order of the day. Ideally, the divested entity will also have express remedies it can call upon for a failure of the supplier (the previous affiliate of the divested entity) to meet the performance metrics, such as liquidated damages.
The supplier, for its part, will not be keen on such a regime. It will argue that it is reluctantly providing these interim services as an accommodation to the divested entity, and that it is not in the business of normally providing these services to third parties — and therefore holding it to commercial standards is not reasonable.
The compromise often arrived at between these two extremes is that a standard of performance is agreed to, but it is a fairly low one — namely, that the supplier has to provide the divested entity with the same level of service it provides to itself. Put another way, if there is some resource that is in short supply, it cannot be allocated in a manner that favours the supplier over the divested entity.
A third issue relates to what type of access the staff of the divested entity can have to the systems of the supplier, which was previously an affiliate of the divested company. But that is no longer the case, and the two bodies are now third parties, dealing with each other at arm’s length.
This means, in some cases, that the supplier cannot afford to give the divested entity’s staff access to the systems of the supplier — such access is prohibited by the supplier’s licence agreement with its third-party software licensor. This can quickly become a material cost issue, as the licensor demands an additional payment for allowing access by the divested entity’s staff. This increasingly common scenario illustrates the benefit of adding into the initial licence agreement a provision allowing the licensor of such software to use it on behalf of a former affiliate for an interim period of transition, at no additional cost.
These are but three of the salient issues that arise in these important transition services agreements. There are many more. Twenty-five years ago, these agreements were five pages long. Today, with schedules, they come to about 50 pages. That is a reflection of how critical these arrangements have become — and it is proof that tech breakups are indeed hard to do.
George Takach is a senior partner at McCarthy Tétrault LLP and the author of Computer Law.
