FLOSS Best Practice for Business and Government (Draft, April 2008)

Introduction

In April I attended a meeting of FLOSS lawyers in Amsterdam. One of the things I got to talk about there was some directions for FLOSS related policy – which turns out to be unusually relevant because the Australian Government is conducting a review into innovation in Australia. This post is some thoughts on what might make good FLOSS policy for community and government and may form the basis for OSIA’s submission to the Innovation Review. The submission is due by 30 April 2008. If you have any thoughts or comments on any of these please email me or drop me a comment below.

1. Business

1.1 Organisations should adopt KPIs for management which include community contribution. Community should demand such KPIs of FOSS companies.

1.2 Community contribution should be evaluated on a broader basis than just developers supported. Other contributions, such as to legal, design, evangelisation, documentation, training or marketing should be valued.

2. Government

2.1 Governments should contribute to FLOSS development.

2.2 Government contribution to FLOSS should at a minimum include voluntary contributions to nationally based FLOSS collecting societies calculated according to FLOSS usage (in much the same way that Government makes such contributions to other collecting societies on behalf of other copyright authors). That collecting society should use the money to fund FLOSS related initiatives.

2.3 Government contribution to FLOSS may include adoption of FLOSS technologies or contribution of code.

2.4 Publicly funded development should be commercialised under a FLOSS licence (although it may also be commercialised under other non-FLOSS licences). Publicly funded development should not be exclusively licensed.

2.5 Governments should use open data formats (eg odf) for Government data that is intended to be retained for extended periods or used for interchange with the public . Recent developments at ISO indicate that ISO approval is not sufficient for a format to qualify as “open”.

2.6 Government websites and data made available on the Internet should be made available in W3C compliant standards.

2.7 Government should have no closed source dependencies for the access to services or data – in particular no such dependencies should be present for regulatory, corporate or tax authorities or departments (eg ACCC, ASIC and ATO).

2.8 All Government interaction with business and consumers should be technology neutral and must either be through the use of established open standards, or on a very technologically conservative basis with an emphasis on documented, widely accessible and interoperable formats.

2.9 Government should maintain a publicly available portal detailing its use and contribution to FLOSS.

3. Metrics

3.1 Metrics must be reengineered to account for the value of FLOSS. A whole range of existing metrics used for policy formulation are clearly wrong in the FLOSS context. For example, metrics which focus on revenue implicitly assume value is generated through sale of a product. However, FLOSS products generate value by providing an opportunity to use or by providing a cost saving. For any organisation which uses FLOSS there may be no direct impact on revenue, but rather an impact on profit, or, alternatively the revenue of the organisation will be better utilised (eg savings from FLOSS may be spent on development).

3.2 Measuring the benefits and costs of technology should be focussed on whole of community cost or benefit and not on the benefit to government or benefit to department. Subsidised use by specific departments impose costs on the wider community. These costs must be taken into account when evaluating tenders. This is particularly important for key public resources such as libraries, galleries, public transport information etc.

4. Competition Policy and Procurement

4.1 Legislation should clearly state that ownership of property, interoperability and competition rights take precedence over copyright, patent and trade mark rights.

4.2 Government tenders should not discriminate against open source.

4.3 Government purchasing should not discriminate against open source.

4.4 Discrimination against open source includes specification of products rather than requirements, and specification of requirements which are an implicit specification of a product.

4.5 Evaluation of FOSS should take into account the broader public benefit (see 3.2). Where procurement is decentralised individual business units will have a natural tendency to pursue their own benefit and budgetary constraints may overbear public value considerations. This requirement may therefore imply that some mechanism be implemented to ensure that whole of society considerations are given due weight (and are not overborne by the budgetary requirements of specific business units).

4.6 Technologies for which there are multiple providers/supporters which are not contracted to a single ultimate source for the supply of the technology should be preferred over those which are.

4.7 Government procurement of software should mandate that the Government can on-sell or on-supply copies of software it has acquired (including, but not limited to at the end of life of the software), and must be able to do so independent of any hardware acquired in conjunction with such the software. For example, if the Government acquires 10 copies of software, it must at a minimum be able to on-supply each of those 10 copies (possibly on the basis that it deletes that number of copies from its own system). Ideally though, the acquisition by Government of software ought to permit Government to freely redistribute that software to all citizens. Similarly, whole of Government contracts must permit each copy acquired under the contract to be on-supplied.

4.8 Whole of Government or whole of business unit licensing for software should include provisions which ensure that cost savings result where the software is not used across the whole of the business unit.

5. Legal

5.1 Courts should acknowledge that existing case law makes assumptions about the interaction between the relevant parties which are not necessarily appropriate to open source. Areas for review would include:

(a) standing to sue – as FLOSS licences have a large consumer protection component query whether persons other than the copyright author ought to have standing to sue;

(b) interpretation of licences – the interaction between the author of the licence, the author of the software who adopts the licence and the community of users who use the software;

(c) interests of the community of participants – these interests in particular are poorly represented under law which adopts a binary paradigm for dispute resolution;

(d) application of existing rules of interpretation to FLOSS licences (part of the more specific issues listed above).

6. Programs and Grants

6.1 Governments and philanthropic associations should allocate grants to assist in funding creation of software packages for SMEs, Students, Arts. Grants should also be targeted as incubators for entrepreneurs using or developing FLOSS.
6.2 IP clauses in grant documents should anticipate:
(a) that third party FLOSS may form part of solution; and
(b) research outputs must be able to be commercialised through FLOSS licensing.

6.3 Grant conditions should not discriminate against FLOSS commercialisation of outputs.

6.4 Grants should be made preferentially for those projects which promote interoperability between Government and FLOSS operating systems.

The Tragedy of the Anti-Commons

or Why Government FLOSS Purchasing Policy is Misapplied

Summary

Misapplication of “value for money” requirements when purchasing software results in poor value for money – Government purchasing policies for software tend to support the creation of monopolies.

Government purchasing has effects on the price paid by citizens for the product purchased. In some cases purchasing produces volume which permits scale discounts and therefore a net benefit to citizens who also purchase the product. However, in the case of lock in software* Government purchasing can create a monopoly in the software which leads to increased costs for citizen purchasers and a net detriment for society as a whole. It is not appropriate for value for money policies to be assessed on a per acquisition basis when software is being acquired. Doing so will almost certainly create net costs for the community when considered in the aggregate.

A Tale of Two Widgets

Consider the case where the government must buy one of two types of widget (called Widgets A and B respectively). Assume also that both widgets are more or less equivalent. Not only do both widgets meet the government’s needs, but they would also both meet the needs of most general purchasers of widgets. Assume further that the government price for Widget A is about half that of Widget B. At this point take out your taxpayers hat and place it squarely on your head and think about which widget you’d like the government to buy. That is, would you prefer the government to take more of your money and spend it on Widget B or would you prefer it to spend your money on the cheaper Widget A?

It was the Best of Times

Did you choose Widget A? Surely, based on what I’ve told you, that must be right! You’d think government would need to be mad, bad or corrupt to purchase Widget B in those circumstances. Not surprisingly this purchasing preference is reflected in government procurement policies. For example:

• The Commonwealth Procurement Guidelines require Australian Federal Agencies to secure value for money in procurements. This is stated to be a “core principle”.
• The UK policy on OSS states that contracts will be awarded on a value for money basis (at page 4).

Let’s assume now that the Government does purchase Widget A and take the scenario further to analyse some of the assumptions we made in arriving at the purchasing decision. What if Widget A is used to lay roads? What if Widget A is not interoperable?

What if Widget A has been specifically designed so that if it is used to lay a road, then to drive on the road a car must also be fitted with Widget A? (Assume, for the sake of fairness, that Widget B also requires a car to be fitted with Widget B). Would you still be happy for the government to buy Widget A? Maybe you would – Widget A costs half of Widget B. Presumably you’ll be no worse off. You will need to buy one of the two Widgets and you’ve already paid half** the price of Widget B when the government used your taxes to buy Widget A, if you have to pay half the price of Widget B again, you’re square with the price of buying Widget B – in fact you’re better than square because if the government had bought Widget B you’d pay the full price for it with your taxes and you’d have to pay the full price for it in order to drive your car.

It was the Worst of Times

There is a but – and it is unrelated to the characterstics of Widget A and Widget B, their functions, design and operation. That “but” is the availability of Widget A and how it can be priced. Assume that Widget B is made by lots of different people and there is fierce price competition in relation to it. Assume also that Widget A is only available from a single vendor. The vendor of Widget A (Vendor A) is able to set different prices for Widget A in different markets (the vendors of Widget B are not able to do so, because of the assumed competition in the market). Vendor A can choose to set a very low price for Widget A for Government purchasers, knowing that governments build a lot of roads. They can then choose to set a higher price for other purchasers – the prices given above were prices for government purchasers (not for chumps like you and me). Want to drive on a government road? Sorry, that’ll be 10 times the price of Widget B.*** Now, any way you cut it you are out of pocket. Assuming most roads are laid by the government, over time Widget B will be pushed out of the market or at very least relegated to small niches.

Intermediate Conclusion

We can conclude from the above that it is not possible to make a judgment as to value in isolation. Something which seems to be good value in a particular purchase scenario can lead to extremely poor value from public expenditure.

What’s the Problem

Government procurement can both create and reinforce a monopoly in goods and services which it is acquiring. Anecdotal evidence suggests that bureaucrats look at “value for money” type formulae and assess it against the cost to Government on a purchase-by-purchase basis. This approach is fine in respect of goods and services which are easily substitutable (such as hammers, screws, cars etc). In respect of goods which are specifically designed to prevent substitutability – eg devices which are not designed to be interoperable it is an extremely hazardous approach. If those goods also tend to be a natural monopoly (such as software in general, but particularly that which is designed not to be interoperable) this approach is absolutely the wrong one. The reasons should be obvious:

• the vendor of the product can almost always underprice competitive offerings – even when competitors are loss leading;
• the Government, bound by its bureaucrat’s incorrect understanding of the value for money policy is required to purchase the monopolist’s product;
• over time network effects enable the monopolist to crowd out competitive offerings;
• the vendor, now a monopolist, can charge what it likes to the rest of the community safe in the knowledge that, because of the preponderant use by Government others have no choice but to acquire the product;
• ironically, over time the monopolist will even be able to charge the Government more because of the its huge installed base and the previous elimination of competition.

The Tragedy of the Anti-Commons

A prospective monopolist has a period of vulnerability before it has established the monopoly product in the market in which this strategy is risky (because it must carry the costs of underpricing). However, the tragic (ie fatalistic) nature of the process, coupled with the huge rewards to be had from playing the game makes it inevitable that sooner or later a monopoly will be established – it only requires one prospective monopolist to succeed for a monopoly to become entrenched. No number of failed attempts will prevent the next attempt and the winner take all nature of the scenario will continually draw in new prospective monopolists.

What is a Better Approach?

Government may have many roles in the procurement of goods and services but supporting, establishing and maintaining unregulated monopolies is not one of them.

While the value for money requirement is fundamentally correct, to elevate it to the status of gospel or taking it out of context is not. Value for money must be determined by reference to the price paid in the aggregate by the community for the Government’s acquisition, not to the price paid by Government or authority for the acquisition. This value for money assessment is further complicated by the fact that the assessment must necessarily:

• be an ongoing one. A purchase today has no immediate cost impacts on the rest of the community – those impacts are all in the future and some of them may be in medium or long term;
• involve a review of pre-existing Government acquisitions (as a previous (acceptable) acquisition may be unacceptable when taken in combination with a proposed acquisition); and
• involve a review of things other than the software – in particular whether the vendor is likely to be in a position to manipulate the market.

Of course, the complexity of issues to be addressed by a value for money assessment make it difficult to apply with any consistency or certainty. In relation to lock in software it may only be a feel good term with little real substance. Any doubt should be resolved against the creation of monopolies.

If the licence terms permit perpetual use of each copy and permit the Government to onsell each copy of the software acquired and to do so independently of any hardware acquired in conjunction with the software that would reduce some of the monopolistic impact of the arrangement. Unfortunately the structure of copyright law usually forbids this arrangement in practice and, in any event, would not eliminate all monopolistic effects.

Particular Example – Whole of Government Purchasing

Whole of Government acquisitions of lock in software provide especially poor value for money on this analysis. Such acquisitions provide a vast installation of the software across government and effectively create an environment in which incremental improvements are net costs rather than net savings. For example, if the software has been purchased for the whole of Department X, then using a cheaper product for some users will not result in any cost savings – on the contrary since there is an effective doubling up on the licensing to the small group it costs more to use cheaper software! Further they create an entrenched installed base which increases the costs in the next round of acquisition (because this installed base effectively dictates purchasing requirements in that acquisition round).

Particular Example – Key Resources

Government acquisitions of software for key services or resources also provide especially poor value for money on this analysis as well. In these cases the importance of the relevant project (for example, the provision of public information by a health body, broadcaster or library) creates a lock in because of the general need of the public to interact with that body. That need for interaction will create in the public a need to acquire the software in order to access the resource, with the consequent establishment of a monopoly. It is a dangerous vanity for public resources to adopt lock in technologies in the provision of information or services through public facing interfaces.

Note on Formats, Standards and Protocols

This discussion has focussed on software primarily because it is more familiar and is conceptually easier to understand. However, the arguments presented apply equally to the adoption of products which require the use of a particular data format, standard or protocol if that format, standard or protocol has the lock in characteristic. Indeed, ultimately the issue is not so much in the software which manipulates data but in the manner in which data is stored and exchanged. In many instances software (and particularly lock in software) has a direct mapping against a specific data format and can therefore be identified with that format. If no lock in data format is used, the negative effects of the acquisition of lock in software is greatly reduced.

Notes

* For the purposes of this paper “lock in software” refers to software for which: the licence for that software ties the licensee to the licensor or to any third party either implicitly; or the software is designed to effect such a tying and there is no capacity either at all or in practice for the licensee to avoid or remove that tying. Lock in software includes software: which is not interoperable (eg doesn’t save to a standard format in its default configuration) or not interoperable outside the product set for a specific vendor or set of vendors, for which there is only one manufacturing source (multiple sales channels don’t count) and that source of the software has a substantial degree of market power in the relevant software market. By definition, lock in software does not include software which meets the open source definition.

** Technically probably less than half. It’s only half if the Government must buy one widget per car on the road.

*** The price will be determined by the demand for Widget A and may not be (but also might exceed) 10x. If, as in the case of software, the law prevents on sale, Vendor A will also be able to price discriminate, by charging each individual consumer as much as they are willing to pay.

Finally, a “widget” in this context is a placeholder term for some object the subject of discussion.

[Note initially made available for review on 7 January 2008]

Eee at Vicini, Using OOo and OpenSuSE live

Vicini is a truly lovely cafe/restaurant in Annandale. They serve probably the best flourless chocolate cake I have had – ever (ahh… I mean “ever if you’re excluding those baked by family members”). [update July 08- their supplier has stopped making cakes to focus on biscuits. Argh! update Sept 08 – apparently it is back on the menu again, but they don’t serve it with double cream] I took the eee with me for coffee this morning. This time I actually used it for serious work (drafting an advice for a client) rather than just posing.

The moment I took it out one of the waiters came over and fawned over it. “I want one,” he said. A little later one of the other waiters came over and asked about it. I gave a short demo and told them the price and where to get one. It is increasingly clear to me that the eee is an object of desire.

Ooo writer has a noticable delay in bringing up an “open file” dialog but otherwise operates fine. I would like a view mode in which the text is not wysiwyg, but rather the text is flowed to the borders of the screen – I have not tried web layout, but this seems to do the trick. This will allow editing in a large font which can then be reviewed for layout later (or on a desktop machine). The eee demonstrates how poorly thought out the OOo’s treatment of context sensitive toolbars is as it in effect will not permit the toolbars to be turned off to save screen real estate. More on this later if I have time.

I was able to ping someone’s wireless router from the cafe but that’s all. So the wireless clearly works.

There is an OpenSuSE live flash drive iso available with instructions, but having booted it up last night it appears to be designed primarily as a means to overwriting the existing distribution on the eee – which is not something I want to risk atm. It is not a full blown live distro in (eg) the knoppix mould. Why it takes up 2G is beyond me [note later in day – I mounted the flash drive and took a look at it – it is only about 50MB and most of that is in the boot directory].