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.