Law and technology

Legal risks for IT pros

InfoWorld has an article on lurking legal gotchas (and how to avoid them) for IT pros. Its list includes:

• Confidentiality and privacy violations
• Pornography use
• Copyright and source code violations
• “Financial shenanigans” – essentially fraud or other criminal activity.

The article is based on US law, but the above list is applicable in New Zealand. However an important distinction not made entirely clear is that between intentional (i.e. malicious) activity and accidental contravention. Also, in most cases employees who are honestly carrying out their job are entitled to be indemnified by their employer for any liability arising against them personally (subject to employment contracts and other factors). Independent contractors are generally liable for their own actions, however, and insurance is an important risk management practice for contractors.

Open source wrangling

Computerworld reports on a controversy over whether a US company has breached the GPL terms of the R statistical software (developed out of Auckland University and the original version of which I used in stage-1 stats). The company, Revolution Analytics, denies breaching the GPL. It uses the increasingly popular (but sometimes controversial) “open core” model where (for example) the core program remains licensed on open terms, but other components and add-ons are under proprietary licenses. The situation highlights the sometimes murky issue of copyright ownership, assignment and licensing in large open source projects. Another example, involving OpenOffice, is reported here.

Copyright vs Contract law

A UK government advisory board, the Strategic Advisory Board for Intellectual Property, has completed a lengthy report (182 pages, 6MB pdf) on “the relationship between copyright and contract law”. The highly academic report appears to be a last hurrah for the quango, which is to be axed. The report is based on extensive research into “creator contracts” – i.e. supply side contracts such as those entered into by authors, musicians, artists, etc – and “user contracts” – i.e. demand side contract typically involving licensing of IP to end users. A summary of the fairly impenetrable report is here.

Computerworld reports:

A requirement that a component of a government IT tender be open-source has sparked debate on whether such a specification is appropriate.

The relevant part of the RFP (for the State Services Commission) puts the requirement as follows:

We are looking for an Open Source solution. By Open Source we mean:

• Produce standards-compliant output;
• Be documented and maintainable into the future by suitable developers;
• Be vendor-independent, able to be migrated if needed;
• Contain full source code. The right to review and modify this as needed shall be available to the SSC and its appointed contractors.

The controversy is whether this is a mandate of open source licensing (which it isn’t). The government should not mandate open source licensing or proprietary licensing on commercial-line tenders. More precisely, it should not rule solutions in or out based on whether they are offered (to others) under an open source licence. The best options should be on the table.

The four stated requirements are quite sensible. As the SSC spokesman said, there is nothing particularly unusual about them in government procurement. These requirements (or variations on them) are similarly common in private-sector procurement and development contracts. In the public sector in particular though, vendor independence and standards-compliance help avoid farcical situations like the renegotiation of the Ministry of Health’s bulk licensing deal.

Open standards and interoperability in public sector procurement is gaining traction around the world. Recently, the European Union called for “the introduction of open standards and interoperability in government procurement of IT”. And in the recent UK election, all three of the main parties included open source procurement in their manifestos.

So why the controversy in this case? Most likely it’s the perhaps inapt use of the term “open source” in the RFP (even though the intended meaning is clarified immediately afterwards). The term “open source” is a hot-button word that means many things to many people, but today it generally means having code licensed under a recognised open source licence, many of which are copyleft. Many vendors simply could not (or would never want to) licence their code under such a licence, and it would be uncommercial and somewhat capricious for a Government tender to rule out some (or even the majority of) candidates based on such criteria.

However, it is clear that the SSC did not use the term in that context, and does not intend to impose such a requirement. An appropriate source-available licence is as capable of meeting the requirements as an open source licence (see my post on source available vs open source). The requirement for disclosure of code to contractors and future modification can be simply dealt with on standard commercial IP licensing terms.

A level playing field for open and proprietary solutions is the essential starting point, with evaluation – which in most cases should include open standards and interoperability – proceeding from there.

Technology policy and law is featuring prominently in the UK election campaign currently underway, with issues such as cloud computing, open source procurement and data protection finding their way into manifestos:

• Lib Dem manifesto focuses on ‘better’ IT procurement

“The Liberal Democrats’ election manifesto published today (14 April) called for improved government IT procurement, including the use of cloud computing and open-source software.”

• Tory manifesto: We will freeze new government IT spend

“The Conservative party has reiterated its plans to freeze major new IT spending and make changes in government procurement in its election manifesto… The Tories also pledged to create a “level playing field” for open source IT in government procurement, and to break up large IT projects into smaller parts to enable SMEs access to contracts.”

• Labour manifesto’s IT pledges: A triumph of hope over experience?

Labour repeatedly highlighted the importance of IT in its election  manifesto, which was launched today, but made few new IT-related promises.
The Labour Party stands on strengthening the digital economy, using open source in government IT …

• Election 2010: Pirate Party on tech (which deserves a mention as a tech-specific party!)

“Despite the name, the Pirate Party isn’t just about file sharing. Yes, it wants to ensure a right to file share, as well as format shift – such as moving songs from CDs to iPods, which is currently technically illegal. It also wants to cut copyright from 70 years to 10 and put labels on products to warn of the “defect” of DRM… On top of that, the party would ban spying on communications, end “compulsory ID cards” and toughen up data protection laws.”

More links on tech policies from: the SNP and Plaid Cymru, and the Greens.

Clearly, IT is figuring much more prominently in the upcoming UK election than in New Zealand’s last election in 2008. One reason is that the UK has suffered a number of major IT project blow-outs in recent years (such as the disastrous £12.7 billion NHS National Programme for IT) that have basically become minor election issues.

There are signs that technology is featuring more prominently in New Zealand’s political scene, though hopefully this will not be due to scandals over failed government IT projects.

However, the cynical last word must go to the Inquirer:

In short if you want to vote for someone on the basis of their enlightened IT policy you would be better off spoiling your ballot.

Proposal to ban software patents irks patent attorneys…

Two patent-specialist law firms have criticised the Commerce Committee’s recommendation to ban software patents in New Zealand (read here and here). Both express surprise that the Committee appears to have accepted submissions by open source proponents, as if that alone is reason not adopt the report. The articles do not accurately represent this arguments, in my view, and the New Zealand Open Source Society has now provided a response.

While another says “stop wasting money on patents”

US intellectual property lawyer Erik Heels writes:

In most cases, filing a patent application is a waste of time and energy. Especially for startups. Your money and time would be better spent hiring programmers, marketers, and a sales force.

This is good advice for New Zealand businesses, especially tech start-ups. As Erik says, it can make sense in some cases, but at least consider the definite immediate opportunity costs versus the possible future benefits (and hidden costs to attain those benefits) of seeking a patent.

Historical legislation online

The Parliamentary Counsel Office has begun digitising historical legislation dating back to 1841, to be provided free online. Historical legislation doesn’t only have historical interest value, it can also have practical uses – such as providing a comparison to assist interpretation of current laws. While the first step involves simply scanning the old legislation (including the “shattering statutes“), longer term the plan is to OCR the documents into the excellent New Zealand Legislation website.

The Select Committee examining the proposed Patents Bill has recommended that software patents be excluded from patentabilty (full report, 1.6MB PDF):

We recommend amending clause 15 to include computer programs among inventions that may not be patented. We received many submissions concerning the patentability of computer programs. Under the Patents Act 1953 computer programs can be patented in New Zealand provided they produce a commercially useful effect. Open source, or free, software has grown in popularity since the 1980s. Protecting software by patenting it is inconsistent with the open source model, and its proponents oppose it. A number of submitters argued that there is no “inventive step” in software development, as “new” software invariably builds on existing software. They felt that computer software should be excluded from patent protection as software patents can stifle innovation and competition, and can be granted for trivial or existing techniques. In general we accept this position.

It is great to see the committee has accepted the core arguments put forward by a range of submitters (including myself) and rejected the opposing views put forward against those arguments. The mention of open source is significant and quite likely the first time it has directly influenced policy.

The actual proposed amendment implementing the ban is straightforward:

15(3A) A computer program is not a patentable invention.

The committee has not attempted to define “computer program”, which is sensible and consistent with the use of that term in the Copyright Act 1994. The amendment is not wide enough that it will necessarily prevent someone attempting to dress up what would otherwise be a software patent application as a business method patent. But it will be highly effective in most cases, and should prevent the worst examples of software patents granted (or threatened) overseas from being replicated in New Zealand (e.g. 1-click).

The House will need to vote on the proposed changes to the Bill.

The committee also discussed embedded software:

While the bill would provide adequate incentives for innovation, however, we are aware of New Zealand companies who have invested in a significant number of software-related inventions, involving embedded software.* We sought advice on the approach
taken in other jurisdictions such as the United Kingdom and the United States, and whether legislation that would enable “embedded software” to be patentable might be practicable. After careful consideration we concluded that developing a clear and definitive distinction between embedded and other types of software is not a simple matter; and that, for the sake of clarity, a simple approach would be best. We received advice that our recommendation to include computer programs among the inventions that may not be patented would be unlikely to prevent the granting of patents for inventions involving embedded software.

Software in any form would likely be caught by the proposed section 15(3A), but the final sentence of the above quote reflects the fact that it will not be possible, or practical, in many cases to separate the embedded software from an invention. It is important to note that the proposed Bill does not expressly endorse embedded software patents, but as with business method patents each application will need to be assessed on its merits.

Mozilla Public License

The Mozilla Public License is going to be redrafted.  Although this license is only used by about 2% of open source projects, it is the main license used by Firefox and Thunderbird. A controversial question is whether the new version will be compatible with the Apache license, which allows non-copyleft commercial use.

Ask before linking?

An amusing story about a blogger who actually applied to get written consent before linking to the Royal Mail website, as required by its website terms. This is a relatively common provision in website terms. New Zealand Post’s terms include the provision too (under the heading “Hypertext Links”). While such a provision could, technically, be binding, in practice it will be entirely unenforceable and is therefore pointless. The ongoing presence of the clause in so many website terms is a good example of “precedent” terms being copied without much thought.

“Subject to contract” agreement can be binding

The UK’s highest court, the UK Supreme Court (formerly the Judicial Committee of the House of Lords) has ruled that an unsigned agreement, which was “subject to contract”, had actually become binding because the parties acted as if it had. The Court said:

“… we do not think that the reasonable honest businessman in the position of either RTS or Müller would have concluded as at 25 August that there was no contract between them … all the terms which the parties treated as essential were agreed and the parties were performing the contract without a formal contract being signed or exchanged … The only reasonable inference to draw is that … the parties had in effect agreed to waive the ’subject to contract’ provision.

It is quite common for technology contracts to get underway before a formal contract is signed. This case is a good reminder that, even where an unsigned agreement clearly states it to be “subject to contract”, one party may not be able to walk away from it if their behaviour is clearly consistent with a binding agreement having been reached.

Today’s report of the “successful” renegotiation of the Ministry of Health’s bulk licensing deal with Microsoft provides a text-book example of why the Government must properly mandate open standards and multi-vendor capable solutions for future state-sector IT procurement. From the article:

Mr Hesketh says the health sector is paying slightly more for software licences under the new three-year agreement. …

“We got the best possible deal out of Microsoft we could have got at this time.” …

The commission has encouraged government agencies to investigate alternatives to Microsoft products, including open-source software, but this was not an option for the sector as Microsoft is heavily embedded in its infrastructure, says Mr Hesketh.

There is no suggestion that Microsoft software is not perfectly suitable, and in all likelihood the best, choice for the Ministry at present time. But it makes a mockery of the idea of “renegotiating” a deal when an alternative supplier is, by the purchaser’s own admission, “not an option”. By definition, monopolies do not compete. At least when there is a viable alternative (even if not an ideal one), it enables price and other such factors to be negotiated to some degree and a competitive assessment to take place. Not so in a one horse race.

Nor would it be fair to criticise the current management for the single-vendor dependent situation it finds itself in. In fact, it is very likely that Microsoft was the best choice at all relevant times in the past, resulting in the current situation through no fault of anyone (and commendably smart business and great products by Microsoft). The point is that it provides an example (if another is needed) of why proprietary lock-in in the taxpayer-funded (public) sector should be avoided where possible going forward.

It would be interesting to hear some further explanation as to how the MoH can possibly claim the outcome as a “win”, when the result was it ended up paying more than the old deal – especially when the State Services Commission all-of-government negotiations broke down over price.

The article says the “win” claimed by the MoH is that each department did not need to “go through their own legal process of vetting the agreement and doing the negotiation process. We did that once rather than 24 times”. This is a highly dubious claim for several reasons:

• In what way were the “negotiations” possibly going to be different for each department? A supplier in a monopoly position, who has already hard-balled the biggest Government procurement agency, is hardly going to negotiate 24 much smaller deals. The commercially sensible premise is “take it or leave it”.
• If the SSC had no ability to leverage on price, there is no basis for claiming as “savings” the cost of not negotiating 24 much smaller sub-agency agreements.
• The “marginal cost” of legally vetting an agreement of the type negotiated here should not be significant for a lawyer familiar with software procurement and licensing issues. 90% of it would be boilerplate, standard terms and disclaimers (see The allure and illusion of commercial software support). If the agreement was identical to an already “vetted” version, as would seem likely, the marginal cost would be around zero.

Equally as dubious is the claim that the deal allows “licences to be transferred between the participating health sector agencies at no extra cost should they be reformed or reconfigured”. How much of a benefit is this? Let’s see:

• The standard EULA’s in Microsoft Office 2007, SQL Server 2008 and Windows 7 Ultimate (to pick 3 examples) allow no-cost transfers to a third party.
• At law, the benefits of a contract can (generally) be transferred freely “by default”.
• In the case of any statutory reforming / reconfiguring departments, legislation is able to deal with assignment of assets (including intangibles) to the new entities.

So how is the free transfer of licenses, already provided for in the standard EULA’s, regarded as a “win”?

An Australian version of the Peer-to-Patent initiative was recently launched in conjunction with IP Australia (official site). From the official announcement:

Peer-to-Patent Australia opens part of the patent examination process and invites the public to review patent applications volunteered for the trial… The process is designed to tap into the expertise of the public to help assess whether a particular application is eligible for a patent.

The system is currently being run as a 12 month pilot programme, limited to business method patent applications.

The original Peer-to-Patent initiative completed a 2 year US pilot in June 2009. While the US Patent Office has yet to report on its results, the first year report from the New York Law School was positive (some criticisms are listed at Wikipedia). The US pilot was not limited to business method patents, although interestingly the patent application which received the most user interaction was such a patent – “Method, apparatus and computer program product for providing status of a process” (hmm, maybe they could also give it a unique name like ps or top?).

It is a good idea for the Australian pilot to be limited to business method patents, which covers most manifestations of software patents. It appears that IP Australia is giving good support to it. Let’s hope that IPONZ watches this closely – IPONZ (like the MED) has good IT systems and has been quite progressive with IT. If the pilot works, it will be a major improvement to a currently in-need-of-improvement system.

Of course, as with any community-driven system, its quality will only be as good as the community supports it. For open source, could it be a case of “many eyes make bad software patent applications unsuccessful”?

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.