[Osia-members] NSW Government Procurement actively discourages use of Open Source

Jack Burton jack at saosce.com.au
Thu Aug 24 18:20:50 AEST 2017


On Wed, 2017-08-23 at 13:27 +1000, Cameron Shorter wrote: 
> In 2014 we discovered that NSW Procurement guidelines for large projects 
> state [1]:
> /23.1 The Contractor must ensure that://
> //(a) none of the Deliverables comprise Open Source Software; and//
> //(b) it does not insert any Open Source Software into the Customer 
> Environment,//
> //except to the extent otherwise approved by the Customer in writing. /
> 
> I've been alerted to the fact that this clause still exists in the new 
> draft, which is apparently due to be made public in September.

I've just checked, and it seems that ProcureIT v3.2 has been make public
*already* (although it will only start applying to new contracts from 1
Sep 2017 onwards).

See:
https://www.procurepoint.nsw.gov.au/before-you-buy/standard-procurement-contract-templates/procure-it-framework-version-32

OSIA raised several issues with both ProcureIT v3.0 (which is still
current for another week or so -- this was the version you originally
brought to our attention in 2014) and with some very early drafts
(which were not made public) of v3.2.

[note: there was never (at least while I was involved) any v3.1 of
Modules 13 & 13A. However, there *was* a v3.1 of the Customer Contract
and of all other modules. Agencies were continuing to use Modules 13 &
13A from v3.0 pending the release of v3.2]

The major issues were:

1. Flawed definition of OSS
===========================

Clause 1.3 of Module 13A in v3.0 contains a rather inaccurate definition
of OSS, which read like an attempted definition of they copyleft class
of OSS licences (rather than OSS licences in general), but did not even
get that quite right.

In v3.2 all definitions moved into the Dictionary (Part II).

I recommended against DFSI attempting to define OSS for themselves,
suggesting that they should instead adopt the OSD, as published &
maintained by OSI.

I made that recommendation formally on two occasions (first in relation
to v3.0 at a meeting that Ryan Cross & I attended with the then
principal solicitor at DFSI in January 2015, then again in relation to
v3.2 in OSIA's formal comments to DFSI on a v3.2 draft) and informally
on many other occasions.

It is pleasing to see that DFSI have adopted that recommendation: v3.2
defines OSS by reference to the OSD (and adds a note explicitly
including CC licences too -- no doubt to cover things like
documentation & data).

See here:
https://www.procurepoint.nsw.gov.au/system/files/documents/procure_it_v.3.2_dictionary.pdf

The v3.2 definition of OSS reads:

"1.82 Open Source Software means software available under a licence
which meets the criteria of  the Open Source Definition published by the
Open Source Initiative at http://www.opensource.org, and includes the
forms of creative commons licences published as the Creative Commons
Legal Code for Australia at http://www.creativecommons.org."

That is a big improvement to ProcureIT's precision & accuracy, although
it does not affect the core policy issues (see below).

2. Prohibition of OSS by default
================================

This is the issue that Cameron originally raised with clause 23.1 of
the v3.0 Module 13A.

Again, I objected to it formally on at least two occasions (the same
two listed above) and informally on many more, on each occasion
recommending that the provision in question be removed from ProcureIT
altogether.

Sadly, it seems that our recommendations were not followed: clause 23.1
of Module13A in v3.2 retains the exact same wording as in v3.0:
https://www.procurepoint.nsw.gov.au/system/files/documents/module_13a_major_project_systems_integration_services_v3.2.pdf

3. Discrimination against OSS
=============================

Clause 23.2 of the v3.0 Module 13A requires Suppliers seeking to offer
solutions involving OSS to provide additional warranties and
indemnities over and above what is required of Suppliers offering only
closed-source solutions.

This is not only discriminatory, but also ill-advised: in practise,
issues around disclosure to third parties (particularly of a Customer’s
Confidential Information) are far more likely to arise under the terms
of closed source software licenses than under OSS licenses.

Again, I objected to this formally on at least two occasions (the same
two listed above) and informally on many more, on each occasion
recommending that the provision in question be removed from ProcureIT
altogether.

Again, sadly, it seems that our recommendations were not followed:
clause 23.2 of Module13A remains in v3.2 just as in v3.0.

4. Impact of moving provisions from Module 13A to Customer Contract
===================================================================

In the early v3.2 drafts that DFSI provided OSIA to review in 2016,
clauses 23.1 & 23.2 from the v3.0 Module 13A had been moved out of
Module 13A and inserted into the Customer Contract (as clauses 13.14 &
13.15) instead.

Last year I argued strongly that this change made things substantially
*worse* by extending the discrimination & the default prohibition
described above to *all* NSW Government contracts (whereas when those
clauses were in Module 13A alone, they only applied to major project
systems integration services).

Looking at the "beta site" for v3.2, we can see that DFSI have left
those provision in the v3.2 Customer Contract *as well as* re-inserting
them into the v3.2 Module 13A. See here:
http://ec2-54-66-245-30.ap-southeast-2.compute.amazonaws.com/?q=node/173

(yes, I know that's not a gov.au URL. But I got there by following a
link from DFSI's website)

In the early drafts, the flawed definition of OSS was also present in
the Customer Contract -- which we objected to as well -- but that draft
provision has been removed from the v3.2 Customer Contract.

5. Proposed removal of OSS exceptions to warranties & indemnities
=================================================================

The v3.1 Customer Contract provided some explicit exceptions to
requirements for warranties & indemnities in relation to OSS. From our
perspective, these were *good* provisions. The exceptions applied
everywhere except on major projects (where they were overridden by
Module 13A).

In the early v3.2 drafts, those exceptions had been removed from
clauses 9.1(f) & 19.5(a) of the Customer Contract, and the qualifying
phrase "to the best of its knowledge and belief" had also been removed
from clause 9.1(f).

Naturally, we objected strongly last year to their proposed removal.

It is pleasing to see that DFSI have re-instated the exception for OSS
in clause 19.5(a) and that they have re-instated the qualifying phrase
"to the best of its knowledge and belief" in clause 9.1(f).

It is disappointing however to see that DFSI have not re-instated the
exception for OSS in clause 9.1(f).

6.  Proposed removal of OSS savings provision
=============================================

Clause 13.13 of the v3.1 Customer Contract provides a fairly standard
savings provision that affirms the survival of the terms of any existing
OSS license.

As I noted at the time, that appeared to have been added to the v3.1
Customer Contract in order to ensure that agencies can reap the
economic benefits of OSS by accessing broader competition in the
marketplace, which makes good sense.

In last year's early v3.2 drafts, that provision had been removed.

Naturally, we objected strongly last year to its proposed removal and
recommended its re-instatement.

It is disappointing to see that DFSI have not re-instated the savings
provision for existing OSS licences.


Please understand that the early v3.2 drafts I reviewed were not all
bad. There were also some *good* changes that DFSI were proposing, which
I'll describe now:

7. Privacy of Customer Data
===========================

In the early v3.2 drafts, DFSI was proposing must stricter privacy
requirements than in v3.1. These were most evident in Clause 15 of the
Customer Contract.

Whilst clearly there are some exceptions on both sides, privacy is an
area in which FOSS companies generally tend have a significant advantage
(from the customer's perspective) over their closed-source competitors.

So naturally, we *supported* those proposed changes.

It is pleasing to see that DFSI have retained the privacy enhancing
changes in Clause 15.1.

However it is disappointing to see that DFSI has abandoned the proposed
Clause 15.2 (which would have further strengthened the privacy
provisions of the contract).

8. Perpetual & irrevocable licenses
===================================

In the early v3.2 drafts, DFSI was proposing to require that licences
granted be perpetual & irrevocable. This was to be done in Clause 13.9
of the Customer Contract.

Again, from the customer's perspective this is an area were FOSS
suppliers tend to excel in comparison to their closed-source
competitors.

It is pleasing to see that DFSI have retained the new Clause 13.9 in the
v3.2 Customer Contract.

However, it is disappointing to see that v3.2 has introduced a massive
loophole with the qualifying phrase "Unless expressly agreed otherwise
in the General Order Form".

In other words, whilst the strong requirement is there by default, it
can be overridden all too easily.


Note that there were also a wide range of relatively minor matters
relating to ProcureIT which we raised with DFSI informally in 2015 &
2016. However, the 8 points above (6 substantial problems and 2
significant improvements) were the only ones that were seen as major
and therefore the only ones that we raised formally.

> Jack,  I know you co-authored a submission to get this changed, and 
> presented the submission. Where did that eventually get to?

I did indeed lodge a document with NSW DFSI on behalf of OSIA (on 19
Oct 2015) entitled "Preliminary comments on NSW ProcureIT v3.2 draft
(Module 13 and contract)".

Over a period of almost two years we had ongoing interactions with
various DFSI personnel regarding this matter. I took two formal
meetings with DFSI in Sydney (Ryan Cross was also present at the first
one), a number of calls & teleconferences and exchanged many emails, in
addition to providing our written comments on the v3.2 drafts.

In addition, with board approval, on several occasions I also discussed
the matter at length with the appropriate people at AIIA, who were also
engaging with DFSI on the ProcureIT review (AIIA agreed with us on
points #1 through #6 above -- especially #5 & #6 -- but disagreed with
us on points #7 & #8, and also raised a variety of other issues of
their own, which we saw as fairly minor in comparison to the 8 points
listed above).

Naturally I have not been involved in this matter since I resigned from
the OSIA board on 25 Nov 2016.

However, details of my contacts at DFSI were provided to the 2016/17
board in my post to osia-board@ of 3:41pm (Adelaide time) on 28 Nov
2016, which was one of a long series of reports I provided to the board
between 26 Nov & 28 Nov by way of a comprehensive handover of all
active OSIA matters for which I had previously been the principal
contact at OSIA.

The board were already (prior to that) well aware of the status of the
matter, by means of my umpteen written reports posted to osia-board@ &
other reports (both written & oral) given at various board meetings
over the course of the two years for which the matter had been active.

As for what, if anything, OSIA said or did on this matter after 28 Nov
2016, I have no idea.

You'd need to ask one of the current directors.

Indeed, I'd be interested to hear about that too.

> I'm thinking we might need to resubmit your submission.

It is probably too late for that now.

ProcureIT v3.2 has been announced, with a start date of 1 Sep 2017 (8
days from today).

Nevertheless, like you I am very disappointed to see that v3.2 looks set
no only to perpetuate the anti-OSS discrimination that was introduced in
Module 13A of v3.0, but extend it to cover contracts other than those
for major projects systems integration.

Still, there does appear to be one faint glimmer of hope. The website
on which DFSI has published the v3.2 Customer Contract is described as
"beta".

It is not altogether clear whether that refers to the v3.2 Customer
Contract itself, or merely to the form of the website on which it is
published.

One can only hope that it means the former.

If so, it would be good to see some last ditch attempts made to prevent
this travesty.

I have no standing to make that approach -- as I no longer represent
OSIA and neither of my companies sells to the NSW Government.

However, the current board could well make such an approach if they see
fit to.

Likewise, there is nothing stopping you -- and/or any other OSIA member
who sells into NSW Government -- making such an approach in parallel
yourself, or indeed via any other industry body you may also belong to
(e.g. I seem to recall one of your earlier approaches being under the
auspices of a group representing the OSS GIS sector).

If you want to discuss the specifics in more detail than might be
appropriate on the osia-members@ list, feel free to give me a call any
time.



More information about the Osia-members mailing list