Making an informed decision to release open source software
Motivations to release government open source software
Concerns about open source licensing of software
Communicating open source release during procurement
Appendix: Communicating open source software licensing and release in Request For Proposals
1. This guidance note is to help government agencies understand:
a. Considerations that are relevant to deciding whether to release new software code produced by a supplier (procured) under an open source software licence.
b. When and how to communicate to suppliers during the procurement process should agencies decide to release code under an open source software licence.
c. How to make use of the two current policies relating to software code procurement and open source as an end to end process.
2. It does not:
a. Cover the use of existing open source software in procured projects from suppliers.
b. Cover intellectual property rights other than copyright.
c. Cover the treatment of copyright in newly developed works that are not software code (other than documentation that accompanies the code). These are dealt with in NZGOAL guidance note 3.
d. Constitute legal advice. Agencies should seek legal advice from their legal advisors to the extent required.
3. You should use this guidance when:
a. You are procuring newly developed software code not already owned by your supplier; and
b. Your agency needs guidance on whether to release the developed software code as open source software using the NZGOAL-SE principles and release process.
4. When considering development of custom software from a supplier there are two policy documents to consider:
a. Guidelines for Treatment of Intellectual Property Right in ICT Contracts (2008) [PDF 218 KB] - this is referred to in the Government Rules of Sourcing, rule 61 and we will refer to these as the "IPR Guidelines" from now on in this guidance. The IPR Guidelines help agencies determine who should own the copyright in newly developed software code by a supplier.
b. New Zealand Government Open Access and Licensing framework - Software Extension (2016) - we will refer to this as "NZGOAL-SE" from now on in this guidance. NZGOAL-SE helps agencies correctly license publicly funded software code using an open source licence when they have decided to do so.
5. The IPR Guidelines default position is that suppliers should own the copyright in newly developed software code. The reasoning is that the government is not in the business of commercialising software. In certain limited situations the default can be overridden, one of these being that "the agency intends to allow free use of the [software] on open source terms"1. Open source licensing allows commercialisation opportunities of software code by anyone under the open source licence terms.
6. If an agency decides "yes, we intend to allow free use on open source terms"then the IPR Guidelines recognise that an agency may wish to own new intellectual property rights in the software that is to be procured. This can be important because, as the NZGOAL-SE review and release process notes, an agency that wishes to release software under an open source software licence needs to consider whether it has sufficient rights to do so. If the agency owns the intellectual property rights in the software and has not exclusively licensed it to someone else, it usually will have sufficient rights. In some cases the same result might be achieved by obtaining a sufficiently broad licence from the supplier that allows release on open source terms but this path can be more complicated and involve more paper work.
7. The IPR Guidelines do not contain guidance on what to consider when deciding whether to release software under an open source software licence. They also contain little guidance as to when and how to communicate to suppliers an agency’s intention to release procured software on open source terms (as that was not their purpose). These two aspects are addressed in this guidance note.
8. The following diagram demonstrates how agencies can respect the IPR Guidelines during a software procurement while incorporating a decision to release the procured software under an open source software licence. Note that it only considers the interaction between the IPR Guidelines and release of software on open source terms under NZGOAL-SE. There may be other reasons as to why an agency wishes to own procured software but they are not relevant to this guidance note.
Diagram demonstrating how agencies can respect the IPR Guidelines during a software procurement while incorporating a decision to release the procured software under an open source software licence.
9. This guidance note advises agencies to weigh up potential motivations for releasing software on open source terms alongside any concerns they may have in relation to releasing on open source terms. Agencies may also discover the potential value of the software code proposed during the procurement process so it’s important to be open and communicate well with respondents to notices of procurement.
10. Open source licensing of government procured software code in New Zealand is not mandated. It’s left up to individual agencies to consider and an informed decision to license their software on open source terms.
11. Agencies are encouraged to document the rationale for their decisions, regardless of whether they decide to release the procured software under an open source software licence.
12. Take into account that the default position in the IPR Guidelines is for the supplier to own the copyright in newly procured software and then consider:
a. Your agency’s existing policies regarding open source software (if any).
b. The benefits, exceptions and principles set out in NZGOAL-SE.
c. Any insights gained from pre-market engagement.
d. The common myths surrounding open source software.
e. The potential motivations and concerns set out below (which comprise the main body of this guidance note).
13. The final decision on whether to release procured software on open source terms will depend on your agency’s particular circumstances and the nature of the software in question.
14. The following sets out potential motivations for releasing procured software (that an agency owns or has sufficient rights to release) under an open source software licence.
15. One point of view is that newly developed, publicly-funded software should be treated as a public asset. Open source licensing allows legal reuse of this public asset and each reuse multiples the value of the public funds that contributed to its development (as the same code does not need to be developed more than once).
16. In some cases your agency’s technical know-how and processes may be captured through their having been embedded into the developed software code. Where this is the case, open source licensing of this code may:
a. facilitate ongoing access to and retention of this knowledge when technical staff move on, as having the code and documentation in an open source software repository makes it more accessible (this can be particularly valuable in specialist knowledge domains in which there are limited practitioners); and
b. releasing such code may help grow local IT talent and attract quality staff for an agency when required (being able to work on open source projects as part of one’s job can be a draw card and many organisations now look at developer candidates’ public code contributions as part of the technical recruitment process).
17. Releasing code under an open source licence can allow a wider range of suppliers to study, develop and offer support services to agencies in relation to the code2. This can also encourage competition in the market (as there is a choice of suppliers and low exit costs due to reduced vendor lock-in). Open source release in a public repository also maintains access to the code into the future should a supplier of this code stop trading or is acquired.
18. A rule of thumb with open source software is that what gets reused, gets maintained. You might consider breaking down procured deliverables into modular components containing your agency's specific business logic (less desirable for others to reuse and potentially not suitable to open source license) and more generic components able to be built upon further by others (good candidates for open source licensing).
19. An advantage of a growing open source community is that other users can help share the load of answering technical questions about the software. Don’t underestimate the effort required to build a thriving open source software community3. You might consider starting small and increasing community engagement over time.
20. An open and transparent software development process releases code early and builds it up iteratively in a public repository. This process can be used to help catch bugs, make it easier to maintain over time and improve reliability of the software4.
21. It can be important for citizens to be able to see how something they interact with works and that, in turn, may foster trust that they are being treated fairly.
22. Take for example, a digital public service that provides a calculation. If the business rules or calculations are not sensitive and do not raise any identifiable security or privacy risk then the code that produces the calculation could be released on open source terms.
23. An added benefit of this is that having calculations expressed in reusable code can improve consistency of this calculation across a range of software, both open source and proprietary. In some cases open source can also be used strategically to gain adoption of open standards and facilitate interoperability.
24. There is a move by governments internationally to what is referred to as a Government as a Platform5 approach to digital services delivery. Agencies combine modular and reusable components of software and open data to deliver digital government services to citizens more quickly and iteratively improve them over time6.Open source licensing makes the reuse of digital service delivery components easier by reducing the transaction costs of acquiring and assembling the required components to deliver digital services to the public. Currently, the New Zealand Government ICT Strategy and Action Plan can be seen as supporting this approach as it calls for more "common capabilities" and that "common service components are re-used by agencies"7.
25. The below sets out and assesses potential concerns agencies may have in relation to releasing procured software under an open source software licence.
26. Open source licensing of software code does not guarantee it will have superior security to code developed under a proprietary model or vice versa. A bug is a bug, and no software style is immune. However, making the code openly available may result in expert attention being given to it by experienced developers in the community that might not be available internally.
27. Releasing software code does not mean releasing data the software uses, configuration of the software in production or other sensitive credentials. Security or privacy-sensitive code or configuration layers should not be released and NZGOAL-SE recognises that it’s Open Access and Licensing Principle does not apply if release of the software on open source terms would create an unacceptable security risk or an unacceptable privacy-related risk. A key point to note here is that, through good design, it will often be possible to separate security or privacy-sensitive code or configuration layers (not to be released) from the rest of the code that can be released.
28. If there is an identifiable security risk or the code forms a critical system for government and exposes security enforcing functions8 you might consider not releasing the code. However, as noted, you may be able to isolate sensitive code from the more general reusable code, releasing only the latter under an open source licence.
29. Releasing your code under open source terms doesn’t necessarily cause a flood of interaction to occur and you level of interaction may change over time if the software gets wide reuse.
30. When you don’t have internal support experience to regularly maintain the project or allocated time to answer contributor questions, you can look to mitigate this through:
31. If you have a support team, remember that you open source license your code, not your time and attention. You can usually set expectations as to how frequently you will reply to external contributors in the documentation accompanying your software. Note that some questions about the software may be considered requests for official information. In such cases the Official Information Act 1982 would usually apply.
32. NZGOAL-SE was created to help make the open source licensing process straightforward for government agencies. It includes a detailed set of principles, a review and release process and specimen contract clauses for IP indemnity and warranties agencies can insert into contracts with suppliers. Open source licensing is grounded in copyright, if you need assistance you should consider consulting your legal team.
33. If you don’t have internal technical support for software you’re thinking of releasing under an open source software licence, you have the option of talking to suppliers in the market about providing this support for you. Suppliers can study the software and offer commercial service offerings (usually training and support) around it due to its openly accessible nature11.
34. While a valid concern, the IPR Guidelines are clear in stating that cost saving is usually not a sufficient reason for accepting a restricted licence (from supplier to agency) because accepting cost savings as a valid reason could:
a. reward vendors for deliberately tendering an unrealistic all-of-government price while offering a realistic single agency licence price; or
b. incentivise agencies to take a purely self-interested approach, at the expense of the government as a whole.
35. Suppliers may still be able to commercially exploit the software under the terms of the open source licence.
36. You may consider that the open source release of government software might compete directly with and unfairly impact local technology suppliers who developed the code or who have a similar commercial offering. Note, however, that: a. local suppliers themselves would be able to make use of the software and compete on service provision rather than selling code; and b. releasing publicly funded software under an open source software licence could accelerate and improve government digital services and (as noted above) be seen as aligning with the New Zealand Government ICT Strategy and Action Plan.
37. Potentially against that, another consideration is that accelerator12 or catalyst13 programmes and hackathon events14 are becoming more popular in driving better digital government services through the use of private-public initiatives and open government data15. Private sector retention and exclusive commercial exploitation of software code produced through these may be an incentive for participants to take part (though some events require code to be open source licensed).
38. All open source licenses include liability exclusions and warranty disclaimers as part of the licence terms. They state that the party releasing the code will not be liable for the consequences of its use and that it is not giving any warranties in relation to the software.
39. In addition, the NZGOAL Software Extension provides guidance you can follow to help you responsibly correct and communicate the issue using a process called a Coordinated Disclosure16. This process can help you to control and safely release sensitive changes reported by external contributors to your open source project.
40. The IPR Guidelines encourage communication of the copyright ownership intention as part of a Notice of Procurement, such as Request for Proposals (RFP), and rule 61 of the Government Rules of Sourcing contains a similar statement that applies to new intellectual property more generally. You should provide your reasoning for the decision to help suppliers understand and encourage responses.
41. Considering your decision to open source license may occur as early as an initial investment proposal or building a business case. Your considerations may be informed through discussions with internal stakeholders, other agencies and with suppliers through pre-market engagement processes.
42. Once you have decided that your agency intends to release new software code under an open source software licence, you will need to ensure you communicate this as early as possible to suppliers.
43. There are three ideal times when you should communicate your agency's intention to release publicly funded software under an open source software licence: pre-market engagement, in your RFP and in the contract (that will usually be attached to or mentioned in the RFP). Each are covered in more detail below.
44. You may be putting together a business case or request for information (RFI) to help define the problem you are trying to solve with your software development project. Framing your project as a user problem to be solved, rather than specifying a technical solution at this early stage is useful. It's at this stage that your decision to release the project as open source may also be informed as you learn more about the project characteristics. You might also investigate the "Prepare" and "Discovery" phases in the ICT.govt.nz Accelerate project framework to help guide your pre-market engagement.
45. For example, you may discover existing government open source solutions that fit your needs (or at least in part). In this case your project may reuse and build upon existing code, configuring it to your specific need and contributing back any resulting new software code. Alternatively, you may find out that the problem you are solving is being faced by other agencies and nothing currently exists to solve it. Here the reusability of the open source software code would be valuable to release and communicating early to other agencies would avoid duplication, give rise to a potential co-funding model17 and build support for releasing the code under an open source licence to ensure reuse by other agencies has a low transaction cost.
46. During a pre-market engagement consider:
a. Communicating with a wider set of government agencies.
b. Opening a dialogue with related communities of practice (online and in-person both locally and globally) in case they have solved the problem or would provide value helping to maintain software code you release as open source.
c. Raising the idea of open source release with suppliers to gauge openness to developing software in the open.
d. Building proofs of concept if no software exists to solve your problem (these could be released as open source to test demand and reusability of the project in a more tangible way).
47. The IPR Guidelines state that agencies should set out the conditions of copyright ownership in the RFP when going to market (which, at least for purchases worth $100,000 or more, will be via the Government Electronic Tenders Service). If you have made the choice to release procured software code under an open source licence, the RFP may be the earliest point at which you communicate this to suppliers. Your RFP should ensure it is clear that you are looking to procure developed software which you would like to release under an open source licence and that you are respecting the policy set out in the IPR Guidelines.
48. In your RFP we recommend that you:
49. As a separate matter, it is also desirable to document your decision process to open source license the software including your motivations, concerns and risk mitigations.
50. You may also wish to determine the approach to releasing the software code publicly18 including asking questions such as:
a. Will it be released once the work is completed as a whole?
b. Will you require the supplier to release an early iteration?
c. Will you require the supplier to carry out open development of the software?
51. Before reaching the contracting stage of the procurement, you should have already explained your intention to release procured code under an open source software licence. However, in some situations you may have learnt through the RFP process that open source software release is preferable. If the decision to open source license is made at this later point and the supplier is also in agreement you should ensure that the intellectual property provisions in your contract are drafted in a manner that gives you the rights you need to release the software on open source terms.
52. There are specimen contract clauses in the IPR Guidelines that can be used as starting points for the intellectual property ownership and licensing section of your software development contract. The clauses are in Appendix One to the Guidelines and the relevant ones (short form, medium form and long form) are numbered A3, B3 and C3 (the choice between depends on the nature, value and risk of your procurement).
53. Note that you can also:
54. Agencies are encouraged to seek assistance from their legal teams for these tasks.
Agencies are encouraged to include the following paragraphs in their Requests For Proposals (RFPs) once they have decided to release procured software code under an open source software licence. Communicating this is consistent with Rule 61 (Intellectual Property) of the Government Rules of Sourcing and the Statement of Policy set out in the Guidelines for Treatment of Intellectual Property Rights in ICT Contracts. The paragraphs are written on the assumption that a draft contract is attached to the RFP and that the draft contract confers ownership of new intellectual property rights on the procuring agency. The specimen clause for use in RFP below has been adapted from NZGOAL guidance note 3: Procuring copyright works19 and reads as follows:
1. Copyright and licensing a. Respondents should note that [name of procuring agency] will own copyright in new copyright works created as a result of this procurement and may elect to release and license them for re-use in accordance with the New Zealand Government Open Access and Licensing framework Software Extension (NZGOAL-SE) under: i. for software, a free and open source software licence; and ii.for documentation, a Creative Commons licence. Except as indicated below, respondents should not seek to alter the intellectual property provisions in the draft contract attached to this RFP that confer ownership of new intellectual property on [name of procuring agency]. b. Respondents may, however, have a legitimate interest in being able to re-use such copyright works before [name of procuring agency] licenses them for re-use in accordance with NZGOAL-SE. Where that is the case, respondents should request an appropriate licence from the procuring agency allowing them to do so. c. If a respondent feels there is overwhelming commercial or other reason as to why it must own the copyright in new copyright works under the contract, it should raise this with [name of procuring agency]. The respondent should expect that, if [name of procuring agency] allows the respondent to own copyright in new copyright works, [name of procuring agency] will require a licence to [name of procuring agency] that allows [name of procuring agency] to use the works for any purpose and to sub-license them for re-use under one or more of the licences referred to in NZGOAL-SE.
1. IPR Guidelines, p. 13. See https://www.ict.govt.nz/guidance-and-resources/open-government/procurement-advice/guidelines-for-the-treatment-of-intellectual-property-rights-in-ict-contracts/decision-process-for-determining-ownership-and-commercialisation/
2. http://www.dwheeler.com/oss_fs_why.html#wont-destroy-industry.
3. See http://wenger-trayner.com/introduction-to-communities-of-practice/.
4. http://www.dwheeler.com/oss_fs_why.html#reliability
5. See https://www.gov.uk/government/policies/government-as-a-platform
6. Open source software and the public sector. (Report by the National IT and Telecom Agency, Denmark, January 2009). Retrieved from http://www.digst.dk/Servicemenu/English/IT-Architecture-and-Standards/Open-Source-Software/Open-Source-Software-and-the-Public-Sector
7. https://www.ict.govt.nz/strategy-and-action-plan/strategy/
8. GDS in the UK provides a useful blog post on the situations when they opt not to release open source code at https://gds.blog.gov.uk/2014/10/08/when-is-it-ok-not-to-open-all-source-code/
9. The Department of Internal Affairs or the Ministry of Business, Innovation & Employment may have a relevant common capability, syndicated or all-of-government contract in place that agencies can sign up to, without needing to conduct their own primary procurement exercise, if they wish to obtain support in relation to software they release. See ict.govt.nz and procurement.govt.nz for details.
10. "Dispel Myths Within Your Organization" by Karl Fogel used under CC BY-SA 4.0
11. http://www.dwheeler.com/oss_fs_why.html#wont-destroy-industry
12. http://www.r9accelerator.co.nz/
13. http://datafutures.co.nz/our-work-2/catalyst-projects/
15. https://www.ict.govt.nz/programmes-and-initiatives/open-and-transparent-government/open-government-information-and-data-work-programm/
16. http://www.nzitf.org.nz/pdf/NZITF_Disclosure_Guidelines_2014.pdf [PDF 785 KB]
17. NZ Government Common Web Platform shared service has a co-fund open source model. See https://www.cwp.govt.nz/working-with-cwp/development-pool.
18. Consider here that the longer a software project stays closed the more difficult it is to make open later. Developing in the open ensures code is produced in a way that is more maintainable as an open source project going forward. See http://producingoss.com/en/producingoss.html#starting-open-for-govs
19. https://www.data.govt.nz/manage-data/policies/nzgoal/guidance-note-3
Last updated 22 March 2018