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:

Commissioning Guidance for users and developers:

Setting up facilitating structures: