We meet a lot of clients that fail to obtain a written agreement, or blindly sign the form provided by the developer – and when a dispute arises, only too late realize the problems created by that lack of diligence. This post addresses critical provisions in a website development agreement.
First, you want to make sure you will own the material and content created by the developer. Thus, you want a provision in the agreement (which must be in writing) that recognizes that the developer’s work for you is considered a “work made for hire” and you want a copyright and intellectual property assignment as well. These clauses ensure that, although the developer is not your employee, you are the owner of the website materials and intellectual property rights. You do not want to find that your website designer created something unique for you only to discover the same unique layout on another website. Many businesses are surprised to learn that in the absence of this statement in a written agreement, an independent contractor (in this case the website developer) typically is the owner of work they create, and the business at most would be a licensee of the material. This means you don’t own the work; rather, you only have permission to use it.
Second, you want to have a provision in the contract that states that the work on the website is the website developer’s original work and/or that the developer has the necessary permission/licenses from the owners to use the work on your site. For instance, the website developer may place photographs on your website – you want the developer to represent that the developer has the right to use those photographs on your website (i.e. either the developer took the photos or it has the permission to use them). If the developer uses photographs owned by a third party on your website without the third party’s permission, the third party could claim you are infringing on their copyright by displaying their work on your website without their permission, and would demand you cease use of the photos and may demand damages as well. Thus, have your website developer represent the work is original or that he has permissions to use all work on your website.
Third, make sure to have an indemnification provision in your agreement. This provision should provide that the developer will indemnify you in the event you incur damages or a loss due to a third party claim that you are infringing their intellectual property rights – where they claim the work on your website is actually their material. For example, a business thinks the graphics on its site are original, however, it receives a cease and desist letter from a third party alleging that its use of the works on its website without the third party’s authorization is copyright infringement and demands damages. Under Copyright Law, if the third party is the owner of a registered copyright in the work, the business as an unauthorized user could be subject to statutory damages ranging from $700 to $30,000 for unintentional infringement, and up to $150,000 for willful infringement. Thus, if material placed on your website by your developer is subject to a claim or legal action for infringement, you want your developer to indemnify you for these actions since you are relying on their knowledge, creativity and skill in developing and designing your website.
Finally, it is important that you make sure that the developer periodically delivers all source codes and native files to you, and that you control all passwords and access to critical website assets, such as the domain registration. You want to make sure that such files and access rights cannot be withheld in the event of a dispute. Thus, if a dispute arises, the developer’s sole remedy should be money damages. You should not be prevented from transferring the work done (to the point of a dispute) to a new developer, so you can finish your site, and deal with the dispute separately.
For more information, please contact Kim Grimsley.
In GMG Health Systems v. Amicas, Inc., 1st Cir April 10, 2012, the court had occasion to address a dispute between a software licensor / developer, and a licensee, in which more typical contractual language was in issue (for example, use of the term “go-live” and the phrase “substantially conform to Documentation” and typical warranty limitations).
GMG is a medical services provider – they typically have several systems to manage their billing, processing and other business functions. Here, GMG contracted with a third party (Amicas) for its software – which had to interoperate with software from an already existing vendor used by GMG. Like so many disputes, this one arose because of finger pointing between two vendors as to whose software was causing the error. As an added twist here, and something we have litigated on at least one occasion here – GMG had decided to leave Amicas and go with another vendor, and was desperately trying to find a way out of the long term agreement.
Normally in such disputes, the licensee (client) makes some effort to produce a viable claim of breach of the agreement by the licensor / software developer. In this case, however, GMG, which had not negotiated the agreement and signed a pre-printed form provided by the software company, produced a sole witness to fight the motion for summary judgment filed by the software developer. This witness had no IT or software training, was not a project manager, was not familiar with the function of either of the software systems at issue, and could not provide any details beyond that the “interface did not work.” GMG feebly tried to argue that the merger clause – a clause that states that all prior agreements including verbal understandings between the parties are “merged” into the agreement, did not apply because it had not negotiated the agreement. The court dismissed that argument without any discussion.
Without the ability to provide evidence of what the parties intended – the so called “seamless integration” with the other system – GMG was unable to overcome the warranty limitation in the agreement, which stated that Amicas did not promise that the software would work for GMG in its environment. Not surprisingly, GMG lost on all counts . . . and that loss was affirmed on appeal.
What is the moral of the story?
First, negotiate large scale enterprise resource planning agreements! Yes, the negotiation can be expensive, but far, far less than the litigation costs and potential damages. For example, in the GMG case, it was forced to pay an additional $700,000 for software it had abandoned, it was subject to an attorney fee award, it lost all kinds of time dedicating resources to fight the case, it had to pay its own lawyers, and it ended up taking 5 times as long to reach it s goal (of an integrated system).
Second, even if you do not want to hire a lawyer to negotiate, at least make sure that the party providing the service has stated clearly in the agreement, the deliverable, what it will do, and what you expect from the service. We have reviewed too many scenarios to count where a client has signed a pre-printed form that had NO promises or very light ones, like this agreement. If it is a critical result that software X must interoperate with software Y, state that in the agreement.
Third, consider the remedy. Many contractual negotiations can get hung up on the representations, warranties, disclaimers and so on – when they can be resolved by thinking in the opposite direction – assuming a performance representation is not met, what is the remedy? Remedies range from the “nuclear” option (total contract termination), to some form of “notice and cure” to a repair, re-perform remedy.
Fourth, consider the term of the agreement. In the GMG case, the parties amended their agreement and made it a longer term agreement. Many vendors will offer more significant fee discounts, or less escalation, if the term is longer. These can be attractive deals – but consider that as with GMG, you may desire to move away from that solution. So, my rule of thumb on this point is . . . the longer the fixed term of the contract, the more closely you must negotiate it – and the more you must pay attention to escape hatches and “relief valves” if something changes. Technology changes very fast – locking into a vendor for 5 years (as was done in GMG) is almost unheard of. A three year deal presents enough technology-change-risk to be the outer limit of most of these deals.
I could go on, but if you made it this far . . . well, thanks!
For more information, contact Mike Oliver.
In a decision in the Oracle v Google case, the court held that APIs – application program interfaces – small amounts of human readable source code, are not sufficiently original to qualify as copyrights. This decision can impact API licenses, which most likely are based on copyrights.
What Google did. Google decided that to construct a mobile platform operating system (ultimately, the Android operating system) it wanted to be able to “interoperate” with java programs – in this way, developers could rapidly publish their programs written in Java, to the mobile platform. In order to do this, however, Google either needed a license to the Java virtual machine to allow it to “port” it to the mobile hardware, or it needed to emulate that environment. Google approached Sun (later bought by Oracle) for this license, but the parties never agreed. Google eventually copied the names of the base classes and methods, and wrote its own original code to implement the particular functions. So as an example, a Java program would call a function, using the precise identical name of the function, class or method, but the “behind the scenes” black box code in Android that returned a result, was written by Google and not copied from Java. Google did a few other things (for example, they decompiled some executable code in Java, and used the source code derived from that to test their own software compatibility, and they included verbatim 9 lines of code in a range check function, which the court utterly dismissed as De-minimis copying)
What Oracle claimed. Faced with having examined 15 million lines of code and discovering that only the structure, sequence and function was copied, Oracle took the position that it had a copyright in that structure, function and sequence.
What the court held. The parties had agreed that the issue of copyright was for the court to decide, with the jury being the arbiter of any infringement or damages. The court did a very good job of reviewing the history of protection of computer software – which really started in about 1980, with amendments to the Copyright Act that recognized computer software as a literary work. (this case is very well written and researched, so I can commend it to anyone who wants a crash course in software law)
The trouble with the copyright protection, however, is that copyrights cannot protect ideas – that is the exclusive domain of patent law. So, whenever a copyright expresses an idea, we often say that the idea is free but the expression of it may not be. However, where there is only a limited way of expressing the idea – courts hold that the idea then “merges” into the expression, becoming inseparable, and renders that particular expression free from copyright protection. That is what the court held here – essentially, the court said that if you want to protect the sequence, function and structure of how a software program works, you must use patent, and not copyright, law. This ended the case for Oracle, as Oracle had lost on patent infringement.
The court summarized the best argument as follows: “Oracle’s best argument, therefore, is that while no single name is copyrightable, Java’s overall system of organized names — covering 37 packages, with over six hundred classes, with over six thousand methods — is a “taxonomy” and, therefore, copyrightable under American Dental Association v. Delta Dental Plans Association, 126 F.3d 977 (7th Cir. 1997).” (emphasis added)
What impact does this case have? In the abstract, this case follows a fairly well defined line of cases that have denied copyright protection to such things as menu structures and programmatic access to underlying operating systems. In this regard, the case does not change the law. However, in a bigger picture view, and with particular reference to the amount of copying here – all of the main class and method calls in Java were replicated verbatim . . . it could be seen as a step toward requiring either very good contracting practice, or patenting, to protect access to a software language system. The only other way to protect access is under the Digital Millennium Copyright Act – installing and using a sufficient technological measure that must be decrypted in order to access content.
If a software developer desires to restrict access to base operating code, the Oracle v Google case poses a significant barrier to reliance on copyright alone. As stated above, the developer should consider proper contract language, patenting the system, and use of encryption technology to unlock such access.
For more information contact Mike Oliver.