Law and technology

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.

It is too early to tell whether the collapse of the Government – Microsoft “G2009″ licensing negotiations signals a desire by the Government to see an increased use of open source software. Certainly, the Government should be actively considering OSS for reasons of economy (at least as a bargaining chip in future commercial negotiations) and, more importantly, to develop its own (shared) intellectual capital in our public IT infrastructure.

The sticking point has always been support. The question is often framed thus: How can a Government agency, or any commercial / professional organisation for that matter, responsibly afford to risk using software that doesn’t have the backing of a major commercial vendor? To adapt an old adage, nobody ever got fired for buying Microsoft.

The term “support” here is used broadly and includes: helpdesk services, on-site support, bug-fixes, training, documentation, upgrade paths and the general “comfort” from dealing with a reputable commercial vendor (also known as “having someone to sue if it all turns to custard”). At least anecdotally, these are often raised as factors for ruling out a non-vendor-backed solution.

But how real is the “support” gained from dealing with a commercial vendor? Let’s consider each type of vendor support mentioned earlier, in the context of a major customer such as a government agency:

In summary: standard contracting and licensing practices mean that commercial software vendors actually give very little, if anything, in the way of “support” to customers, other than what the customer and vendor are prepared to expressly include and pay for.

However, it is important to separate the “support” arising from the software license (and the fact it is provided by a major vendor) from support (and other rights) arising under a commercial contract. Virtually all software licenses exclude all forms of liabilities and warranties to the fullest extent permitted by law (which in the case of business customers can be everything). Open source licenses such as the GPL are no different in this regard. The nature of software is such that it is infeasible to accept such liability or provide other than the most trivial warranties. Therefore they are customarily all excluded (and often in upper-case text for some reason), and most software vendors – closed or open source – are very reluctant to change their license terms.

The rights gained by a customer under the commercial or services component of a deal are quite different, and can be negotiated on a case-by-case basis. The obligations of the service provider (the software vendor or a third party) to support, integrate, implement, customise, etc., will be whatever the parties agree upon.

This is where OSS has the potential to shine, as both customer and service provider can contract with the comfort and knowledge of having:

1. Full, unrestricted access to the source code;
2. The ability to fix, modify, maintain and document the software;
3. The freedom to recontract with another service provider should the need arise.

This arguably provides a higher level of “support” (as defined above) than dealing with a commercial vendor ever could. This is particularly so when, as is often the case, the customer is not actually licensing software from the entity it is dealing with. For example, Microsoft New Zealand Limited may negotiate a licensing deal, but the software license is actually a contract between the customer and Microsoft Corporation in the US – a separate legal entity (although the customer’s commercial contract may be with the New Zealand entity).

If a technology decision is made in favour of OSS, it should not be overruled on the basis of a commercially-supported solution if the “support”, on closer inspection, is in fact illusory.

Two recent events concerning trade marks, one in New Zealand and one in the US, highlight the same underlying issue, albeit in different ways.

The first incident: local blog Editing the Herald received a cease-and-desist letter from APN, publisher of the NZ Herald, on the basis that EtH was using a modified version of the Herald masthead, a trade mark of APN.

The second incident: the author of a book on Ubuntu, whose website used the Ubuntu logo without authorisation from Canonical (owner of the US Ubuntu trade mark) sparked much comment by claiming that “trademarking is almost totally incompatible with the essential freedom offered by open source. Trademarking is a way of severely limiting all activity on a particular product to that which you approve of.”

Both of these incidents highlight that trade marks are not about “ownership” in the way that copyright is, but are about identity and origin. As the Intellectual Property Office of New Zealand says:

“A trade mark enables businesses to distinguish their products or services from similar products or services offered by competitors.”

If you are the registered owner of a trade mark, then you have the exclusive right to use that trade mark in connection with the products and services that it covers. If anyone else uses your trade mark (or something similar to your trade mark) without your permission in the course of trade, you are entitled to take action against them. Use of a trade mark that is not in the use of trade is not infringement, however the meaning of “in trade” is wide.

It is important to note that a trade mark will usually only apply to the goods and services that it is registered for. That is, it does not amount to a blanket monopoly on a word or phrase. For example, the word Kiwi is registered as a trade mark by a number of companies for different products such as shoe polish, bacon, beer, milk and packaging. If you owned the Kiwi trade mark for beer, you could not prevent someone using the Kiwi name to sell clothing, for example.

The trade mark (logo) for “New Zealand Herald” is registered for the following goods and services:

“printed matter; publications; paper and cardboard; stationery; posters and photographs; instructional and teaching materials (except apparatus)”

and

“publishing; electronic publishing; education, entertainment and cultural activities in this class including (without limitation) the organisation and running of competitions for education and/or entertainment; information services (including, without limitation, on-line information services) relating to education or entertainment”

The terms “publications” and “publishing” are very broad, and would clearly apply to someone publishing a blog. So using the New Zealand Herald logo (or an imitation of it) on a blog without authorisation would infringe the trade mark, if the use is “in trade”. But is a non-commercial blog “in trade”? EtH sums it up well: “I would have at least an arguable case in court but it would cost both money and time, only one of which I have in appreciable amounts”.

Should there be “parody rights” for trade marks? Probably not – trade marks are used to designate origin, not protect content. Copyright, on the other hand, should expressly protect parody as fair use.

As for the trade mark and open source issue, this is far from the first time it has arisen. Indeed, early on in the history of Linux, one opportunistic William R. Della Croce, Jr registered the US trade mark Linux and attempted to extract royalties for its use. Fortunately the matter was soon resolved, and the US trade mark is now owned by Linus Torvalds.

The Ubuntu author’s statement that trade marks are “totally incompatible with the essential freedom offered by open source”, is off the mark. The “essential freedom” of (fully) open source software is that you are free to copy, modify and redistribute the code. If someone releases software under their trade mark, you are free to take their code and re-release it under your own name or trade mark (subject, of course, to any terms and conditions of the specific licence such as attribution). Of course, the trade mark owner may allow you to release it under their name. But that is their choice. The unfettered ability to release software under any given name (and therefore possibly mislead as to its origin) would certainly be a “freedom” but is not the essential freedom.

The inverse makes the point. It would be unfortunate if a someone could simply take any well-known open source project, modify it into a buggy version, and then promote it under the original name. Admittedly, in some cases the issue is slightly less clear cut, as in the Firefox / Iceweasel tussle. In that situation, a more light-handed trade mark policy may have solved the problem.

Ultimately, it is the “essential freedom” that wins the day. If a project becomes too oppressive on a matter such as trade marks, it can be forked and rebranded, the prospect alone of which may help common sense to prevail.

A recent court case in the US upheld an open source software licence in a way that is important for two reasons.

Continue reading ‘Open source enforced’ »