NZGOAL Software Extension
Version 1
July 2016
ISBN 978-0-478-10773-9 (PDF version)
ISBN 978-0-478-10772-2 (HTML)
Crown copyright ©. This copyright work is licensed under the Creative Commons Attribution 4.0 International licence. In essence, you are free to copy, distribute and adapt the work, as long as you attribute the work to the New Zealand Government and abide by the other licence terms. To view a copy of this licence, visit http://creativecommons.org/licenses/by/4.0/. Please note that neither the New Zealand Government emblem nor the New Zealand Government logo may be used in any way which infringes any provision of the Flags, Emblems, and Names Protection Act 1981 or would infringe such provision if the relevant use occurred within New Zealand. Attribution to the New Zealand Government should be in written form and not by reproduction of any emblem or the New Zealand Government logo.
Contents
Introduction
Purpose
Free and open source software and licences
Approach and scope
Additional guidance notes
Legal and policy context
Copyright law
Guidelines for Treatment of Intellectual Property Rights in ICT Contracts
Government Rules of Sourcing
NZGOAL-SE Policy Principles
Introduction
Open access and public release of agency software using free and open source licences
Ensuring copyright ownership or right to sub-license
Exceptions
Adaptations
Security code review
No additional controls or discrimination
No charging
Updating FOSS licensed software
Contributions
Obtaining rights when procuring or commissioning the development of software
Act fairly towards developers when drafting IP warranties and indemnities
Liability
Review and Release Process
NZGOAL-SE Review and Release Process
Introduction
Stage 1: Copyright-related rights evaluation
Stage 2: Evaluation of exceptions
Stage 3: Select a FOSS licence
Stage 4: Application of chosen licence
Stage 5: Release the software
Review and release process decision tree
Annexure: Specimen IP warranty and IP indemnity clauses
Introduction
Purpose
1. Government agencies invest significantly in software development and often own the copyright in the software that they develop or that is developed for them. Public sharing and the licensing of this government-owned software under free and open source software licence terms has the potential to:
save agencies time and money, resulting in a more efficient use of scarce resources;
encourage open innovation on the part of both the public and private sectors;
contribute to economic growth, primarily through the private sector being able to leverage and support government investment in the software it openly releases for re-use;
contribute to the formation of trusted communities of users whose public and private sector members have common or similar goals or interests;
result in continuous and ongoing maintenance of the released software code through these communities of users in a way that may not be achievable by a single agency alone;
enable agencies to better align their operational and strategic activities with relevant aspects of the Government ICT Strategy 2015; and
in some cases, foster transparency — for those who can read software code — as to the methods or algorithms used for the creation or delivery of public data and services, thereby enabling critical analysis and potentially the provision of improvements back to the releasing agency.
2. This NZGOAL Software Extension (NZGOAL-SE) provides agencies with a means of realising this potential. It:
explains the legal and policy context that is relevant to agencies' open source licensing of software;
sets out a series of policy principles to guide agencies in their open sharing of software code;
advocates the use of particular open source software licences for this purpose; and
sets out a review and release process to guide agencies through the review of the software they propose to release for re-use, the purpose of which is to help agencies make decisions that are legally robust and practically useful.
Free and open source software and licences
3. For the purposes of NZGOAL-SE, free and open source software (FOSS) is software source code that is released on licence terms that grant others the freedom to use, copy, modify and distribute the software, for either non-commercial or commercial purposes, as long as they comply with the applicable licensing conditions. It is important to note the following:
the licensing conditions that users of the software need to comply with depend on the form of FOSS licence applied to the software;
"free" in FOSS refers to the granting of a set of "freedoms" or permissions usually only available to the copyright owner and arising from the bundle of property rights the owner has in its copyright work; and
there are several common phrases in use that refer to the same style of licensing, such as "free software", "free and open source software", "open source", "FOSS", "OSS" and "FLOSS". Depending on the context, NZGOAL-SE uses a combination of "free and open source software", "FOSS" and "open source", all with the same meaning referred to above.
4. There are two main forms of FOSS licence:
more permissive licences that confer broad freedoms and minimal obligations on those who wish to use, adapt and distribute the software (e.g., the MIT licence, the BSD licence and the Apache 2.0 licence); and
sharealike licences (also known as copyleft licences) that confer similar freedoms and require those who adapt the licensed software to license their adaptations with the same licence if they distribute them (e.g., the GNU General Public License, or GPL for short).
Approach and scope
5. NZGOAL-SE is an extension of, and is modelled in part on the approach to, the open licensing of government copyright works set out in the New Zealand Government Open Access and Licensing framework (NZGOAL). NZGOAL-SE is a self-contained extension or framework, rather than being part of the original NZGOAL framework, because certain considerations are different to those relating to open information and data. Incorporating both frameworks under a single roof would unduly complicate matters for agencies and others interested in the frameworks.
6. NZGOAL-SE is not concerned with the proprietary versus open source debate or with the considerations that agencies may wish to take into account when using existing open source for their own internal purposes.1 Its sole focus is on the public release and open source licensing by agencies of software they own or are authorised to release and license.
Additional guidance notes
7. Additional guidance notes may be released over time which:
explore, in greater detail, some of the issues addressed or raised in NZGOAL-SE; or
address operational or technical issues which arise in practice.
↑Top
Legal and policy context
Copyright law
8. Key aspects of copyright law relevant to open licensing generally are set out in the NZGOAL Copyright Guide.2 Additional aspects relating specifically to software include the following:
copyright exists in original software: software is a form of "literary work" and original literary works are a category of works in which copyright exists (section 14(1) of the Copyright Act 1994 and the section 2(1) definition of "literary work");
infringement: as such, unless entitled to do so by a copyright licence or statutory provision, a person infringes copyright in software that that person does not own when he or she does any of a number of "restricted acts", the most common of which is copying the work or a substantial part of it or adapting the work;
adaptations: an "adaptation", in relation to a literary work that is a computer program (i.e., software), includes "a version of the program in which it is converted into or out of a computer language or code or into a different computer language or code, otherwise than incidentally in the course of running the program" (section 2(1));
first owner of copyright:
employee-employer relationship: when employees create software for their employer in the course of employment, the employer is the first owner of copyright in the software unless the employment contract states otherwise. This is the case where the employer is the Crown (section 26) and where the employer is another person, agency or entity (section 21(2));
service provider-customer relationship: when a service provider creates software for a customer under a contract for services, the customer is the first owner of copyright in the software unless the contract for services states otherwise. Again, this is the case where the customer is the Crown (section 26) and where the customer is another person, agency or entity (section 21(3)).
Guidelines for Treatment of Intellectual Property Rights in ICT Contracts
9. These Guidelines3 are relevant where an agency procures the development of software from a service provider. They state that only in limited circumstances should the government own and exploit new intellectual property rights (IPR) created under an ICT contract. The default position is that the supplier should own the new IPR, with licences being granted to the customer agency and other State Services agencies.
10. This position could create an obstacle to an agency licensing developed software on open source terms because the agency can only do so if it has the requisite rights to do so. If it doesn't own the copyright, it doesn't have the requisite rights unless expressly authorised by the copyright owner.
11. The Guidelines recognise, however, that there may be situations where an agency needs to own the IPR. One of those situations is where the agency "intends to allow free use of the IPR on open source terms". Agencies would, therefore, be acting consistently with these Guidelines if they were to require the development contract to confer ownership of copyright in the software on the agency, on the basis that they wish to license the software on open source terms.4
Government Rules of Sourcing
12. Who is to own the copyright in new software is a significant issue that needs to be considered at the time of procuring the software development services, a point that is made clear in Rule 61(1) (Intellectual Property) of the Government Rules of Sourcing.5 That Rule states:
"If an agency's procurement of goods, services or works involves the supplier creating new Intellectual Property, the agency should set out, in its Notice of Procurement, its intentions regarding ownership, licensing, and future commercialisation of that Intellectual Property."
↑Top
NZGOAL-SE Policy Principles
Introduction
13. Government agencies are strongly encouraged to apply the following Policy Principles in relation to publicly releasing and licensing their software on open source terms. The Principles should be read in their entirety but here is a summary:
Policy Principle
Summary
Open access and public release of agency software using free and open source licences
If an agency wishes to license its software, it is encouraged to do so on open source terms, to use public version control and source code repository platforms and to follow the NZGOAL Review and Release Process and decision tree.
Ensuring copyright ownership or right to sub-license
Make sure your agency has the required copyright-related rights to license the software.
Exceptions
Releasing under open source terms does not apply where an exception applies.
Adaptations
Respect existing licenses when re-using existing software. Be careful when considering whether you're "adapting" pre-existing software.
Security code review
Consider whether a security code review is required to identify sensitive elements that may need to be removed.
No additional controls or discrimination
Do not seek to impose requirements that are inconsistent with the freedoms in the chosen FOSS licence.
No charging
Do not charge people for access to FOSS licensed software.
Updating FOSS licensed software
If you spot a bug with software you've licensed, consider informing users and, if you fix the bug, release the updated files. Take appropriate action if there's a security risk.
Contributions
Where appropriate, adapted, pre-existing open source licensed software should be contributed back to the open source community. Agencies should provide guidance on how they will accept external contributions to their own released source code.
Obtaining rights when procuring or commissioning the development of software
If you commission the development of software that you want to FOSS license, make sure you obtain the rights to license it on FOSS terms.
Act fairly towards developers when drafting IP warranties and indemnities
If you commission the development of software that uses pre-existing third party FOSS licensed software and/or that you may FOSS license, act fairly in relation to IP warranties and indemnities.
Liability
Replicate all disclaimers and exclusions contained in the relevant FOSS licence when you release software under that licence.
Review and Release Process
Follow the NZGOAL-SE Review and Release Process.
Each Policy Principle is set out below.
Open access and public release of agency software using free and open source licences
14. If government agencies have the required copyright-related rights to do so, and wish to license their software source code for re-use, they are encouraged:
to consider making their source code, that is or may be of interest or use to people, available for re-use under a FOSS licence as further described in these Policy Principles and in accordance with the NZGOAL-SE Review and Release Process and decision tree, unless an exception in paragraph 18 applies; and
if they decide to do so, to:
use existing version control systems and source code repository platforms to allow for discussion and improvement of released software;6 and
make the software publicly accessible by releasing it online; and
use existing, freely available software to interact with the released software source code
(the Open Access and Licensing Principle).
15. For the purposes of NZGOAL-SE, the recommended set of free and open source software licences for which selection guidance is provided are:
the MIT licence:7 this is a more permissive licence in the sense that it does not contain a sharealike obligation that would require adaptations to be licensed under the same terms if distributed (the full text of the MIT licence can be found on the website of the Open Source Initiative)8; and
the GPL licence: this is sharealike/copyleft licence that requires those who adapt the source code to release their adaptations on the same terms if they distribute them (the full text of the GPL licence can be found on the website of the Free Software Foundation).9
↑Top
Ensuring copyright ownership or right to sub-license
16. Paragraph 14 makes it clear that, for the Open Access and Licensing Principle to apply, an agency must have the required copyright-related rights to license the software.
17. Agencies should only license software for re-use by others under a FOSS licence where:
they own or can obtain an assignment of all copyright in the software and have not exclusively licensed it to a third party; or
to the extent they do not own the copyright, they have or can obtain permission from the copyright owner(s) to do so
(the Rights Clearance Principle). It can be important, in this context, to check whether developers have reused tracts of code from elsewhere and, if they have, to assess the licences that apply to those tracts to ensure the agency has all the rights it needs.
↑Top
Exceptions
18. The Open Access and Licensing Principle does not apply where:
civil wrongs: open source licensing of the software would constitute a breach of contract, breach of confidence, breach of privacy, disclosure of a trade secret or other actionable wrong;
commercial interests: open source licensing of the software would be contrary to an agency's own or the Government's legitimate commercial interests (note, however, that most government agencies are not in the business of commercialising developed software);
security or privacy risk: release of the software on open source terms would create an unacceptable security risk (whether to an agency, organisation or individuals) or an unacceptable privacy-related risk.
↑Top
Adaptations
19. In the course of its activities, an agency may incorporate or adapt pre-existing software source code that is licensed under one or more FOSS licences. Alternatively, an agency may produce new software source code that interacts with a pre-existing FOSS-licensed application. Take a plug-in or extension to an existing application as an example. Depending on the context, a plug-in or extension may be an adaptation of pre-existing source code (e.g., where it has forked an old plug-in or extension) or it may be new source code designed to interact with a pre-existing application but without taking any pre-existing source code. If an agency proposes to release its source code in these kinds of situations, the agency should:
respect the terms and conditions of the existing licences (such as attribution requirements); and
where possible, use the same free and open source licence or licences applying to the pre-existing software source code, even in cases where - strictly speaking - it is not required to do so
(the Respect Existing Licences Principle).
20. It is important to note that using more permissively-licensed source code (e.g., MIT-licensed source code) and sharealike/copyleft-licensed source code (e.g., GPL-licensed source code) together in a broader project may require you to release your new source code under the same sharealike/copyleft licence or a compatible licence (in most cases the licence will be version 2 or 3 of the GPL)10 rather than under the more permissive licence. Whether this is the case depends on the circumstances. Legal advice should be sought if required.
21. Difficult legal questions can arise as to whether a given piece of developed software, that in some way leverages or interacts with other software, is in fact an adaptation or derivative of that software. If:
an agency's developed software does leverage or interact with other software; and
that other software, or part of it, is software owned by a third party that has been released under a sharealike open source software licence like the GPL,
the agency should be cautious about concluding that its developed software is not an adaptation or derivative of the other software. The need for caution arises because if the agency concludes mistakenly that the developed software is not an adaptation, release of the developed software under an incorrect licence could result in the agency breaching third party rights and expose it to the risk of complaint or legal action. End users would also be at risk of breaching third party rights and be exposed to the risk of complaint or legal action. If an agency is in any doubt on this issue, it should seek specialist advice (which could be both technical and legal) before releasing the software for re-use.
↑Top
Security code review
22. Before releasing software for re-use, agencies should:
consider whether there is any prospect that the code or associated files may contain sensitive elements that may need to be removed prior to release; and
if there is such prospect, have the code and any associated files security-reviewed before release.
↑Top
No additional controls or discrimination
23. When releasing developed software under an open source software licence, agencies must not seek to impose controls or requirements, whether contractual or otherwise, that are inconsistent with the freedoms or permissions granted by the selected licence. For example, agencies are not able to license software under an open source software licence and then seek to discriminate between individual, not-for-profit and commercial uses of the software.
↑Top
No charging
24. Government agencies that release software under open source software licences should not seek to charge people for access to the software.
↑Top
Updating FOSS licensed software
25. If an agency:
publicly releases software on open source terms; and
subsequently identifies a bug or other issue with the software that could have a material adverse effect on users of the software,
the agency should (subject to paragraph 26):
consider whether to inform users of the software of the bug or other issue (e.g., by adding a notice to the repository, site or service that contains the software files); and
if the agency has rectified the bug or other issue for its own purposes, release the updated file(s) to the relevant repository, site or service.
26. If the agency is aware:
of a bug or other issue that creates a risk to the security of sites or services using the software or to the confidentiality or privacy of information held by those sites or services; and
that other government agencies are using the software,
the agency should inform the Government Chief Information Officer (and where relevant the Government Chief Privacy Officer and Office of the Privacy Commissioner) as soon as possible, take all reasonable steps to inform the other agencies of the risk and give them time to mitigate the risk before making any public announcement that could result in people with malicious intent or crackers11 exploiting the bug or other issue. Agencies may also wish to consider including a Coordinated Disclosure Policy12 in an accompanying "contributing" file to set expectations as to how the reporting of security risks ought to be handled.
↑Top
Contributions
Agency contribution to FOSS communities
27. Where an agency has re-used and adapted pre-existing free and open source software source code or has developed new code to interact with free and open source software source code, the agency should:
consider asking the free and open source software community or the software source code owners whether any agency adapted feature or improvements or the agency's new source code would generally be re-usable by others (if this isn't already clear);
if so, contribute their adapted or new source code back to the free and open source software community project unless an exception listed in paragraph 18 applies; and
avoid using a diverging fork13 copy of the software source code when it could reasonably use the upstream source code and contribute agency adaptations of it back to the community for general re-use
(the Contribute to FOSS Communities Principle).
Agency acceptance of contributions from others
Contribution guidance and files
28. Part of the value of releasing free and open source software in accordance with the Open Access and Licensing Principle is that external contributors can re-use and contribute back improvements to agency-released software source code. To accept contributions from external contributors in a manner that enables contributions to be licensed properly and shared with others, agencies should consider providing explicit contribution guidance to users that:
explains any technical aspects of making the contributions;
sets expectations for users as to how the agency will review and accept contributions of source code;
sets out any code of conduct, moderation policy or terms of use that apply when external contributors engage publicly in discussions about the agency-released software source code;
indicates whether external contributors need to physically sign and return a contributor licence agreement14 or other document before the agency will accept contributions from them, or specifies that the act of contributing source code means the contributing user is agreeing to license his or her contributions to the agency and others under a specified FOSS licence; and
ensures that users know that they must own the copyright in their contributions or be permitted to license them to the agency and others under the licence that the agency specifies (this is important as it seeks to mitigate the risk of the agency accepting and publishing external contributions that, for copyright reasons, should not be accepted and published).
29. In the open source software context, a common means of providing this contribution guidance to users is by including a 'contributing' file in documentation that accompanies the source code. It is important that this file (or other document if an alternative approach is used) is brought to the attention of users before or at the time they submit contributions. Some source code repositories bring the existence of a 'contributing' file to the attention of users at the time of submission but if an agency is not using such a repository it should take care to ensure the terms of contribution are brought to users' attention.
30. Whilst this is a decision for agencies, NZGOAL-SE suggests that it will usually be unnecessary, administratively burdensome and potentially counterproductive to require contributing users to physically sign and return a formal contributor licence agreement or other document. In most cases agencies will be able to secure the rights they need, with sufficient confidence, by including the 'contributing' file mentioned above in documentation accompanying the source code and ensuring that this file is brought to users' attention before or at the time of submitting their contributions. Agencies should seek advice from their legal teams if required.
Comment on assignment versus licensing
31. Agencies may wish to note that there are two ways in which an agency could obtain the rights it needs from contributors. An agency could require contributing users to assign (i.e., transfer) any copyright in their contributions to the agency or it could require contributors to license their contributions to the agency and others under a specified FOSS licence. The advantage of seeking assignments of copyright is that this enables the party maintaining the source code to own it all. That makes it easier to take action against a user who does not comply with the applicable FOSS licence terms. The significant disadvantage of seeking assignments of copyright is that it can inhibit contributions (as developers may wish to retain their copyright). In a government context, it could also be seen as 'over-reaching'. An assignment also needs to be "in writing signed by or on behalf of the assignor" (section 114 of the Copyright Act 1994). It will be evident from the approach suggested above that NZGOAL-SE does not recommend that agencies seek to obtain assignments of copyright in users' contributions. Rather, the suggested approach allows contributors to retain their own copyright and only requires them to license their contributions under a specified FOSS licence.
Suggested licensing text for 'contributing' file
32. NZGOAL-SE suggests that agencies include the following kind of licensing text in their 'contributing' file or other documentation that they bring to the attention of users before or at the time of source code submission (the content in square brackets needs to be completed):
33. Agencies may also wish to ensure that the 'contributing' file, or other document that is brought to the attention of users, contains the matters referred to in paragraph 28(a)-(e) above.15
↑Top
Obtaining rights when procuring or commissioning the development of software
34. When procuring or commissioning the development of software, government agencies should consider whether they may wish to release the software to the public for re-use under an open source software licence. If the answer is yes, agencies should consider the steps that may be required as part of their procurement and contracting processes to ensure that either:
they have the relevant rights to release the software under an open source software licence; or
that the developer will release the software under a specified open source software licence.
35. Such steps may include:
ensuring the agency owns the intellectual property rights in the developed software; or
ensuring the agency obtains a broad licence from the service provider allowing the agency to sub-license the software under the MIT licence or GPL (or, if required, some other free and open source software licence); or
insisting on contractual provisions that require the service provider to release the software under a specified open source software licence (and, where relevant, to a specified code repository).
36. Taking these steps may require:
the inclusion of appropriate paragraphs in a notice of procurement (where applicable); and/or
the inclusion of specific contractual provisions in a draft contract; or
where an existing panel supply arrangement is being used, a review of the intellectual property provisions in the panel contract and, if required and possible, amendments to them for the purposes of the software development in question; and
ensuring that the contract does not include confidentiality provisions that would inadvertently prevent release of the software under an open source software licence.
↑Top
Act fairly towards developers when drafting IP warranties and indemnities
37. If:
a government agency is commissioning a service provider to develop software that is to be released on open source terms (either by the agency or by the service provider under a contractual obligation for the service provider to do so); and
it is known that the developer will be leveraging or adapting existing open source software developed by others,
the agency should act fairly towards the service provider in relation to the drafting of intellectual property warranties and indemnities.
38. In particular, it is generally considered unreasonable to expect a service provider to give an unqualified intellectual property (IP) warranty and an unqualified IP indemnity in relation to third party open source software that the agency agrees can be used by the service provider in developing software for the agency. This is especially so when the agency will be releasing the developed software under an open source software licence or requires the service provider to do so on its behalf. Sample IP indemnity and IP warranty clauses are provided in the Annexure to NZGOAL-SE.
↑Top
Liability
39. The MIT licence and the GPL both contain broad disclaimers of warranties and exclusions of liability that are widely known and acknowledged and ought to protect releasing agencies from liability in connection with the software they have released. In essence, people use free and open source software at their own risk. Agencies should ensure that all disclaimers and exclusions contained in the MIT licence or the GPL (as applicable) are replicated when they release software under these licences.
↑Top
Review and Release Process
40. Government agencies should follow the NZGOAL-SE Review and Release Process before publicly releasing and licensing their software for re-use under a free and open source software licence. The Review and Release Process is set out below.
↑Top
NZGOAL-SE Review and Release Process
Introduction
41. It is recommended that government agencies follow the review and release process set out below before releasing software source code for re-use under a FOSS licence, with assistance where required from their technical and legal teams. The process consists of five main stages:
copyright-related rights evaluation;
evaluation of exceptions;
select a FOSS licence;
application of the chosen licence; and
release of the software.
42. Each stage contains one or more issues that may need to be worked through. The stages and the issues within them reflect a mixture of the NZGOAL-SE Policy Principles, legal requirements and practical considerations.
43. It can be important to work through these steps to ensure that the agency:
has all relevant rights in or to the software source code it proposes to publicly release;
uses the appropriate open source licence; and
does not expose either itself or those who may re-use the released software to liability or related risk.
44. A decision tree diagram for the review and release process is set out at paragraph 82 below.
↑Top
Stage 1: Copyright-related rights evaluation
What the stage involves
45. The first stage involves:
clearly identifying the boundaries of the software that the agency proposes to release (e.g., the software may comprise a range of files, all of which would need to be released together);
determining whether that software constitutes or contains one or more copyright works; and, if so
evaluating whether the agency has sufficient rights to license the software under open source terms.
46. In the vast majority of cases, software that an agency wishes to license will constitute or contain one or more copyright works. In the unlikely event that a given piece of software does not constitute or contain one or more copyright works, an agency could, if no exception in Stage 2 applies, release it into the public domain using an NZGOAL-style "no known rights" statement. See NZGOAL for that statement. It is not discussed further in NZGOAL-SE.
Issues where agency does not own all copyright
47. When an agency is in the situation of not owning all copyright in the software it would like to release and license for re-use and needs permission from the copyright owner(s), it is important to appreciate that the software may:
be all new source code (i.e., be a completely new copyright work);16 or
build on pre-existing source code (i.e., be an adaptation / derivative of pre-existing source code).
48. The analysis for these two scenarios is different:
All new source code: In the case of all new source code that the agency doesn't own but wishes to license, the agency would need to either:
already be entitled, under a FOSS licence that the owner has recently applied to the software, to sub-license the software; or
obtain irrevocable written permission from the copyright owner to sub-license the software on the relevant open source terms.
Notes on sub-licensing: As to the first option, it is important to note three points. First, if the software has already been licensed under a FOSS licence, there may be no need for the agency to sub-license it because anyone who gets the software has the rights granted by the licence that the owner has applied. Second, some licences prohibit sub-licensing. For example, you cannot sub-license GPL-licensed software. Third, if there is a right to sub-license, that right would need to be broad enough to allow sub-licensing under the particular FOSS licence that the agency wishes to apply to the software.
Adaptation / derivative of pre-existing code: In the case of an adaptation / derivative of pre-existing source code, the agency would need to:
be able to identify who owns the pre-existing source code (noting that there could be more than 1 owner/contributor) and who has made and owns the new copyright in the adaptation / derivative work; and
to the extent that the agency does not own the copyright in the adaptation / derivative work, have permission from the other copyright owner(s) for their parts of the overall new work to be licensed under the FOSS licence the agency wishes to use.
To understand this, one needs to appreciate that an adaptation / derivative work consists of property (copyright) owned by the original licensor(s) (let's call them A) plus new and separate property (copyright) over the new original parts of the adaptation / derivative work that are created by B. The adaptation / derivative work is a distinct copyright work in its own right but B doesn't obtain property rights that are greater than B's own contribution. As a United States court has put it, "[t]he aspects of a derivative work added by the derivative author are that author's property, but the element drawn from the pre-existing work remains on grant from the owner of the pre-existing work".17
Depending on the number of pre-existing owners, the licences (if any) under which they may have released their code and the licence the agency wishes to apply to the adaptation / derivative work, this can get complex very quickly. In cases of any complexity, agencies may need to seek expert legal advice.
Common scenarios where an agency will not be able to license software for re-use
49. There are certain scenarios in which, from a copyright perspective, an agency will not be able to license software either under any FOSS licence or under a particular FOSS licence. Three common scenarios are as follows:
third party owner: copyright in the software is owned by a third party and the agency is not permitted to license the software for re-use under a FOSS licence. In this scenario the agency cannot license the software under any FOSS licence;
adaptations of proprietary software: the software is an adaptation or derivative of proprietary software and the agency does not have the proprietary software owner's written and irrevocable authorisation to license the adaptation or derivative under a FOSS licence (whilst the agency might own the copyright in its new contributions, it still needs authorisation from the owner of the base software that it adapted). In this scenario the agency cannot license the software under any FOSS licence; and
adaptations of GPL or similarly FOSS-licensed software: the agency wishes to license the software under the MIT licence but the software is an adaptation or derivative of open source software that is licensed under a sharealike FOSS licence, such as the GPL, that requires distributed or conveyed adaptations or derivative works to be licensed under the same licence. In this scenario the agency cannot license its adaptation under the MIT licence.
↑Top
Stage 2: Evaluation of exceptions
50. If an agency has completed Stage 1 and concluded that it does have sufficient rights to license the software under a FOSS licence, then the NZGOAL-SE Policy Principles recommend that the software be licensed under open source terms unless an exception set out in paragraph 18 applies.
51. For each proposed release, the exceptions need to be considered in the light of all the surrounding circumstances relevant to the specific software and its release.
52. In many instances, the exercise will be quick as none of the restrictions will apply. In that event, the agency can proceed to Stage 3 (Select a FOSS Licence) below. This is because the Open Access and Licensing Principle will not have been displaced.
53. If one or more of the exceptions applies, the Open Access and Licensing Principle will be displaced and not apply. One of two consequences will follow:
No FOSS licensing: FOSS licensing of the source code may not be possible unless the reason for the exception(s) can be removed in accordance with paragraph 53(b). If FOSS licensing is not possible, the analysis ends and there is no need to consider the subsequent stages below.
FOSS licensing after amending or anonymising the source code: If the source code can be amended or altered to remove the reason(s) for the exception(s) applying, the Open Access and Licensing Principle is resurrected and one progresses to Stage 3.
↑Top
Stage 3: Select a FOSS licence
Introduction
54. Once an agency has determined that it has:
the copyright-related rights it needs to license the software (in accordance with the Rights Clearance Principle); and
none of the exceptions listed in paragraph 18 that would negate the Open Access and Licensing Principle applies,
the agency can work through Stage 3 to select the appropriate FOSS licence before applying the selected licence in accordance with Stage 4.
55. In most cases, an agency's selection of a FOSS licence is likely to turn on the answers to one or more of the following questions:
whether the source code builds upon and/or interacts with existing FOSS-licensed source code;
if the source code does not build upon and/or interact with existing FOSS-licensed source code, whether a person who adapts the code and distributes it to others should be required to license the adaptations for re-use by others;
whether there are known reasons or use cases for releasing the source code under a FOSS licence other than the recommended GPL or MIT licences.
56. NZGOAL-SE does recommend a default set of licences (GPL and MIT) but a "yes" answer to the first question may require (legally or ethically) the selection of a different FOSS licence and a "yes" answer to the third question might suggest that a more targeted FOSS licence is preferable. Each of the three questions is now discussed in turn.
Source code builds upon and/or interacts with existing third party FOSS-licensed source code - respect existing licence(s)
57. If the source code builds upon and/or interacts with existing third party FOSS-licensed source code, the Respect Existing Licences Principle applies. In this scenario, an agency should — where possible — select the same licence(s) for its new software code as the licences applying to the pre-existing source code (the upstream licences), or licences that are compatible with the upstream licence(s). For consistency reasons, using the same licence(s) is usually preferable to using compatible licence(s).
58. To give an example, if an agency developed a software library that interacts with a pre-existing open source application licensed under the Berkley Software Distribution (BSD) licence18, it would be consistent with the Respect Existing Licences Principle for the agency to license its new source code under the BSD as well. Effectively, the BSD licence would become the selected FOSS licence as an outcome of the Stage 3 analysis.
59. Note, however, that the words "where possible" are used above because it will not always be possible to apply the same licences as the upstream licences. This can be the case where different parts of the pre-existing software the agency has used are licensed under different FOSS licences. For example, some of the pre-existing code might be licensed under the MIT licence (which is not a sharealike / copyleft licence) and other parts of the code might be licensed under the GPL (which is a sharealike / copyleft licence).
60. Where an agency uses these differently licensed parts of software in a broader project (e.g., the agency might adapt the pre-existing software) the agency may be required, by the sharealike licence, to release its new code under the sharealike licence when the agency distributes its new code. In other words, a sharealike licence like the GPL may trump the non-sharealike licence (in this example, the MIT licence). Generally speaking, if an agency is using multiple pieces of software in a project and those pieces are licensed under different FOSS licences (non-sharealike and sharealike), new code should be released under the sharealike licence and not the non-sharealike licence. See the Adaptations Principle in paragraphs 19-21 for further explanation and, if in doubt, seek legal advice before selecting and applying a FOSS licence.
61. To give an example, if an agency develops and distributes a plugin for a content management system that, legally speaking, is an adaptation of MIT-licensed code and GPL-licensed code that the agency has mixed together and used, the agency may need to license the plugin under the GPL. Whether there is an "adaptation" can be a difficult legal question in some cases but, if there is an adaptation, the GPL will trump.
Entirely new source code - default FOSS licences
62. As noted above, NZGOAL-SE recommends a default set of licences - two licences - for cases in which an agency wishes to release entirely new source code for re-use; in other words, for cases in which the source code to be released does not build upon and/or interact with existing FOSS-licensed source code.
63. The default licences, in no particular order, are the GPL licence and the MIT licence. These default licences and the reasons for selecting them as the NZGOAL-SE defaults are described in the NZGOAL Policy Principles (Open access and public release of agency software using free and open source licences).
64. NZGOAL-SE suggests that an agency's choice between these two default licences should turn on the answer to this simple question: would you like everyone to be able to re-use other people's distributed adaptations of the source code in the future?19
65. If the answer to this question is yes — that is, a person who adapts the code and distributes it to others should be required to license the adaptations for re-use by others — then the agency should select the GPL (version 3).
66. If the answer to this question is no — a person who adapts the code and distributes it to others does not need to license the adaptations for re-use by others — then the agency should select the MIT licence.
67. Answering the question yes or no is a judgement call for the agency.
68. In either case, the agency should proceed to Stage 4 (Application of chosen licence) unless there are known reasons or use cases for releasing the source code under a FOSS licence other than the recommended GPL or MIT licences (as discussed immediately below).
Known reasons or use cases for releasing source code under an alternative FOSS licence
69. In some cases an agency may wish to release entirely new source code and there may be specific known reasons or use cases for not opting for the GPL or MIT licences. Two examples of this are as follows:
Libraries: the source code to be released is a library of code and the agency knows that there are proprietary software suppliers who wish to use the agency's particular library within, or to link the library to, their own proprietary source code without having to release (or it being argued that they have to release) their proprietary code if they distribute their software. The GNU Lesser General Public Licence (LGPL) will allow this kind of use without exposing the downstream user to risk. The LGPL requires software licensed under it to be modifiable by end users through source code availability and does not require proprietary code that is linked to the LGPL-licensed library to be made available under the GPL.
Server side use of licensed software: the sharealike obligation in the GPL (i.e., the obligation to license one's adaptations under the GPL) is triggered upon distribution of an adaptation. Where software is installed on a server to provide a service to end users (e.g., in an application service provider or cloud services context), the sharealike obligation is not triggered. To some people this seemed like a loophole. The GNU Affero General Public Licence (AGPL) was designed to close that loophole. It is based on the GPL and sates that if source code is adapted then the "public use of a modified version, on a publicly accessible server, gives the public access to the source code of the modified version".20 There may be cases in which an agency is FOSS-licensing software that is used on servers where the agency would like to achieve this result or where communities of interest ask the agency to achieve this result. If so, the agency may wish to select the GNU Affero General Public Licence (AGPL) instead of the GPL.
70. The selection of licences for unusual use cases like these can be difficult and in some cases using one of the NZGOAL-SE default licences (the GPL or MIT licence) may suffice. If in doubt, seek technical or legal advice in the context of your particular use case.
Licensing of accompanying documentation
71. Explanatory documentation files included alongside open source software code are usually separate copyright works. These works are often thought to be licenced under the FOSS licence that has been applied to the source code. However, most FOSS licences used for source code are not designed for documentation and often don't naturally or comfortably apply. A more appropriate approach is to apply a Creative Commons licence to documentation in accordance with NZGOAL.
72. Two situations need to be considered: the first is where the agency has created completely new documentation, the second where the agency has adapted pre-existing documentation.
New documentation: In the case of new documentation that the agency owns (i.e., it owns the copyright), the Creative Commons licensing is straight-forward. In this situation, NZGOAL-SE recommends that the Creative Commons licence choice reflect the nature of the selected FOSS licence. This means that an agency releasing new documentation alongside source code released under:
a more permissive licence such as the MIT licence, should license the documentation under a Creative Commons Attribution 4.0 International licence; and
a sharealike/copyleft licence such as the GPL, should license the documentation under a Creative Commons Attribution S