• Getting to yes, but at what cost? Computerworld 15 June 2010

In New Zealand, several laws are relevant to allegations of deceit or misrepresentation in trade, the most significant of which is the Fair Trading Act 1986. The key part of this Act states that “no person shall, in trade, engage in conduct that is misleading or deceptive or is likely to mislead or deceive.” The Act cannot be excluded by contract, and applies to virtually all local commercial dealing.

…

BSkyB v EDS provides a useful example, applicable in New Zealand, of a vendor impliedly misrepresenting that there was a proper foundation for making a statement in a pre-contractual situation. The message is that such conduct (making a representation without foundation) may not simply be “negligent” or an oversight, but may be found to be deceitful.

Since publication, it has been announced that HP (which bought EDS) will pay a total settlement of £318 million (~NZ$680 million), and will not appeal the High Court judgment.

An amusing aspect of the trial involving a barrister’s dog is mentioned here.

The judgment itself is here.

In one case, the website terms were binding. In the other, they were not. These decisions do not change the law, but they are useful reminders not to overlook your disclaimers when designing a website.

Full article: Update on Enforceability of Website Terms, February 2010

Links to the cases:

• Major v McCallister, Missouri Court of Appeals, No. CD29871 (23 December 2009) [pdf]
• Hine v Overstock, US District Court E.D.N.Y. (4 September 2009) [pdf]

In the case Miller v Facebook (15 January 2010, US District Court, Georgia), the plaintiff claimed that part of Facebook’s terms and conditions did not apply – specifically, the clause requiring any claims to be brought in Facebook’s home state of California (known as a “forum selection” or jurisdiction clause). The court said:

“striking the forum selection clause could wreak havoc on the entire social-networking internet industry. If this court were to determine that the forum selection clause contained in Facebook’s TOU was unenforceable, the company could face litigation in every state in this country and in nations around the globe which would have potential adverse consequences for the users of Facebook’s social-networking site and for other internet companies”

The court therefore upheld Facebook’s forum selection clause.

Common law legal systems (such as New Zealand, the UK, the US and Australia) have long recognised “customs of merchants” (the lex mercatoria) in applying and shaping the law. There are good reasons why the common law has done so, going back many centuries: it provides certainty for commerce, recognised accepted “best practice”, and promoted uniformity conducive to trade. To ignore it would have been to potentially disrupt and destabilise commercial dealings.

For the same reasons, as the common law is continuously evolving, the customs of “e-merchants” should also be taken into account by courts.

This is likely to be relevant to the enforceability of website terms and conditions. There have been a number of cases in the past year involving disputes over whether or not website terms are binding (for example Website disclaimers – yes, they do work). Some have argued that a standard link to a disclaimer is insufficient. There are a number of legal grounds for finding it is sufficient (and a growing number of cases have upheld them – successful challenges are rare).

However, there is good argument that such practice is now also customary. Many websites have a disclaimer link, often at the bottom of the page. It is commonly understood that when you use a website, there may be “Terms of use” or “Disclaimer” link. That is accepted and, today, could be said to be the custom for online business. The common law should not disregard the accepted, reasonable and necessary practices established by modern merchants.

Although the Facebook decision is only a lower-court procedural ruling, it provides an encouraging demonstration of a court’s willingness to consider the new lex mercatoria (and other policy considerations), and the perils of the law ignoring them, relating to e-commerce.

In Jacobsen v Katzer (13 August 2008), a software developer (Jacobsen) had developed a Java-based software library for controlling model train sets. The software was released through the SourceForge website under the open source Artistic License (version 1). Another developer (Katzer) took Jacobsen’s code and included it in his own software – which is permissible under the Artistic License – but did not comply with the conditions of the licence.

Specificall, Katzer failed to:

• Include the original author’s name;
• Retain the original copyright notices;
• Link back to the SourceForge website; or
• Describe what modifications had been made to the original code;

as required by the licence.

Jacobsen took Katzer to court to prevent him from continuing to use the code in breach of the licence.

In Court, the fact that Katzer had not complied with the licence was not in question. The key issue was whether, having breached the terms, Katzer could be prevented from using the code. Katzer’s argument was (in effect) that even though he had breached the licence, Jacobsen suffered no harm (as the software was freely given away and able to be modified), and therefore on the usual contract law damages principles, Jacobsen had no remedy.

In a significant victory for open source licensing, the US Court of Appeals for the Federal Circuit (the 2nd highest Court in the US, one level below the Supreme Court) rejected this argument. The Court ruled that failure to comply with the terms of the licence meant that Katzer had no right to use the software. His use of the software in contravention of the licence was therefore not a simple breach of contract, but a breach of copyright. As a result, Katzer would have to stop using the software.

While open source licences have been upheld before, and this particular case was only a procedural hearing, the decision is still noteworthy for two reasons:

1. Collapsible software licensing

It provides an excellent example of a “collapsible software licence”. The right to use the software was held to be conditional on continued compliance with the terms of the license. Failure to observe those conditions resulted in the right to use the software collapsing, or never coming into existence in the first place. This is quite different from a situation where the right to use the software exists independently from the other terms of its use, and any breach of a term of the licence simply allows to the licensor to claim for damages (if the breach has caused any loss) but does not take away the right to use the software.

2. Strong endorsement of open source licensing

It provides a robust endorsement by a high-level Court of an open source licence and the conventions surrounding them. For example:

• The Court implicitly accepted that including the terms of a license in a file called COPYING – which is customary, though not universal, in open source project – are binding.

• The Court also accepted that conditions such as author attribution, preservation of notices and links back to the project website are enforceable, valuable terms that the licensor can insist must be complied with.

• The Court stated that just because open source software is free, that does not mean the license is unenforceable (on the technical legal grounds of lack of consideration). On this point the Court said:

“The lack of money changing hands in open source licensing should not be presumed to mean that there is no economic consideration, however. There are substantial benefits, including economic benefits, to the creation and distribution of copyrighted works under public licenses that range far beyond traditional license royalties.”

Relevance in New Zealand

While New Zealand courts are not bound by this decision, being a US court applying US law, it is still of relevance in New Zealand. The Court’s robust, straight-forward interpretation of the terms of the licence may be influential on a New Zealand court facing a similar situation. Furthermore, as software development is a particularly international industry, developers in this country may be able to point to the decision should questions arise as to the intended effect of using a similarly-worded licence.

One small difference does arise under New Zealand’s copyright law. Unlike in the US, in New Zealand the right to be identified as the author of a “literary work” (which includes software) is enshrined in section 94 of Copyright Act.

The emergence of agile development

Agile development emerged during the mid 1990’s and early 2000’s as a grass-roots reaction to the problems of traditional development experienced in many projects. There is no official definition but rather a set of principles, the most authoritative text being the Agile Manifesto.

Principles contained in the Agile Manifesto include:

• Customer satisfaction through early, continuous delivery of working software;
• Welcoming changing requirements, even late in development;
• Clients and developers working together throughout a project;
• Regarding working software as the primary measure of progress.

This requires a significant departure from the structured processes of traditional development. It allows developers and clients to adapt a project as it progresses. It allows software to be delivered and used continuously and problems corrected early and often. It encourages large projects to be broken into smaller projects, with functionality being added incrementally. It allows developers and clients to provide ongoing feedback and refinement as the system is developed. This dynamic can be invaluable in today’s business environment where businesses must be ready to adapt their business processes to meet market conditions and new technologies.

On the technical front, agile development encourages flexible system design through the use of software patterns, standards and best practices. Project management models have been created specifically for agile development and a range of sub-methodologies under the “agile” umbrella have emerged.

Agile development is not intended to replace traditional development but is an alternative methodology. Traditional development is still used on many projects and has many benefits. However, agile development has become increasingly popular, and by some estimates (see here and here) is now the predominant development methodology in use today.  It appears to be successful.  The Standish Group’s 2006 Chaos Report attributed the decreasing failure rate to 19% in part to agile development.  Other evidence supports this conclusion.

Contrasting traditional versus agile development

The following table contrasts key elements of traditional versus agile development.

These elements are discussed below.

Continuous delivery

It is common for software development contracts to define deliverables to be handed over at the end of a project. For example, the deliverables may be a functioning system meeting the contract specifications together with completed documentation and other supporting artefacts.

In contrast, agile development promotes continuous delivery throughout a project where incrementally updated versions of a system are delivered as they are available, with the objective being to enable the client to begin using the software as soon as possible, even if only for a subset of the final intended functionality. In this way, flaws in system design can be detected and remedied earlier than would be otherwise possible and feedback can be acted upon.

At this point, it is worth asking “why would anyone want to use an incomplete system?” The answer is, by breaking large projects into smaller projects, it can be possible for even a very complex system to be delivered incrementally. How each interim delivery should be used depends on the project, with options ranging from production use to basic testing, and go-live risk management provisions should always be in place. Ultimately the extent and manner in which continuous delivery is viable and sensible for a given project is a commercial decision.

In-project requirement changes

Every software development project needs some up-front requirements analysis. The extent and formality of the initial analysis phase will vary project by project. Traditional development relies on heavy up-front requirements analysis (Big Design Up Front) which is typically incorporated into a contractually binding specification. It is not intended that continuous or major changes be made to the specification during the project.

In contrast, agile development expects, and even welcomes, changing requirements during a project, even at a late stage. This is essential to agile development. It allows the project to develop and evolve incrementally and respond to changes in business processes that it seeks to implement.

This may appear contractually problematic, even dangerous, and indeed it would be if it were allowed to be uncontrolled. A sensible change process must always be defined, together with parameters to control project scope including technical direction, timelines and cost. There is no reason why agile development projects cannot utilise common contractual elements for controlling scope while still allowing the desired flexibility for regular requirement changes.

Collaboration

Collaboration in the sense of agile development means the process of ongoing, regular, formal and informal communication and co-operation between the client and the developer, even to the extent of working together on a daily basis throughout a project. This contrasts with the customer-vendor model of traditional development, where the developer works on a project off the specifications largely in isolation from the client and “hands over” the finished product at the end of the project.

While traditional development often utilises control groups, steering committees, scheduled reviews and the like as effective forms of client-developer collaboration, agile development seeks to go much further. Agile development advocates having representatives of the client and the developer working together constantly throughout the project. This raises potentially thorny legal issues such as representations, authorisations and estoppel. These are issues which must be considered both practically and legally in all software development projects and there is no reason why an agile development project cannot utilise the protections against these risks commonly found in traditional development contracts.

Again, the manner and extent of collaboration is a commercial decision for each project and the practicalities of this arrangement should be clearly defined at the start of a project.

Finally, in conclusion…

To lawyers, agile development may appear an unattractive or even counter-intuitive option when compared to a highly structured traditional development project. After all, how can a contract accommodate informal requirement changes, continuous delivery, close collaboration and other “agile” processes while still providing the clarity, safeguards and controls required in commercial dealings?

It must be remembered that it is the problematic rigidity of traditional development that agile development specifically seeks to avoid. This is not for the purpose of reducing liability of any party, but to reduce the risk of project failure. A heavyweight, rigid contract may provide greater advantages to a party in the event of litigation, but for some projects may actually increase the likelihood of litigation.

Whether or not to use agile development on any given project is ultimately a commercial decision. It is one that incurs a risk versus return trade-off like anything else and clients must be in a position to make an informed decision.

The key issue where agile development is desired is that the contract supports the necessary agile processes. Contracts used in agile development projects must be drafted to ensure that the agile processes are not curtailed by a contractual regime better suited to traditional development. This does not mean that contracts should be any less clear and precise than they otherwise might be, nor does it require the diminution of standard commercial safeguards and time and cost controls. But it does place a greater onus on the drafters of contracts to ensure that clients and developers can reap the benefits of agile development under a contract supportive of that methodology.

Agile development is a relatively new methodology for software development which has rapidly gained popularity. Much has been written on agile development in the technology media, however there is little mention at present in legal circles. Perhaps this is due to the subject being regarded as a technical issue best left to the IT crowd.

Lawyers involved in contracting for software development need to be aware of this now common methodology. This article outlines agile development and some of the contractual issues it raises.

Traditional software development

Software development has traditionally been viewed as a structured process, sometimes known as the “waterfall model”, where each phase of the project is clearly defined as part of a linear sequence. A typical project may be look like this:

• Phase 1: Requirements specification;
• Phase 2: Design;
• Phase 3: Programming;
• Phase 4: Testing and debugging;
• Phase 5: Deployment.

A project such as this, with discrete steps capable of clear definition and sequencing, is well suited to a structured contractual framework. Common elements of a contract supporting this model are:

• Comprehensive, detailed specifications;
• Formalised processes such as control groups and regulated variations;
• Segregation of responsibilities between the developer/vendor and the client;
• Strict timetables;
• Deliverables;
• Sign-off and handover processes.

While there are as many variants of software development contracts as there are projects, in this article a traditional software development contract is one taken to include the above as well as the usual commercial terms and exclusions.

Problems with traditional software development

As practitioners involved with IT and followers of IT media will doubtless be aware, software projects have historically failed at terrible rate. Way back in 1995, US consultancy The Standish Group conducted its inaugural “Chaos Report”, an annual study into development project failure. The first study reported that 31% of all development projects failed – that is, are cancelled and scrapped at some point – while only 16% were on-time and on-budget. The remainder are termed “challenged”, where the project is eventually completed, but is over-budget, over-cost or cut down from the original plan.

Through such studies and industry analysis, it soon became accepted that the “heavyweight” processes of traditional development are not always compatible with the highly dynamic modern business and technical environment. From a contractual viewpoint, the formalised specifications, processes and deadlines mandated for a project often conflict with the informal, complex and constantly evolving business requirements they seek to implement.

The problem as it relates to custom software development has even been judicially noted:

“[There] is a significant risk that a non-standard software product, ‘customised’ to meet the particular marketing, accounting or record-keeping needs of a substantial and relatively complex business … may not perform to the customer’s satisfaction”.

Watford Electronics Ltd v Sanderson CFL Ltd [2001] EWCA Civ 137

Of particular importance is the challenge of obtaining detailed and complete specifications at the beginning of a project. This is known as Big Design Up Front, and the output of the design is often used to form the basis of a contract.  In such cases, the success or failure of the project is dependent on the quality of the contracted specifications.

Unfortunately this has in many cases proved highly problematic. [For an early influential paper (1986) on the challenges of design see “A rational design process: how and why to fake it”]

While there are many causes of project failure and disputes, inadequate requirements are regularly cited as a leading cause.  Key problems, simply stated, include:

• Difficulties in documenting complex abstract business processes;
• Inability to completely specify requirements at the beginning of a project;
• Requirements changing during the course of the project (particularly for long duration projects).

Part 2 of this post discusses how agile development aims to address these issues, and the challenges for contracting such projects.