Law and technology

Gareth Morgan has written an interesting article (a follow up to this one) discussing the “systemic failure to be more successful in using IT to capture material productivity improvements”:

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.

In this week’s Computerworld, I have written an article on how intellectual property can be protected from trading risks. Software developers and tech companies in particular should consider implementing this sort of model. It is common for businesses in other industries to do so, but technology firms for some reason often do not.

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)

Someone recently asked what open source licence would enable them to provide their customers with source code, but prevent the customer from redistributing or reselling that code.

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.

Should software developers be liable for their code? While the EU is currently debating this question as part of a proposal to extend consumer guarantee laws to cover to software, New Zealand has had such a law in place for over 5 years.

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.

New Zealand’s copyright laws contain an important feature known as the “commissioning rule”. Software developers – whose stock in trade is intellectual property – need to beware of this rule.

Note: the Government is proposing to repeal of 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.

Continue reading ‘Copyright ownership and software development’ »

“The road to hell is paved with good intentions”.

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.

Continue reading ‘Joint Ventures in Software Projects, part 1’ »

For part 1 of this post, click here

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.

Continue reading ‘Contracting in an agile world, part 2’ »

Are your contracts agile? If you are involved in contracting software development it is worth asking that question.

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.

Continue reading ‘Contracting in an agile world, part 1’ »