By focusing on the technical weakness inherent within the job specification that the client has signed off on, and forcing variation to contracts as they work their way through, even though the supplier knew at the start that they could not meet timeframes and delivery targets, the multinational easily arm-wrestles the hapless customer to fund excess profitability. These projects follow the same pattern over and over again, they become five to six times over budget – a $20 million project can turn into a $120 million one. The supplier knows that walking away is not an option for these clients.

While Gareth addresses a broader issue, many of the problems he discusses arise from poor contacting. There are a number of problems endemic in IT project contracting:

• The project is simply contracted far too large.
• The contract relies on the often faulty assumption of Big Design Up Front.
• The contract is prepared as if it were a construction contract.
• The contract is only seen as “safe” if it nails down every last detail, and only allows changes through variations, which as Gareth says usually produce poor results.
• The contract imposes completely unrealistic and ineffective “project management and control procedures”, that are either never used or are simply “caught up” on from time-to-time.
• The contract is usually in conflict with the “agile intention” of the project (whether or not an agile methodology is actually going to be adopted).

I have written about some of these problems (and overcoming them) here: Contracting in an agile world (part 2 here). The solutions are not complicated, but when contracting is seen as a contest (which party can tie the other up the most?) the result can be a contract that’s more useful when the project actually fails, than facilitating the project’s success.

When the cost of IT failure in New Zealand is $5.4 billion a year, it pays to get the comparatively small matter of contracting right.

An important thing to remember: it is often a lot easier to implement this model at the start of a business / project than once it is in place. It is usually not difficult per se to achieve after the business / IP is up & running, but there can be tax & accounting issues to deal with.

• Article: Firewalling your intellectual property from creditors (Computerworld 18/11/09)

They had a commercial model, in that they sold their software and did not want to “give it away” as open source just yet. But they still wanted to be able to provide their customers with the source code – not because their customers actually needed it, but in order to be “transparent” and provide customers the assurance of having the source code.

Two points came to mind:

1. “Source available” != open source. Not for any reason of semantics (semantically, I think it’s acceptable to say open source == source available), just that open source now has a fairly well understood meaning which includes redistribution and other rights. It could be confusing to customers to label a restricted “source available” model as open source. I wouldn’t go as far as calling it misleading and deceptive, but I would recommend using an alternative term if what is being provided is outside of a commonly accepted meaning of open source.
2. If all you want to do is provide your customers with source code for your proprietary software, there is no need to use a “standard licence” (and little point). There are a few such licences in use – the Microsoft Reference Source License probably being the most common – but these are very basic (which is all they need to be) and not comparable to the GPL, Apache, etc.  A few extra sentences in your standard proprietary license can do the trick just fine.

The growth of open source means that the source available model (I’ll stick with that term for now) will become increasingly common for proprietary software. Probably the best example is Microsoft’s shared source initiative, which has been around for a couple of years now, although this does provide more liberal licensing than the example I’ve given.

Source available will also, in most cases, supersede the little-used (but often cited) code escrow model. Except for special/high-end situations, code escrow has become increasingly irrelevant and has probably long been more hassle than it’s worth. (Has anyone actually called on a code escrow? If so, what did they do with the code?)

So why would a proprietary software developer want to supply their source code on a no-redistribution basis? Three reasons are:

• To give customers the ability to audit their code (or at least to know it is auditable).
• To give customers some assurance of being able to fix their code and modify/ /integrate the code for in-house purposes (the code escrow purpose).
• To improve interoperability.

The down side is that the developer would generally lose any technical ability to control distribution or copying of their code, whether or not that is legally permitted by the licence.  This may be critical where the code itself constitutes a trade secret, such as for high-end complex applications, code implementing proprietary algorithms / processes, and applications with significant market value.  In such cases, if the developer nevertheless still wants to provide the source code, a contractual indemnity (i.e. requiring the customer to indemnify the developer for the customer’s breach) may be appropriate.

However, in some cases this “down side” should be weighed against the decreasing costs of development. The barriers to entry for software development are continually lowering. Free IDE’s and platforms and better tools and libraries continue to make software development quicker, easier and (supposedly) cheaper. Open source development provides vast free resources to projects.

As a result, some proprietary source is not the asset it used to be. Consequently the commercial value of maintaining source code as a trade secret has decreased; not yet to any critical degree – there is no question that proprietary software continues to be an exceptionally successful industry model – but enough to make services and subscriptions an important strategy for many proprietary developers. It may make commercial sense to accept some of the downside risk for the up-side benefits.

Key points

Some key points for licensing on a source available, no redistribution basis:

1. If you do not intend the customer to disclose the source (if you did, you probably want an open source licence), make sure it is covered by a confidentiality provision.
2. As with all confidentiality agreements, make sure the “confidential information” is properly defined. A classic mistake is to impose an obligation of confidence over ill-defined (or even undefined) material.
3. Specify what the customer is and isn’t allowed to do with the source. Can the customer create and distribute derivative works? Can the customer adapt the work in-house? Must the customer provide any improvements back to you?
4. The source code should not be assignable, sub-licensable, etc, without prior written consent.
5. The licence should be “collapsible”, i.e. the licence should automatically terminate upon certain events such as insolvency of the customer.

Since 2003, the Consumer Guarantees Act 1993 (NZ’s primary “consumer protection” law) has specifically included software in the definition of “goods“. This means that software developers (as “manufacturers”) must provide the same consumer warranties as makers of physical goods. At first, this does not seem too surprising. After all, why should a customer not have these rights when they buy software for domestic use? If the Consumer Guarantees Act applies to computer hardware, why not the software that comes with it?

Among the warranties that the Consumer Guarantees Act imposes on software developers:

1. A guarantee that the software is of “acceptable quality” (what this means will depend on the circumstances – it is highly improbable that software would need to work perfectly to be of “acceptable quality”);
2. A guarantee that the software will comply with any description provided by (or with the consent of) the developer (this could include statements on the developer’s website or in a manual);
3. A guarantee that the developer will take ensure there are “facilities for repair of the goods” (i.e. fix the software – this is an example of the Act, which was intended for physical goods, sometimes requiring awkward interpretation and a small amount of artistic license to accommodate scenarios involving software)

The above rights are only the consumer’s rights against the developer. Consumers have additional rights against the supplier (e.g. in the case of commercial/retail software, the shop where you bought it), and the supplier will usually be the first point of redress. For consumer (i.e. non-business) purposes, the Consumer Guarantees Act cannot (in most part) be contracted out of, and it is an offence to attempt to do so.

While the extension of the Consumer Guarantees Act to apply to software passed without much fanfare, the EU’s proposal to do the same thing has created some small controversy. The EU proposal has been criticised by the Business Software Alliance, representing major software makers including IBM, Apple and Microsoft. The BSA has stated:

“Digital content is not a tangible good and should not be subject to the same liability rules as toasters… Unlike tangible goods, creators of digital content cannot predict with a high degree of certainty both the product’s anticipated uses and its potential performance.”

These are valid concerns. The unique nature of software makes it inappropriate to simply apply “faulty product” rules that apply to physical goods. As software is entirely intangible, it only “exists” within a virtual environment. The software developer cannot necessarily control the hardware, drivers, libraries, settings and other parts of the environment that their code needs to run properly. If their software does not work correctly, who determines if it is actually a bug in their software, or a bug or malfunction or misconfiguration in some other part of the environment? And who says it’s a bug – it may be a feature request!

Of course, virtually all software has genuine bugs and vendors / maintainers are usually very open about them; such is the nature of software development. Patches and updates are commonplace, and a consumer could certainly not reasonably complain if they fail to keep their system up to date.

But where a product does have a significant bug, is it reasonable for the consumer to have legal rights under the Consumer Guarantees Act against the developer? Opponents are not against having some consumer rights for commercial consumer software. The concern is that a poorly drafted law (such as an amendment like that made in New Zealand to the Consumer Guarantees Act) may force software developers to, in effect, support other companies’ software and hardware, and continue to provide support for obsolete products (either their own or someone else’s).

The amendment to our Consumer Guarantees Act in 2002 gained little attention and, to date, has had little known impact on software developers. This is partly because New Zealand is a relatively small market for the (mainly) US-based software vendors. More importantly, New Zealand does not have an established “class action” legal process. In a recent New Zealand case the Court of Appeal noted its concerns at the “lack of development” in this area, and proposed a law change to improve the situation. By contrast, in Europe and in the US, class action lawsuits have proven lucrative for consumers “harmed” by a product – and very costly for manufactures. An amount of damages multiplied by (potentially) millions of consumers equates to serious money.

Another interesting angle is the impact on open source development. Under the Consumer Guarantees Act, the fact that software is provided for free by a non-commercial body is irrelevant – the Act still applies. It is hoped that if the EU proposal moves ahead, this is not the case. In 2007, key Linux kernel hacker Alan Cox appeared before the House of Lords to argue that open source developers should not be liable for their code. Given that much more open source development occurs in EU nations than most other places, the impact could be significant.

If the EU proposal moves ahead, the extent to which it impacts software developers – commercial and open source – will take some time to be seen.

Note: the Government is proposing to repeal this rule. As of April 2009, the amending Bill (carried over from the previous Labour-led Government)  sits at number 18 on the Government’s Order Paper (right after the Dog Control Amendment Bill), so the rule may not be repealed for some time.

The commissioning rule – who owns 1^st copyright in code?

If a software developer is hired (i.e. “commissioned”) by a customer to develop some code, an important question is who owns the copyright in the resulting code – the customer or the developer? The rule that governs who owns commissioned works is known as the commissioning rule, which in New Zealand is contained in section 21 of the Copyright Act 1994. Under that rule, the answer will typically be one of the following scenarios:

1. If the software developer is a person (as opposed to a company) who was hired as an employee (part time or full time) by the customer, then the customer (i.e. employer) will own the copyright in any original code produced by the developer.
2. If the software developer (either a person or a company) is contracted by the customer to produce some code, and is to be paid for it, then the “default rule” is that, again, the customer will own the copyright in any original code produced by the developer. Importantly, the customer will have ownership of the software whether or not they have actually paid the developer for it.
3. If the software developer (either a person or a company) is contracted by the customer to produce some code, and both agree that the developer will own the copyright, then the developer will own the copyright in the code they develop for that customer. The agreement would usually be in writing (though it need not be a formal, or even signed, contract). A verbal agreement will suffice, though without any written evidence, it may be difficult to prove what was agreed.

The simple rule is that if the software developer and the customer agree in advance as to who will own the copyright, then that agreement will prevail.

However, in reality as many will know, the contracting/paperwork side of software development can be a bit of a mess. Projects are started without contracts being place, undocuments variations and “sub-projects” may emerge, “interim” off-contract solutions are implemented, and final agreements may never be signed.

In particular, with the increasing use of agile development methodologies, the emphasis is even more on delivering working code than negotiating contractual terms – though as always, getting a contract in place before starting is highly recommended.

When the parties have not agreed (usually in writing) who will own the copyright, then the “default rule” is that the customer will own the copyright (scenario 2 above).

Copyright ownership and code reuse

Copyright ownership is of particular importance to software developers who reuse code – which means virtually all developers. Simply, unless a developer owns copyright in some particular code (or obtains an appropriate licence), they are not entitled to reuse that code anywhere else. This applies even if the developer wrote the code themselves – no copyright ownership, no reuse. If the developer does not own the copyright, then the copyright owner’s approval (or their authorised licensee) must be obtained.

This is the basis on which open source software works. Under the GPL version 3, for example, a developer is licensed to reuse the code as they see fit (subject to some conditions). The developer does not actually own the copyright of the open source code they are reusing, but they are licensed by the copyright owner(s) to reuse the software in their projects.

For in-house code libraries, it is essential that the developer retains copyright in the relevant code they develop. Often, this code will not be of particular commercial value to any one else but the developer who wrote it, but it is very valuable to the developer to be able to reuse it in other projects. It should be noted that if a developer already owns copyright in code that is used in a customer project, then the developer will not be at risk of losing that existing copyright. But if the code library is modified, then the copyright in those modifications may be be deemed to be owned by the customer. It is easy to imagine how this could potentially result in complex, tangled situations.

Unfortunately, it is not possible to retrospectively “claw back” ownership of code that has been developed for and owned by another customer. In this situation, the developer would need to get the customer to assign (e.g. transfer ownership of) the copyright to them. If the customer wants to own the copyright of code they have paid for – which is perfectly reasonable – then the developer may want to either separate out and retain ownership of common, generic code that they intend to reuse on other projects, or license back such code.

In any case, it is much easier to deal with these issues at the outset of the project, in the form of a clear, easily understood contract.

A software project that starts life as an informal “plan” between friends has the potential to become problematic, if essential terms are not decided at the beginning. Often, the informal and casual nature of a software project, which at first is an advantage, becomes the source of problems once money (income or expenditure) is involved.

When two people come together specifically to work on a software project, there is a good chance that they have created what the law terms a joint venture. People often think of a joint venture as a large project between big companies. But joint ventures can arise in many situations, from the very large to the very small.

A joint venture is not recognised as a separate legal entity such as a company or a partnership. But it is recognised by the law. The term “joint venture” describes a relationship between parties working together to achieve a common objective and may be as formal or informal as the participants want.

How is a joint venture established?

A joint venture can be formed by contract, but it can also be formed automatically when two (or more) people begin working together on a common project. There is no need for any written documentation between the parties. The key requirement is that the parties intended to form a joint venture:

“The essence of a joint venture which is not yet contractual is that it is an arrangement or understanding between two or more parties that they will work together towards achieving a common objective. … A joint venture will come into being once the parties have proceeded to the point where, pursuant to their arrangement or understanding, they are depending on each other to make progress towards the common objective.”

Chirnside v Fay (6 September 2006, NZ Supreme Court)

It does not matter how formal or informal the arrangement was. As long as the elements described above are present, the law may recognise that a joint venture exists.

So I’m in a joint venture – what difference does that make?

In general, joint ventures impose a relationship of trust and confidence on the parties to act in good faith towards the objectives of the venture.

“[Each] party is entitled to expect from the others loyalty to the joint cause, loose as the formalities of the joint venture may still be”.

Chirnside v Fay (above)

In practice, this means:

• A party must not compete against the joint venture;
• A party must not undermine the joint venture;
• A party must not exclude another party from the venture, act disloyally or misappropriate the work product that the parties had developed; and
• A party must keep the commitments they have promised to the venture (e.g. to spend a certain amount of time on the venture).

To put it bluntly: you can’t screw over your partner.

If you have been working with a friend on a software project joint venture, it may come as a surprise to find out that you are “bound” by legal duties, especially if you have not signed anything or put anything in writing. But it is a mistake to think that our legal system only operates on strict black-and-white lines.

Our Courts retain what is called an equitable jurisdiction which (as the name suggests) is founded on principles of equity. A primary objective of the law of equity is fairness. If you have put in a lot of time on a joint venture with a friend, how fair would it be for your “friend” to walk out at the last minute and set up a competing venture, using all of your commonly developed ideas and know-how?

This is what happened in the case of Chirnside v Fay (above).

Similarly, the law can prevent one party in a joint venture from free-loading off the work of the other. If you had committed to put a reasonable amount of time and effort into the venture and didn’t, then you probably cannot complain if your joint venture partner wants to continue the project by him or herself. This is an example of the law of equity’s “clean hands doctrine“. This says that “one who comes to equity must come with clean hands”. That is, you must have acted fairly yourself in order to obtain a remedy against the other person.

However, much depends upon what the parties are taken to have intended. If it is clear that the parties never intended to form a joint venture, or only intended a very limited co-operation, then the parties will have lesser duties to the joint venture.

Similarly, participating in a joint venture does not prevent the parties from have existing businesses or jobs. Indeed, many joint ventures are set up as “side projects” and are intended to be performed in the parties’ spare time. In such cases, there is likely to be only a low level of time and effort required by the parties to meet their commitments to the joint venture.

My next post will talk about how to avoid these risks at the outset.

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.