"OSS AS A POSSIBLE DEFAULT EXPLOITATION ROUTE FOR GOVERNMENT FUNDED SOFTWARE"

A Response by the Association For Free Software

The Association For Free Software (AFFS) is a membership organization which promotes and defends Free Software in the UK. Our membership is made up of a broad section of Free Software users, home users, developers and business people alike. More information about the AFFS is available on our website, http://www.affs.org.uk/.

The AFFS is excited by the draft policy proposal, and believes it is a useful step towards a policy that presents an excellent opportunity for businesses and academia to work with Government on software projects that both benefit the public at large, and those who undertake this work. We present this response in the hope that we can improve and refine the policy futher.

Policy - Comments

1. "A default should be established which should apply if no exploitation route is specified for government-funded R&D software outputs."
   
   We agree with both the sentiment and original wording of this policy point.
   
   

2. "The default position is to adopt an OSS license which complies with the OSI definition (which includes GPL and Berkeley style licenses) or a UK-specific analogue of it."
   
   We believe this should be changed to:
   
   The default position is to adopt a Free Software license which compiles with the FSF definition of Free Software (which includes GPL and modified Berkeley style licenses).
   
   Rationale: The change from OSI to FSF definition is not merely a point of opinion. At four points, rather than ten, the FSF definition is the simpler definition and therefore the clearest. The FSF is also the more mature definition (the Debian Free Software Guidelines were derived from this definition, which in turn was where the OSI Open Source definition was derived). Also, we believe the difference between the definitions - although slight - to be material. For example, the APSL (Apple Public Source License) is accepted as an Open Source license, but not a Free Software license. The APSL requires anyone who modifies software covered by it to release all modifications back to the originator, even if the modifications are not distributed - we believe this is not in the interests of businesses working with such software, and hence the Free Software definition is the preferred one. Consistent with this definition, the term "Free Software" is used throughout this response, although a term such as "Free/Libre and Open Source Software" or "FLOSS" is often used as an inclusive description.
   
   The removal of the 'UK specific' clause is due to the case for the need for a UK specific license not being established. License proliferation is not in the interests of businesses working with Free Software - it is preferable to work with licenses businesses will already recognise, leveraging current IT/legal knowledge. It's also not clear whether or not a 'UK specific' license would be compatible with either the Free Software definition, or the OSI open source definition.
   
   The slight change to the phrase "Berkeley-style licenses" is introduced because the original Berkeley license is problematic in the Free Software world, due to the "obnoxious advertising clause", a problem which has been subsequently repaired and should not be re-introduced.
   
   It is our belief that this modified clause better achieves point 1 of policy.
   
   

3. "For those who use a specified exploitation route that is not consistent with the default at 2, an OSS license consistent with 2 should be adopted for the original government-funded software code, following a 2 year period."
   
   We believe that this approach should be re-evaluated, and be replaced with a system such as the following:

   
   For those who wish to use an exploitation route that is not consistent with the default at 2, a dual-license scheme should be adopted where one of the partner licenses is a Copyleft-type license consistent with 2.
   
   Rationale: the worry here is that the original clause would encourage developers to choose route 3, even when they intend to release under a Free Software license. A two-year period of exclusive commercialisation of the software is clearly of value, and that appears to be the only difference between points 2 and 3. Hence, with this increased value, it would be unlikely people would choose route 2. Some kind of balance therefore needs to be struck for the original clause to have an effect in practice.
   
   The confusion here appears to be the difference between commercialisation and proprietisation - software does not need to be licensed under a non-free license for it to be commercially viable. There are many examples of this model, including pure-play models not based on services (MySQL, for example, successfully sell licenses to their eponymous software in a non-free manner, while continuing to sell and distribute the same software in a free manner. Trolltech operate a similar system for their 'Qt' development environment).
   
   The obvious alternative, therefore, to the default exploitation route is a dual-licensing scheme whereby the software is made available in two forms - a copyleft form (such as under the GNU GPL), and a proprietary form. The reason for tightening from the many Free Software licenses to specifically a "Copyleft" license would be to preserve some exclusivity of exploitation on the part of the originator, whilst simultaneously making the software available under Free Software terms. This business model has been executed successfully by many firms, and we feel that these terms would be more beneficial to the originator than the original clause 3) above. The originator would be able to derive value from selling proprietary licenses to those businesses who feel they cannot accept the Free Software terms of distribution, and this would be a right they would retain exclusively as a quid pro quo for also making it available under Free Software terms. It is envisaged that although the software would be dual-licensed, there would only be one version of the software being distributed.
   
   

4. "All government-funded software should be accompanied by appropriate documentation which will assist the exploitation via the OSS license."
   
   We believe this should be changed to read:
   
   All government-funded software should be accompanied by appropriate documentation which will assist the exploitation via the Free Software license. Such documentation should be licensed on terms consistent with the licensing of the software; either the same license, or a similar Free Documentation license.
   
   Rationale: documentation is a crucial component of any software system. To be able to exercise the rights given by Free Software licenses, good documentation is critical. As the software evolves - with perhaps many businesses and organisations modifying and improving the software - it is essential that the documentation be able to keep up with the development of the software. This has been recognised by the Free Software Foundation and others, and has resulted in the creation of a number of licenses specifically designed to address the problem of technical documentation for Free Software - this allows the user rights over the documentation similar to those over the software, so that they may maintain and improve the documentation also. Any documentation licensing system which prevents the user from updating the documentation to reflect changes in the software (for example) would prevent exploitation of the software.
   
   Modern documentation licenses in use in the Free Software community also go beyond addressing the immediate aspect of copyright, to address other areas which are able to hinder the exploitation of documentation. Proprietary documentation formats, "Digital Rights Management" systems and other such technological controls prevent effective exploitation by anyone other than the originator of the documentation. Legal mechanisms, such as trademarks, can also be used to prevent exploitation, in much the same way they can be used to prevent exploitation in software. Many of these problems are explicitly addressed in some documentation licenses, and it makes sense that a policy on the default exploitation route for Government-funded software also mandate such transparency, so that documentation can be exploited alongside the software.

Implementation of Policy - Comments

Incorporating policy in research funding and contract award conditions:

• "The policy would be included in funding award documentation, such as Research Council Grant Conditions and DTI Contract Terms and Conditions."
  
  Comments: it is clear that for this policy to have any beneficial effect, the value-for-money benefits to the Government and the public offered by the default exploitation route must be considered when evaluating awards of contracts or other funds. As well as including the policy in funding documentation and conditions, it seems prudent to also issue guidance to those awarding contacts/funds so that they are able to effectively evaluate different bids, especially when such bids seek to use different exploitation routes.
  
  Currently, it is commonplace for the cost to the taxpayer of a development to be offset, to some extent, by the future potential revenues from the commercialisation of software. That system should continue for developments that are made available via a license consistent with policy point 2; however, the increased exclusivity aspects of an exploitation route not consistent with point 2 would mean that the potential for future revenue could be seen as less risky. Hence, it could be expected that comparison of bids on a value-for-money basis would need to take into account such a balance of risk.
  
  The basis on which this policy will operate should also be made transparent. For example, under what circumstances will the various exploitation routes be taken? Will the default route be the preferred route?

Commissioning Guidance for users and developers:

• "Guidance on all distinct types of OSI-consistent licenses and the implications for use should be commissioned for developers and users. A key element would include liability considerations and definitive advice for UK developers and users."
  
  Comments: clearly, we would prefer here again that guidance also be related to Free Software licenses as defined by the FSF, although it may also be necessary to issue guidance as to the difference between open source and Free Software (although the two cover wholly similar ground).
  
  As a part of Europe, it would also seem useful to give advice about the different copyright system that operates on the continent (the droit d'auteur system). Much work in this area (researching and ensuring European consistency of Free Software licenses) has been done by the Free Software Foundation Europe, and such advice could build on that work, especially for those developers working in partnership with continental businesses.
  
  

• "Guidance on exploitation planning for developers should be produced."
  
  Comments: exploitation guidance is undoubtably useful. Good advice to businesses planning using an exploitation route consistent with policy point 2. would be extremely useful, since for many the move away from a proprietary single-vendor model to a multi-vendor model (such as that operated by most current Free Software-developing businesses) would be a new opportunity.

Setting up facilitating structures:

• "Should it prove to be appropriate, a rights holding body would be set up to hold OSS rights, for the purposes of protecting OSS developers from rights claims."
  
  Comments: legal protection for Free Software is obviously crucial, in a number of areas. Previous comments about the European copyright system also apply again - where any software project is produced partly/jointly with a European partner, ensuring the rights to the software are protected is essential. Again, the Free Software Foundation Europe has done a lot of work on copyright assignment of Free Software projects (for example, the Fiduciary License Agreement, or FLA).
  
  Government should also seek complete rights to the software product - there are many rights beyond copyright that may subsist in a particular software product, and if those other rights require some form of licensing it would negate the effects of a Free Software license of the copyright. Examples of these other rights which may also pertain include, but are not limited to, trade marks, design patents, mechanical copyrights, etc. If any of these are restricted, then the software itself is effectively restricted. It should be clear, then, that all rights must be obtained with respect to the software product, and that those rights be licensed/made otherwise available on a basis that is consistent with the Free Software license in use (some licenses, such as the GPL, explicitly address this, some do not - however, the issue is equally important in both cases).
  
  

• "A repository of government-funded OSS software would be set up and maintained."
  
  Comments: yes, this would be useful. Such a respository would ensure that people were not only aware of the software, but also of the value of the software and the opportunities with respect to exploitation. This should also seek to integrate any and all current and previous Free Software projects that have been funded by the Government, so that all such projects can be found in one location.