Software escrow companies are in the business of protecting parties involved in software licenses. As a neutral third party, they hold things like source code, data, and documentation. They can release it to the business owner according to the terms of the SaaS Escrow Agreement. A document like this involves both the software and legal industry, requiring knowledge from both sides.
Attorney and tech founder Martin Clausen tears down Escrow London LTD’s SaaS Escrow Agreement. He shows why attorneys should only draft these documents if they have a deep understanding of the technical details of how software works. As he points out, this is usually not the case.
Questions In This Episode
- What happens when your software vendor goes under?
- What is a SaaS Escrow Agreement?
- How do you spot the red flags of poorly used language?
- How do you keep from getting out of date versions of the software?
- How do you protect against more than viruses?
Software as a Service (SaaS)
SaaS is big business. Years ago, you bought software in a box and installed it yourself. Today, you buy spectacular software services that you can access from your work computer, laptop, or phone from anywhere in the world.
SaaS Escrow Agreements: how do you keep your software and your business running when your vendor goes out of business? #ContractTeardown Click To Tweet
The 2021 SaaS market is estimated to be worth $123 billion. The average medium-size company, 100 to 1,000 employees, will spend about $2.47 million each year on SaaS to run their businesses. Amazon Web Services (AWS) cloud computing and hosting solutions, host to many SaaS companies, made more than $43 billion last year.
But what happens to you and your business when your software vendor goes out of business, or goes into bankruptcy, or just stops delivering services? What do you do to keep your software and your business running?
Red Flags Pop Up in the Definitions
Unfortunately, most SaaS contracts are written by attorneys without expert knowledge in software. This introduces great financial risk to the business owner. Clausen shows how to spot many red flags in these agreements to help you identify and avoid the pitfalls of poorly drafted SaaS agreements.
In Escrow London’s agreement, the first red flags are the imprecise use of terms in the Definitions Section. Clausen gives several examples of words used by the drafter that mean one thing to lawyers but something different to software engineers. Below are two quick examples:
Source Code. The Saas Agreement gives the business owner the ability to access the “source code” under certain conditions. People unfamiliar with building software seem to think there’s a magical property about anything called “source code.” Code is code. Just calling the needed code “source code” is a tip-off that the drafter is unfamiliar with software engineers and their language.
Build. In defining deposit materials, the agreement talks about items required to “build” the product. To software engineers, “build” is one specific step in the process of making software accessible and available to the end-user, along with terms like “deployed” and “operated.” The way the word “build” is used in this agreement is inexact and another warning sign.
Source Code and Build mean different things to a software engineer than to an attorney. SaaS Escrow Agreement #ContractTeardown Click To Tweet
Only Worried About Viruses?
Suppose your software vendor goes out of business. In that case, you need access to the material that will let you continue to run that software for your company. The escrow company holds materials for you, and this agreement defines them as deposit materials. These include codes, images, documentation, and other materials you need to keep your software running.
But you don’t want anything dangerous in that code that might damage your other business systems or make you susceptible to hackers. Escrow London’s agreement says that the deposit materials can be accessed “free of viruses.” Just viruses!
Business owners are becoming painfully aware of attacks on business software. Ask the meat processing company, JBL, who was digitally extorted for $11 million in February 2021.
Besides viruses, there are Trojan Horses, worms, encrypted spyware, and more. Using just the word “viruses” in a Saas escrow agreement is another red flag that the drafter may not be familiar with the software world.
Keeping the Lights On
If you don’t pay your electric bill, you will soon be sitting in the dark.
The same idea applies to the companies that host the licensed software applications you are using. As an example, AWS is the largest cloud computing service provider and hosts businesses like General Electric, Harvard, Comcast, Disney, NASA, Netflix, the CIA, and more.
Your software vendor may be using AWS, Microsoft, Google, Oracle, or IBM to host the software. What happens when your software vendor goes out of business, and the hosting company does not get paid? A flick of a switch for an unpaid hosting bill can shut down your entire business.
But it gets worse. Your software vendor is likely hosting all their customers’ software on AWS or another host. When it comes time for you to take over and pay the hosting bill, you need access and an explicit agreement of how to pay only the hosting costs attributed to your business and no one else’s.
You need to have a clear path of what third-party hosting vendors are being used and how to keep your software going even when your vendor goes out of business.
Beware of Getting Out-of-Date Versions
Another pitfall in the Escrow London agreement is the lack of a date for depositing new releases.
Software is constantly updated and new product releases seem to come out faster and faster. Look how many versions there are of Microsoft Word or iPhones. Google has new Chrome releases about every six weeks.
Escrow London’s agreement states that the Depositor (the software vendor) must deposit the materials, namely the code, documentation, and other needed items, within 20 business days of an executed escrow agreement.
Always define a time requirement for depositing new releases in a SaaS Escrow Agreement. #ContractTeardown Click To Tweet
But there is no date or time requirement for depositing new releases of the escrowed software. The language simply says that a further copy of the deposit material shall be submitted “following a new release” of the product. This could be one month, ten months, or more after a new release. You could be stuck with an old and out-of-date version of the software.
Sufficient is Not Enough
Escrow London’s agreement calls for the deposited materials to be “sufficient to permit the product’s manufacture, use, and support.” Suppose you have to take over the software. In that case, you may only get materials that are sufficient – and in plain English, that means the bare minimum.
You may have spent thousands to millions of dollars on this software, and now you are only guaranteed something sufficient. If you bought a Ferrari and your insurance company guaranteed you a replacement car that was “sufficient” for you to drive on the road – you would feel a bit uneasy with that arrangement. The same is true here. You want everything you are paying for – not just what is sufficient.
Other Clauses of Concern
Clausen finds more imprecise language and a lack of details in other clauses of the SaaS Escrow Agreement.
Third party licenses. What happens to third-party licenses used by your software vendors when you have to take over? You need to know who they are and what types of licenses you need to renew and how much the cost will be. Without this information you could be looking at a huge bill.
| 2.14 | If the Deposit Materials contain Third Party Codes, the Depositor warrants that it has been granted the valid rights under a license agreement with the owner of the Third Party Codes. The Depositor must supply written authorization by the Third Party Codes owner consenting to the deposit of the Third Party Codes under this agreement. In the event of a release of the Deposit Material, the Beneficiary shall be responsible to obtain the necessary licenses from the Third Party to utilize the Third Party Codes. |
Default Triggers. What are the exact default triggers for when deposit materials are released? Instead of saying that materials will be released when the business folds, lay out exactly what triggers that. Who begins the process? What is the first thing that happens? Then the next? And when?
Dispute Resolutions. What happens if the Escrow Company decides not to give you the escrowed materials? You could be left on your own to figure this out if a clear process is not laid out in the agreement.
The Takeaway
The takeaway with Escrow London’s SaaS Escrow Agreement is straightforward.
A poorly drafted SaaS Escrow agreement could be disastrous for your company. A well-drafted one could keep your software going even if your software vendor goes out of business. (And when your software is integral to your business, you don’t want a second of downtime if you can help it.)
Attorneys should only draft SaaS Escrow documents if they have a deep understanding of the technical details of how software works. #ContractTeardown Click To Tweet
But, intellectual property and licensing laws are global and complex. Software development is complex and rapidly changing. Lawyers and software engineers do not speak the same language.
If you need an SaaS escrow agreement, find someone who is an expert in software and can inform the language of the contract. Anything less is a risk you might regret.
Show Notes
THE CONTRACT: Escrow London LTD’s SaaS Escrow Agreement
THE GUEST: Martin Clausen is the Managing Director of Syngrato ApS, a Danish legal tech startup building a practical, computable contract platform. You can find him on LinkedIn or at www.syngrato.com.
THE HOST: Mike Whelan is the author of Lawyer Forward: Finding Your Place in the Future of Law and host of the Lawyer Forward community. Learn more about his work for attorneys at www.lawyerforward.com.
If you are interested in being a guest on Contract Teardown, please email us at community@lawinsider.com.
Transcript
Martin Clausen [00:00:00] It is not useful to have something like this reviewed by somebody who doesn’t understand someone, how it’s built, because they will not detect half of the issues and the critical issues. So so for something like this, you really want somebody ideally with an engineering background who became a lawyer all the other way around because they are so technical and it’s the smallest thing that can trip you up and make your insurance policy completely uninteresting and unusable.
Intro Voice [00:00:33] Welcome to the Contract Teardown Show from Law Insider, where legal experts tear down contracts from some of the most well-known companies and high profile executives around around.
Mike Whelan [00:00:46] In this episode, attorney and tech founder Martin Clausen digs into a SaaS Escrow agreement from Escrow London Ltd. This document has a particular purpose giving a business that’s relied on a technology, the ability to continue using it, even if the developer closes up shop. But while escrow agreements are a common form of insurance, translating them to the modern world can be a clumsy undertaking. Martin explains how lawyers can mess up that transition and why they should defer to drafters that understand the context. There’s a lot to learn here about bringing old concepts into the modern world, so let’s tear it down.
Mike Whelan [00:01:28] Hey, everybody, welcome back to the Contract Teardown show. I’m Mike Whelen. The point in this show is to beat up contracts. I hang out with smart friends like my friend Martin over here and we make fun of things and we pull things out. You should pay attention to and maybe help you write a little better. Martin, how are you doing today?
Martin Clausen [00:01:47] I’m good, thank you, how are you?
Mike Whelan [00:01:50] I’m OK, it’s OK, everything’s just OK, but I had a day yesterday was Monday anyway. I don’t know why Monday’s still hurt my feelings because there’s no such thing as a weekend now.
Martin Clausen [00:02:00] It’s offensive. It’s offensive.
Mike Whelan [00:02:02] It’s still bugged me. That should be unconstitutional. So, guys, what we’re doing today is talking about a specific document. Let me share my screen with you real quick. It is actually found on Law Insider. It is a single beneficiary software escrow agreement. This one comes from Escrow London.co.uk. And you can see lots of links in here. Basically what that means on Law Insider is that you can find similar language to these different clauses elsewhere. But before we dig into it, Martin, let me ask you real quick to tell me, what is this document? When will people see it? Why do they care?
Martin Clausen [00:02:39] Well, so the last maybe five, 10 years, the way of consuming software has changed drastically for many people in many organizations. So whereas in the past, software was something you bought maybe in a box and installed on a server in your own data center or maybe a servers with a data center that you had access to locally. The software today is for many people, something you just access online as a software, as a service or web application or whatever you want to call it. Now, this agreement is is has been created as a sort of an extension of agreements that that that existed also when software was something you just bought in a box and installed, because people back then were already thinking, what if this software vendor goes away one day? What if they go bankrupt? What if their HQ burnt to a cinder or whatever? How do I keep this software maintained and in working order as a company when I’m now relying so heavily on this piece of software? So people came up with the idea of a software escrow agreement whereby the source code and materials that were necessary to maintain and keep the software operating were deposited at a third party trusted third party that would then upon one of these events happening that would make it infeasible for the vendor to continue supporting the software, would release the source code and all the materials to the licensee, and they could then proceed to either maintain and support the software themselves or maybe hand it over to a third party. Same problem happens and occurs the same theoretical problem as it presents itself with software as a service, but with a few added complications, because now the software is also now hosted typically in a third party data center, Amazon Web Services, Google search cloud, whatever. And it becomes important to maybe keep that infrastructure up and running if the vendor goes away. So we’ll see that that topic is sort of also addressed. We won’t have time to go into the details of that, but that’s topics also addressed to you. So that hopefully sort of sums up the rationale, the the need for the rest of this type of agreement.
Mike Whelan [00:04:57] So talking to me like I’m an idiot, you got a buyer, a seller, a dude in the middle or a middle woman, whatever middle gender neutral term you want to use. You got somebody in the middle who’s making sure you can get access to the source code if you’ve relied on this thing for a while. But as you said, it’s weird because now we got somebody else involved, this hosting company. So what we’ll do is go through this section by section. You are not an idiot, however, Martin. So before we get into this, tell me really briefly about your background. What brings you to this kind of document? Do you see this a lot in your practice?
Martin Clausen [00:05:27] So not these days? Because these days I do legal tech software, actually, but I spent the majority of my career in in I.T. law working with contracts both on the on the seller and buyer side. And I’ve seen this type of agreement from both sides all the way from way back when they were used for just old school software to software as a service. And it’s an interesting type of agreement because, you know, details often matter in agreements, but in these types of agreements, a lot of practical things that needs to be in place for this agreement to be useful at all, because the whole idea of taking over somebody else’s software and maintaining it either yourself or having a third party is. Is very hard to get right in the first place, but if you’re up against something when you’re not getting access to the right bits and pieces at the right time and so on, it’s going to be impossible. And you you’re going to have been paid paying for something that turns out to be useless. So if you decide to put one of these things in place, you have to invest the time to get it right. And getting it right in this case means getting everything it otherwise it will potentially be worthless.
Mike Whelan [00:06:43] Yeah, let’s get through it because it’s such an interesting context, taking an old concept and trying to wrap language around it that makes it, you know, apply to the now. So so we’re going to start at the beginning, as lawyers do, and go to the definitions. We’ve got a fairly long section with a bunch of words in quotes. They’ve set it out. They put it at the beginning. We’ve talked about this in other episodes. Talk to me about some of the terms that are in here that are raising red flags for you.
Martin Clausen [00:07:06] Yeah, well, the first one that I’ve highlighted in the text is the word deployed and the definition of access credentials. It’s just to highlight the fact that it is actually not this is not about software that is deployed on a server about this virtual server. It does exist in the agreement and it makes sense. But deployment usually means that something is deployed where you can then access and use it. In this case, deployed means something else. And I just wanted to highlight it. Shouldn’t be confused by that. Deployed in this case just means there’s a copy of the software on the server, but it doesn’t mean you can use it. It’s just a place where it is. Is that next thing that I highlighted, as is the word source codes in the deposit materials, I highlighted that mostly to make fun of it, because it’s clearly that this clear that this agreement is written by somebody who doesn’t know a lot about software, because if you use the word codes and sort of state of source code, it’s because you think that source codes are somehow cryptographic codes or something that will unlock something, which is, of course, not the case. And it should just as a general thing, make you raise your eyebrows and be aware that some of the technical aspects of this agreement might not be in order because it’s been written by somebody at some point who didn’t even understand the fundamental terms of what they were dealing with, namely source code, which is totally boring.
Mike Whelan [00:08:28] My I’m nodding my head right now as if I know what you’re saying, because I saw Web games with Matthew Broderick 20 years ago. But I’m with you. I should not write these things.
Martin Clausen [00:08:39] You should if you if you trip over something like this, you should sort of OK, maybe there’s other things that they haven’t got. Right. That that’s really important to me. The next thing is the word builds again, it’s a technical thing, but this is going to be highly technical. And that is why you want somebody reviewing these types of agreements, a lawyer who actually understands software and understands how software is built, how it is deployed, how it is operated. Because the word that they’re using is this saying they’re saying that it means that the proprietary technology are required to build the product. Now, build is a specific step in the process of making software accessible to an end user. But it’s not everything. There’s a lot more to something than just building it. You need to deploy it, as we talked about, which means copying the right bits to the right parts of the server infrastructure. You need to monitor it afterwards. So you’re sure that it’s behaving as you want, that it’s not running out of memory or using too much bandwidth and so on, so forth? It’s just to say that if you go into one of these agreements and this one particular, you want to make sure that the steps that you are going to need down the road. I actually covered by this and it’s not covered by using that word build. It’s probably going to take us too far to come up with an alternative definition, but it’s just something to be aware of. Moving on file integrity test definition. There’s a there’s a it inspired the word viruses, which is kind of saying, OK, you need to make sure that we have the material that we promised. But you also need to make sure that it’s free of viruses and it’s utterly arbitrary word in a world where there are a lot of other things that could be wrong with the software besides being virus infected. It could be other types of malware. It could have booby traps. It could have like encryption that all of a sudden spreads to the rest some key part of the software that makes it unusable. So you probably want to modify that definition to to make sure it covers all the adverse effects that could apply to the software. Next thing here is this is a SaaS software as a service specific thing, the hosting access credentials. I’ve highlighted billing and payment section of the third party hosting and application vendors. The reason why you you want access to this at all is because you want to be able to pay this hosting vendor to keep the software as a service operating going in. The idea here is that I’m a software vendor. I provide you with the software as a service solution, but I’m probably using a third party like Amazon Web Services, something to actually to actually serve the software. Now, one thing that happens if I go bankrupt and the materials released to me is to the to the customer that is is that the bills are going to be stopped. The bills are not going to be paid anymore. And you want access to to be able to pay those bills so you can keep the software operating. You want to consider whether or not those two sections actually cover what you want. That’s all I’m saying with this. It might not it might be that you need access to the monitoring section of the website, whatever. Just think about it in practical terms and in the light of the specific software that you are you’re buying. A software agreement definition, I’ve highlighted the computer code as part of the definition of source code, which is utterly now here on the same line of this agreement, I don’t really know why, but just to say that there might be other things that you want to include in the source code definition, there might be configuration files that a a a person would not say actually qualifies as computer code because its configuration there might be data, there might be other types of information that you would want included in the definition. All depends on the product. It might be the computer code is fine. It might also be that it’s actually not fine. And you want something else included in that definition. So it can already tell now by now that it’s really nitty gritty stuff that we’re dealing with here. It’s not, you know, principled, high level stuff. But if you fail on any of these things, you risk invalidating the purpose of this agreement entirely and it’s just not worth dealing with then it’s not worth the hassle of entering into it.
Mike Whelan [00:13:16] Well, and you’ve almost like two degrees removed from the lawyer in the sense that, you know, it was already complicated when it was the 90s and we were buying software and boxes. And now we’re trying to extend this language even further, which that lawyer might not understand. And so that’s really helpful. And I’m looking now, I mean, this is an escrow agreement. So I’m thinking about the deposit of deposit materials, as they call it, in Section two. Take me through some of the language in that section that stands out to you.
Martin Clausen [00:13:43] Section two to say the section two. One is the sort of primary thing. It’s the you have to start by depositing the source code or the deposit materials, as it’s called, by tronic or upload. That’s a duty of the software vendor. They have to upload the source code to a server. And now it’s in the case of escrow London in this case. So that’s, of course, fine that we start out on the day that we enter into this agreement. But of course, software changes and you don’t want the version that was current of whatever product like two years ago. When something happens, you want the latest and greatest. So that’s what two deals with. But it’s as opposed to the first section, it actually doesn’t even give a deadline as to when new versions needs to be uploaded. So I understand simply delay the upload by six months, by eight months, by nine months, and then when need release event happens, what I when I open crack open the server and see what I’ve got, it’s something that’s nine months old. That’s not. And I simply I don’t understand why you would take care to include a deadline, but 20 days, 20 business days and six to one and then not do it for new releases of the product. It seemed
Mike Whelan [00:15:01] as just as filing a new release, which
Martin Clausen [00:15:04] and it seems just sloppy. I don’t know. I have no idea why they would do it. We are getting back to the really technical stuff here to five three. It sort of specifies what information needs to be available in this deposit. And they they’re saying here detailed documentation detailing the operating system, hardware, third party software and software tools fight for recompiling the product. Also, oddly, specific term, because compilation is part of building a product, you’re taking source code and turning it into something the computer understands through a compilation process. That’s a very rough, you know, description of what happens that no computer science person would ever forgive me for using. But that’s essentially it. The thing is that there are other ways of building things. Not all software is compiled, some misinterpreted and so on. So you need to be specific on whether or not this actually covers your documentation needs for this particular package. And to evaluate that, you need to understand the details of this software also it wisely and which is kind of a plus, I would say, in two five four says that it’s not enough that you give me documentation. I need to know who did this, because sometimes there’s tacit knowledge that I can only get it by knowing who’s actually who, who who built this thing. I want to be able to reach out to those people. You don’t see that in all its agreements. Somebody has wisely included it here, but they are only sort of addressing people who know the product development and structure. I’m not sure that I’m I feel comfortable with with that. I actually might also want the people who know how to test the software. I might want specific individuals that do something about, you know, the dark corners of something that might be a specific algorithm somewhere that only one person or two persons know something about. That’s key to keeping this thing alive. You might want to consider, you know, inquiring into that and getting the right people either by name or by other rules. And people who know about development structure, as you can tell, again, very practical, low level stuff. Again, if you don’t get it right, you might not. This might this thing might not save you as you were hoping. Two materiality requirements. And two, six, two and two, six, three, they should just be deleted. They make no sense in the in the context of what they’re talking about. They talk about material changes to names and contact details. There are, as far as I can tell, no such thing as an immaterial change to somebody’s contact details. I mean, as which spoke about just before we went on here, if you change one digit of somebody’s phone number, it’s still not going to work for you. Right. So what is this material thing? It doesn’t make sense again at all. This specific thing that some technical person that wasn’t the person who used the word source code put in here in two seven git repository. OK, you know, this is a it’s a it’s a it’s a very specific piece of software that’s used to archive and version control your source code. But it’s it’s one version control system among many, many software version control systems. And I don’t understand how somebody put in here a specific name of a product could be that this vendor uses a different product, that this doesn’t apply.
Mike Whelan [00:18:39] So I don’t know. Can you move in to to two nine? This one’s a section that fascinates me. And you sort of see this coming up through this document there, disclaiming a warranty here of things that seem like exactly why you’re purchasing this relationship in the first place. Talk to me about the language of this disclaiming a warranty that’s in two nine.
Martin Clausen [00:19:00] Yeah, it’s just overly broad. I mean, it’s OK that they are not, as an escrow provider, liable for the Internet connection coming into them and maybe corrupting something. But if you go to it with a fine tooth comb, we don’t have the time to pick it apart. Just be aware of it. It’s overly broad and it actually excludes some things that you want them exactly to be liable for. So so please be aware and you’ll see that in many, many escrow agreements, escrow provider trying to be completely outside reach from a liability point of view. Two eleven. It’s it’s again, it’s what is going to be deposited. It says here it it warrants it represents that the deposit materials are sufficient to permit the manufacture, use and support. Again, manufacturer. It sounds like it’s software, something produced in a tin can factory. Right. It’s again, somebody who’s not doesn’t know the specifics of how software is built, that’s for sure. Then I’m being I’m being kind. But sufficient is a problematic word here because I don’t want what’s sufficient. I want everything I want because sufficient means that it’s theoretically possible for me to build something that’s not what I want. I want exactly what all the niceties, all the tools, all the bells and whistles that they used to build that for themselves. I want all that. I don’t just want what’s sufficient. So sufficient is actually truly dangerous word in this definition. Well, yeah, because because
Mike Whelan [00:20:36] am I right that in this kind of agreement, they’re assuming that plausibly you you company owner are going to take this information at your expense, go build something. I mean, if they give you just, you know, sufficient zeros and ones, it doesn’t necessarily it could make it really hard and business wise impossible for you to maintain.
Martin Clausen [00:20:56] And it’s extremely hard in the first place, even provided with all the information, all the access information, everything. It’s still some people considered more or less theoretical that you could even do with that you could hand over moderately complicated software packets and source code form and then either for the vendor, for the customer, or some even knowledgeable third party could take it over in a timely fashion. So some people just avoid it altogether for that reason. But some people think that it’s possible and they evaluate the circumstances, say, well, it is possible, but it’s certainly not going to be possible just with the sufficient material. It’s going to you are going to be wanting everything because you’re starting from scratch, you or somebody else on your behalf. There’s going to be starting from scratch. And it’s that’s a challenging proposition. And in in itself, not so inefficient.
Mike Whelan [00:21:48] And this deposit area that that standard out to you.
Martin Clausen [00:21:52] Yeah. So we had we had 214. This is just a thing to be conscious of. You know, when people build software, they sometimes rely on software. They license some third parties. This agreement deals with that and it includes the the source code for those third party products. But it also says that when it’s released, you have to go yourself to these third parties and ensure that you have a license to use it. You don’t know what that license is going to cost or whether that third party is going to be very cooperative in granting you that license. That’s a potential hold up scenario that if I ever saw one. So you probably want to clarify this, maybe get some specific options to get those license with a price, whether that line, all of that. So you’re sure that you actually know the terms and the entirety for getting access to this stuff? So. Yeah, and lastly, in two 24 Escalon, London may assign subtrend trenchcoat, blah, blah, blah, blah, all of its obligations now. When you pick an escrow vendor, you probably picked them because of their reliability, because of their track record, because they are dead solid, because they have excellent infrastructure that will protect the source code against all eventualities and so on. Is it really reasonable for somebody like that just to be able to assign this to their brother who runs the kebab shop down the corner? I don’t think that it is. You’re picking this entity for a specific purpose with a view to their skill and their track record. So I would just, you know, obliterate a clause like that or I would substitute for something with a lot more assurances as to the quality and and so on off the substitute. The Escorpion. Right.
Mike Whelan [00:23:45] Which is as simple as if an assignment is proposed. Give me some ability to refuse that or whatever. Or some.
Martin Clausen [00:23:51] Some exactly. All objectively prove to me that they at least as good as we are. Right. But something like that.
Mike Whelan [00:23:59] Yeah, no, that’s really helpful. And once the deposit is made and they’re holding the stuff I’m looking down at four where they talk about default, and if I’m understanding correctly, they’re not talking about default of the original agreement or whatever they’re talking about, what are the triggers that lead to this release of the information that was deposited into it?
Martin Clausen [00:24:17] That is exactly what they’re talking about. And these are events of default, namely where the software vendor fails to make good on their promises under this SaaS agreement. Right. So for the first one is here that they fail to support that deposit materials in accordance with the SaaS agreement. Technical point here. Actually, they are not supporting to deposit materials, they’re supporting the SaaS application to you. So this is just on its face wrong the way this is described. Secondly, you want to make sure that the words support here is adequate and that it matches some concept that you can find in this SaaS agreement. So they’re probably doing something else beyond just supporting the software. They’re operating at that idea. So you want to match those terms up the to the service that you are being provided. And in four one five, it just talks about. It’s that that the that the depositors ceases active operations of a business, that this continues the licensing or maintenance of the deposit materials in material breach of the SaaS agreement. Again, I would consider whether or not material is relevant here, because if they breach it, they breach it. And that should be enough to, uh, to given that the qualifications here already cease active operation of its business at this continues to license. I mean, how is I don’t see how a materiality requirement would operate meaningfully here. So I would at least challenge it and I would make sure that I, I get this to trigger. Would the things happen that I want.
Mike Whelan [00:26:03] Got it. So moving, moving down the contract. So now we’ve had we’ve deposited the stuff, we’ve had a triggering event. Stuff has to be released. So we’re down in five release of deposit materials. What’s standing out here for you?
Martin Clausen [00:26:15] Yeah, we have this very odd concept in five three of contrary instructions. So this is a this is like the vendor’s ability to say, you know, OK, I realize I’ve been notified by Escrow London that you customer are claiming that that lease event happened. I disagree. And now I’m providing you contrary instructions not to release this software to the customer who paid for this agreement and everything. And then it triggers a dispute resolution mechanism that is not nearly as quick as it needs to be considering what we’re talking about, the dispute resolution mechanism is this is found in Section six further down the document. Right.
Mike Whelan [00:27:01] The whole point is that,
Martin Clausen [00:27:02] you know, the whole point is that
Mike Whelan [00:27:04] isness.
Martin Clausen [00:27:05] Exactly. The point is also that if I’m making this claim and I’m turned out not to be right, I will I will be paying substantial damages to the software vendor at a later stage. But it cannot be that software vendor in a potentially and likely in a very fragile state. There may be fighting for the business on the verge of bankruptcy or whatever gets to make a contrary instruction as this thing. I would just wipe this thing out. I think I have seen it before, but I still considered very unusual in this context. I would say where? So we have we have the in five, six, we have to use we have the terminology of the word use the deposit materials. So so this is talking about what are my rights in relation to this deposit materials that I’m now being handed? I get the right to I have a world wide royalty free irrevocable, perpetual freely sublicensable, nonexclusive license to use the Deposit Materialss. I mean, that looks on its on its face pretty OK, but since we are talking about potentially copyrighted material, it uses actually not one of the exclusive copyright rights. One of the rights that you get to maintain exclusively for you if you have copyright in something is the right to line of copy stuff. You I can’t use copyright to prevent somebody from using something that I have copyrighted so I can prevent them from copying something. I can prevent them from displaying something. You know, viewers should look up the definition of what copyright exclusive rights are and they are a little bit different depending on jurisdiction and so on. But use is not one of them. So it’s very odd that that that what they’re granting here is the right to use because it’s not an exclusive right that I have via my copyright. So look into that. Make sure that the license grant is actually fit for purpose. Hmm.
Mike Whelan [00:29:22] Well, in in five seven, you know, they start talking about the financial event of default. It’s it’s defined up in four. They talk about the depositors failure to pay the financial invoices of any third party vendors in accordance with their agreement. So what’s the specific trigger under that particular reason for releasing the information?
Martin Clausen [00:29:43] So so this is prior to it. We should probably look at the middle sentence here prior to making any payments to a third party vendor on behalf of the depositor Escalon, and should be entitled to receive full payment of outstanding invoices from the beneficiary that the a financial event of default. So if I call this financial event of default, I need to pay up anything that is owed already by the depositor. You should just it’s probably it’s probably not something you can change due to the circumstances, but just be aware that there’s a potential massive bill to be paid upfront before anything happens here. And the thing is that you end up you might be paying on behalf of other customers, too, because software, social service has the nature that it’s hosted on a piece of infrastructure somewhere for the benefit of all the customers of this vendor, not just you. And the bill is proportional to the fact that there’s potentially a lot of customers. But so you will be facing potentially a bill that’s not doesn’t stand in relation to your own value or your own payments for the software, but to the totality of the value of the software. So think about that. It might be completely prohibitive to even pick this bill up.
Mike Whelan [00:31:05] Yeah, yeah. And I’m just as an aside, we’re going down to seven where it talks about indemnification, which is a long section. And we’ve talked about these sections on different videos. I would encourage you guys to look at the playlists for other videos. But, you know, one of the point that seems to be stand out to you is at the very beginning, where it talks about who’s indemnifying here, why highlight the word beneficiary? What’s standing out to you.
Martin Clausen [00:31:25] It’s just because we get to to indemnify the London, Escrow London together with the depositor for any liabilities whatsoever. And it doesn’t make any sense. How is it that I should be liable for anything? I don’t own the copyrights and the source code I didn’t create. How is it expected that I can sort of impose some liability? You should at least put some fences around which kinds of indemnification should be should be applied to you as a customer and which should be exclusively applied to the depositor? It doesn’t make sense to put everything in one bowl because we’re not equal partners. I didn’t create the software. I’m just paying the bills and using the software. Right, right.
Mike Whelan [00:32:12] So this kind of agreement is to benefit the beneficiary. Which brings us to the last thing we wanted to talk about, which is the force majeure clause down in 10. It seems to undermine the very point in why we’re doing this agreement. Talk to me about the force majeure clause in an escrow account.
Martin Clausen [00:32:27] Yeah, yeah. It’s kind of odd, right? Because one of the functions of a escrow agent is to keep to to keep safe this source code and protect it and make sure that it’s available even under adverse circumstances. You know, that it was some circumstance that might take out the software vendor might also take out huge parts of all the infrastructure. Right. So I can’t really I mean, having a force majeure clause whereby the escrow London can get out of its obligations under this agreement is is is odd because they are supposed to protect us, among other things, not only the sort of exclusive events happening to the vendor, but also more general events. So I would at least make sure that it’s such a force majeure, couldn’t be used to escape things like flooding, lack of electricity, whatever hacker attacks and so on, that I’m actually actively seeking and paying for the protection against so far shall not be OK. Overly broad force majeure clauses like this? Absolutely not.
Mike Whelan [00:33:34] Hmm. And it’s not like this is an insured, you know, sword from Alexander the Great. There’s only one copy. You can only have it in one physical place. I mean, you can spread this code in different, you know, all this data in multiple places to protect it and the chances that the whole world is going to be flooded. I mean, we’ve been told that’s not going to happen for a while. I think we’ll be OK if you put it different places. It’s an interesting principle there about, you know, the language because somebody is unfamiliar, undermining the purpose of the contract. So let’s get into principles. Tell me about what’s the big principle that we can pull from this, even if we’re looking beyond a contract of this type?
Martin Clausen [00:34:11] I would say that if we if you’re looking to software agreements in general and agreements that have to do with the technical aspects of software, in this case, being able to recreate and effectively continue to maintain the software, it is a. It is not useful to have something like this reviewed by somebody who doesn’t understand software, how it’s built, because they will not detect half of the issues and the critical issues of this. So so for something like this, you really want somebody ideally with an engineering background who became a lawyer all the other way around because they are so technical and it’s the smallest thing that can trip you up and make your insurance policy completely uninteresting and unusable. So I think it’s one of those types of agreements. There are other types of agreements if you’re licensing source code from somebody to use in your own product or other kinds of things, highly technical things, I would advise against taking the advice on something like this from anybody who doesn’t understand themselves how software works.
Mike Whelan [00:35:26] Yeah, you don’t need just any nerd guys. You need a nerd like Martin. Martin, if people want to follow up with you and talk more about these kinds of IT contracts, I mean, obviously you’ve dug into these deep both as a lawyer and now as an owner of a tech company. What’s the best way for people to reach out to you?
Martin Clausen [00:35:42] So I’m on Twitter, I’m @martinclausen8, and I’m I have my own company called Syngrato, where I’m reachable on my email Mike Alpha Charlie MAC@Syngrato.com. Awesome. You guys, I say, yeah.
Mike Whelan [00:35:58] Sorry. Go ahead Martin.
Martin Clausen [00:36:00] No, I was just going to say I don’t I’m happy to talk to people, chat people on this I, I don’t provide legal advice activity anymore, but I’m still interested as people can still be too interested in these things. So I’m happy to chat about it. And if nothing else point you in the direction of somebody who is just as nerdy as myself, who I actually, you know, still making their living advising of these things,
Mike Whelan [00:36:24] this is a safe place for nerdiness. Martin, thank you. I appreciate it. You guys, all the information that we’ve talked about, including the link to this document which can be found on Law Insider will be at LawInsider.com/Resources. You can find the contact information for Martin in the show notes as well. And if you want to be a contributor to the Contract Teardown show, just email us to the community@LawInsider.com. I need more friends. Call us, go to community@lawinsider.com. Email us there. I will see you guys next time. Thanks again, Martin.
Martin Clausen [00:36:54] You’re welcome.