Giving meaning to source code escrow agreements: FilmFlex, Piksel clash over interpretation

Our friend Catherine Lee, a.k.a. the Cat the Kat, has been highly industrious on our behalf, taking the trouble to write up the following note on a legal decision that is deadly serious, a ruling that so little lends itself to humour that it is right and proper that the first illustration should illustrate that earnest creature, the dog. In an almost unparalleled act of kindness, Catherine also makes sure that no-one plunges into the IP bits of this blogpost without understanding what an escrow is. This is what she says:
As the etymologically-inclined readers of this blog will know, the word ‘escrow’ can be traced to the old French word ‘escroe’ which meant a ‘scrap, small piece, rag, tatter, single parchment’.  Originally, the term referred to a deed which was delivered to a third person until a future condition was satisfied in the sense of being a ‘deposit held in trust or security’.  In modern times, many things can be placed in escrow, such as real estate documents, tenant rental deposits and payments for services.  As far as this emeritus Kat is aware from her brief Google search, no cat has ever been placed in escrow (the position may be somewhat different with respect to dogs judging by this dog t-shirt, right).  
The same could not however be said about source code.  Under an escrow arrangement, a software developer or software maintenance provider supplies an up-to-date copy of source code to a trusted third party escrow agent.  That agent is then instructed to release the source code to the customer in the event that the developer or maintenance provider is unable to perform its contractual obligations, such as due to bankruptcy.  The situation is designed to ensure the continued operation and maintenance of a piece of software which may be critical to a customer's business.  There are usually two kinds of escrow agreements:
* a single user agreement (a trilateral agreement between the software copyright owner, the customer and the escrow agent); and,
* a multi-user agreement (a bilateral agreement between the software copyright owner and the escrow agent where there is more than one user of the software). 
Given that two agreements now governed the use and access to the source code (namely the software development and/or maintenance agreement and the escrow agreement), which one takes precedence if there is a conflict regarding access by the customer to the source code?  Although this is a rather important question, there have been comparatively few escrow cases.  That is, until Filmflex Movies Ltd v Piksel Ltd [2015] EWHC 426 (Ch) came before Mrs Justice Rose in the High Court, England and Wales, last month. 
FilmFlex is a provider of video-on-demand movie streaming services. It provides this service to customers such as Virgin Media, TalkTalk and EE who want to stream movies and other video content to their own customers. FilmFlex provides these services by means of an online content delivery platform which was designed, built and maintained for it by Piksel.  
Piksel is a video broadband software designer and developer and a managed services provider that designs, creates, hosts and manages the software, websites and other components that allow its customers to deliver video content online. Its customers are primarily video content owners, aggregators and distributors such as FilmFlex. The software system in question performs a number of functions, including delivering the video content, managing which content is available to which consumers and interfacing with the billing systems of FilmFlex's customers so that it can incorporate the fees for viewing the videos into their overall invoicing to their individual customers. 
The Master Services Agreement  
The parties entered into a Master Services Agreement (MSA) on 21 June 2012.  Clause 9 provided for the ownership of intellectual property rights in the software system in question and for the creation of an escrow account where the software would be deposited.  
Clause 9.10 dealt with the trigger events upon the occurrence of which the Escrow Agent would release the material held in escrow to FilmFlex.  They were:
* termination of the Agreement by either FilmFlex or Piksel, or Piksel's material or persistent breach of the Agreement;
* termination by NCC (the escrow agent) of the Escrow Agreement;
*  the insolvency of Piksel;
* change of control of Piksel; or
* the appointment by Filmflex of a third party to provide services in relation to the software in question.
Further, Clause 9.11 provided that Piksel acknowledged that FilmFlex would have access to the source code throughout the agreement at its request. 
The Escrow Agreement  
FilmFlex and Piksel entered into an escrow agreement (EA) with NCC Group Escrow Limited ('NCC') later in 2012.  The agreement was in accordance with NCC's standard terms. Under clause 6, NCC would release the source code to NCC:
* if Piksel is wound up, has an administrator appointed or enters into a compromise with its creditors or has a receiver appointed;
* if Piksel ceased to carry on its business or the part of the business which relates to the software in question;
* if Piksel assigned the rights in the source code to a third party and that third party did not adopt the Escrow Agreement; or
* if Piksel was in material breach of its obligations to keep the software in question up to date.
It can be readily seen that the events in clause 9.10 and 9.11 of the MSA do not mirror those in clause 6 of the EA.  

The source code  
In September 2014 FilmFlex asked Piksel for a copy of the latest source code. Piksel provided a file which, it said, complied with the request but which, FilmFlex said, was functionally useless. On 17 November 2014 FilmFlex appointed a third party developer ADITI Technologies Private Limited ('ADITI') to work on developing the software in question.
FilmFlex sought to obtain a copy of the source code on three grounds under clauses 9.10 and 9.11 of the MSA:
* it had appointed ADITI to provide services in relation to the software in question as it was contractually entitled to do;
* it had an express contractual right to “access” the source code; and,
* because it owned the intellectual property rights in some of the software and had a perpetual licenc in respect of the other parts of the software.
Piksel rejected each of these arguments:
* the right to appoint a third party to provide development services no longer applied on the basis that the parties had entered in to the Escrow Agreement which provided for a narrower set of events;
* the right of "access" amounted merely to a right of inspection, not a right to a copy;
* the provisions relating to intellectual property rights did not provide for a physical delivery up or handing over of a copy of the source code.
The preliminary issue 
Rose J found in favour of FilmFlex on all three grounds: 
* Although the Escrow Agreement came after the MSA was signed, the terms of the Escrow Agreement did not oust the terms of the MSA. Further, although the agreements did not mirror each other, there was no real inconsistency between them.  The substitution of the much more limited clause 6 of the Escrow Agreement for the more extensive trigger events in clause 9.10 of the MSA would have been a substantial surrender by FilmFlex.  This was particularly so in respect of the freedom conferred on FilmFlex under other terms of the MSA to appoint another contractor in addition to or instead of Piksel. There is no reason why FilmFlex would retain the right to make such an appointment under the MSA but give up the entitlement to release of the source code from escrow under clause 6.  To the extent that there was any inconsistency between the two agreements, the bespoke wording of clause 9.10 of the MSA should prevail.  
* Clause 9.11 of the MSA did not specify the purpose for which access to the source code was given. After considering the complexity of the particular software and the definitions in the MSA, Rose J decided that if a contract provided one party access to certain material and the scope of that material is defined as including everything necessary to carry out certain activities, it makes sense to construe the access granted as including whatever access is needed in order to carry on those activities.  It followed that, if FilmFlex wanted to use, reproduce, modify or enhance the software, it must not only be able to look at the source code but also have a copy of it that it can use. 
* The parties must have intended, by licensing each other to use the rights in their software in the manner described in clause 9, that they would be entitled to a copy of the software from the other if that was necessary in order for those rights to be exercised. This was the only commercially reasonable interpretation of the arrangement. 
Therefore on the true construction of the contractual arrangements and in light of the events which transpired, Rose J held that FilmFlex was entitled to delivery up of the source code by Piksel and also to require Piksel to procure the delivery up of the source code by NCC. As to what constituted 'delivery up', the judge made clear that delivery up means providing a copy of the source code in a format which means that the copy can be kept by FilmFlex, revised by it in a way which results in that copy diverging from any copy retained by Piksel and which FilmFlex can transfer to a third party without the further involvement in that transfer of Piksel.  It did not matter whether this was effected by providing the source code on a memory stick or disc or by emailing a file.
Thanks, Catherine, for this clear and concise explanation of a not-so-easy case.
Giving meaning to source code escrow agreements: FilmFlex, Piksel clash over interpretation Giving meaning to source code escrow agreements: FilmFlex, Piksel clash over interpretation Reviewed by Jeremy on Sunday, March 15, 2015 Rating: 5

No comments:

All comments must be moderated by a member of the IPKat team before they appear on the blog. Comments will not be allowed if the contravene the IPKat policy that readers' comments should not be obscene or defamatory; they should not consist of ad hominem attacks on members of the blog team or other comment-posters and they should make a constructive contribution to the discussion of the post on which they purport to comment.

It is also the IPKat policy that comments should not be made completely anonymously, and users should use a consistent name or pseudonym (which should not itself be defamatory or obscene, or that of another real person), either in the "identity" field, or at the beginning of the comment. Current practice is to, however, allow a limited number of comments that contravene this policy, provided that the comment has a high degree of relevance and the comment chain does not become too difficult to follow.

Learn more here: http://ipkitten.blogspot.com/p/want-to-complain.html

Powered by Blogger.