Law and technology

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.

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.

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