Technology / IP

Using Open Source Software

What is open source software?

If you are a software developer, you will know all about open source software (OSS).  OSS is software whose source code is publicly available to be used, adapted, modified and re-licensed, usually free of charge.  Because it is unusual for software developers to give away their source code, some people think OSS is released without being subject to licence terms.  In fact, most (although not all) OSS is licensed under one of a variety of public licences, the most commonly used of which is the General Public Licence (GPL) which exists in multiple versions.

Most software developers nowadays will make use of some OSS for the obvious reason that it avoids them having to re-invent the proverbial wheel. It is unlikely to cause you problems if you use OSS in internal products, although the question of OSS may arise if the company is acquired. Where, however, it is used in your proprietary software which is licensed to or hosted by third parties, the situation becomes more complex.

What are the risks in using open source software in proprietary software?

Most OSS is supplied under licence.  OSS licences range from very wide ‘permissive’ licences like the Berkeley licence (which has a requirement to reproduce the copyright notice, one clause of conditions and the specified disclaimer on any re-licence), to the GPL, which runs to around nine pages in its latest incarnation (version 3) and is a complex document which needs to be approached carefully.

The terms of an OSS licence may be wide but you essentially inherit a licence which will then apply to that OSS if used in products you supply to clients.  The terms of the OSS licence are almost certain to conflict with the terms of the overall licence to your software and if you are using OSS governed by different licences, those licences will probably conflict with each other too.  An OSS licence is likely to entitle your client or customer to ask for the OSS source code, to adapt it, modify it and re-license it.  In addition, if you have modified the OSS to create what you might view as your own code, the licence terms of the original OSS are very likely to apply to the modified code.

Compliance issues for businesses using OSS typically fall into two main categories.  The first (relevant, for example, under the GPL) is making the source code itself, together with the relevant licence terms, available to downstream users and inserting the required copyright notices.    We see many companies which develop their own code but use OSS for specific tasks, fall down on these basic steps.  This tends to act as a red flag to investors and buyers.  While there have been enforcement actions (see www.gpl-violations.org), OSS projects have generally been content to see the issue put right so the threat of legal action and the ensuing negative PR is not always the main concern and this sort of risk is often curable in practice. Potential investors and buyers are, however, likely to see failure to get the house in order on OSS as an indication that the business does not take intellectual property rights seriously.  

The most serious risk associated with OSS is that it ‘infects’ your own proprietary code (assuming you have any – this is not a concern for a ‘pure’ OSS business). If this happens, your own code will, effectively, become open source, governed by the terms of the relevant licence. In the worst case scenario, anyone to whom the software is distributed will be entitled to ask for its source code and adapt, modify or re-license it as they see fit.

This is a grey area with online discussion creating more heat than light. Infection may occur if proprietary code interfaces with or links to OSS but it can be difficult to determine whether or not code has been infected and it will also depend on which open source licence governs the OSS. Unfortunately, many of the open source licences are poorly drafted which makes knowing when they apply complicated. Good practice has emerged around how you implement the interoperation of OSS and proprietary elements to manage the infection risk. Experienced developers who have been through this before are a blessing and external legal advice from tech specialists will also help.

Having said this, if you have developed your own source code, while it is likely to contain some OSS, it is unlikely that your entire product will become infected and in most cases, the risk of a client being able to ask for the entire source code to your software, is low. We think the scare stories in this area have been overblown. Buyers and investors tend, however, to be less than sanguine on the issue of OSS so you cannot afford to ignore it. They may very well ask you to identify all OSS and licences used in your proprietary software. If you are unable to do this (and in some cases, even if you are) they will ask for a set of indemnities and warranties in relation to any OSS contained in what they are buying or investing in. We have also seen buyers use fears of infection (whether real or opportunistic) to lower company valuations.

How do we mitigate risks?

OSS is a fact of life in the software development world so the thing to do is mitigate the risks of using it in any software you intend to be proprietary. Helpful precautions include:

1. not over-relying on OSS if you want your software to be proprietary;
2. ensuring your developers know about the risks of using OSS and take steps to ring-fence it technically if they use it;
3. if you are heavily dependent on OSS and you do not have an expert familiar with the licences and the main compliance issues, hiring one;
4. having a firm-wide policy for use of OSS and other third party products, and ensuring the CTO (or a small tech committee) pre-approves the use of any OSS component;
5. ensuring that customer/client licences carve out OSS expressly from the licence to your proprietary software; and
6. using an OSS management programme like Black Duck Protex to track your use of OSS and the licences which govern that use.

These relatively simple steps can save you a great deal of trouble when you get to the stage of looking for further investment or selling your company.

Data Protection

Any data which can be used to identify an individual is ‘personal data’. All businesses will process (use) personal data (for example in customer and supplier databases and employee records) and as such, may need to notify the Information Commission about their data processing activities as a data controller. In addition, legislation requires that all data controllers take precautions to treat personal data with care, including not collecting more than they need or say they are going to collect, being transparent about what they do with the data and keeping personal data secure.

Data protection has become an increasingly hot topic in recent years, particularly with so much personal data now being used on the internet. It may not be at the top of your list of priorities when setting up a business but you are legally obliged to comply with data protection law. Depending on the nature of your business, this can be extremely simple or quite complex so it is important to put the correct procedures in place right from the start. Failure to notify where required, or to keep a notification entry up to date is a criminal offence for which the Information Commissioner can prosecute offenders.

Data Protection in the UK

The UK Data Protection regime is predominantly determined by EU legislation, most notably the Data Protection Directive, which was incorporated into UK Law by the Data Protection Act 1998 (DPA).

The DPA applies to the "processing" of "Personal Data". Personal data is defined as any information which is capable of identifying an individual. This means that information may become Personal Data if it is combined or is supplied to persons with the ability to combine it with other information so that it can be used to identify an individual. So, for example, an IP address may apply to a household and not identify an individual but when combined with the email address of a registered user of a site it becomes Personal Data.

"Processing" is very widely defined and includes collecting, storing, reorganising, analysing and supplying data through to and including destruction of the data. Indeed, any activity which an organisation carries out involving Personal Data will almost certainly qualify as processing.

Data Controllers and Data Processors

Under the DPA, responsibility for the way in which data is processed falls primarily on the Data Controller. A Data Controller is any organisation or individual responsible for determining how and why personal data is processed. Data Controllers must register as such with the Information Commissioner, the Data Protection Authority in the UK (www.ico.gov.uk) (there are a few exemptions). Registration must provide details of what information will be collected, who will be able to access it and what it will be used for. Failure to register where required is a criminal offence.

Where a Data Controller appoints an agent to carry out the processing and that agent does nothing with the data on its own initiative and only deals with the information as instructed by the Data Controller, that agent will be a Data Processor rather than a Data Controller. The Data Processor has no direct obligations under the DPA but needs to be contractually obliged to comply with the instruction of the Data Controller. The Data Controller is liable for any breach under the DPA caused by its Data Processor. Data Controllers should, therefore, seek guarantees as to the security measures the Data Processor has in place, put written contracts in place with any Data Processor and be comfortable that any staff (including those of the Data Processor) involved in the processing are fully briefed on their obligations and that the Data Processor is living up to the security guarantees it has provided.

The Data Protection Principles

The core obligations of the Data Controller when processing personal data are set out in the Data Protection Principles found in Schedule 1 of the DPA and include the following:

Processing should be fair and lawful – further details of what constitutes "lawful" processing are contained in Schedule 2. This provides a limited list of circumstances in which it is acceptable to process Personal Data. The key ones are:

1. where the data subject consents to the processing of its data;
2. where use of the Personal Data is necessary to complete a contract (for example the use of credit card details to complete an online transaction); and
3. where there is a legal obligation to do so (for example checking identification before boarding an aeroplane).

In order to process personal data fairly, it is necessary to be transparent with the data subject about:

1. what information is being processed;
2. the purposes for which it will be processed;
3. the possible consequences of agreeing to or refusing the information being processed; and
4. who will be granted access to the information (for example whether this will be limited to the employees within the organisation carrying out the collection or whether they will share it with other third parties).

Limited to specified purposes – information should only be used for the processing for which it was collected and, where applicable, for purposes that the Data Subject has agreed to.

Adequate, relevant, not excessive, accurate and up-to-date - the Personal Data collected should be appropriate to the intended purpose. For example, requiring details of employment may be relevant and appropriate for a recruitment agent but not for an online shopping site. There is also an ongoing obligation to ensure that information is accurate and to act upon any reasonable request of the Data Subject that personal details should be changed.

Deleted when no longer needed – information should not be kept for an excessive amount of time. In practice this means that in the absence of a legal obligation to keep the data for a specific period of time (such as tax records) businesses should keep records under review and remove data that is no longer required.

Data Subject Access – Data Subjects have a right to request access to any information an organisation holds which relates to them. Once a written Data Subject Access request has been received, the Data Controller has 40 calendar days to respond.

Adequate security provisions – the Data Controller must take adequate steps to protect the security of the information. This may include technical measures such as firewalls and access restrictions; physical measures (such as ensuring that all files are locked away when not in use); organisational measures such as staff training (informing all staff that will deal with personal information to treat it with appropriate discretion); and having appropriate data protection policies.

As mentioned above, Data Controllers are responsible under this principle for ensuring that processing carried out on their behalf by a Data Processor is secure and clearly defined by the contract.

Transfers outside the EEA – the Data Controller has an obligation not to allow Personal Data it is processing to be transferred outside the European Economic Area (EEA) unless it has verified that the information will be dealt with under a regime that has safeguards in relation to data protection which are at least equivalent to those in place in the EEA.

Certain countries have been approved as having a data protection regime which is of an equivalent standard to the EU system (available via the Article 29 Working Party website). In other cases, it may be necessary to implement transfers of Personal Data to other countries outside the EEA, under a standard form transfer agreement based on EU approved model clauses so that the party receiving the data, undertakes to deal with the data as if operating under the requirements of EU data protection legislation.

The US Federal Trade Commission also runs an approved scheme called Safe Harbor which can be used to enable lawful transfer of Personal Data from the EU to the US. By registering with this scheme, a US organisation undertakes to implement the procedures that would be required of an organisation dealing with Personal Data in the EU. Safe Harbor also offers its own adjudication service to which a Data Subject can appeal if the US organisation has breached these terms.

Sanctions

The Information Commissioner (IC) is responsible for monitoring and enforcing compliance with Data Protection Legislation. Data Subjects can complain to the Information Commissioner’s Office (ICO) if they feel their Personal Data has been used in a non-compliant manner.

The IC’s powers include:

1. requiring businesses to sign up to undertakings that they will take steps to improve their data protection procedures;
2. issuing enforcement notices to stop practices which breach data protection law;
3. conducting mandatory audits of public bodies or ‘with consent’ audits of private organisations;
4. issuing monetary penalty notices (of up to £500,000) for serious breaches of data protection law; and
5. for the most serious or repeated breaches, prosecuting the offending organisation.

In practice, the ICO has sought to build co-operation with organisations rather than rely on its more heavy handed remedies; it prefers to require businesses to sign up to undertakings to change their behaviour rather than to issue enforcement notices. It has issued monetary penalties with the highest being around £325,000 out of a possible maximum of £500,000. Substantial monetary fines have only been issued for serious security breaches, such as the loss of patient information by NHS employees on an unsecured laptop.

The European Commission has proposed a complete overhaul of EU data protection rules. Proposals have been published in draft form and are currently expected to come into force in 2014, leading to implementation in 2016. The new rules are expected to give enhanced rights to individuals and place increased obligations on data controllers and data processors so it is important to stay up to date on data protection.

Cookies

Cookies are small text files placed on user devices by websites in order to improve customer experience and gather information about the customer. They are widely used by businesses with an online presence but they cannot be used without taking certain precautions.

Rules on the use of cookies recently changed. Whereas previously it was sufficient to inform users about the use of cookies and give them information on how to opt-out in the privacy policy on the website, the consent of the visitor to the website to the use of cookies is now needed. The only exception to this requirement is where the cookie is strictly necessary for a service requested by a user. The scope of this exception is limited but would typically apply where, for example, a person uses a shopping service and a cookie is necessary to enable the purchases to appear in the shopping basket.

The Information Commissioner has published guidance on how to comply with the new cookie rules which you can find on the ICO's website. 

There are different possible approaches to the challenge of obtaining consent depending on the type of cookies that are used, the purposes they are used for and how intrusive they are. In broad terms, analytic cookies will not be viewed as being as intrusive as, for example, cookies used for behavioural advertising purposes. Whatever their use though, it is also necessary to provide clear information and actively alert visitors to the fact that cookies are used when they arrive on your website.

While there are no hard and fast rules about how to go about this, you should have prominent information on the landing page of your website with a link to a privacy and cookies or a cookies policy.  The visitor should be prompted to react to this, for example, by ticking an 'accept' box or having to click on a pop-up box to make it disappear.  Remember that you only need to collect consent once although if your use of cookies changes, you will need to get fresh consent.

You should have a cookies section in the privacy policy or a separate cookies policy.  This should give general information about what cookies are and how they may be used together with information about how to change browser settings or otherwise control cookies.

The policy should also provide specific information about the cookies used on the website which would involve:

• identifying the cookie(s);
• explaining what each cookie does; and
• providing a link to an opt-out from that cookie where it is available.

It is also worth noting that EU Member States have had some discretion as to how to implement the cookie rules and not all of them have taken the same approach.

  Previous page

Sitemap

Regulatory

Privacy Policy

Terms of Use

© 2013 Taylor Wessing LLP