• No results found

software in the procurement process

N/A
N/A
Protected

Academic year: 2021

Share "software in the procurement process"

Copied!
19
0
0

Loading.... (view fulltext now)

Full text

(1)

Manual on open standards and open source

software in the procurement process

Bart Knubben, consultant on Open Source Software [email protected], +31.70.8887821

(2)

Overview

Background OSOSS and Dutch policy Background manual

Principles within procurement regulation Open source software and procurement Open standards and procurement

(3)

Programme OSOSS

Past (2003-2005): OSOSS = “informing Dutch

government organisations on open standards and open source software”

2006-2007: OSOSS = open source software

integrated within the ICT-strategy of governments (ICTU)

2006- and further: OVOS = structural attention for

(4)

Dutch policy on OS & OSS

Widely supported motion in the Parliament (end of

2002)

Minister of the Interior and Minister of Economy:

- Open standards:

* Apply in case new software is built * Open up government standards

* Create new open standards on a European level - Open source software:

* Equal chance (“freedom of choice”) * Start up pilots

(5)

Policy and procurement law?

OSOSS received many questions from government

organisations;

Questions from the parliament to the Minister (2003).

“What is possible within the boundaries of Dutch and European procurement regulations?”

--->

Manual on open standards and open source software in the procurement process

(6)

Pivotal question

To what extent may a government organisation

calling for tender state in the tender documents that:

Open source solution is a requirement;

Open source solution is a preference / wish; A specific open standard is required;

A specific open standard is a preference / wish ?

Requirement = “must”

(7)

Principles of procurement law

Transparency Objectivity

Justification of choices Non-discriminatory

(8)

When does procurement law apply?

Tender by a government organisation; Exceeding franchise value / limit:

For supplies and services > EUR 162.000,=

So, in case open source software per se is acquired

(“downloaded”) and implemented by the

organisation itself (without a service or support contract) procurement law does not seem to apply.

The manual regards software solutions, i.e. software

(9)

Starting point of the manual

What is open source software? What is an open standard?

--->

(10)

Open source definition (OSI)

Used for approving licenses (www.opensource.org): 1. Free distribution

2. Availability of the source code

3. Permitting adaptation (derive works) 4. Integrity of the author's source code

5. No discrimination against persons or groups 6. No discrimination against fields of endeavour 7. Distribution of license

8. License must not be specific to a product 9. License must not restrict other software 10. License must be technology-neutral

(11)

Definition for open standards

1. Maintained by a not-for-profit organisation, open decision-making procedure;

2. Publication of specification;

3. Intellectual property on a royalty free basis; 4. No constraints on the re-use of the standard. Source: European Interoperability Framework

developed by IDABC.

Dutch catalogue of open standards: CANOS, www.canos.nl

(12)

Open source or open standards as a

requirement or preference

Open source software or open standards may be

required when all specific features/elements are of importance;

Open source software or open standards may be

preferred (wish) when some specific features/elements are of importance;

(13)

How to provide good justification?

Substantiate the need per element of the definition

in (internal) tender documents;

(14)

Open source example

VIR-BI (Dutch Regulation on Security of Special

Government Information) states that “modifications to hardware, software or procedures must be

checkable”.

This can be used to justify the requirement of feature “2. Availability of the source “

A government organisation foresees that certain,

additional functionality has to be created.

“3. Permitting adaptation (derive works)” is a crucial element for this organisation.

(15)

Open standard example

The Dutch law on archiving explicitly requires that

government organisations use a.o. XML.

This can be used to require XML which is considered to be an open standard.

The European directive on the re-use of public

sector information states: “To facilitate re-use, public sector bodies should make their own

documents available in a format which, as far as possible and appropriate, is not dependent on the use of specific software.”

(16)

Is referring to a specific open standard (i.e

“ODF”) allowed?

“Yes”, if it is a European norm, a European technical

approval or common technical specification. This means bottomline: standards from ISO, CEN and NEN, or standards prescribed by law.

Oherwise “No”, except when it is not possible to

indicate the required technical specifications in any other way than referring to the specific open

(17)

“...or the equivalent thereof.”

It is recommended to use the phrase “...or the

equivalent thereof.” This follows from the non-discriminatory principle.

Example: “The provided solution must be available

under an open source license or the equivalent thereof.”

This is not free of obligation. The government

organisation has to demonstrate afterwards that there were no equivalent tenders that met the specifications.

(18)

Suggestions for future steps

Collect and publish best and worst practices; Create example tender documents, i.e.

“procurement of a CMS”;

Address this on a European level, because

(19)

Questions and discussion

References

Related documents