Law and technology

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

and

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

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

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

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

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

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

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

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. Continue reading ‘The Affero General Public Licence’ »

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

Continue reading ‘Open source enforced’ »