Policy paper

Open Standards principles

Updated 11 September 2015

Foreword

Digital technologies continue to transform government. They help to make government services more accessible to you, their users. As a government, we are committed to an ambitious programme of constant improvement in digital services.

We believe this will not only provide better, more accessible services, but also more efficiency and better value for taxpayers’ money.

When the Open Standards Principles were first published in 2012 they underlined the government’s commitment to the wider use of open standards across government.

Since 2012, we’ve made a lot of progress towards this objective. In light of advances and developments over the last three years, it is now the right moment to update the Open Standards Principles.

Better, more accessible services can only be delivered by a truly open process: open to those who use our public services, and open to suppliers, of all sizes, so that competition and innovation can deliver improved services.

Several common platforms based on open standards have already been developed or delivered, such as GOV.UK and GOV.UK Verify.

Despite this progress, we can and must do more. The publication of the refreshed Open Standards Principles is another step forward, helping to level the playing field for open source and proprietary software, and disaggregating government IT into smaller, more manageable components.

Our aim is simple: government technology that is affordable and open, improving public services for the citizens that they serve.

The Rt Hon Matthew Hancock MP Minister for the Cabinet Office and Paymaster General

Introduction

The first version of this policy became active on 1 November 2012. From this date government bodies (central government departments, their agencies, non-departmental public bodies (NDPBs) and any other bodies for which they are responsible) were required to adhere to the Open Standards Principles - for software interoperability, data and document formats in government IT specifications. It has been reviewed and updated in 2015 – differences are highlighted in a separate document.

The Technology Code of Practice commits the government to creating a common and secure IT infrastructure based on a suite of agreed, open standards. This commitment is supported by the Digital Strategy, the Service Design Standard and the Digital Inclusion Strategy, which focus primarily on the opportunity to harness technology to redesign and improve public service information and transactions.

Since the Open Data White Paper was published in June 2012, transparency and access to data have been put at the heart of government and public services, making it easier for data publishers to release data in standardised, open formats. The Open Data Principles contained within the Open Data White Paper have become a fundamental part of the process of government data publication. The National Information Infrastructure (March 2015) which follows on from the white paper places the UK government Open Standards Principles at its heart. Public data is published using open standards, and data from different departments about the same subject should be published in the same, standard formats and with the same definitions, such as calendar events using iCalendar (RFC5545) format. Even without creating a new open standard, the Public Sector Digital Infrastructure data uses these principles.

The Open Standards Principles provide a foundation on which to select and implement open standards to support open data, the IT and digital strategies.

Scope

This policy and its principles refer to the government in its role as a purchaser of IT and to services delivered by, for, or on behalf of central government departments, their agencies, non-departmental public bodies (NDPBs) and any other bodies for which they are responsible. We recognise, however, that most public bodies deliver services through IT enabled projects, many of which need to work across organisational boundaries. Consequently whilst this policy focuses on central government, we shall work to promote the open standards principles for software interoperability, data and document formats with all public bodies in the UK. Local government, the wider public sector and the devolved administrations are encouraged to adopt the principles to deliver wider benefits.

These principles relate to open standards for software interoperability, data and document formats as depicted in figure 1.

Diagram showing open protocols for software interoperability, with data stored in data stores as open data and document formats
Figure 1 - Diagram illustrating the technical scope of the Open Standards principles for software interoperability, data and document formats

These standards enable software to interoperate through open protocols and allow the exchange of data between data stores and software through open data and document formats. Standards for internal processing within hardware (including telecommunications hardware), which are not relevant to external interfaces, are out of scope.

This policy describes principles for the selection and specification of open standards which can be implemented in both open source and proprietary software. For information on the government’s level playing field policy see the Cabinet Office Technology Code of Practice.

Future policy development

The open standards policy will be reviewed in 2018 and may be updated to account for technology changes, changes to procurement regulations or lessons learned from implementation. Associated action plans and standards selection activity will be continually updated.

What open standards help to deliver

By implementing the Open Standards Principles for software interoperability, data and document formats, government bodies are supporting the delivery of:

  • a level playing field for open source and proprietary software providers competing for government IT contracts
  • improved flexibility and ability for government to cooperate with other bodies, citizens and businesses
  • more sustainable cost in government IT projects

Open Standards Principles

These principles are the foundation for the specification of standards for software interoperability, data and document formats in government IT:

  1. We start with user needs
  2. Our selected open standards will enable suppliers to compete on a level playing field
  3. Our standards choices support flexibility and change
  4. We adopt open standards that support sustainable cost
  5. Our decisions on standards selection are well informed
  6. We select open standards using fair and transparent processes
  7. We are fair and transparent in the specification and implementation of open standards

Principle 1: We start with user needs

Statement

Government IT specifications are based on user needs, expressed in terms of capabilities with associated open standards for software interoperability, data and document formats.

Rationale

At present, the data gathered by the public sector is not always readily accessible. A lack of common standards is a barrier that can make it difficult for users to scrutinise activity or generate added value. The National Information Infrastructure, updated in March 2015, is a framework to manage the government’s strategically important data. Its principles include interoperability and user need.

Citizens, businesses and delivery partners must be able to interact with the government, exchanging appropriately formatted information/data using the software package of their choice. They must not have costs imposed upon them, or be digitally excluded by the IT choices which the government makes, beyond those which may reasonably be associated with accessing digitally provided services (i.e. internet access).

The government needs to share appropriate information and data across and beyond government boundaries to provide efficient services to citizens, businesses and delivery partners. This level of interoperability may require technical, semantic, legal and organisational agreements. In some cases these services may need to work across European or international borders.

Selecting open standards for software interoperability, data and document formats in government IT specifications removes the potential for unintended barriers to digital participation.

Implications

The product choice made by a government body must not force other users, delivery partners or government bodies, to buy the same product e.g. web-based applications must work equally well with a range of standards-compliant browsers, irrespective of operating system, and not tie the user to a single browser or desktop solution.

Government bodies must not impose undue cost on citizens and businesses due to the standards choices made in government IT specifications.

Government bodies must be clear about the user need and functional outcome for a standards-based solution in specifications so that suppliers can meet these needs. Government bodies must not specify particular brands or products.

The selection process that government uses to identify pan-government open standards for IT should start with identifying a user need.

Principle 2: Our selected open standards will enable suppliers to compete on a level playing field

Statement

Open standards can be implemented by a diverse range of suppliers. In selecting open standards for government IT specifications, the government removes barriers to competition, such as lock-in.

Rationale

The government’s procurement choices have resulted in a lack of diversity in existing government IT contracts. As a purchaser of IT, this restricts our options and threatens value for money.

Expressing user needs in terms of required capabilities, which are in turn based on open standards, helps government bodies to ensure that better choices are made for service delivery through IT specifications. It also means that there is no unintentional lock-in built into government IT.

European procurement law requires that technical specifications must allow equal access to suppliers, while not creating unjustifiable obstacles for opening up public procurement to competition. In addition, where a technical specification is defined by reference to certain external standards, contracting authorities must allow solutions which meet the required functionality by alternative means if a tender satisfies the requirements of those specifications in an equivalent manner.

In addition, where a technical specification is defined by reference to certain external standards, contracting authorities must allow solutions which meet the required functionality by alternative means if a tender satisfies the requirements of those specifications in an equivalent manner.

Open standards for software interoperability data and document formats, which may be implemented in both open source and proprietary solutions, provide an environment that is agnostic and plural with regard to technology, suppliers and commercial arrangements. They also enable the breaking down of large IT contracts into smaller components, supporting the government’s IT strategy presumption against contracts over £100 million.

Implications

When specifying IT requirements for software interoperability, data and document formats, government bodies must request that open standards adhering to the definition described in this policy are adopted, subject to the principle of equivalence. (Specifications/standards in IT procurements must comply with Regulation 42 of the Public Contracts Regulations 2015 - paragraph 11 of Regulation 42 refers to the principle of equivalence. Note that in the context of Regulation 42, national standards are those maintained by British Standards Organisations: British Standards Institute; British Electrotechnical Committee).

Whether they are designed and built in-house, outsourced, or commercial, off-the-shelf (COTS), government bodies must require solutions that comply with open standards, for software interoperability, data and document formats, where they exist and meet functional needs, unless there is a robust and transparent reason why this is inappropriate.

Frameworks for government IT procurements, where applicable, must specify that open standards for software interoperability, data and document formats should be implemented, subject to the principle of equivalence, unless there is a clear business need why an open standard is inappropriate and an exemption has been agreed.

When specifying IT standards, government bodies must ensure that they are compliant with European Regulations.

Cabinet Office provides guidance to government bodies on the process for requesting an exemption to the open standards policy.

Principle 3: Our standards choices support flexibility and change

Statement

The government’s IT and data and the standards upon which they are built, are enablers for change, giving services the freedom to evolve according to changing user needs, expectations and technology innovation.

Rationale

Flexible IT, built on open standards-based components, enables interoperability and compatibility between existing and new systems or solutions, or transferability of data and information between old and new systems. Standardised data accompanied by open data formats also facilitate re-use.

Full interoperability requires organisation and legal alignment, as well as semantic and technical agreements.

Smaller, component-based IT projects provide a flexible design to allow choice and enable an evolution of the government’s IT estate, rather than costly big bang changes. This reduces the risk of lock-in to suppliers, software, service and support, or to old and inefficient IT.

Information and data shared appropriately across organisational boundaries without loss of integrity, reduces the need to hold duplicate data and supports efficient service delivery. The opportunities for exploiting information greatly increase when it is made available in standardised and linkable forms. As Government as a Platform (GaaP) develops from concept into reality, it will provide much of the organisational, technical and semantic context in which the open standards operate. A single publishing platform (GOV.UK) means people only have to look in one place to find what they need. A single data platform can make it easier to find data and find new uses for it. A single platform for identity can give us a secure way to verify who we are with government.

Making data and APIs available allows others to produce alternative, innovative views of government data and access to government services.

By being more innovative on small-scale, low risk IT projects, the government can deliver innovative solutions. For larger scale, more high risk government IT projects, implementing mature open standards with a broad market support provides a stable infrastructure on which to build. Responsive and flexible IT requires skilled professionals from a range of disciplines to be involved in the specification, procurement and delivery of solutions. The government continues to reinforce the message of the Civil Service Reform Plan (updated October 2014). It highlights the importance of a unified, skilled and innovative workforce, with particular emphasis on digital professions across the Civil Service.

Implications

Government projects may publish suggested solutions to operational challenges on the Standards Hub. These should seek proposals for organisation, legal, semantic and technical aspects of interoperability within a specific context.

The Standards Hub process requests proposals and results in adopted open standards or open standards profiles for use in a specific government IT context.

A senior-level government sponsor (a Senior Responsible Owner or SRO) must be responsible for each standard that progresses through the Standards Hub process. The SRO shall identify needs (functional and user) and provide implementation guidance for adopters.

Respecting data protection, privacy and security requirements, information and data must be shareable across government IT systems in line with current legislation, policies and principles.

Advised by the SROs for adopted standards, a central open standards secretariat shall maintain a pipeline to inform the review of adopted standards through the Standards Hub process.

Subject matter experts, with implementation experience in government bodies, should participate in the committees of standardisation bodies for software interoperability, data and document formats.

Government bodies should expose application programming interfaces (APIs) for their services to enable value-added services to be built on government information and data.

Procurement, project management, information and IT professionals in government bodies must have the skills to make appropriate choices in IT specifications and bid assessments, in line with the Open Standards Principles. Training and guidance should be offered through partnerships with established profession and skills development networks.

Principle 4: We adopt open standards that support sustainable cost

Statement

Decisions are based on the most economical solution for the public sector as a whole and costs are sustainable.

Rationale

The government has implemented IT spend controls to ensure that it spends taxpayers’ money more carefully and avoids unnecessary investment.

Total cost of ownership calculations for software often consider the exit and migration costs as part of the cost of the new solution, when in fact this may in part represent the hidden cost of lock-in to an existing solution.

Greater standardisation enables sharing and reuse of IT solutions and components across government organisations. It reduces complexity and the need for bespoke integration between non-standardised solutions.

Value for money is achieved through avoidance of lock-in and providing a level playing field for suppliers to compete for government IT contracts, coupled with sustained competitive tension after the point of purchase.

Short-term financial savings based only on cost could risk longer-term lock-in and are not necessarily the most cost-effective in terms of whole-life or when broader cross-government working or re-use is considered.

Implications

Where there is an economic and operational benefit for government as a whole, a compulsory open standard (or open standards) for software interoperability, data or document formats shall be identified through the Standards Hub process. (Compulsory open standards must be specified by government bodies unless an exemption is agreed through a comply or explain process)

The Standards Hub process must make an economic appraisal (including analysis of costs, a value for money proposal and statement) when recommending an open standard or standards-based profile to the Open Standards Board for compulsory use in government IT.

For all new government IT expenditure (for new systems or extensions to existing systems), government bodies must specify compulsory open standards (or open standards profiles) for use within common government contexts (subject to the principle of equivalence). This may be subject to exceptional case-by-case exemption if agreed in advance by the government’s Senior Responsible Owner (SRO) for open standards (or through Departmental Accounting Officer procedures for cases below the Cabinet Office spend controls threshold for IT).

The Senior Responsible Owner (SRO) for open standards in government IT must agree all exemptions to the open standards policy in specifications for projects above the spend controls threshold, through the existing IT spend controls process.

The Departmental Accounting Officer in a government body must be accountable for approval of any exception to the open standards policy in specifications for projects below the Cabinet Office IT spend controls threshold.

Government bodies must perform an economic appraisal for each request for an exemption as part of a comply or explain process.

For government bodies that are identified as not adhering to the Open Standards Principles (eg through transparent reporting or spend controls cases), Cabinet Office may consider lowering the threshold for IT spend controls until alignment is demonstrated.

As part of examining the total cost of ownership of a government IT solution, the costs of exit for a component should be estimated at the start of implementation. As unlocking costs are identified, these must be associated with the incumbent supplier/system and not be associated with cost of new IT projects.

For existing systems that are not being modified, these should be considered as legacy and should not be extended. Transition to open standards for software interoperability, data and document formats must be considered by government bodies within exit management plans, in accordance with the timescales for the refresh lifecycle of the existing technology.

In preparation for any technical refresh projects, or in exceptional circumstances, where extensions to IT contracts or to legacy solutions have been agreed, government bodies must formulate a pragmatic exit management strategy. These must describe publicly the existing standards used together with the transition to open standards and compulsory open standards. Transition should take place within a specified timescale (agreed as part of the Standards Hub process).

Newly developed frameworks competed by the Crown Commercial Service (CCS), which include lots pertinent to software interoperability, data and document formats, should be aligned with the Open Standards Principles.

Principle 5: Our decisions about standards selection are well informed

Statement

Effective selection of standards for government IT specifications is a result of pragmatic and informed decision making, taking the consequences for citizens, users and government finances into account.

Rationale

Open standards evolve and updated versions or entirely new standards develop in response to technology innovation. There is a risk that selecting particular standards may prove costly in the long run if:

  • a standard that is selected is not compatible with other government systems
  • the same open standard is not interoperable across different implementations in government
  • the standard is not supported by the market, either in the short or longer term

In some circumstances, open standards do not exist for a particular function, may not meet the identified need, or an alternative solution may be proposed by a supplier through an open procurement process.

Alternative standards may therefore need to be evaluated to meet user and service delivery needs through government IT. However, the potential variance across implementations has to be taken into account as this may cause interoperability problems across government boundaries.

In the UK, appropriate legal and security constraints must be considered in order to share information and data across and beyond government boundaries. In international and pan-European projects, government bodies also need to interoperate according to agreements made with delivery partners.

A rigorous and transparent selection process is needed for the assessment of compulsory open standards for software interoperability, data and document formats in government IT, before they are adopted. This should have defined criteria and an appropriate governance structure. Government bodies need to be assured that the proposed compulsory open standards will achieve the required outcomes and keep pace with technology and market changes.

Professionals in government bodies and those scrutinising projects require the knowledge and skills necessary to assess standards for inclusion in IT specifications.

Implications

The Standards Hub must describe specific operational requirements that open standards in government IT may help to solve.

Cabinet Office, advised by an Open Standards Board, determines the compulsory open standards for adoption by government bodies in government IT, using the Standards Hub. This process is published on the Hub. The Open Standards Board membership is selected from a group of industry, professional, developer and academic volunteers who have demonstrated implementation, standards setting or strategic leadership in this field. The chair of the Board is the government’s senior responsible owner for open standards. The Board is supported by panels of data and technology experts drawn from within and outside of government.

Where necessary, profiles of open standards for software interoperability, data or document formats in government IT should be agreed to ensure interoperability across different implementations.

Government bodies should engage in the Standards Hub process. Subject matter experts outside of government bodies may engage in the Standards Hub process.

The selection criteria for compulsory open standards in government IT is based on the European Common Assessment Method for Standards and Specifications (CAMSS). It is published on the Standards Hub. The selection criteria considers security and legal requirements; user and operational needs; context; economic efficiency; interoperability; market support; potential for lock-in; the criteria for open standards and maturity. Only open standards that are considered to be mature should be considered for compulsory adoption.

All selected standards have a review period that is identified during the selection process according to relevant factors. Earlier reviews should be initiated where there are new developments, for example in technology.

The open standards SRO, advised by the Open Standards Board (OSB), shall ensure that recommendations from the Standards Hub process are implementable and supported by the market.

The government may develop or encourage the development of open reference implementations for the standards being considered, where these do not already exist, in association with suppliers, voluntary groups or academia.

Government bodies must fulfil international obligations and regulations relating to agreed standards for cross-border interoperability, whether or not these comply with the Open Standards Principles and definition.

Where possible, government bodies shall encourage use of open standards for software interoperability, data and document formats in international government IT projects.

Officials in government bodies in IT project scrutiny and oversight roles and those involved in creating IT specifications should follow guidance on standards selection.

Guidance is available so that government bodies understand their responsibilities relating to open standards in IT specifications for projects being considered under the spend controls process. (Under the IT spend controls process operated by Cabinet Office, a pipeline of upcoming IT procurement is maintained for government bodies to enable early engagement.)

The selection criteria for standards chosen by government bodies for software interoperability, data and document formats in government IT must consider each of the criteria the Cabinet Office identifies in the selection criteria for compulsory open standards. In addition, government bodies requesting an exemption to compulsory open standards must also provide an analysis of the impact that their standards choice may have, according to specified impact criteria (e.g. interconnection with new cross-government solutions, opportunities for suppliers in a level playing field).

Migration to a new open standard or newer versions of compulsory standards in government IT shall be considered through the Standards Hub process, on a case by case basis, taking into account the costs, timescale and impact of migration on existing systems.

Guidance and training shall be provided on issues relating to open standards in government IT for professionals in project management, procurement, information and technical roles.

A government body must provide evidence of a pragmatic and informed process to reach its decision if it wishes to apply for an exemption that allows it to specify a standard that is not open where an open standard exists for software interoperability, data and document formats.

Government bodies may support or participate in the committees of standardisation bodies, fora and consortia as subject matter experts.

Government bodies must be compliant with current government security policies and standards.

Principle 6: We select open standards using fair and transparent processes

Statement

The selection and adoption process for open standards and open standards based profiles in government IT is transparent, allowing engagement with the public and subject matter experts.

Rationale

Transparent engagement and selection processes for standards for use in government IT allows a vast wealth of implementation and user-based knowledge to be shared, helping government to reach the right decision.

Transparency allows government bodies to have a two-way conversation with the users and suppliers of government services and the experts who develop and implement standards.

Implications

The Standards Hub process must be transparent and collaborative to support continuous engagement and implementation improvements.

For each proposal on the Standards Hub, public engagement must be supported and notes of meetings relating to the consideration of proposals for standards adoption must be published.

A transparent feedback facility must be provided through the Standards Hub to allow implementers and subject matter experts to report issues with open standards that have been selected as compulsory for use in government IT.

Principle 7: We are fair and transparent in the specification and implementation of open standards

Statement

Government IT procurement, specifications, implementation plans and agreed exemptions from the open standards policy are open and transparent.

Rationale

Holding the government to account in the decisions we make ensures that we are fair - for example when selecting open standards or in an IT procurement process.

Potential suppliers need a way to engage with government if inappropriate specifications are advertised that distort a level playing field. Standardised IT solutions sometimes operate well at a local level but do not interoperate across boundaries, for example when extensions or complex implementation profiles are adopted. This can lead to additional cost and reduces the benefits of implementing a standardised approach.

Implications

Government bodies must provide publicly available information on their alignment with compulsory open standards for software interoperability, data and document formats. Implementation plans for transition to the open standards or open standard profiles, within a specific timeline, must be published.

All agreed exemptions to the open standards policy must be published, detailing the standards specified and the reasons for exemption, unless there are national security considerations which prevent this.

Other than for reasons of national security, essential government extensions or variations to open standards for software interoperability, data or document formats must themselves be made available under an open licence and be publicly shared to enable others to build upon them.

Exit management strategies developed as part of exceptional extensions to IT contracts or legacy solutions, or in preparation for a technical refresh project, must be published, describing the existing standards used and the transition to open standards and compulsory open standards, unless these are classified for security reasons.

The tender process for IT contracts must be transparent and must follow the appropriate CCS process, including publication on Contracts Finder. Complaints relating to the specification of standards during the procurement and tender process should be made through existing channels such as the Cabinet Office Mystery Shopper Scheme.

Sources of further information

Follow us on Twitter @gdsteam and @cabinetofficeUK.

Requirement levels

In line with RFC 2119, the key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as follows:

  1. MUST - This word, or the terms “REQUIRED” or “SHALL”, mean that the definition is an absolute requirement.
  2. MUST NOT - This phrase, or the phrase “SHALL NOT”, mean that the definition is an absolute prohibition.
  3. SHOULD - This word, or the adjective “RECOMMENDED”, mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
  4. SHOULD NOT - This phrase, or the phrase “NOT RECOMMENDED” mean that there may exist valid reasons in particular circumstances when the particular behaviour is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behaviour described with this label.
  5. MAY - This word, or the adjective “OPTIONAL”, mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)

Open standard: definition

Open standards for software interoperability, data and document formats, which exhibit all of the following criteria, are considered consistent with this policy:

Collaboration - the standard is maintained through a collaborative decision-making process that is consensus based and independent of any individual supplier. Involvement in the development and maintenance of the standard is accessible to all interested parties.

Transparency - the decision-making process is transparent and a publicly accessible review by subject matter experts is part of the process.

Due process - the standard is adopted by a specification or standardisation organisation, or a forum or consortium with a feedback and ratification process to ensure quality.

Fair access - the standard is published, thoroughly documented and publicly available at zero or low cost. Zero cost is preferred but this should be considered on a case by case basis as part of the selection process. Cost should not be prohibitive or likely to cause a barrier to a level playing field.

Market support - other than in the context of creating innovative solutions, the standard is mature, supported by the market and demonstrates platform, application and vendor independence.

Rights - rights essential to implementation of the standard, and for interfacing with other implementations which have adopted that same standard, are licensed on a royalty free basis that is compatible with both open source (see a list of open source licences approved by the Open Source Initiative via their License Review Process) and proprietary licensed solutions. These rights should be irrevocable unless there is a breach of licence conditions.

Glossary

API - Application Programming Interface

Compulsory open standards - standards which must be specified by government bodies, subject to the principle of equivalence, unless an exemption is agreed under a comply or explain process.

Data format - a specification which defines how data is structured in a file.

Document format - a file format for storing and sharing documents.

Government bodies - in the context of this document, these are central government departments, their agencies, non-departmental public bodies (NDPBs) and any other bodies for which they are responsible. Interoperability - the ability of information technology systems, as well as the business processes they support, to exchange data and enable the sharing of information and knowledge.

Level playing field - an environment in government procurement in which every tender proposal is considered on its own merit and there are no advantages in the procurement process for incumbent suppliers, or for suppliers of a particular size.

Lock-in - a lack of interoperability and compatibility between existing and new systems or solutions, or from a lack of transferability of data and information between old and new systems which restricts choice of supplier, product or solution.

Open source software – software which guarantees the right to access and modify the source code, and to use, reuse and redistribute the software, with no royalty or other costs. In some cases, there can be an obligation to share code improvements with the wider community.

Open standard - many definitions of this term exist. For the purpose of software interoperability, data and document formats used by government bodies, the definition is provided in section 12

Profiles - profiles define subsets or combinations of standards that have a specific scope and deliver a defined function whilst conforming to the related standards.

Spend controls - a Cabinet Office process and measures for reviewing and authorising requests from government bodies to spend money on IT-enabled projects, within a specified threshold.

Standard – codified knowledge providing specifications for interfaces between software, systems or the documents and data that pass between them.