Negotiating indemnity clauses

Double_indemnityContractual indemnities are commonly sought in IT and software development / licensing contracts. While they are a relatively straightforward concept, they should should be carefully considered.

I have written an article on this issue here, covering key legal issues:

  • Indemnities vs warranties;
  • Types of indemnities;
  • When indemnities are appropriate;
  • Limiting indemnities; and
  • Key issues for negotiating an indemnity clause.

Of course, negotiations on indemnities will often be strongly influenced by bargaining power and positions, but it is always important (and useful in negotiations) to have properly assessed the legal/liability issues first.

Full article: Negotiating indemnity clauses

Assumed liability – an insurance issue for IT firms

assumeIt’s a good idea for software developers and other IT firms (or any professional services business) to have professional indemnity (“PI”) insurance. This insurance can provide cover and other assistance in the event of a customer claim.

However, it’s important to understand how your PI policy works. One important issue is that PI policies often exclude cover for what is known as “assumed liability”. This is essentially where you voluntary assume additional risk beyond what the law would normally impose, which is something that we occasionally see in commercial contracts. Beyond the general risks or assuming a higher level of liability, It is important to consider any potential insurance implications.

I have written an article on this issue here.

Clients naturally want “the best” from their service providers. However, service providers and other suppliers who agree to provide “the best” – or any standard or duty higher than usual – should be aware of the possible implications this may have on their insurance cover.

Full article: Exclusions for assumed liability

Using GPL code in your software

I’ve written an article on using GPL code in your software, covering “the essentials” on:

  • The GPL (GNU General Public License) and LGPL (Lesser GPL)   *US spelling…
  • Challenges of interpreting the GPL
  • Key legal issues when incorporating GPL-licensed code in proprietary programs
  • Issues and consequences arising from GPL violations.

The article doesn’t cover other open source licences. While GPL is the most well-known open source licence, an interesting issue is the apparent (let’s say alleged) trend away from copyleft open source licences (such as the GPL) towards permissive open source licences such as the Apache, MIT and BSD licences.

Whatever licence is used on a third-party components of your software, it is important from a legal and commercial perspective to ensure that you understand the implications. As outlined in my article, consequences of a GPL (or other) licence breach can include:

  • Liability to the licensor or an injunction;
  • Problems arising from IP audits or due diligence projects, which could have significant implications for a proposed business/asset sale, valuation, joint-venture or merger;
  • Breaches of IP warranties or other contractual obligations to end-users; and
  • Potential conflicts with end-user procurement policies (i.e. policies stating that all suppliers must fully comply with licensing requirements)

Update on Aussie price-gouging inquiry

An update on this post from almost a year ago about price gouging in Australia (and New Zealand) by tech companies.

Adobe appears to have bowed to public pressure and cut the price of some of its products – a day after being summonsed to the parliamentary commission investigating the rorts. Adobe had earlier refused to attend voluntarily, which seems a rather strange strategy when you know the result will be a parliamentary summons. Whether the timing of the cuts will help the company in the inquiry or be construed as an admission of guilt remains to be seen, but the timing suggests an attempt to stave off some criticism.

It seems that the price cuts apply to New Zealand customers too, which is only sensible given the proximity of the markets and the fact that New Zealand authorities have signaled they are watching the Australian inquiry with interest.

There is no doubt that New Zealand (and Australian) consumers have been paying far more for identical software delivered via the internet. Australians have seen prices for some digital products stay well above pricing for US customers even as the AUD  exceeded parity with the greenback. It is getting technically harder for companies to enforce regional pricing differentials, and also harder to justify to consumers.

Ironically, when I had to buy Adobe Acrobat last year I was able to pay far less than the online price by buying it (from all places) at Warehouse Stationery. It was the first time in probably 10 years that I had bought software in a box, and will probably (hopefully) be the last! The boxed version was exactly the same software as offered via Adobe’s online store, but much cheaper, even with GST added.

I reiterate that companies should be free to set whatever prices they want (subject to competition laws), but it is good that they can be held accountable by public pressure, competition, and light-handed oversight such as the Australian parliamentary inquiry, which in this case at least has already prompted a voluntary response.

Electronic Transactions Act (Contract Formation) Amendment Bill

A Bill to confirm that standard offer-and-acceptance principles applies to electronic contract formation has been drawn from the Members’ Ballot. It is the Electronic Transactions Act (Contract Formation) Amendment Bill, in the name of National MP Paul Goldsmith. The operative provision of the Bill reads:

“32A Contract formation

An offer that can be accepted by electronic communication is deemed to be accepted at the time of receipt of the acceptance by the offeror.”

Which simply confirms the general law that is presumed to apply anyway. The only exception is the old postal acceptance rule, which says that a contract is formed as soon as acceptance is posted in the mail (which could be several days before the offeror hears about the acceptance). There has been occasional talk over the years about whether the postal acceptance rule should extend to online scenarios – it’s good law school fodder – but the prevailing view is it should not. The issue was briefly considered in a 2009 Australian Federal Court case, Olivaylle Pty Ltd v Flottweg GMBH & Co KGAA (No 4) [2009] FCA 522, in which the judge concluded in effect that the postal acceptance rule should not apply to acceptance by email.

So it will be perhaps somewhat nice to have this confirmed, but having such an anodyne and relatively trifling Bill in the Members’ Ballot does raise the prospect of (smart) “ballot stuffing” by Government MPs, to reduce the chances of more controversial bills, such as same-sex marriage or euthanasia bills, being drawn!

How robust are your escrow arrangements?

My new Computerworld article talks about the “curious beast” of source code escrow:

The collapse of one of Telecom’s software providers Aldous demonstrates that the value of source code escrow is only as good as its implementation. This column looks at the Telecom situation, and outlines key components to a robust escrow arrangement.

One point of clarification is that my reference to “onerous” contracts does not refer strictly to the receiver’s powers, but to the receiver’s role, and if (as often happens) a liquidator is subsequently appointed, then the liquidator has express powers to disclaim onerous property.

The judgment referred to in the article, Telecom New Zealand Ltd v Aldous Ltd (in Rec) [2012] NZHC 1501 is not yet publically available, so I have attached it to this post (download here).

The situation confirms my thoughts about source code escrow a few years ago:

Except for special/high-end situations, code escrow has become increasingly irrelevant and has probably long been more hassle than it’s worth.

The impact of cloud computing / SAAS is also counterintuitive to source code escrow. I expect that data escrow will emerge as the more relevant consideration in the future.