Risks and Consequences of Non-Compliance

Our group have been presented with the data set: Road Collision Casualties in Camden. This data is published by the London Borough of Camden which is licensed under the Open Government Licence. All data on road collisions are provided by TfL (Transport for London), who present the data in three parts on an annual basis. The data set contains information on the casualties where some information has also been added from attendants. The attendants and vehicles are recorded as separate data sets and are available on an open platform, as a result they can be joined together by the use of a reference column. If joined together the data will show accidents where multiple casualties, attendants and vehicles were present. In the reference there will be several records for the same incident. It is suggested that data analysis should be undertaken which uses three years of data in order to avoid any anomalies.

The statistics in the data set displays personal injuries which have taken place on public roads which were reported to the police. The police note down the information using a STATS19 form and this is how the data is recorded.

While it is not possible to predict every potential legal issue that the application may face, both during development stage and in use, utilising the Road Collision Casualties in Camden data set, the most common pitfalls can easily be avoided. Implementing a proactive legal compliance strategy, during the early part of the development process, will help to minimise the legal risk and strengthen the protection of application itself.

Introduction

Risks and consequences of non-compliance

Failure to design the software in accordance with the various legislative and industry constraints, may result in a product that will attract, in the worst case scenario, legal action and/or make the product difficult to sell. Also, it may be incompatible with other software or data formats. Research into the various standards, industry codes and relevant legal obligations will allow the design to progress with clarity regarding these requirements.

Standards, codes legislation

The particular items that are relevant to this project are as follows:

-The British Computer Society Code of Practice

-The Open Government Licence for Public Sector Information

Data Protection Act 1998

It is considered that this Act is not applicable for the data accessed by the software, as it contains no personal information. However, it is likely to be applicable to data being held regarding the users of the application in terms of their logging into the system and the history of their use of the data, so we have to be in compliance with Data Protection Act 1998(DPA). Because we will be storing and handling personal information, small errors and inaccuracies can lead to severe data protection breaches and give rise to serious consequences. Compliance with data protection legislation is not just a matter of good practice, it is a legal requirement and, as the penalties for nonfulfillment are extremely serious, especially nowadays in an environment of increasing focus upon data protection, it goes without saying that for this application that we are creating, we need to take great care to protect personal information.

The Data Protection Act 1998 is enforced by the Information Commissioner’s Office (ICO), which has considerable powers when it finds an organisation to be in breach of the data protection principles in the way data is handled. The Information Commissioner has historically shown he is ready and willing to take action, and in extreme circumstances, to bring criminal proceedings with respect to mishandling of personal information. The consequences and penalties which may follow breach of data protection obligations are varied, and in most cases very serious. The ICO’s action can include:

• Monetary penalty notices; (For serious breaches of the DPA the fines could reach up to £500,000).
• Criminal Prosecutions; (Deliberately breaching the DPA can lead to possible prison sentences).
• Undertakings; (Organisations have to commit to a particular course of action to improve their compliance and avoid further action from the ICO).
• Enforcement notices; ( Organisations in breach of one or more of the DPA principles are required to take specific steps in order to comply with the law).
• Audit; (The ICO has the authority to audit government departments without consent to check organisations are complying).

Disability Discrimination Act 1995

This would apply in terms of the presentation of the user interface with reference to, for example, colour contrast and legibility.

Add compliance with the DDA to the project requirements.

Analyse the range of user types and identify any persons likely to fall under the DDA that would use the system. Look at the human interfaces that the system will employ and ensure that all projected users can utilise the application.

Demonstrate that the application has been designed to meet these needs in terms of, for example, character/font/ size/colour/contrast or in terms of any audible or spoken interfaces.

Display Screen Regulations 1992

The user interface should not compromise an employer’s ability to comply with this legislation. For example, repetitive strain injuries or eye strain. There is also a Human Factors consideration here in terms of optimising user performance by maintaining concentration, thereby reducing errors. This is unlikely to have a direct impact on the designer/supplier of the software but may have a reputational impact if the product is problematic in the workplace.

Intellectual property

Before we started our project it was essential for us as a group to have a firm grasp of intellectual property rights and how they apply to the software industry, as protecting our software application would make it easier to take legal action against anyone who steals or copies it. Computer software law is distinguished from most other intellectual creations protected by intellectual property law in that different aspects of the software is eligible for protection by patent, copyright and trade secret laws. Each type of protection has advantages and disadvantages under the current laws.

Historically it’s been quite hard to get software application approved for patent from UK Intellectual Property Office. This means that UK software developers have been left to rely on copyright to protect their work. This was something we had to take into consideration because copyright only offers protection against being copied. However, the Patents are an absolute right against unauthorised use of the patent holder’s invention, and can protect the underlying/original ideas and processes of our application. So with a patent, it does not matter whether a competitor has copied the program or developed an identical program – or indeed a different program which uses the same ideas or process steps – on their own, it still breaches the patent and us as patent holders can claim damages and/or an injunction to enforce their rights.

In the case of our application, copyright law would protect the source and object code, as well as certain unique original elements of the user interface. While the patent can protect the novel ideas embodied in our application which copyright cannot. However, as I already mentioned, historically it’s been shown it is quite tough to get software application approved for patent and there is no guarantee that the UK Intellectual Property Office will grant a patent for our software invention. Moreover, the costs for obtaining a software patent are significantly higher, so we as a company have to weigh our options and go with the best possible.

Furthermore, the terms of use for the application itself are provided by us who designed the application, but also it should be noted that the data being accessed by the application is also subject to conditions of use by the data owner. This data is published by the London Borough of Camden which is licensed under the Open Government Licence v3.0. These conditions should also be provided to the end user and embodied in supplier’s terms of use. The Licensor grants us a worldwide, royalty-free, perpetual, non-exclusive licence to use the Information subject to the conditions like:

“acknowledge the source of the Information in your product or application by including or linking to any attribution statement specified by the Information Provider(s) and, where possible, provide a link to this licence”

This means we are obligated by the Open Government Licence to provide a link for our end user or let the end user know that applications contains public sector information licensed under the Open Government Licence. This is one of the most important conditions of this licence and if our company fails to comply with them the rights granted to us under this licence, or any similar licence granted by the Licensor, will end automatically.

It is also important to note that this is version 3.0 of the Open Government Licence. The Controller of this licence may change the licence itself from time to time and issue new versions of it. And if that happens the terms of that licence will continue to apply from the previous version (current version which is 3.0).

Software licensing

A software license is a document that provides legally required guidelines for the usage and sharing of software. A software licensing agreement will protect our copyright and IP rights by placing restrictions on the end user in relation to how the software can be used.  The software licence will allow the end users to have one or more copies of our software, without violating copyrights.

When we publish our end product it is critical that we licence our software very carefully to retain the IP rights and to ensure we are able to generate revenue from our work. A software licence usually comes in one of three major forms:

• Proprietary licence
• Free licence
• Open software licence

User requirements

Consultation with the user of the software and the client, for whom the work is being undertaken, will enable a full and clear understanding of their expectations to be captured in the form of a User Requirements Specification. In particular, the types of users, how the data will be accessed and used should be sought from client and fully understood. This, combined with any legislative, industry or standards requirements, will form the overall Project Requirements Specification.

Specification/requirements

Taking all of the above a definitive set of Project and Technical requirements can be developed. These will enable the project to proceed from a clear and common understanding. All Stakeholders should sign the requirements and any subsequent changes should be avoided, but if necessary, undertaken in a controlled process. This is important in controlling cost, programme and avoiding differing expectations.

Verification

It is important to continually check back against the requirements as the design develops. This can be done in the form of a requirements matrix and recording evidence (links to docs/specs) that each requirement is being met.