8.OIA 2017.2562 Substantive response to requestor 27Feb2017.pdf

New Zealand Fire Service

National Headquarters
Level 12
80 The Terrace
PO Box 2133
Wellington

New Zealand

Phone+64 4 496 3600, Fax +64 4 496 3700



27 February 2017

A J

By email: [FYI request #5298 email]

Dear A J

OFFICIAL INFORMATION REQUESTS RELATED TO MYFIRE

Background

In your correspondence of 28 - 30 January 2017, you requested a range of information from
the New Zealand Fire Service Commission (‘NZFS’) pursuant to the Official Information Act
1982 (‘OIA’).

Namely, your requests were as follow:

1
If this request is to be denied via the reason that the software is in fact a trade secret of the
supplier;  I  would  expect  to  see  the  section  of  the  original  contract  (or  the  contract  in  its
entirety) that states that the IP and software still belongs to the supplier and not the NZ
Fire Service Commission.1
2
I’m unsure how the old supplier’s trade secrets could be protected from every potential
future competitors / supplier (given the new supplier would be working with the old source
code) and Guidance in this area would be appreciated as to how exactly the New Zealand
Fire Service Commission believes the trade secrets of suppliers will be protected into the
future.
3
What  unit  test  framework  and  language(s)  are  used  for  the  development  of  the  myFire
mobile app?
4
Who  has  the  rights  over  the  myFire  source  code?  Specifically,  the  right  to  make  this
information public?   If it is the developer, please provide the developers details. If it is the
NZ Fire Commission, please revisit the OIA request which was declined as releasing trade
secrets.  If the developer has rights over the source code, does this mean the developer is
also able to withdraw the source code from the fire service to protect his/her trade secrets
from  their  competition  had  the  latest  tender  been  won  by  a  different  supplier?  Is  the
expenditure  on  the  myFire  app  therefore  considered  a  donation,  as  the  NZ  Fire
Commission does not actually have rights over what was paid for? If this was a donation,
is the developer a registered charity?

1We have assumed the request referred to is your request, dated 13 December 2016, for the myFire Source Code.
www.fire.org.nz
Leading integrated fire and emergency services for a safer New Zealand │Te Manatū o ngā ratonga ohotata kia haumaru
ake ai a Aotearoa

1813644_1

5
How many submissions were made for the latest myFire tender (Nov/Dec 2016 period)?

NZFS sent you a letter on 22 February 2017 providing certain information that you requested
in  connection  with  OIA  Request  [1]  and  notifying  you  that  your  request  for  the  contract
governing  the  supply  of  the  myFire  Source  Code  had  been  transferred  to  the  Ministry  of
Business, Innovation, and Employment in accordance with subsection 14(b)(ii) of the OIA.

The purpose of this letter is to provide you with NZFS’s responses to your OIA Requests [2]
– [5].

For clarity, where an OIA Request was constituted by more than one part, I have separated
those OIA Requests into its constituent parts, and provided NZFS’s responses immediately
under each of those parts.

OIA Request [2]

In OIA Request [2], you asked:

I’m unsure how the old supplier’s trade secrets could be protected from every
potential  future  competitors  /  supplier  (given  the  new  supplier  would  be
working  with  the  old  source  code)  and  Guidance  in  this  area  would  be
appreciated  as  to  how  exactly  the  New  Zealand  Fire  Service  Commission
believes the trade secrets of suppliers will be protected into the future.

The myFire Source Code is hosted in NZFS’s secure cloud computing environment.  NZFS’s
systems  provide  both  practical  protection,  and  legal  protection, to  that  environment.  The
myFire Source Code (including trade secrets of suppliers incorporated into that source code)
is subject to the entirety of those protection measures, which I set out in detail below.

Practical measures to protect source code

NZFS’s secure cloud computing environment is rights-controlled by NZFS. It is able to be
viewed or accessed only by people or organisations that NZFS expressly authorises to do
so.  This ensures that:

a.  source code is not able to be viewed or accessed by members of the public;

b.  source code is not able to be viewed or accessed by regular users of myFire (except
for the presentation layer source code);

c.  source code is not able to viewed or accessed by employees or contractors engaged
by NZFS; and

d.  source  code  is  able  to  be  viewed  only  by  people  or  organisations  expressly
authorised by NZFS for that purpose (and only following appropriate scrutiny of that
person / organisation, and subject to the legal restrictions set out below).

Legal measures to protect source code

In order to receive authorisation to view source code, NZFS first requires that a person or
organisation  is  subject  to  express  legal  restrictions  that  restrict  the  manner  in  which  that
information can be used.  Amongst other matters, those relate to related to confidentiality,
restraints  from  trade,  and  conflicts  of  interests.    In  the  case  of  NZFS  employees,  those
restrictions are set out in employment agreements and / or the NZFS Code of Conduct.  In

21813644_1

the  case  of  contractors  (including  suppliers  selected  to  provide  IT  services  to  NZFS
applications),  those  obligations  are  set  out  in  the  contractual  terms  governing  a  given
contractor’s engagement.

NZFS  does  not  provide  any  person  or  organisation  with  access  to  its  cloud  computer
environment  until  both  (a)  that  access  is  considered  necessary  and  appropriate  for  that
person  /  organisation,  and  (b)  that  person  /  organisation  formally  agrees  to  the  legal
restrictions described above.  (One outcome of this practice is that people / organisations
that lodge tender proposals to support NZFS IT applications are not provided with access to
the  source  code  of  the  application  until  NZFS  and  that  party  have  entered  into  a  formal
contractual relationship.)

OIA Request [3]

In OIA Request [3], you asked:

What unit test framework and language(s) are used for the development of the
myFire mobile app?

No unit testing framework (or testing automation framework) was used for the development
of the myFire mobile app.  Manual unit testing was undertaken.  The language used for the
development of the myFire app was C# (Xamarin Studio).

OIA Request [4]

In OIA Request [4], you asked:

Who  has  the  rights  over  the  myFire  source  code?  Specifically,  the  right  to
make  this  information  public?      If  it  is  the  developer,  please  provide  the
developers  details.  If  it  is  the  NZ  Fire  Commission,  please  revisit  the  OIA
request which was declined as releasing trade secrets.  If the developer has
rights  over  the  source  code,  does  this  mean  the  developer  is  also  able  to
withdraw the source code from the fire service to protect his/her trade secrets
from their competition had the latest tender been won by a different supplier?
Is the expenditure on the myFire app therefore considered a donation, as the
NZ Fire Commission does not actually have rights over what was paid for? If
this was a donation, is the developer a registered charity?


Who  has  the  rights  over  the  myFire  source  code?  Specifically,  the  right  to  make  this  information
public?

Certain information (namely, intellectual property incorporated into the myFire Source Code,
which  was  created  or  developed  by  the  myFire  supplier  before  the  myFire  Supplier  was
engaged by NZFS) is owned by the myFire Supplier (the ‘Supplier IP’).  NZFS does not
have the right to make the Supplier IP public.

With the exception of the Supplier  IP, NZFS  commissioned and  owns the myFire Source
Code.  NZFS has the discretion to make that information public if it considers appropriate.

Revisit OIA request (8 December 2016) for myFire Source Code

You asked:

31813644_1

If  it  is  the  NZ  Fire  Commission,  please  revisit  the  OIA  request  which  was
declined as releasing trade secrets

NZFS  has  reassessed  your  request,  previously  received  on  8  December  2017,  for  the
myFire Source Code.2

NZFS’s  reassessment  has found,  in accordance  with  the  provisions  of  the  OIA,  that  it  is
necessary to withhold the myFire Source Code.

Particularly, NZFS findings are that:

1.  in  accordance  with  subsection  9(2)(b)  OIA,  it  is  necessary  to  withhold  the  myFire
Source Code in order to protect information where making the information available
would disclose a trade secret (‘Ground A’);

2.  in accordance with subsection 9(2)(b)(ii) OIA, it is necessary to withhold the myFire
Source  Code  in  order  to  prevent  likely  unreasonable  prejudice  to  the  commercial
position of the person who supplied or who is the subject of the information (‘Ground
B’), and

3.  in  accordance  with  subsection  9(2)(c)  OIA,  it  is  necessary  to  withhold  the  myFire
Source Code in order to prevent likely prejudice to measures protecting the health
or safety of members of the public (‘Ground C’).

In finding that it is necessary to withhold the myFire Source Code due to Grounds A and B,
NZFS’s assessment had particular regard to the following:

1.  notwithstanding  that  NZFS  owns  the  myFire  Source  Code  (as  set  out  above)  the
source code incorporates trade secrets of the supplier (as earlier set out in my letter
of 26 January 2017);

2.  the myFire Source Code discloses unique methods and techniques, developed by
the Supplier, to prepare the myFire Source Code;

3.  the  Supplier  incurred  significant  cost  in  developing  the  myFire  Source  Code  for
NZFS;

4.  the  myFire  Source  Code  could  be  duplicated,  reverse-engineered,  and  /  or
repurposed by a third party;

5.  the  myFire  Source  Code  would  be  of  commercial  value  to  a  competitor  of  the
supplier, and

6.  the  myFire  Source  Code  is  not  known  outside  of  NZFS  and  the  supplier  (Within
NZFS’s  IT  environment,  the  myFire  Source  Code  is  able  to  be  accessed  only  be
persons or organisations expressly authorised by NZFS and subject to appropriate
legal  restrictions.    Whilst  it  was  within  the  supplier’s  IT  environment,  the  myFire
Source Code was able to be accessed only be persons or organisations expressly
authorised by the supplier).

In finding that it is necessary to withhold the myFire Source Code due to Ground C (and as
previously noted in NZFS’s response of 26 January 2017) NZFS had particular regard to the

2 NZFS responded to that request on 26 January 2017.

41813644_1

likehihood  that  providing  the  myFire  Source  Code  could  prejudice  mission-critical  IT
infrastructure used to protect life and property from fire and emergencies.

More particularly, the myFire Source Code interfaces with a number of systems in NZFS’s
IT environment.  Providing the myFire Source Code would any viewers of it to identify and
exploit vulnerabilities in NZFS’s IT infrastructure.  This could disrupt the delivery of NZFS’s
life-critical services to member of the public, and / or compromise the accuracy of information
hosted on NZFS’s IT infrastructure.

NZFS has reconsidered other matters that may render it desirable, in the public interest, to
make  the  myFire  Source  Code  available.      NZFS  does  not  consider  that  those  matters
outweigh the reasons for withholding the myFire Source Code in these circumstances.

Supplier’s ability to withdraw source code

You asked:

Is  the  developer  able  to  withdraw  the  source  code  from  the  fire  service  to
protect his/her trade secrets from their competition had the latest tender been
won by a different supplier?

NZFS (a) legally owns the myFire Source Code to the extent that it was created for NZFS,
and (b) legally owns the rights to use Supplier IP in the myFire Source Code to the extent
required to use myFire.

Accordingly, the developer of the myFire Source Code would not have the right to withdraw
the myFire source code from NZFS without NZFS’s express consent.

For completeness, NZFS adds that,  any subsequent ICT service suppliers, authorised by
NZFS to access the myFire Source Code, would be bound by the legal obligations set out
above.  NZFS considers that those appropriately protect the trade secrets, incorporated into
the myFire Source Code, belonging to the supplier.

Donation and myFire Expenditure

You asked:

Is the expenditure on the myFire app therefore considered a donation?
If this was a donation, is the developer a registered charity?

NZFS does not consider any expenditure incurred in the development of myFire to date has
been incurred for a charitable purpose, nor paid / treated as a donation.  NZFS does not
consider that the myFire Supplier is a registered charity.

Charities Services maintains a public record of all organisations with registered charitable
purposes in accordance with the Charities Act 2005.  The Charities Register is public, and
can be accessed at: https://www.register.charities.govt.nz/CharitiesRegister/Search.

OIA Request [5]

In OIA Request [5], you asked:

How many submissions were made for the latest myFire tender (Nov/Dec 2016
period)?

51813644_1

By  way  of  background,  NZFS  issued  an  RFP  (Request  for  Proposals)  for  Web  /  App
Development  Services  –  myFire  (NP2211)  on  23  November  2016.    The  deadline  for
proposals to be lodged with NZFS in response to the RFP was 22 December 2016.

NZFS  has  assessed  your  request  for  the  number  of  proposals  lodged  with  NZFS,  in
response to the RFP, in accordance with the OIA.

NZFS considers it is necessary to withhold that information until after NZFS has entered into
an agreement with a supplier of the services that the RFP related to (the ‘Agreement Date’).

In  particular,  NZFS  considers    it  is  necessary  to  withhold  the  information  to  that  time
because:

a.  in accordance with section 18(d) OIA, the information will be publically available, by
being published on the Government Electronic Tendering Service (‘GETS’), no later
than 30 days after the Agreement Date. GETS is available at www.gets.govt.nz; and

b.  in accordance with section 9(2)(j) OIA, to enable NZFS to carry on negotiations with
suppliers without prejudice or disadvantage.

NZFS has considered other matters that may render it desirable, in the public interest, to
make this information available prior to the Agreement Date.   NZFS does not consider that
those matters outweigh the reasons for withholding this information until after the Agreement
Date.

NZFS  presently  anticipates  that  the  Agreement  Date  will  occur  in  mid-March  2017,  and
following that looks forward to advising you how many proposals were received in response
to the RFP.

Review of decision(s)

If you are dissatisfied with any decision(s) made in connection with your requests, you have
the  right  to  seek  a  review  of  the  decision(s)  through  the  Office  of  the  Ombudsman  in
accordance with section 28(3) of the OIA.  The Office of the Ombudsman can be contacted
on 0800 802 602 or online at www.ombudsman.parliament.nz.

I trust that  the  information  provided  is  sufficient for  your  purposes.   In the  event  that  you
have any further queries, please do not hesitate to contact NZFS.

Yours sincerely

Leigh Deuchars
Director, Office of the Chief Executive

61813644_1