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)

Accreditation risk

A recent case involved a software firm suing the Government for setting accreditation criteria that allegedly put it out of business.

In Integrated Education Software Limited v Attorney General [2012] NZHC 837. The plaintiff company, IES, had provided school management software since the 1980s. By the 2000s, it was one of a number of software providers to New Zealand schools.

Around this time, the Ministry of Education decided to implement interoperability standards for school management software. As the judgment notes:

The overall market was … very fragmented. There were 37 software vendors providing software to the compulsory education market. Most were small. Some were one-man back shed operations. The school software market had grown organically over the decade since 1989 and, although it was almost entirely state-funded, there were no uniform standards or other controls in place to ensure product quality.

… there was also concern within MoE about the variable quality of software packages and after-purchase support. Lack of technical expertise at school management level meant school leaders were often unable to make good choices. Ultimately it was felt that this represented a risk to government in terms of wasted expenditure where software was not up to spec or the vendor company failed.

So the MoE decided to set an accreditation model whereby software packages that met certain requirements would be accredited. A financial incentive would be put in place for schools that used an accredited package.

After some refinement and teething problems with the accreditation criteria, testing was carried in 2005. Seven vendors received accreditation, but IES did not. Users of IES’s software began to migrate to other, accredited vendors.

As a result, IES claimed that the accreditation process had damaged its business:

Although MoE argues that IES was in fact losing clients before the second accreditation round, there can be no doubt that IES’ failure to achieve accreditation did have a significant impact on that company’s fortunes. This occurred at two levels. First, it made it harder for IES to retain existing clients in the face of monetary incentives to change and MoE’s aggressive change campaign. Second, and for the same reasons, it made it more difficult for IES to attract new clients from the pool of 300 schools hunting for a new provider.

IES brought claims against the Government for:

  • Negligence, on the basis that the accreditation process was misconceived and poorly carried out; and
  • Bias / breach of natural justice (s 27 Bill of Rights Act).

Both of these claims (and another) were rejected.

On the negligence claim, the Court found that MoE’s adoption of an accreditation model was a policy matter, in which Courts are traditionally reluctant to intervene:

 The means by which the government is to fund the provision of SMS services to schools so as to ensure proper interoperability and appropriate standards in an era of widespread computer usage is a policy matter… These are questions for officials and politicians not Judges.

It also found that the MoE had no duty of care to IES in formulating and carrying out the accreditation process (it is worth noting that the Court suggested that the “proper footing” for a claim of this nature would have been misfeasance in public office), and considered that key facts were not made out.

On the bias claim, IES pointed to evidence it said showed that the MoE’s accreditation criteria favoured another vendor. The Court disagreed, saying there was no evidence to support an allegation of bias.

Lessons

The case provides an example of regulatory risk for IT vendors, and confirms that the Government has a broad (though not unlimited) ambit to implement standards, accreditation regimes and other policies without judicial interference. It is logical and sensible for a Government agency such as MoE to implement baseline standards (e.g. interoperability requirements) for state-funded schools, and accredit providers meeting the standard to allow schools to make an informed choice. It is unfortunate that IES, for whatever reason, could not or did not get accredited in time (in 2005).

The case does not explain why IES could not alter its software to meet accreditation. Software development is often an expensive and time-consuming process, and many vendors would face financial or resource constraints to significantly update what may be a “legacy” package to meet new requirements (which they may consider to be flawed or inapplicable).

But if IES had been able to update its software before or during the accreditation process (over a period of some months and years), presumably it could have reduced it alleged losses. Whether this could have been alleviated by a different contracting model or business model is unknown.

Oracle v Google: API wars

The Oracle v Google lawsuit in the US, which was shaping up to be yet another patent slugfest (albeit an important one), has taken an interesting turn with Oracle adding important detail to its copyright infringement claims. Oracle’s amended statement of claim now alleges the following (full document here):

Android includes infringing class libraries and documentation. Approximately one third of Android’s Application Programmer Interface (API) packages are derivative of Oracle America’s 19 copyrighted Java API packages and corresponding documents.

The infringed elements of Oracle America’s copyrighted work include Java method and class names, definitions, organization, and parameters; the structure, organization and content of Java class libraries; and the content and organization of Java’s documentation.

Examples of this copying are illustrated in Exhibit I to this complaint. In at least several instances, Android computer program code also was directly copied from copyrighted Oracle America code. For example, as may be readily seen in Exhibit J, the source code in Android’s “PolicyNodeImpl.java” class is nearly identical to “PolicyNodeImpl.java” in Oracle America’s Java, not just in name, but in the source code on a line-for-line basis.

Copyright claims are quite a different beast from patent infringement claims. Generally, copyright infringement requires there is (a) a copyright work; and (b) unauthorised copying of a substantial part of that work. While Oracle is alleging outright copying of code, it is the recent addition of more novel categories of “works” highlighted above that sparks interest.

The first question that arises is, does copyright subsist in “works” such as:

  • Method and class names
  • Parameters of methods
  • The “structure, organisation and content” of class libraries
  • The “content and organisation” of documentation.

These are quite different concepts from software code itself. Code is recognised as literary work for the purpose of copyright, and is protected as such. But what about related aspects and “concepts” such as the method names?

Copyright attaches to certain “original works” involving some independent intellectual effort. Clearly this will apply to the code comprising most human-authored non-trivial methods. The method could possibly be copyright as an individual work, or (more likely) as a part of a larger work (like a chapter in a novel). The name of the method may be included as part of the copyright work; to borrow the novel analogy again, in the same way as a chapter heading would probably be included as part of the novel’s copyright, albeit a very minor part.

An important distinction with a novel’s chapter headings, however, is that most method names are purely functional. In fact, good software design dictates that methods follow a logical and obvious naming convention. “Creativity” should be kept to a minimum (for the sanity of future developers!) For that reason, an individual method name is unlikely to attract copyright protection on its own, and would only constitute a very “thin” part of the overall work. Another developer, seeing the method name alone and copying it, would probably not have infringed copyright because the method name was not a substantial part of the copyright work.

The Oracle claims are not about copying just one or two method names, but rather about copying all (or most) of the Java methods, classes and parameters in order to replicate the Java API. If one method name is not copyrightable, what about all method names in an API? Compilations of works (or parts of works) are certainly copyrightable, but again there needs to be a minimum level of intellectual effort. And beside method names, does an entire API – consisting of method names, class names, return types, parameter names and types, access levels, namespaces and so on – have copyright protection?

How the US court answers this question could have important implications for developers.

Contracting for success or failure?

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.

The consumer liability of software developers

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.

Copyright ownership and software development

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 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