Licensing virtualised software isn’t getting any easier:

Big picture: Software licensing for virtual desktops is incredibly complex, confusing and, in some cases, prohibitively expensive. “It’s like the tax code,” says Dave Buchholz, principal engineer at Intel’s IT unit

Like the tax code – ouch. This is not new, yet from a contractual point of view, licensing virtual software is relatively straight-forward. The complexity is not an inherent licensing problem, but simply a commercial consequence – partly due to the well-worn idea that complexity is good for business (think mobile phone plans), and partly due to vendors trying to have their cake and eat it too.

Besides piracy, studies show that even users who actively try to be fully compliant often cannot understand the licensing rules (and as the article says, even vendors can struggle to understand their own licensing). The reality is that in most cases, if there is money on the table that a licensing tweak could recover, those tweaks would have already been made. But while the practice of overly-complex licensing has perhaps lasted longer than expected, disruptive technologies such as usage-based cloud computing, and open source software and the increasing use of virtualisation itself, mean the trend will be toward simplified licensing and subscription models.

Name suppression laws to be tightened

The Government has announced changes to name suppression laws, following a number of high profile incidents, a prosecution, and a Law Commission report into the matter. Among the announced changes:

Introducing a new offence to capture New Zealand-based Internet service providers or content hosts who do not remove locally hosted suppressed information which they know is in breach of a suppression order, and who fail to block access or remove it as soon as reasonably practicable. [emphasis added]

This is an improvement on the Law Commission’s recommendation that ISPs and hosts “carrying” suppressed information should “block access” to it, which would have caused practical problems for ISPs (see my comments here). Having a requirement simply to remove locally hosted content is a simpler and more realistic approach. But it still remains an iffy matter – IT lawyer Rick Shera raises some pertinent questions here.

Coincidentally, on the same day as the Government’s announcement, a name suppression order forced a number of bloggers to remove posts that had previously the identity of certain individuals. By which time the information was already available in caches, syndicated posts, Twitter, etc – just another reminder of the difficulty of name suppression in the present day.

Who’s suing who(m)?

Another day, another US patent infringement claim. There are so many flying around, its hard to keep up. Fortunately the Guardian gives us this diagram. Expect to see a few more arrows added in the near future.

If you can’t beat ‘em?

Minorly ironical: Ars Technica reports on antipiracy lawyers apparently pirating the legal forms of other antipiracy lawyers.

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.

A UK court has ruled, and a customer found out the hard way, that what was described as a “perpetual” software licence was not a “never ending” licence. In BMS Computer Solutions v AB Agri Ltd (UK High Court, 10 March 2010) the customer was granted a “UK-wide perpetual licence” for a program. However, the contract granting the licence also required the customer to keep buying support from the developer:

In the event that the software technical support agreement is terminated for any reason whatsoever this agreement shall terminate.

The customer wanted to terminate the support agreement, but keep using the software. Terminating the support agreement would terminate the contract which had granted the licence. It is quite common for specific terms of a contract (including software licences) to survive termination (assuming that is what the parties intended). The question in this case was whether the grant of the “UK-wide perpetual licence” intended to create a never-ending licence that would survive termination of the main contract. The judge said:

The word “perpetual” can carry different shades of meaning. It can, for example, mean “never ending” (in the sense of incapable of being brought to an end) or it can mean “operating without limit of time”.

The judge found that in this instance, the “perpetual licence” meant a licence “operating without limit of time”, i.e. it continued until either party terminated it for some valid reason (such as ending the support agreement).

The ruling does not mean that every “perpetual licence” is perpetual until terminated. A contract (such as a licence) is always interpreted according to its terms and intentions of the parties. In some cases, “perpetual” will clearly mean “never ending” (in which case it may be a good idea to record it as “perpetual, irrevocable licence”). In this case, the “perpetuality” was trumped by the tied support requirement, and could not have been intended as never-ending – either a case of poor drafting by the customer, or good (or fortuitous) drafting by the developer.

Smoking gun emails

The major court battle over copyright infringement between YouTube and Viacom currently underway in the US has turned up some pretty damaging internal emails between the founders. E.g. this from YouTube co-founder Steve Chen to Jawed Karim:

“jawed, please stop putting stolen videos on the site. We’re going to have a tough time defending the fact that we’re not liable for the copyrighted material on the site because we didn’t put it up when one of the co-founders is blatantly stealing content from other sites and trying to get everyone to see it.”

While the founders probably aren’t too concerned (having long since cashed out), the evidence may yet cause YouTube’s owner Google a headache. Another reminder not to put damaging comments in writing – in litigation, almost everything is potentially discoverable.

More audio/visual technology in NZ courts

“A bill that will allow greater use of audio visual links in courtrooms passed its first reading in Parliament yesterday.” more…

Nestlé trade marks Kit Kat shape

Nestlé has won an appeal allowing it to trade mark (in Australia) the shape of a Kit Kat bar (or as the application prosaicly calls it, “Chocolate confectionary being chocolate-coated confectionary blocks or bars and chocolate-coated wafer biscuits”). Trade marking shapes is permitted in New Zealand and other countries (for example Toblerone chocolate in some countries). In fact, many “non-lexical” things can be trade marked, including (in New Zealand) colours, smells, sounds, and tastes.

Strangely, chocolate has long been a major battle-ground for trade mark disputes. In New Zealand, Cadbury lost a 2008 Court of Appeal battle to trade mark the word “purple” (though not the colour, which it already trade marks). Last month in Australia, Guylian lost a Federal Court battle to trade mark its seahorse shaped chocolates, which the court found “not sufficiently inherently distinctive”.  In contrast, two years ago a Japanese court allowed Guylian the same trade mark in Japan, finding that the shape was sufficiently distinctive.

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

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.

Making a backup copy of software is expressly permitted under section 80 of the Copyright Act 1994. However, a backup copy can only be “used” if the original is lost or destroyed (or it can be used in lieu of the original copy). One of the issues the case clarified is that the occasional testing of a backup – which is of course sensible – does not breach that restriction.

However, if the purchaser was given an express direction that a backup cannot be made, then section 80 does not apply (i.e. a backup cannot be made). It is important to note that the direction not to make backups is only effective if given before or at the time the software was acquired. If the direction/prohibition was given in a click-through licence, but the software was “acquired” before that licence was accepted, section 80 will apply (i.e. a backup can be made). However, the licence agreement could still impose various other conditions about how the backup can be used/tested.

When the Copyright Act backup provisions were drafted, most backup scenarios would have involved physical media, not a failover system (hot/cold) backup. The court decision confirms that in the absence of any pre-purchase direction (which could be a simple notice on the package or on the website the software is downloaded from), a cold server backup can be made, and (subject to the licence terms) occasionally tested. A user could not, however, rely on section 80 to set up a hot server, as this would involve “use” of the copied software beyond the extent permitted.

It was good to see the court make a well-researched and practical judgment, following a hearing that involved a number of IT experts, including disaster recovery specialists. By the way, if this all sounds like much ado about not very much, it is worth noting the software in question was very expensive main-frame based software ($1m plus per licence) which, presumably, justified the cost of going to court. It is highly unlikely that Microsoft or Apple would have a major battle over a user making a simple backup of their software! Indeed, many software houses expressly permit it.

Read my full article here:

Computer program backups and the Copyright Act (Clendons Barristers & Solicitors)

The judgments:

Primary – Racing & Wagering Western Australia v Software AG (Australia) Pty Ltd [2008] FCA 1332
On appeal – Racing & Wagering Western Australia v Software AG (Australia) Pty Ltd [2008] FCA 1526

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.

The AGPL arose from a perceived loophole in the GPL and other licences regarding software used across a network. (I’ll refer to this as software as a service for the purposes of this article even though, like “cloud computing”, I find the name rather inapt sometimes).

The latest version of the AGPL, version 3, essentially replicates the GPL version 3, but with an extension specifically applying to SaaS – that is, programs providing “remote network interaction”. The Free Software Foundation, publisher of the GPL and AGPL licences, says examples of programs meeting this criteria are web and mail servers, interactive web-based applications and online games servers (here).

Under the GPL, when software is distributed, the source code must also be distributed, thus allowing modification or incorporation into other software. But in the case of SaaS, it is not the software itself which is being distributed, but rather some functionality of the software.

A simple example is a website. The user receives the output of a program (e.g. a stream of HTML), but not the actual program generating the output (i.e. the web server). As the program itself is not being distributed, the provider of the service is not required to distribute their source code.

Another example is Google, which uses open source software in its search engine, but does not distribute the source code – indeed, Google’s source is kept a closely guarded secret.

While convenient for users, critics claim this situation is contrary to the spirit of the GPL. They say that firms can benefit from open source software without returning their improvements to the community, which was probably not the intention of developers who release their software under an open source licence.

That the GPL does not expressly address SaaS is not surprising; version 2 of the GPL was developed in 1991, before the Internet services era (for most people at least). However, with the huge rise in the use of SaaS, the loophole will become an increasingly important issue.

The AGPL aims to provide a way of closing the SaaS loophole by introducing a requirement that modified source code must be provided to users of the service. The essential provision of the current version (AGPL version 3, clause 13), states:

“… your modified version must prominently offer all users interacting with it remotely through a computer network … an opportunity to receive the Corresponding Source of your version”.

The Free Software Foundation initially considered closing the SaaS loophole in its latest update of the GPL but (wisely) decided instead to promote the AGPL as a separate licence, allowing developers to choose whether to impose the additional requirement of the AGPL.

Few projects use the AGPL at present, though this will doubtless increase. One live example is the UK Prime Minister’s e-Petitions website. – see the link on the FAQ page to download the source code.

Update: a local example of an AGPL-licensed site is ScoopIt, but it does not appear to provide a facility to download its source code.

For users, the most common encounter with the AGPL is likely to be a website content management system (CMS). If the CMS is licensed under the GPL (or similar), a firm can modify the CMS as required without the need to provide the source code as long as they are simply using the software to provide a website and are not distributing the CMS software itself. Thus the modified CMS is essentially a private, in-house project.

However, if the CMS is licensed under the AGPL, the modified source code must be made available to users who access the website (e.g. everyone in the case of a public website).

The AGPL is not without controversy.

There is debate about whether the AGPL is overly onerous for those who simply want to modify open source code for the purpose of providing a publicly-accessible online service or website. The AGPL will in such cases force the modifier to release every update of what may be thought of as an in-house project, albeit with a public interface. Contrast this with the GPL which, as the Free Software Foundation says:

“… does not require you to release your modified version, or any part of it. You are free to make modifications and use them privately, without ever releasing them.”

Whether the AGPL will therefore discourage the use of particular code remains to be seen. Certainly, it does introduce an additional obligation on licensees beyond those in the GPL. But with the increasing growth of SaaS, where the distribution of software is of less relevance than the service it provides, the AGPL may be an important factor in ensuring the continued feedback of modified code to the community.

This is an edited version of an article of mine recently published in Computers and Law magazine in the UK.

In Jacobsen v Katzer (13 August 2008), a software developer (Jacobsen) had developed a Java-based software library for controlling model train sets. The software was released through the SourceForge website under the open source Artistic License (version 1). Another developer (Katzer) took Jacobsen’s code and included it in his own software – which is permissible under the Artistic License – but did not comply with the conditions of the licence.

Specificall, Katzer failed to:

• Include the original author’s name;
• Retain the original copyright notices;
• Link back to the SourceForge website; or
• Describe what modifications had been made to the original code;

as required by the licence.

Jacobsen took Katzer to court to prevent him from continuing to use the code in breach of the licence.

In Court, the fact that Katzer had not complied with the licence was not in question. The key issue was whether, having breached the terms, Katzer could be prevented from using the code. Katzer’s argument was (in effect) that even though he had breached the licence, Jacobsen suffered no harm (as the software was freely given away and able to be modified), and therefore on the usual contract law damages principles, Jacobsen had no remedy.

In a significant victory for open source licensing, the US Court of Appeals for the Federal Circuit (the 2nd highest Court in the US, one level below the Supreme Court) rejected this argument. The Court ruled that failure to comply with the terms of the licence meant that Katzer had no right to use the software. His use of the software in contravention of the licence was therefore not a simple breach of contract, but a breach of copyright. As a result, Katzer would have to stop using the software.

While open source licences have been upheld before, and this particular case was only a procedural hearing, the decision is still noteworthy for two reasons:

1. Collapsible software licensing

It provides an excellent example of a “collapsible software licence”. The right to use the software was held to be conditional on continued compliance with the terms of the license. Failure to observe those conditions resulted in the right to use the software collapsing, or never coming into existence in the first place. This is quite different from a situation where the right to use the software exists independently from the other terms of its use, and any breach of a term of the licence simply allows to the licensor to claim for damages (if the breach has caused any loss) but does not take away the right to use the software.

2. Strong endorsement of open source licensing

It provides a robust endorsement by a high-level Court of an open source licence and the conventions surrounding them. For example:

• The Court implicitly accepted that including the terms of a license in a file called COPYING – which is customary, though not universal, in open source project – are binding.

• The Court also accepted that conditions such as author attribution, preservation of notices and links back to the project website are enforceable, valuable terms that the licensor can insist must be complied with.

• The Court stated that just because open source software is free, that does not mean the license is unenforceable (on the technical legal grounds of lack of consideration). On this point the Court said:

“The lack of money changing hands in open source licensing should not be presumed to mean that there is no economic consideration, however. There are substantial benefits, including economic benefits, to the creation and distribution of copyrighted works under public licenses that range far beyond traditional license royalties.”

Relevance in New Zealand

While New Zealand courts are not bound by this decision, being a US court applying US law, it is still of relevance in New Zealand. The Court’s robust, straight-forward interpretation of the terms of the licence may be influential on a New Zealand court facing a similar situation. Furthermore, as software development is a particularly international industry, developers in this country may be able to point to the decision should questions arise as to the intended effect of using a similarly-worded licence.

One small difference does arise under New Zealand’s copyright law. Unlike in the US, in New Zealand the right to be identified as the author of a “literary work” (which includes software) is enshrined in section 94 of Copyright Act.