What is service contract?

What are the best practices for termination of a service contract, that includes transfer or licensing of source code?

• Imagine a company RandCorp which is very good at computing random numbers on a daily basis. RandCorp meets BizCorp, a company which believes can sell RandCorp's daily random numbers to its big address book. Both companies want to draft a contract : for some fee, RandCorp will send to BizCorp its numbers, every morning. Both companies are quite small, and the service provided by BizCorp to its clients will heavily depends on RandCorp's own service. It's more a partnership than a simple contract between the two companies. So BizCorp wants to be sure that it will not be suddenly left alone if RandCorp changes its mind and doesn't want to provide its numbers anymore. My question(s) is on the following clause : if RandCorp wants to terminate the contract, it will have to transfer or license its source code to BizCorp, and take care of the transition (e.g. training the new team in charge). 1. How is such a clause called? 2. Should RandCorp charge BizCorp for the transition phase? 3. Should RandCorp charge BizCorp for the source code license? (the source code may be priced in hundreds of thousands $) 4. Should a distinction be made between RandCorp acting as a "good leaver", ie giving a e.g. one-year notice before leaving (so BizCorp can find another solution during that time and RandCorp doesn't have to license its code) -- and as a "bad leaver", ie giving only a e.g. 3-month notice? 5. Is that logic healthy? 6. To what possible scenario should they pay attention to and how to deal with the possible complicated situations? A last thing : neither company want to use a code escrow service.

• Answer:

  You're describing a complex strategic relationship between two companies involving an ongoing intellectual property transfer. These are always unique  transactions that involve negotiation by the parties and custom-drafted agreements from their lawyers. You could call them anything you want but they often go by the name of strategic partnerships, IP licenses, technology transfer agreements, or something more descriptive like "Random Number Provisioning Agreement". It's also a little bit like what's known as a "supply contract" where one company promises to be a supplier to the other, but the exact volume isn't known in advance. Imagine company A hires company B to supply hot dogs for its hot dog stand. They'll sign a contract to that effect, but the actual number of hot dogs depends on how many customers Company A can attract. These sorts of contracts are quite common. Some of the issues there are quality, timeliness, minimum and maximum amounts, price tiers, exclusivity and territories. Yes, it makes a lot of sense to distinguish between good and bad leavers in a supply contract. Specifically you would distinguish between contracts that are terminated: (a) due to breach by one party or the other, in which case the other party is entitled to the benefit of the contract, either cash damages or "specific performance" of obtaining the things they contracted for, or (b) due to the expiration of the term, or if specified in the contract, upon appropriate notice, in which case the contract winds down and everybody goes home. You could also provide for other reasons the contract might be suspended or terminated such as bankruptcy, government order, natural disaster (or civil unrest, or hacker attack), or one party simply terminating without required notice (which is usually a breach but could be called out specifically as a "termination for convenience" or "without cause"). If the parties don't want source code escrow they might be out of luck because that's probably the simplest and most foolproof way to ensure that the licensee continues to receive the services of the licensor in the event the licensor breaches, goes out of busines, or is otherwise unwiling or unable to continue. You could escrow the technology in many ways, not just a repository of source code. You could escrow an entire working installation complete with the technology stack, and have it running idle in the hands of a trusted third party, probably one of those big consulting companies. In this particular example, because random numbers never expire, you could have the provider generate a year's worth of numbers in advance and escrow the numbers themselves with somebody, to be released only if escrow conditions are met. Alternatives to source code escrow would be a "specific performance" clause, mentioned above, that would allow the receiving party to get a court order to the other party to continue to supply random numbers. That would be nearly impossible to enforce if they simply refuse but it would up the ante because a court might for example order a transfer of the code, servers, bank account, etc. There are probably other approaches, this is the sort of thing where you and your lawyers need to brainstorm. The meta-question about dealing with possible complex scenarios is a great one. Think of the contract as a sort of code that maps the real world events and decisions of the parties on the one side as inputs, to desired outcomes, legal rights and responsibilities on the other as outputs. For example, if the input is that one party refuses to continue because it is bankrupt, the outcome is that the other party has a right to go to court to get ownership of the source code. In designing the contract, and in testing the contract, it makes a lot of sense to spend time designing a sample set of scenarios. As a businessperson, you know the scenarious that are most important: those you want to happen, you think are likely, and those you are afraid of. Your lawyer probably has a lot more experience than you do spotting things that can go wrong, because that's usually where they come in — nobody calls the lawyer about a contract when everything is going as planned. So they'll plan for situations you may not have dreamed of, for example one of the companies being acquired by a competitor, a third party filing a patent lawsuit, or the passage of a new law. You have to keep the lawyer from becoming a complete nay-sayer, and the lawyer has to keep you grounded and aware of real world risks. Once you have those scenarios in mind, you and the lawyer try to draft terms that are simple, elegant, efficient, understandable, scalable, and everythign else, just like code artchitecture. It's very bad practice to write a contract as a giant switch statement that says "in case 1, do A; in case 2, do B, etc." because the number of things that could happen in the world is nearly infinite and the more you try to be specific the more likely you're going to end up in a situation that the contract did not anticipate.