Guide to Open Source Software for Australian Government Agencies
Sharing OSS solutions
In most situations, open source solutions procured by an agency do not require tailored code modification, so deployment can proceed in a straightforward manner. However, open source solutions offer broad scope for customisation by either the originating vendor, the agency or a third party. In such situations, agencies need to consider several possible scenarios.
Modifying products for use within one agency
In one scenario, an agency requires source code modifications but does not expect the resulting software to be used by other agencies or the broader ICT industry. During contract negotiations, the agency and the vendor must resolve several issues (preferably in explicit contractual terms) including:
- Whether any code modification is required;
- Commercial fees and scope for such modification; and
- Whether the resulting work is to become the copyright property of the agency (and therefore the Australian Government).
The agency should ensure the commercial agreement stipulates that it receives copies (in machine-readable electronic form) of such code modifications. As part of a standard risk mitigation process, it is good practice for an agency to maintain multiple copies in a safe and secure place. These code modifications can be reapplied to an open source product to recreate the original solution, if necessary.
The agency is not required to re-release any source code developed during the project into the open source community. The code enhancement is the property of the Australian Government, and the agency may decide that the code is only suitable for use within the Australian Government.
The only widely used open source licence that mandates re-release of source code enhancements is the GNU General Public Licence (GPL). However, the GPL does not automatically require a user to release any modifications it makes to source code; it only stipulates that when an agency chooses to release such modifications it does so under GPL conditions.
Specifically, GPL requires downstream developers (in this case, the OSS solution vendor) to provide the source code for any enhancement to their customer (the agency). In other words, the OSS solution vendor has an onus to ensure that the client agency receives the full source code to any modifications; there is no requirement for the solution vendor to provide such source code to anyone else. At no point does the GPL mandate that the vendor (or the agency client) must release copies of the modified source code to anyone else. If the agency wants to keep that code internal to the agency, it is legally entitled to do so.
An agency may decide, after risk assessment and due diligence, that there are no issues with releasing the code. It may also be possible to negotiate a reduced services fee if the modifications developed for the agency are re-assigned back to the vendor for subsequent release into the open source community.
Some agencies could consider such a strategy as a potential way to reduce the cost of the OSS-based solution. Many smaller open source vendors are interested in extending the capabilities of their products using this process. Agencies should only agree to such a process after assessing and documenting the necessary security and privacy implications in advance.
In general, such cases allow agencies to follow standard project management procedures associated with externally sourced software development activity. The principal difference centres on the possibility of code enhancements being made available to others; this is discussed in detail in the next section.
Sharing modified products with other Australian Government agencies
In this scenario, one agency procures an open source solution and requests modifications. It then wants to make the enhanced solution available to other Australian Government agencies. Assuming the original product codebase is open source, there are two ways to achieve this outcome.
The first is through direct technology transfer between agencies. As per the previous section, any add-on code created when enhancing the software should also be owned by the Australian Government. As a result, other Australian Government Agencies may simply decide to adopt the product through an in-house sourcing process. They are legally able to do so without licensing restrictions, as the Crown is considered a single legal entity.
Alternatively, the downstream agency can negotiate with the original vendor for the vendor to supply a solution based on the enhanced product. In such cases, the agency should be able to negotiate an attractive price because the cost of developing the enhanced product was already borne by the first agency. Further cost efficiencies may result from establishing a multi-agency procurement framework as part of the original agreement. This approach can give the Australian Government additional volume purchasing leverage with the vendor.
A recent example of this approach in action was the release of an open source content management system (CMS) developed for the Australian Government Information Management Office (AGIMO) by SME technology company Squiz.net using MySource Matrix, an open source CMS platform. Through a practice known as ‘white-branding’, AGIMO and the vendor established a robust and flexible software platform that is now available to other agencies at no upfront cost. For details, see the MySource Matrix White-Branding Documentation Suite published by AGIMO – a business group within the Department of Finance and Deregulation.
Unless an agency has agreed to permit the general re-release of code enhancements to open source products, agreements with the vendor should stipulate that the modified code remains the property of the Australian Government. An agency must manage such a requirement as part of its overall governance of the commercial agreement.
Making modified products available to the open source community
Agencies that decide from the outset to make any project-scope enhancements available to the wider open source community enjoy a number of benefits. The most important advantage is to avoid what programmers call a ‘code fork’.
Code forks occur when the codebase of a product is modified and these modifications are not applied back to the main product code repository. This marks the beginning of divergent processes for development, bug fixes and security fixes. Over time, these divergent codebases will continue to grow apart unless some effort is made to rejoin them. In the worst case, the two codebases can evolve into incompatible technologies. Such a scenario has risk and cost implications for agencies that use the software.
For example, if an agency requests enhancements to a product but does not allow the vendor to apply those changes back to the main code repository, the agency will be running a version of the product that may be increasingly different to the versions used by other clients. Over time, it may be difficult to re-integrate the two diverging codebases. This situation introduces several risks for an agency, including the risk of source code instability and immaturity. Because this code forking process represents the beginning of a different product, the agency must bear the brunt of all future testing and trouble-shooting for its unique environment.
For the vendor it is almost twice as expensive to maintain, enhance, test and fix two divergent codebases. Hence, the vendor may reduce its focus on quality or increase prices to accommodate the requirement to maintain two divergent codebases. Furthermore, an agency can be disadvantaged by not having access to the latest bug fixes, security updates and performance enhancements available to users of the mainstream OSS product. Such possibilities must be factored into the agency’s risk assessment, mitigation planning and contract governance.
An agency can alleviate such a dilemma in one of two ways. It can ensure that the code enhancements are made in a modular manner. This allows the vendor to deploy and maintain the standard product codebase for the agency’s requirements and add/maintain the enhancements separately.
Alternatively, the agency can authorise the vendor to incorporate its enhancements back into the main codebase[10]. There are several benefits to this approach.
Firstly, it expands the user base for the software, with each additional user providing an ongoing real-world testing environment for the enhancements. Flaws and security issues are likely to be located at a faster rate. This gives the agency stronger and more mature code sooner.
Secondly, it facilitates the process of developing, testing and deploying subsequent versions of the software. If the agency decides to separate its enhancements into a unique version for the agency, it faces substantial re-integration costs and increased migration and operational risks in every product upgrade cycle.
Enhanced code can be released back to the OSS community even if the agency decides to retain copyright over the code enhancements, although this may expose the Australian Government to claims from downstream users of the software.
However, it is possible to assign copyright for the enhancement to the vendor. This should only be done on the proviso that such code will be re-released under an open source licence. Such a precaution should be stipulated in the agreement with the vendor. This ensures that the Australian Government has open access to the product in future, avoiding the risk of paying again for the software. Agencies should seek legal advice to establish a framework whereby responsibility for warranty and indemnity issues rests with the vendor.
[10] Obviously this only makes sense if the enhanced code passes the agency’s security and privacy requirements. In addition, the enhanced code needs to useful in other contexts. If the enhancements are merely applicable to the agency itself, the vendor will not normally be interested in offering the code for the mainstream product. Sometimes proper consideration and system design can provide the needed levels of generalisation.
Contact for information on this page: SourceIT@finance.gov.au