After we got past our initial reactions to the “Man up and buy them,” comment from George Crump, at theBDevent last week, we  got down to some practical discussions about how to make OEM agreements work for both parties.  One of the big items that comes up in negotiations is the Source Code Escrow Agreement.  The party that wants to make use of some element of software, the OEM-In, wants to ensure access to the source code from the supplier, the OEM-Out, under a variety of scenarios, including defaults by the OEM-Out.

Of course, since the source code represents the crown jewels of the OEM-Out, they will typically do whatever possible to limit the conditions under which the OEM-In gets access to the source code.  The OEM-In, on the other hand, wants the broadest possible range of triggers for access to the source code.  

Triggers that I have seen proposed by the  OEM-In include:

  • Failure to support
  • Failure to remain current
  • Bankruptcy
  • Acquisition by a competitor of the OEM-In
  • Any change of control

The OEM-Out will look to limit these triggering events by adding time-period constraints and an Opportunity-to-Cure provision.  So, for example, the Failure-to-Support trigger may get limited by requiring the fault to be a “material” fault, and not some trivial event like the GUI had a bug that affects a small subset of the OEM-In’s customers.  And the OEM-Out may require that they be given 30, 60, or 90 days to cure the default.

The OEM-In can limit the impact of a default by the OEM-Out by keeping the OEM-Out’s software outside of the core of the OEM-In’s offering.  A bolt-on application is much less risky for the OEM-In than an element that is embedded in the core.

During discussions this past week on an OEM transaction, we asked the OEM-In if there was any real value in getting access to the source code.  Their very honest answer was, “No. Not if the access comes because your client is in default. How would we know how to support the software.”  Since I’ve been working a lot with Axxana, a developer of a very unique disaster recovery solution, lately, I got to thinking about the parallels between access to source code and the value of a disaster recovery plan.  Having worked on disaster recovery teams in two banks, I can say without hesitation that a disaster recovery plan is of no value, if the first time you use it is during a disaster.  Disaster recovery plans need to be tested.  You could say the same thing about access to source code.  If the first time the OEM-In gets access to source code is during a disaster, then the source code is of very limited value.

One way around this problem is to structure an OEM agreement in such a way as to give the OEM-In a limited license for access to the source code on day one.  This can be done without giving away the crown jewels by focusing the negotiations around limits on the use of the source code and limits on reverse engineering.  The OEM-In can begin learning what is involved in supporting the software. From a partnership perspective this also makes it more likely that the OEM-In will be willing to make the software component an element of the core product, and, over time, may want to take over some of the responsibility for support.

The key in any negotiation is to focus on what we are trying to accomplish, and then to test whether the language that we are proposing actually helps us attain that goal.