E-privacy

E-Privacy – PECR and Brexit

E-Privacy regulations complement data protection laws by setting out privacy rights for electronic communications. The idea being that whilst widespread public access to digital mobile networks and the internet has opened up new possibilities for businesses and users, they have also created new risks for privacy. E-Privacy regulations have been a point of contention within the EU and reform has been expected for some time. On 10 February 2021, 4 years after the European Commission’s initial legislative proposal and to the surprise of many, the European Council reached a compromise agreement on their position on the E-privacy Regulation. What this means for E-privacy rules in the UK remains to be seen. With Brexit behind us, and therefore no obligation to introduce new EU legislation in the UK, but with an adequacy decision pending, and therefore a desire for the UK to align with the EU on data protection, it is hard to say whether or not the UK will choose to implement them. For more information on data protection and a potential adequacy decision after Brexit read our blog.

E-Privacy and PECR

PECR are the Privacy and Electronic Communications Regulations which comprise the E-privacy regulations in the UK. Their full title is The Privacy and Electronic Communications (EC Directive) Regulations 2003. They are derived from European law. PECR have been amended a number of times. The more recent changes were made in 2018, to ban cold-calling of claims management services and to introduce director liability for serious breaches of the marketing rules; and in 2019 to ban cold-calling of pensions schemes in certain circumstances and to incorporate the GDPR definition of consent.

What kind of areas do PECR cover?

PECR cover several areas:

  • Marketing by electronic means, including marketing calls, texts, emails and faxes.
  • The use of cookies or similar technologies that track information about people accessing a website or other electronic service.
  • Security of public electronic communications services.
  • Privacy of customers using communications networks or services as regards traffic and location data, itemised billing, line identification services (eg caller ID and call return), and directory listings.

How does this fit with the UK GDPR?

The UK GDPR sits alongside PECR. PECR rules apply and use the UK GDPR standard of consent (which is a high threshold). This means that if you send electronic marketing or use cookies or similar technologies you must comply with both PECR and the UK GDPR. Unsurprisingly, there is some overlap, given that both aim to protect people’s privacy. Complying with PECR will help you comply with the UK GDPR, and vice versa – but there are some differences. In particular, it’s important to realise that PECR apply even if you are not processing personal data. For example, many of the rules protect companies as well as individuals, and the marketing rules apply even if you cannot identify the person you are contacting.

If you are a network or service provider, Article 95 of the UK GDPR says the UK GDPR does not apply where there are already specific PECR rules. This is to avoid duplication, and means that if you are a network or service provider, you only need to comply with PECR rules (and not the UK GDPR) on:

  • security and security breaches;
  • traffic data;
  • location data;
  • itemised billing; and
  • line identification services.

Electronic and telephone marketing

PECR restrict unsolicited marketing by phone, fax, email, text, or other electronic message. There are different rules for different types of communication. The rules are generally stricter for marketing to individuals than for marketing to companies. Companies will often need specific consent to send unsolicited direct marketing. The best way to obtain valid consent is to ask customers to tick opt-in boxes confirming they are happy to receive marketing calls, texts or emails from you.

E-Privacy: Cookies and similar technologies

Companies must tell people if they set cookies, and clearly explain what the cookies do and why. You must also get the user’s consent. Consent must be actively and clearly given. There is an exception for cookies that are essential to provide an online service at someone’s request (e.g. to remember what’s in their online basket, or to ensure security in online banking). The same rules also apply if you use any other type of technology to store or gain access to information on someone’s device.

Communications networks and services

PECR are not just concerned with marketing by electronic means. They also contain provisions that concern the security of public electronic communications services and the privacy of customers using communications networks or services. Some of these provisions only apply to service providers (e.g. the security provisions) but others apply more widely. For example, the directories provision applies to any organisation wanting to compile a telephone, fax or email directory.

EU Council position on E-Privacy rules

On 10 February 2021, EU member states agreed on a negotiating mandate for revised rules on the protection of privacy and confidentiality in the use of electronic communications services. These updated E-privacy rules will define cases in which service providers are allowed to process electronic communications data or have access to data stored on end-users’ devices. The agreement allows the Portuguese presidency to start talks with the European Parliament on the final text. The agreement included:

  • The regulation will cover electronic communications content transmitted using publicly available services and networks, and metadata related to the communication. Metadata includes, for example, information on location and the time and recipient of communication. It is considered potentially as sensitive as the content itself.
  • As a main rule, electronic communications data will be confidential. Any interference, including listening to, monitoring and processing of data by anyone other than the end-user will be prohibited, except when permitted by the E-privacy regulation.
  • Permitted processing of electronic communications data without the consent of the user includes, for example, ensuring the integrity of communications services, checking for the presence of malware or viruses, or cases where the service provider is bound by EU or member states’ law for the prosecution of criminal offences or prevention of threats to public security.
  • Metadata may be processed for instance for billing, or for detecting or stopping fraudulent use. With the user’s consent, service providers could, for example, use metadata to display traffic movements to help public authorities and transport operators to develop new infrastructure where it is most needed. Metadata may also be processed to protect users’ vital interests, including for monitoring epidemics and their spread or in humanitarian emergencies, in particular natural and man-made disasters.
  • In certain cases, providers of electronic communications networks and services may process metadata for a purpose other than that for which it was collected, even when this is not based on the user’s consent or certain provisions on legislative measures under EU or member state law. This  processing for another purpose must be compatible with the initial purpose, and strong specific safeguards apply to it.
  • As the user’s terminal equipment, including both hardware and software, may store highly personal information, such as photos and contact lists, the use of processing and storage capabilities and the collection of information from the device will only be allowed with the user’s consent or for other specific transparent purposes laid down in the regulation.
  • The end-user should have a genuine choice on whether to accept cookies or similar identifiers. Making access to a website dependent on consent to the use of cookies for additional purposes as an alternative to a paywall will be allowed if the user is able to choose between that offer and an equivalent offer by the same provider that does not involve consenting to cookies.
  • To avoid cookie consent fatigue, an end-user will be able to give consent to the use of certain types of cookies by whitelisting one or several providers in their browser settings. Software providers will be encouraged to make it easy for users to set up and amend whitelists on their browsers and withdraw consent at any moment.

Brexit

PECR continues to apply after the UK's exit from the EU on 31 January 2020. The draft ePR, described in detail above, which is still in the process of being agreed, was not finalised before 31 January 2020 and will therefore not become directly applicable in the UK. Once it is directly applicable to EU member states (which is likely 24 months after its coming into force), the UK will then need to consider to what extent to mirror the new rules. In any case, given that UK companies will continue to process data of EU end users, it will still be necessary to be aware of any discrepancies created by E-privacy reform in the EU.

The deadlock is over

It has long been considered that EU E-privacy regulations have lagged behind the technological progress seen in online marketing techniques and EU negotiations around reform have at times seemed never-ending. The agreement reached by the EU council will therefore be seen as a necessary improvement in legal certainty, although plenty of questions still abound.

PECR in its pre-reformed state will continue to apply in the UK. On 19th February 2021, the European Commission issued its draft adequacy decision that would allow EU-to-UK data transfers. While the E-privacy Regulation is not strictly relevant to the UK’s continued adequacy status, alignment on E-privacy rules would likely be viewed positively by the EU institutions, which could prompt the UK to update its laws in line with the new EU regime. The reforms will of course also be relevant to any UK business that operates in the EU. Even if the Regulation is finally adopted this year, it will not apply for a further two years meaning, these changes will likely not come into effect until 2023 at the earliest.

If you have any questions on E-privacy and data protection, data protection law more generally or on any of the issues raised in this article please get in touch with one of our data protection lawyers.


Space Law

Space Law: The Commercial Space Race Begins

Space law is the body of law governing space-related activities, encompassing both international and domestic agreements, rules, and principles. Parameters of space law include space exploration, liability for damage, weapons use, rescue efforts, environmental preservation, information sharing, new technologies and ethics. SpaceX, in May 2020, became the first private company to send humans to space. What this implies is hard to say. A recent article in the Harvard Business Review sees the sky, or should I say heavens, as the limit. With a healthy interplay between public and private investment, international co-operation and a rule of law suited to this harsh environment, it suggested that NASA’s prediction, in their 1977 report ‘Long-Term Prospects For Developments In Space’, that extra-terrestrial economies could one day out-strip terrestrial ones, was not so far-fetched. The Artemis Accords, signed in 2020 by the directors of 10 national space agencies, also indicates a shift in space law that better accommodate commerce.

Space-for-space economy

An important distinction made in the Harvard Business Review article was between a space-for-earth economy and a space-for-space one. The space-for-earth economy uses space to deliver benefits to those on earth. The use of satellites for telecommunications, internet infrastructure, or earth observation capabilities and national security. The real shift will be when companies are able to offer services in space for use in space – the space-for-space economy. However, creating such a market will require the existence of consumers beyond the stratosphere. Which may not exist for some time. In the meantime private companies will have to rely on public contracts. Hopefully, being able to supply to government space agencies will enable and invigorate supply to future commercial markets. Here are some examples of work being done:

  • SpaceX hopes to support transportation for large numbers of private space travellers. Currently their space-for-space transport solutions have been for government bodies (NASA) only. But with future decreases in the cost of launching spacecraft, SpaceX could be instrumental in putting people into space and creating the demand necessary for a space-for-space economy to develop.
  • Made In Space, Inc. is currently exploring high-quality fibre-optic cable, manufactured in zero-gravity for sale on earth. The company also recently received a $74 million contractto 3D-print large metal beams in space for use on NASA spacecraft. Such construction capabilities will be essential in a developing space-for-space economy.
  • In February 2020, Maxar Technologies was awarded a $142 million contractfrom NASA to develop a robotic construction tool that would be assembled in space for use on low-Earth orbit spacecraft. Such tools will be just as useful for a future private sector.
  • In 2015 Argotec and Lavazza collaborated to build an espresso machine that could function in the zero-gravity environment of the International Space Station. Such luxuries will be crucial for the development of an economy in space, even if for the moment they are mostly publicity stunts.
  • In 2010, Planetary Resources, Inc.and Deep Space Industries, were set up with space mining as their objection (lunar mining). Both failed because the lack of a space-for-space economy made the cost of extracting minerals to be brought back and sold on earth too high to be viable. The natural resources known to exist on the moon will, if a space-for-space economy develops, become big business.

Space law

In what legal system is this commercial activity taking place? Space law is by its nature extra-terrestrial and extra-territorial. Accordingly, its usage is governed by an extensive international legal framework, under the aegis of the United Nations (UN), made up of treaties, agreements and conventions governed by international law, which may be implemented into national law. The Artemis Accords have reinforced many of these frameworks and laid the groundwork for more commercially orientated space law.

The Artemis Accords

The Artemis Accords are named after the NASA project which aims to send the first woman and another man to space by 2024. They are an international agreement for cooperation in the civil exploration and use of the Moon, Mars, comets, and asteroids for peaceful purposes, and are grounded in what is often considered the foundation of space law, the Outer Space Treaty of 1967. The stated purpose of the Artemis Accords is to "provide for operational implementation of important obligations contained in the Outer Space Treaty and other instruments." The provisions:

  • Affirm that cooperative activities under these Accords should be exclusively for peaceful purposes and in accordance with relevant international space law.
  • Confirm a commitment to transparency and to share scientific information, consistent with Article XI of the Outer Space Treaty.
  • Call for a commitment to use reasonable efforts to utilize current interoperability standards for space-based infrastructure, and to establish standards when they do not exist or are inadequate.
  • Call for a commitment to take all reasonable efforts to render necessary assistance to personnel in outer space who are in distress.
  • Specify responsibility for the registration of objects in space.
  • Call for a commitment to publicly share information on their activities and to the open sharing of scientific data.
  • Include an agreement to preserve outer space heritage, which they consider to comprise historically significant human or robotic landing sites, artifacts, spacecraft, and other evidence of activity, and to contribute to multinational efforts to develop practices and rules to do so.
  • Include an agreement that extraction and utilization of space resources should be conducted in a manner that complies with the Outer Space Treaty and in support of safe and sustainable activities. The signatories affirm that this does not inherently constitute national appropriation, which is prohibited by the Outer Space Treaty. They also express an intent to contribute to multilateral efforts to further develop international practices and rules on this subject.
  • The Accords provide for the announcement of "safety zones", where operations of other nations or an anomalous event could reasonably cause harmful interference.
  • Include a commitment to mitigate space debris and to limit the generation of new, harmful space debris in the normal operations, break-up in operational or post-mission phases, and accidents.

National framework – UK

The UK has some of its own space law. The UK Outer Space Act 1986 sets out the UK's obligations under the various international treaties and principles covering the use of outer space. This Act also covers entities in certain of the UK's overseas territories and the Channel Islands, as well as the Isle of Man, and requires all those seeking to launch or procure the launch of a space object, operate a space object or undertake any activity in outer space, to obtain a licence. Licensing and other powers are conferred on the Secretary of State for the Department of Business, Energy and Industrial Strategy (BEIS), who carries out these powers through the UK Space Agency (UKSA). The UKSA was launched in April 2010, bringing all UK civil space activities under one single management. The UKSA began operation as a full executive agency on 1 April 2011.

The Space Industry Act 2018 is space law intended to make provision for space activities including vertical launches and suborbital activities in the UK. The UK government intends that licences under it, including for launch and sub-orbital activities, will be granted by 2021. Secondary legislation will be enacted to cover specific aspects of the Act, including licensing and insurance requirements.

Liability

The status and liability of commercial use of outer space, including the moon and other celestial bodies, is not very clear under the existing space law regimes. According to Article VI of the Outer Space Treaty 1967 and Articles II and III of Liability Convention 1972, the country in which the launch of the spacecraft takes place is liable for any activities in outer space. Even in the case of non-governmental activities, the launching state is liable. The possible litigation relating to the commercial activities are mainly the financial consequence of damage caused and also the technical complications that private entities face in case of supply of defaulted parts to national space agencies.

Legal status of resource exploitation

No nation claims ownership of any part of the Moon's surface, and the international legal status of mining space resources is unclear and controversial.

Russia, China, and the United States are party to the 1967 Outer Space Treaty (OST), which is the most widely adopted treaty, with 104 parties. The OST treaty offers imprecise guidelines to newer space activities such as lunar and asteroid mining, and it therefore remains under contention whether the extraction of resources falls within the prohibitive language of appropriation in the treaty. Although its applicability on exploiting natural resources remains in contention, leading experts generally agree with the position issued in 2015 by the International Institute of Space Law (ISSL) stating that, “in view of the absence of a clear prohibition of the taking of resources in the Outer Space Treaty, one can conclude that the use of space resources is permitted”.

Seeking clearer regulatory guidelines, private companies in the US prompted the US government, and legalized space mining in 2015 by introducing the US Commercial Space Launch Competitiveness Act of 2015. Similar national legislations legalizing extra-terrestrial appropriation of resources are now being replicated by other nations, including Luxembourg, Japan, China, India and Russia. This has created an international legal controversy on mining rights for profit. James R. Wilson, a legal expert stated in 2011 that the international issues "would probably be settled during the normal course of space exploration." In April 2020, U.S. President Donald Trump signed an executive order to support moon mining.

The final frontier

With the huge commercial potential that space offers comes the huge mobilisation required for its realisation. More than a little bit of luck will be needed to see dreams realised in the near future. Three things are certain: the private sphere will need invigoration by both government contracts/investment and their willingness to deregulate, such as allowing private space travellers to take on more safety risks than government funded ones; a vigorous upholding of the rule of law will create a bedrock for competitiveness; and a transcendence of geopolitical divides will ensure safe and unimpeded economic development.

Whilst the Artemis Accords have introduced some co-operation between nations on the question of how to regulate activity in space, it lacked two signatories: China and Russia; and failed to clarify whether, under space law, resource extraction could constitute national appropriation of areas in space.

EM law specialises in technology law. Get in touch if you have any questions on the above.


Robot Manufacturing

Robot Manufacturing: Product Liability Law

Robot manufacturing is a growth industry as the costs of producing robots are going down while the savings in labour costs are rising. With the rise and rise of automation in all areas of life, the word robot has come to mean a wider variety of things. Artificial intelligence (read our blog on some legal issues) has received the most amount of attention recently especially given its crossover with big data (read our blog). But what about the more conventional notion of a robot – the walking, talking lump of steel, more willing to do jobs we’re not so keen on. The sort that product liability law applies to more obviously. This blog covers some issues that a robot manufacturer may encounter when putting such a product on the market.

Robot Manufacturing - product liability and safety risk management

Product liability lies in the accountability faced by a manufacturer of a sub-standard, defective or dangerous product. Such accountability applies to the members of the public who purchase such a product and those below a manufacturer in the supply chain. Contractual protections, insurance and effective risk management can be used to protect a manufacturer from such liability.

Can liability for a dangerous or defective product be excluded or limited?

Contractual protections create a variety of scenarios. Whilst a manufacturer may wish to limit its own liability to parties beneath it in the supply chain, they may well wish to enhance the liabilities of a manufacturer above it. The terms of a contract are the vehicle by which this can be achieved. Additionally a robot manufacturer will want to be certain that quality and safety standards are judiciously applied to every level of its supply chain, especially key suppliers. Given the potential technological complexity of such an industry, it may even be useful to seek the advice of specialist consultants who have the know-how to ensure all the liability that should be attributed to suppliers is and that a comprehensive set of standards is agreed to in the contract.

There are various ways that robot manufacturing companies can do this. Limiting and excluding liabilities within their contracts can be one way – but this is only possible for certain things. There are restrictions on limiting liability for dangerous or defective products. Restrictions that overrule contractual clauses. Robot manufacturers should therefore look to other means, i.e. non-contractual, to control their risk.

Different considerations need to be taken into account when dealing with the various parties within the supply chain. For example, manufacturers, distributors, importers and retailers will all have concerns specific to the role that they undertake.

Is there an effective quality and safety assurance programme in place?

Effective quality assurance is at the heart of non-contractual risk aversion for product manufacturers. This is particularly important in the robot manufacturing industry given that the products usually involve a lot of automation and therefore the blame for something going wrong is more likely to fall on the manufacturers’ shoulders, rather than the customers. Setting up an internal committee to oversee product safety is useful first step. The team should incorporate members from all over the business to ensure nothing is missed. The committee's function should be: to review products and their associated documents; ensure that all appropriate regulatory and internal procedures have been followed and documented before and after marketing; authorise any necessary action (for example, changing warnings or design); review after-sales monitoring reports for trends and significant incidents; review insurance arrangements.

Additionally, keeping good records of exactly what was supplied when and by whom can simplify such a committee’s job.

Is there an effective enquiries and complaints system in place?

A robot manufacturing company must be able to respond to any complaints or enquiries with regard to a product’s safety. This is a legal requirement as well as being based on a desire to look out for your customers and improve your product. Things to think about: does the company have a system to handle customer enquiries and complaints? If so, could it be improved? Are staff adequately trained? Does the company have a policy of recovering allegedly unsafe items and investigating and recording the items and circumstances? Is there a systematic review of adverse incident information involving multi-disciplinary input from different departments? Can the company identify repeat claimants who may not be genuine?

The Services Directive (2006/123/EC), before Brexit, created an obligation to inform customers of how to make complaints and how manufacturers should deal with such complaints. The Services Directive is implemented in the UK by the Provision of Services Regulations 2009 (SI 2009/2999) (PSRs). The PSRs apply to most product manufacturers in the UK and introduce obligations around how to respond to enquiries or complaints about their products.

After Brexit, the Provision of Services (Amendment etc.) (EU Exit) Regulations (SI 2018/1329) implemented this EU law into UK law. All of the obligations around how to deal with enquiries or complaints essentially remain the same. Although some changes were made to EEA-specific provisions. This included the revocation of a requirement not to discriminate against customers based on their place of residence. This means that manufacturers in the UK could treat customers in the EEA differently to customers in the UK now that we have left the EU. The practical implications of this change are yet to be seen.

Robot Manufacturing - Data protection and privacy

The use of robots (drones being a good example) fitted with cameras or other sensors which can collect personal data such as images of people or vehicle plate numbers, geolocation data or electromagnetic signals relating to an individual's device (for example, mobile phones, tablets, Wi-Fi routers, and so on) can have privacy implications.

At EU level, there is no data protection legislation specific to the use of robots/drones; the applicable legal framework is contained in the General Data Protection Regulation (EU) 2016/679 (GDPR). In the UK, the processing of personal data via robot/drones is subject to the GDPR and the Data Protection Act 2018 (DPA) and the legal provisions applicable to CCTV systems. After Brexit, the GDPR will be retained in UK law and amended to become the UK GDPR. For more information on data protection after Brexit read our blog.

The GDPR and the DPA set out the conditions under which personal data can be processed and provide for certain exemptions and derogations, the most relevant being:

  • Household exemption: This applies to the processing of personal data in the course of a purely personal or household activity. This exemption could potentially apply to individuals using robots/drones for their own purposes. However, the ECJ has narrowly interpreted this exemption in the context of the use of CCTV camera. As a result, its application will depend on the specific circumstances of each case. The Information Commissioner's Office (ICO), the UK data protection regulator in charge of enforcing GDPR and DPA requirements, has issued guidance in relation to the use of drones. The ICO makes a distinction between the use of drones by "hobbyists" and their use for professional or commercial purposes. Although "hobbyists" would be likely to be exempted from the GDPR and the DPA on the basis of the household exemption, the ICO has provided tips for the responsible use of drones, inviting people to think of privacy considerations and to apply a common sense approach when recording and sharing images captured by a drone.
  • Journalistic exemption: In cases where personal data is collected through drones with a view to the publication of some journalistic, academic, artistic or literary material. In this case, processing would, under certain conditions, be exempt from many data protection obligations to the extent that such obligations would be incompatible with the purposes of journalism, academic, literary or artistic purposes which are sought by the processing.

Here to help

Robot manufacturing companies come up against many of the same legal issues as other product manufacturing companies. Having risk assessment procedures in place, as well as mechanisms to deal with potential faults, should reduce liability. However, robots are likely to be able to collect data and so data protection law also becomes important.

EM law specialises in technology and contract law. Get in touch if you need advice on Robot Manufacturing or have any questions on the above.


Selling A Software Business

Selling a Software Business - Things to Consider

Software comes in all shapes and sizes, serving a diversity of customers broadened by the internet and strengthened by the onset of generations for whom its application is second nature. Whilst selling a software business will meet unique challenges, there are a number of common threads when considering the legal side. This blog covers a range of topics that, if the seller takes on board, could ensure a buyer’s trust and cooperation when negotiating an agreement.

Selling a Software Business - Intellectual Property Rights

A likely first thing on the mind of a buyer will be to secure all intellectual property rights in the target software. This will mean obtaining an assignment or confirmatory assignment from the owners of such rights. The owners could be employees or consultants. Difficulties arise when dealing with previous employees or consultants who take such rights with them after leaving the developers or business which originally created such software. A seller should therefore do all it can to review intellectual property rights when creating a software it may one day wish to sell. If all else fails, indemnities may be the only way to ensure a buyer is comfortable with the purchase.

Software often uses licenced-in intellectual property rights from third parties. Having a strong understanding of exactly what these are and whether it is possible to grant sub-licences under them should be considered. This will mean reviewing the software’s process of production to ensure that no such rights are missed.

Open source software (OSS) is software code that is usually made available to developers for free and can be licenced in a variety of ways. It would be a incorrect to assume that OSS is licenced in an unrestricted manner at all times, even though in recent years it has generally become less restrictive. BlackDuck is a tool which offers companies the opportunity to search the source code of products for any OSS. Any unclear licences can then be satisfied and again it is likely that a buyer will want indemnities or warranties to ensure that all the OSS has been dealt with. At the very least OSS usually requires an acknowledgement of the original author.

Selling a Software Business - Existing Customers

When selling a software business, a buyer is going to want to assess the revenues of your business, the reliability of such revenue and risks involved with providing services to each customer. Issues likely to arise in customer contracts include:

  • Limits and exclusions of liability.
  • Post-contract services such as maintenance and support obligations.
  • Termination rights - whether through an explicit change of control clause or termination periods, or by unclear drafting in the contract. Much can rest upon whether or not a buyer can rely upon long-term customers to continue to use the software after purchase.
  • Non-compete, exclusivity and similar restrictions. As well as affecting the software’s freedom to operate under such restrictions, they may give rise to competition law issues.

Selling a Software Business - Employee retention

Employees can in some cases be as valuable as the software itself, especially if the buyer is looking to develop the software. Employees often have a breadth of knowledge and experience with a piece of software that is difficult to put onto paper. If key employees are lost then as much information as possible should be put down in the software documentation. Employee retention or at least a point of contact with former employees of a software business may well be the pre-requisite of such an acquisition.

Selling a Software Business - Technology Infrastructure

The issue of technological infrastructure is changing. Before the existence of such readily available online platforms with which companies can access and build their own software, technological infrastructure was, for the most part, hardware. This meant that infrastructure was often difficult to integrate into a buyer’s system.

A seller needs to consider whether the technological infrastructure is shared with anyone (say a subsidiary or other company in the seller’s group), whether they plan to integrate the software into the buyer’s technological infrastructure and whether the software is in any way being provided by a third party:

  • Infrastructure shared with other members of the seller’s group – a number of solutions exist to this issue, the most common being licensing or transitional services arrangement within the group that is often limited in time and to particular services.
  • Integration in to buyer’s infrastructure – as well as technical issues of integration and compatibility, if the infrastructure is duplicated, the target should undertake an assessment of whether these duplications can be eliminated and if the seller can terminate relevant supplier contracts.
  • Third parties – it used to be the case that companies using software would share a server with other companies and such hardware would have to be maintained to reach the requirements of each company. With the trend towards virtualisation of the computing environment, seller’s will often be beholden to a variety of third-party platforms to provide cloud space and hosting capabilities. Sellers should therefore review their position in relation to all such third parties to ensure they have the necessary rights to transfer ownership of any such agreements.

Selling a Software Business - Data protection

Data protection is an increasingly important issue for any software business. In assessing your business, and its IT systems, it is important to understand what personal data is handled, the protections and policies surrounding this, including any instances of breach of these policies, and the applicable laws such as the UK GDPR (for information on how Brexit has affected data protection law read our blog). It is attractive for a buyer to know that the seller takes data protection seriously and has built-in mechanisms to support it.

Developments in software supply have accounted for an increased risk in data protection. Subscription based services which often store customer data on the sellers platform (for instance, if it supplies software under a software as a service (SaaS) model) run into such issues as an obligation is created to secure and lawfully process the personal data being stored by the seller. Software often used to be sold anonymously, and without updates, external content, or other means to identify the user, and the seller was not storing personal data for its customers (because there were usually no logins or other data collections linked to a cloud-based platform). Data protection law is forever morphing in response to the rapidly developing technological landscape and so it could be wise to review your position at multiple points along the timeline of implementing the acquisition of a software business.

Cybersecurity

Cybersecurity is set to become an increasingly important issue for sellers in any software acquisition. On 10 May 2018, the Network and Information Systems Regulations 2018 (SI 2018/506) (NIS Regulations) came into force. They place minimum cybersecurity and incident notification obligations on relevant digital service providers. If the software qualifies as an in-scope digital service provider under the relevant legislation, then it will be important for the seller to understand:

  • What network and information systems it relies upon to provide its services.
  • What measures it takes to manage the risks posed to the security of those systems (including with a view to ensuring continuity of its digital services).
  • What means it has of monitoring and assessing any incidents that have a substantial impact on the provision of its digital service.
  • How it reports such incidents to the Information Commissioner's Office (ICO), the UK regulator in this area, and in what timescales.
  • Failure to abide by the minimum cybersecurity standards and incident notification requirements set out in the NIS Regulations, can attract substantial regulatory fines in the UK of up to £17 million. Relevant digital service providers are also under an obligation to ensure that they have adequate documentation available to enable the ICO to verify compliance with the relevant security obligations, meaning that in practice the ICO may request to see (and buyers will want to diligence) various policies including those relating to system security, incident handling, security monitoring, business continuity management, and compliance with international standards.

Here to help

Selling a software business comes with a range of challenges, whether or not it involves software. Software does, however, introduce some specific issues. The greatest change in recent times has been from software sold for on-premises installation, to software being available to sell via, in most instances, a SaaS platform. This means that, as a software business owner, you are more likely to rely upon third parties to deliver your services. Making sure that your relationship with these third parties is transferrable to a buyer is important. Equally significant is the likelihood of intellectual property rights being scrutinised by a potential buyer. Knowing that you own all aspects of the business you intend to sell will always be high on a buyer’s list of assurances. Software has a uniquely high chance of infringing IPR’s without being aware of it. For more information on this read our blogs Open Source Software and Legal Protection of Software.

EM law specialises in technology and corporate law. Get in touch if you need advice on selling a software business or have any questions on the above.


software as a service

Software as a Service (SaaS) - Some Key Aspects

Software as a Service (SaaS), instead of on-premises software licencing, continues to grow as a model. It is sometimes referred to as ‘on-demand software’, and was formerly referred to as “software plus services” by Microsoft. In a nutshell SaaS is a software licencing and delivery model in which software is licenced on a subscription basis and is centrally hosted by the provider. It exists on the cloud as opposed to being installed on the customer’s on-premises computing system. Read more about cloud computing in our blog.

Software as a Service is a growth area

SaaS has grown its share of the global enterprise software market from less than 2% in 2009 to 23% in 2019. By 2022, the global SaaS market is expected to be worth $140.63 billion. For customers, the service can offer greater access, convenience, and flexibility at a lower cost. And for vendors, it is easier, faster, and less expensive to roll out and sell to customers compared with traditional on-premises software development.

Common characteristics of SaaS arrangements

  • The service software is not installed or stored on the customer's computer systems. The SaaS provider (or its subcontractor) hosts core SaaS software applications. While the customer may receive limited client-side software to aid connectivity to the provider's network, the customer accesses the provider's software remotely on the internet or another public, private, or hybrid public and private cloud network.
  • The SaaS services and infrastructure are managed by or for the SaaS provider and shared by multiple customers. Each SaaS customer accesses the service applications remotely from various client devices, but does not configure, manage, or control the underlying cloud infrastructure.
  • Service customization is limited. The software configuration is largely or entirely uniform throughout the provider's customer base.
  • The supplier maintains the service software and provides service support subject to service levels. SaaS agreement maintenance and support provisions typically specify service levels and standards for the provision of support. Service levels define how well the provider needs to perform and are often accompanied by service credits if the provider fails to maintain certain service level standards.
  • Service fees accrue and are payable on a recurring, periodic basis. Fees may be based on provider subscription rates, the volume of customer use, or both.

Is Software as a Service More Cost Effective?

SaaS deployments are more cost effective (at least initially) than on-premise installations. SaaS customers generally pay a flat monthly fee per user for the software. SaaS implementations are also cheaper because companies don’t have to buy additional hardware or infrastructure to make the software work, so there are no capital expenditures with SaaS. You also generally don’t have to hire consultants to get the software installed as you often have to with traditional enterprise software. (There are exceptions to that generalization. For details, see Stephanie Overby’s article, “The Truth About On-Demand CRM.”) SaaS customers like the idea of a low up-front investment and a predictable expense stream, even though the cost advantages of the SaaS model may be counter-intuitive after three to five years of monthly fees.

Commercial risks in Software as a Service

Suppliers have quite understandably been marketing the potential benefits of usage-based payment models offered as part of cloud services. However, this carries an upside risk for customers if their usage of the services exceeds their expectations and budgeting. One of the key risks here is storage. If customers pay extra for more storage, they need to be certain they have policies in place to control increases in storage of information and data. Businesses need to think clearly about how long they really need to keep information (there is a clear link to legal obligations under data protection).

The most common approach now is a committed term of 1 to 3 years when signing up to an enterprise SaaS service. Suppliers want to be able to recognise revenue in their accounts and customers want to have a good degree of stability in their ICT delivery arrangements.

The commercial and contractual models for cloud service provision transfer risks back to customers, as compared to the outsourcing business model. Customers need to be able to manage a range of service delivery arrangements and to cope with the integration demands arising from using multiple cloud services. Customers need to be self-aware regarding their own capabilities to manage these risks. This may involve changes to business processes and cultures that ensure cloud services are used as efficiently as possible.

Cloud service provision, through its emphasis on standardised and commodity ICT, mean that ICT delivery organisations must work within the constraints of a standardised service offering. Businesses need to design and adopt processes that make the best use of the cloud service as it stands. A number of the traditional outsourcing providers provide consultancy-type services to assist cloud services users in these activities.

Data escrow

Software as a service data escrow is the process of keeping a copy of critical software-as-a-service application data with an independent third party. Similar to source code escrow, where critical software source code is stored with an independent third party, SaaS data escrow applies the same logic to the data within a SaaS application. It allows companies to protect and insure all the data that resides within SaaS applications, protecting against data loss.

There are many and varied reasons for considering SaaS data escrow including concerns about vendor bankruptcy, unplanned service outages, and potential data loss or corruption. Many businesses either ensure that they are complying with their data governance standards or try to enhance their reporting and business analytics against their SaaS data.

SaaS in the financial services sector

Firms subject to regulation by the Financial Conduct Authority (FCA) also have to comply with FCA security requirements.  The FCA has jurisdiction over data security breaches committed by financial services firms and continues the policy of its predecessor, the Financial Services Authority (FSA), in this area. The FCA actively pursues firms that fail to have adequate systems and controls in place to protect their customers' confidential details from being lost or stolen. For example, in 2018 it fined Tesco Bank over £16 million for failures relating to a cyber-attack.

Under the regulatory regime applying to financial institutions, firms have a responsibility to assess the risks of data loss and take reasonable steps to minimise the risks of this loss occurring. In this context, reasonable steps are deemed to be those that are proportionate to the nature, skill and complexity of the operations taking place.

Although the obligations of a financial institution are no different whether data is stored in a cloud or not, the cloud presents certain challenges in managing third-party suppliers who are responsible for handling such data within a cloud environment. At the centre of this is who has access to the data. It is easier to establish in more traditional models of service provision where the data is and who has access to it at any given time. This is more of a challenge in cloud service provision models.

The FCA has issued guidance to clarify the requirements on firms when outsourcing to the cloud and other third-party IT services. It sees the cloud as encompassing a range of IT services provided in various formats over the internet. This includes, for example, private, public or hybrid cloud, as well as Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS).

Here to help

SaaS is ubiquitous and any business looking to use or deploy IT solutions today will encounter it. The COVID-19 pandemic has accelerated the already fast-paced adoption of cloud computing by everyone from start-ups to multinationals. A key issue for customer and supplier is ensuring that the correct contractual and commercial agreements are in place to safeguard value for money but also that the software meets the specific needs of the customer. Software development for companies used to be highly bespoke and whilst SaaS creates opportunities for speed of access and off-premises maintenance, it also has the potential to leave a customer the victim of over-standardisation i.e. one-size fits all software solutions that don’t meet the customer’s business needs.

EM law specialises in technology and contract law. Get in touch if you need advice on a SaaS agreement or have any questions on the above.


Agile Software Development

Agile Software Development - A Legal Perspective

Agile Software Development came to the fore as a concept in 2001 with the bringing together of seventeen software developers in Snowbird, Utah. All with a shared vision of how software development could be improved for supplier and customer alike. They distilled their views in The Manifesto for Agile Software Development. Among other values it called for “customer collaboration over contract negotiations”. While a potentially wince inducing statement for the conventional lawyer, Agile Software Development has nonetheless proved popular (it is not to be forgotten, however, that such alternative management styles had been experimented with since the 1950s – most notably in Project Mercury, the first human spaceflight programme).

Software development is often a creative and exciting moment for any business. However someone - usually that's the legal adviser - needs to join the party thinking about risk - how it should be apportioned and how it should be minimised.

Waterfall method

In order to understand the conceptual basis for Agile Software Development, it is useful to know what it opposes. The first formal description of the waterfall model is often cited as the 1970’s article, Managing the Development of Large Software Systems by Winston W. Royce, although the term ‘waterfall’ was not explicitly used. The waterfall model was presented as a flawed, non-working model. It is the waterfall model to which Agile Software Development is opposed.

Here is how the waterfall method usually pans out:

Specification requirements – Design – Coding – Testing and Error Detection – Integration – Deployment – Maintenance.

This is how a product is usually made for a customer i.e. the customer specifies what it would like, the supplier creates the product, the product is tested. Once the product passes the tests it is then integrated in the customer’s system, tested again then goes live. Having gone live the supplier usually then provides support and maintenance services to fix any defects in the software.

Agile Software Development - Flexibility

Potential disadvantages of the waterfall method include the difficulty for customers to define their requirements clearly at the outset and that in many cases it does not easily accommodate changes to these requirements made throughout the project. By contrast to the waterfall method, an Agile Software Development project does not have detailed demands for the end product at the outset, although overall project scope and goals are agreed. Flexibility is the core to agile projects as they acknowledge that a customer’s demands and priorates may change from time to time during the course of the project.

Agile Software Development -Method

Typical features of the agile method include:

  • The goal is to deliver functionality and business value to the customer. This means that the solution to business goals and needs cannot necessarily be defined from the outset. It is only the goals and needs that are themselves initially important.
  • The project is divided into a number of sprints, each has its own set of priorities and goals. At the end of each sprint is an approval process assessed by the customer.
  • Planning and review meetings occur at the start and end of each sprint meaning close communication is maintained between the two parties.
  • The customer will reprioritise its needs from time to time, based on its ongoing assessment, and communicate this to the supplier. This may mean that some of the original requirements may become redundant over time.

Terminology

Although Agile Software Development projects can run on their own terms, there is generally a set of positions and relevant terminology used:

  • Product owner – customer’s representative who acts as the first point of communication with the supplier. Key functions include understanding the business needs and organising the development tasks. They must be present at sprint planning and review meetings.
  • Development team – typically supplier personnel. They are responsible for enacting the development sprints.
  • ScrumMaster – focuses on the development team, its progress, removal of obstacles and quality assurance. Typically a member of the supplier’s personnel.
  • Stakeholders – representatives of the customer’s management.
  • Product vision – an explanation of what needs to be developed, focusing on business goals and targeted benefits, rather than technical solutions.
  • Product backlog – a prioritised list of the customer’s business requirements that are to be developed during the project term. These can be reset at any time with new ones added and old ones deleted.

Importance of the product backlog

Maintenance of the product backlog (described above) is a key part of the agile process. The business requirements contained in it and the priorities accorded to them steer the development of the software and testing/approval procedures. These needs are generally described in the form of user stories. Customers should therefore ensure that any mandatory data protection law principles or cybersecurity obligations are contained within the product backlog.

Agile Software Development Scrum

The software development term ‘scrum’ was first used in a 1986 paper titled The New New Product Development Game. The term is borrowed from rugby, where a scrum is a formation of players and is illustrative of teamwork. Scrum is an agile framework used for complex projects (sometimes called extreme programming). Here are its key components:

  • Sprint – a timeboxed effort in which development takes place.
  • Sprint planning – establishes sprint goals.
  • Daily scrum – each day during a sprint, the team holds a daily scrum, preferably at the same place and time, and not longer than fifteen minutes. The scrum is concerned with what each player is contributing to a present/future sprint and has contributed to previous ones.
  • Sprint review and retrospective – demonstrates the work from the current sprint and improve processes respectively.
  • As another sprint begins, the product owner and development team select further items from the product backlog and begin work again.

Legal remedies for a dissatisfied customer

In a waterfall-type agreement the customer can rely upon damages, termination or remedial work in the case of defects or delays. In the case of Agile Software Development it can be difficult to determine whether there is actually any delay or defect because the flexibility of the system means that either can be easily buried behind prioritisation or vague notions of acceptability. Meaning that a delay could be deemed unprioritised by a product backlog and therefore not really a delay or the lack of an accepted definition of acceptance could allow a supplier to argue that no defect exists. The informality of decision-making can also make it difficult to gather the relevant evidence in case of a perceived breach of contract.

Time limits

Time, whilst fluid under an Agile Software Development process, is also bound to sprints and usually given a deadline. In a standard arrangement the customer would estimate the project duration and the number of sprints. It is, however, the discretion of the supplier/customer as to whether or not to formally agree to such estimates. This will need to be negotiated before an agreement is reached. Whilst setting time limits may be tempting, it may also be the undoing of the whole purpose of an agile agreement, in that flexibility will seem undervalued. On the other hand, having some framework in place to ensure contractual remedies is by no means discouraged.

Liability

Here are a some risk areas to be aware of:

  • Not meeting specific requirements within the original timeframe may not necessarily be seen as a breach of the agreement (as they may be re-arranged in the backlog).
  • Acceptance criteria of a sprint – if the agile software development contract is unclear around acceptance criteria the parties can be left arguing over whether an element of the build is completed or not. Acceptance criteria should be described in detail in any agreement so that there is no reliance on less formal descriptions that may be contained in user stories.
  • It is common for agile software development projects to go over budget. Leaving aside delays or quality issues that ramp up costs, if a customer walks into a project not really sure about what they want then it can often happen that their eyes will light up when the developer says “hey, do you want the product to do this cool thing”.
  • Everyone needs to be involved. Developing software using agile methodology is quite an intense process, depending on the project. As it is a collaborative process the parties need each other to be on focused on the project and communicating with each other the whole time. If a key member of the team suddenly goes AWOL then the project may grind to a halt.

Agile Software Development in practice

Agile Software Development as a methodology has the potential to produce creativity and customer/supplier satisfaction  on paper and in practice. It is important, however, to be aware of the potential legal pitfalls from the outset so that each party feels satisfied with the contents of an agreement before moving forward. It is also significant to note that agile methods require both parties to commit to a significant level of time and resources. If either party is remotely located or overburdened with other responsibilities (and so unable to focus on the agile project) the chances of success will be limited.

EM law specialises in technology and contract law. Get in touch if you need advice on Agile Software Development agreements or have any questions on the above.


Software Licences

Software Licences – Different Legal Structures

Software licences come in many shapes and sizes. The range of legal solutions available to software companies is forever morphing and increasing. A significant shift has occurred with the existence of software available via cloud computing (read our blog). This gives suppliers the option of making their software available via the cloud rather than a user being required to upload the licenced software to their own server. Software licences need to maintain a balancing act between protecting the software in question and being attractive to consumers.

Monetising software

Organisations in the technology sector monetise software in various ways, including:

  • Developing software from scratch, or configuring or adapting an existing core package software, to meet a user's specific needs.
  • Software licences that licence (either standard or bespoke) directly to end-users (for them to run on their systems, locally).
  • Providing software-as-a-service. Read our blog.
  • Selling software outright, either as a standalone asset, or as part of a wider share or asset sale of a technology business.
  • Offering other software consultancy services, such as maintenance and support or escrow deposit services.
  • Software licences that licence to an intermediary, such as a software reseller or retailer, who will on-licence the software, either by itself or as part of wider bundle of products
  • Licencing their application programming interfaces (APIs). See section below for a further explanation.

Software licensing

Licensing is still the main method by which most businesses and individuals obtain the right to use software, and how software vendors make money. Traditionally, software has been licensed ‘on-premise’ but recently there has been a surge of organisations migrating to delivery of software as a service via the cloud.

Why does software need to be licensed?

A software licence is typically a combination of a copyright licence, giving the user permission to do something that would otherwise be an infringement of copyright law and a contract, to give the licensor (among other things) the ability to exclude or limit its liability and the right to sue the licensee in contract as well as copyright law.

Software is protected by copyright as a literary work under the Copyright, Designs and Patents Act 1988 (CDPA). The operation of software for all practical purposes always involves its copying in one form or another, for example, when the software is copied on to the hard disk of the computer on loading and later when it is copied into Random Access Memory, for use. Subsequent further transient copies may then be made during operation. This, and the fact that software is statutorily protected by copyright as a literary work, means that the owner of the intellectual property rights in software can prevent its use without permission.

Software Licences Permitted Use

Suppliers will generally only be prepared to grant licences of package software on non-exclusive terms so that they can grant licences of the software to multiple customers. A supplier will also often restrict the use of the software in certain ways, for example, by reference to:

  • The identity of the customer or a group of users associated with the customer.
  • The identity and number of machines or operating system environments on which the software is loaded.
  • The geographical location of the machines on which the software is loaded.
  • The purpose for which the software is used.
  • The number of concurrent users of the software.
  • The volume of processing handled by the software.

The type of restrictions will depend on the nature of the software (the supplier may have developed the software, for example, for use in a particular operating system or other software) and the manner in which the supplier typically licenses its software. The customer should ensure that any applicable restrictions are acceptable, taking into account its current and future business requirements, since use of the software in breach of such restrictions will constitute a breach of the licence and may entitle the supplier to damages, an injunction preventing use or termination (or all three). It is therefore important that the customer knows exactly what rights they are buying.

Technological changes can have a serious impact on licensing. For example, if software is licensed for use on a single server, one must consider the consequence if that server is included within a virtualised environment in which it can be made to function as a number of independent mini-computers or, if software is licensed for use on a specified server or at a specified location, you must consider the consequence of replacing or moving that server.

Software Licences Restricting Use

The supplier will often wish to ensure that use of the software is restricted to the company with which it is contracting. Typically, this is achieved by prohibiting sub-licensing and assignment under the licence. For the customer, this can cause problems in the case of groups of companies. Software that is licensed in the name of one group company may well be accessed by another group company, whether intended, as a result of inadvertence or as a consequence of organisational change. Such access may constitute a breach of the licence unless the licence permits use among group companies. This is a particular problem with utility software where what constitutes ‘use’ or ‘access’ may be unclear. If there is a virus protection program on a network, is it used or accessed by everyone whose PC is connected to the network? Consequently, the customer should ensure, where necessary, that the licence extends to all other companies in its group that are likely to use the software.

Similarly, if outsourcing is contemplated by the customer or the customer intends to engage other external service providers to provide services to the customer (for example configuration or support services), the software may need to be used by, or assigned to, the external service provider. If such use or assignment is not permitted by the terms of the licence, then the supplier may charge a significant fee for agreeing a change of or additional use.

Third parties

From the supplier's perspective, it is difficult to police the use of the software (to ensure, for example, that no illegal copying is taking place), and enforce the terms of the licence, against unconnected third parties. In order to ensure that the customer remains within the terms of the licence throughout its term, the licence could include an obligation on the customer to inform the supplier where there is any change in or additional use of the software and a right for the supplier to audit the use of the software remotely or by entry to all premises on which the software is used (the extent of which will be subject to negotiation and the respective bargaining strengths of the parties).

Software as a service

For typical on-premises software licences, the user will need a licence from the software owner (or from a licensee to whom the rights owner has granted rights to sub-license the software) to copy software to the extent necessary to install and use the software on their own computer. For software as a service, the method of accessing the software, or its functional outputs, may be different but a permission from the copyright owner will still likely be necessary. For example, with SaaS, the application software itself will not need to be installed on the user's machine, but a generic piece of software, such as a web browser, may, and the user's machine will still need to interface with the application software in some way. Because of this, the licence terminology used in a software-as-a-service agreement may change. For example, it may not be the application software, itself, which is licensed for use by the customer; the customer may only be permitted to remotely access certain functional outputs from the software, that is, to receive ‘a service’.

On-premise software licensing

On-premises software licences for business use (such as operating system software) are typically bundled with hardware when purchased. Sometimes a customer may ask for a trial period under which it may evaluate or ‘road test’ business software. This is typically done under an evaluation licence, which will provide a limited licence to use the software for a limited period, free of charge, with few or no warranties being provided by the software supplier during the trial period.

For on-premises software licences for consumer use it is essential that any terms and conditions for the use of software by consumers are drafted to comply with the extensive consumer protection rules that apply in the UK. Different rules apply depending on whether the trader is selling to the consumer online, ‘on-premises’ or ‘off-premises’.

Different distribution models for on-premise licensing

A software producer will sometimes distribute its software through a third party reseller, who may combine or bundle the producer's software with its own products, or offer other value-added services. In both types of agreement, in return for gaining access to this alternative (generally, additional) distribution channel, the producer usually agrees to sell licences to its software to the reseller at a lower unit price than would otherwise be paid if the software were being distributed on its own. The consequence of this is that the reseller obtains a more limited distribution right, as it is only entitled to distribute the supplier's software in combination with particular products of its own and/or on terms and conditions specified by the supplying company.

Competition aspects to Software Licences

Software licences may contain various restrictions which require consideration of UK competition law. These include exclusivity of the licence grant and grants of rights to improvements made by the customer. Software vendors should also be aware that, following the CJEU's decision in UsedSoft GmbH v Oracle International Corp, they may not be able to rely on contractual provisions in their software licences which prohibit a customer from transferring or assigning the software to a third party. This only applies under certain circumstance, such as where the vendor has purported to grant the customer a perpetual licence to use the software for a one-off fee. Along with all other EU case law, UsedSoft v Oracle has been incorporated into UK law following Brexit. UK courts will, however, be able to overrule it in the future.

Open-source software

Open-source software (OSS) (read our blog) is software provided under a licence which grants certain freedoms to the licensee to use and re-distribute the OSS. It is often used by software companies whilst they develop software. There are many different types of OSS licences which differ widely in clarity, length and legal effect. There are many advantages to organisations making use of OSS. The use of OSS is usually free of charge and free of many of the use restrictions that apply to proprietary software. Using pre-made OSS components (particularly for routine, lower-level tasks) shortens the development phase for projects and frees up internal resources to develop higher-level software that confers competitive advantage.

However, use of OSS also presents risks. The main risk is often that certain types of OSS licence, known as ‘restrictive licences’, adopt the principle of ‘copyleft’. This imposes licensing restrictions or requirements where the OSS is amended, adapted or combined with any other software to produce a derivative work. While the provisions vary, restrictive OSS licences will (to a certain extent) apply to both the original OSS and any derivative works based on it. This can be of key concern to organisations when using restrictive OSS alongside their proprietary ‘closed-source’ software, as proprietary software could unintentionally be made subject to the OSS licence. An example of a restrictive OSS licence is the General Public Licence (GPL).

Application programming interfaces (APIs)

In recent years, many technology companies have grown their revenues by licensing their application programming interfaces (APIs). An API can take different forms, but typically provides a set of tools, documents, protocols, and specifications that enable software applications to communicate and interact with each other. Licensing (or opening up) its API is a way for a software vendor to invite third parties to create applications that complement the supplier's offering. By doing so, the software vendor may get a better pool of integrated applications that enhance the user experience for the vendor's offering, without needing to hire or otherwise engage developers. APIs can be differentiated from traditional software applications, including to the extent they are protected under law.

Here to help

There is a lot to think about when putting software on the market. Being aware of the range of licencing issues is key when putting in place a legal framework that exists to the benefit of both supplier and customer. Software licences will continue to develop as technology does and so the challenges faced by lawyers in this sector are unlikely to diminish in the face of the never-ending innovation and ingenuity that defines it.

EM law specialises in technology and contract law. Get in touch if you need advice on a SaaS agreement or have any questions on the above.


Statement Of Objections To Amazon

EC Sends Statement Of Objections To Amazon - Big Data Law

On 10 November 2020, the European Commission announced that it has sent a statement of objections to Amazon as part of its investigation into whether Amazon's use of sensitive data from independent retailers who sell on its marketplace is in breach of Article 102 of the Treaty on the Functioning of the European Union (TFEU). The Commission has also opened a formal investigation into Amazon's allegedly discriminatory business practices.

What data is amazon collecting?

Amazon has a dual role as a platform:

  • It provides a marketplace where independent sellers can sell products directly to consumers. Amazon is the most important or dominant marketplace in many European countries.
  • It sells products as a retailer on the same marketplace, in competition with those sellers.

As a marketplace service provider, Amazon has access to non-public business data of third party sellers. This data relates to matters such as the number of ordered and shipped units of products, the sellers' revenues on the marketplace, the number of visits to sellers' offers, data relating to shipping, to sellers' past performance, and other consumer claims on products, including the activated guarantees.

Investigation into use of independent sellers’ data

In July 2019, the Commission announced that it had opened a formal investigation to examine whether Amazon's use of competitively sensitive information about marketplace sellers, their products and transactions on the Amazon marketplace constitutes anti-competitive agreements or practices in breach of Article 101 of the Treaty on the Functioning of the European Union (TFEU) and/or an abuse of a dominant position in breach of Article 102 of the TFEU.

Statement of objections to Amazon

The Commission has now sent a statement of objections to Amazon alleging that Amazon has breached Article 102 of the TFEU by abusing its dominant position as a marketplace service provider in Germany and France. Having analysed a data sample covering over 80 million transactions and around 100 million product listings on Amazon's European marketplaces, the Commission is alleging in its statement of objections to Amazon that:

  • Very large quantities of non-public seller data are available to employees of Amazon's retail business and feed into automated systems. Granular, real-time business data relating to third party sellers' listings and transactions on the Amazon platform is systematically feed into the algorithms of Amazon's retail business, which aggregates the data and uses it to calibrate Amazon's retail offers and strategic business decisions (such as which new products to launch, the price of each individual offer, the management of inventories, and the choice of the best supplier for a product).
  • This acts to the detriment of other marketplace sellers as, for example, Amazon can use this data to focus its offers in the best-selling products across product categories and to adjust its offers in light of the non-public data of competing sellers.
  • The use of non-public marketplace seller data, therefore, allows Amazon to avoid the normal risks of retail competition and to leverage its dominance in the market for the provision of marketplace services in France and Germany, which are the biggest markets for Amazon in the EU.

The Commission's concerns are not only about the insights Amazon Retail has into the sensitive business data of one particular seller, but rather about the insights that Amazon Retail has about the accumulated business data of more than 800,000 active sellers in the EU, covering more than a billion different products. Amazon is able to aggregate and combine individual seller data in real time, and to draw precise, targeted conclusions from these data.

The Commission has, therefore, come to the preliminary conclusion that the use of these data allows Amazon to focus on the sale of the best-selling products. This marginalises third party sellers and limits their ability to grow. Amazon now has the opportunity to examine the documents in the Commission's investigation file, reply in writing to the allegations in the statement of objections and request an oral hearing to present its comments on the case.

Investigation into Amazon practices regarding the “Buy Box” and Prime label

The Commission states that, as a result of looking into Amazon's use of data, it identified concerns that Amazon's business practices might artificially favour its own retail offers and offers of marketplace sellers that use Amazon's logistics and delivery services. It has, therefore, now formally initiated proceedings in a separate investigation to examine whether these business practices breach Article 102 of the TFEU.

Problems with digital platforms

In announcing these developments, EU Commission Vice-President Vestager commented that:

“We must ensure that dual role platforms with market power, such as Amazon, do not distort competition. Data on the activity of third party sellers should not be used to the benefit of Amazon when it acts as a competitor to these sellers. The conditions of competition on the Amazon platform must also be fair. Its rules should not artificially favour Amazon's own retail offers or advantage the offers of retailers using Amazon's logistics and delivery services. With e-commerce booming, and Amazon being the leading e-commerce platform, a fair and undistorted access to consumers online is important for all sellers.”

The report prepared for the Commission by three special advisers on "Competition Policy for the digital era" highlighted possible competition issues in relation to digital platforms. As part of the Digital Services Act package, the Commission is now considering the introduction of ex ante regulation for "gatekeeper" platforms, and consulted on issues related to this in June 2020

Big data regulation

It remains to be seen how these EC investigations will play out and whether the same principles can be applied to smaller online platforms. UK regulators also appear to be ramping up their interest in the overlap between competition law and digital business. Chief Executive of the UK Competition and Markets Authority (CMA), Andrea Coscelli, noted last month that the CMA is increasingly focused on “scrutinising how digital businesses use algorithms and how this could negatively impact competition and consumers” and “will be considering how requirements for auditability and explainability of algorithms might work in practice”.

If you have any questions on the EC’s statement of objections to Amazon, data protection law or on any of the issues raised in this article please get in touch with one of our data protection lawyers.


ICO guidance on AI

ICO Guidance On AI Published - AI And Data Protection

On 30 July 2020, the Information Commissioner’s Office (ICO) published its long-awaited guidance on artificial intelligence (AI) and data protection (ICO guidance on AI), which forms part of its AI auditing framework. However, recognising that AI is still in its early stages and is developing rapidly, the ICO describes the guidance as foundational guidance. The ICO acknowledges that it will need to continue to offer new tools to promote privacy by design in AI and to continue to update the guidance to ensure that it remains relevant.

The need for ICO guidance on AI

Whether it is helping to tackle the coronavirus disease (COVID-19), or managing loan applications, the potential benefits of AI are clear. However, it has long been recognised that it can be difficult to balance the tensions that exist between some of the key characteristics of AI and data protection compliance, particularly under the General Data Protection Regulation (679/2016/EU) (GDPR).

The Information Commissioner Elizabeth Denham’s foreword to the ICO guidance on AI confirms that the underlying data protection questions for even the most complex AI project are much the same as with any new project: is data being used fairly, lawfully and transparently? Do people understand how their data is being used and are they being kept secure?

That said, there is a recognition that AI presents particular challenges when answering these questions and that some aspects of the law require greater thought. Compliance with the data protection principles around data minimisation, for example, can seem particularly challenging given that many AI systems allow machine learning to decide what information is necessary to extract from large data sets.

Scope of the ICO guidance on AI

The guidance forms part of the ICO’s wider AI auditing framework, which also includes auditing tools and procedures for the ICO to use in its audits and investigations and a soon-to-be-released toolkit that is designed to provide further practical support for organisations auditing their own AI use.

It contains recommendations on good practice for organisational and technical measures to mitigate AI risks, whether an organisation is designing its own AI system or procuring one from a third party. It is aimed at those within an organisation who have a compliance focus, such as data protection officers, the legal department, risk managers and senior management, as well as technology specialists, developers and IT risk managers. The ICO’s own auditors will also use it to inform their statutory audit functions.

It is not, however, a statutory code and there is no penalty for failing to adopt the good practice recommendations if an alternative route can be found to comply with the law. It also does not provide ethical or design principles; rather, it corresponds to the data protection principles set out in the GDPR.

Structure of the guidance

The ICO guidance on AI is set out in four parts:

Part 1. This focuses on the AI-specific implications of accountability; namely, responsibility for complying with data protection laws and demonstrating that compliance. The guidance confirms that senior management cannot simply delegate issues to data scientists or engineers, and are responsible for understanding and addressing AI risks. It considers data protection impact assessments (which will be required in the majority of AI use cases involving personal data), setting a meaningful risk appetite, the controller and processor responsibilities, and striking the required balance between the right to data protection and other fundamental rights.

Part 2. This covers lawfulness, fairness and transparency in AI systems, although transparency is addressed in more detail in the ICO’s recent guidance on explaining decisions made with AI (2020 guidance). This section looks at selecting a lawful basis for the different types of processing (for example, consent or performance of a contract), automated decision making, statistical accuracy and how to mitigate potential discrimination to ensure fair processing.

Part 3. This section covers security and data minimisation, and examines the new risks and challenges raised by AI in these areas. For example, AI can increase the potential for loss or misuse of large amounts of personal data that are often required to train AI systems or can introduce software vulnerabilities through new AI-related code. The key message is that organisations should review their risk management practices to ensure that personal data are secure in an AI context.

Part 4. This covers compliance with individual rights, including how individual rights apply to different stages of the AI lifecycle. It also looks at rights relating to solely automated decisions and how to ensure meaningful input or, in the case of solely automated decisions, meaningful review, by humans.

ICO guidance on AI - headline takeaway

According to the Information Commissioner, the headline takeaway from the ICO guidance on AI is that data protection must be considered at an early stage. Mitigation of risk must come at the AI design stage as retrofitting compliance rarely leads to comfortable compliance or practical products.

The guidance also acknowledges that, while it is designed to be integrated into an organisation’s existing risk management processes, AI adoption may require organisations to reassess their governance and risk management practices.

A landscape of guidance

AI is one of the ICO’s top three strategic priorities, and it has been working hard over the last few years to both increase its knowledge and auditing capabilities in this area, as well as to produce practical guidance for organisations.

To develop the guidance, the ICO enlisted technical expertise in the form of Doctor (now Professor) Reuben Binns, who joined the ICO as part of a fellowship scheme. It produced a series of informal consultation blogs in 2019 that were focused on eight AI-specific risk areas. This was followed by a formal consultation draft published in February 2020, the structure of which the guidance largely follows. Despite all this preparatory work, the guidance is still described as foundational.

From a user perspective, practical guidance is good news and the guidance is clear and easy to follow. Multiple layers of guidance can, however, become more difficult to manage. The ICO has already stated that the guidance has been developed to complement its existing resources, including its original Big Data, AI and Machine Learning report (last updated in 2017), and its more recent 2020 guidance.

In addition, there are publications and guidelines from bodies such as the Centre for Data Ethics and the European Commission, and sector-specific regulators such as the Financial Conduct Authority are also working on AI projects. As a result, organisations will need to start considering how to consolidate the different guidance, checklists and principles into their compliance processes.

Opportunities and risks

“The innovation, opportunities and potential value to society of AI will not need emphasising to anyone reading this guidance. Nor is there a need to underline the range of risks involved in the use of technologies that shift processing of personal data to complex computer systems with often opaque approaches and algorithms.” (Opening statement of ICO guidance on AI and data protection.)

If you have any questions on data protection law or on any of the issues raised in the ICO guidance on AI please get in touch with one of our data protection lawyers.


Legal Protection of Software

Legal Protection Of Software

This blog considers the legal protection of software under UK law. It focuses on the application of the law of copyright to software, but also briefly considers other intellectual property rights which might be relevant.

Legal Protection of Software - Copyright

 A computer program is primarily protected as a copyright work. The Copyright, Designs and Patents Act 1988 (CDPA) provides that copyright subsists in an original literary work, which is defined as including a "computer program" and the "preparatory design material for a computer program", although the CDPA does not define what constitutes a computer program. The CDPA is, in this regard, implementing the EU’s Software Directive which provides that a "computer program", including for this purpose, their preparatory design material, is protected by copyright as a literary work.

However, software is quite unlike the more traditional forms of copyright work - such as books, paintings or letters - for which copyright evolved. Accordingly, the application of copyright to software is not entirely straightforward. In particular, software has a life beyond the black letter of its text in a way that books or paintings do not. It is both a copyright work - in the sense of being a record of information - and a functioning work, which creates effects - such as screen displays or sounds and which may include errors and need to be supported or maintained. This can lead to complications in terms of the legal protection of software by copyright because it is axiomatic that copyright protects the expression of ideas, but not ideas or schemes per se.

Definition of Software

The fact that the term "computer program" appears to be interpreted as referring only to the source code and object code can also lead to difficulties in terms of analysing the copyright works which may subsist in a software package, which, in practical terms, comprises more than just the code. Above the source code or object code of a computer game, for example, there is a layer of visible content - what the user sees and hears when they are playing the game - which may include, among other things, graphics, music or sound effects protected by copyright. 

Requirements for copyright protection of software

In order for copyright to subsist under UK law:

  • A work must fall into one of the categories of work protected by copyright under UK law.
  • A work must qualify for protection under UK law (this usually depends on the nationality of the author or place of first publication).
  • The term of copyright must not have expired.

Works protected by copyright

The works protected by copyright are:

  • Original literary, dramatic, musical or artistic works which, in the case of literary, dramatic or musical works are recorded in some way. A literary work includes a:
    • table or compilation other than a database.
    • computer program and preparatory design material for a computer program.
    • database which meets a specific originality test.
  • Sound recordings, films or broadcasts.
  • The typographical arrangements of published editions.

Computer programs and preparatory design materials

Computer programs and the preparatory design material for a computer program are protected as literary works (section 3(1)(b) and (c), CDPA). The term "computer program" is not defined in the CDPA. However the term has been regarded as referring to source code or, in its machine-readable form, object code by the ECJ in the case BSA.

The source code and object code of a program will be protected as literary works, provided they are original. Software is frequently modified and updated. In each case where a program is revised or modified to a substantial degree, the new version will also be protected as a copyright work.

Additionally, design documents relating to the computer program, such as flow charts, graphs and functional or technical specifications would be protected as preparatory design material for a computer program. The definition of "computer program" in the Software Directive, provides that a computer program includes the preparatory design work leading to its development.

Legal Protection of Software - Confidentiality Laws

 While copyright is the main form of legal protection of software, most proprietary software companies also ensure that the source code of the software is kept as a trade secret, and only disclosed under a secrecy agreement where disclosure is necessary, such as to producers of related software. This is because, as discussed above, the source code is the key to understanding how the software functions and is essential for the maintenance of the software, since it will need to be examined to develop the software or correct errors or defects in it.

There are two basic requirements for information to be treated as confidential according to UK law:

  • It must have the necessary quality of confidence. In other words, it must not be public property or public knowledge.
  • It must be imparted in circumstances importing an obligation of confidence i.e. when shared it must not be done so as if it were public property or public knowledge.

Legal Protection of Software - Database right 

The EU Database Directive (96/9/EC) sought to harmonise the legal protection of databases. A database is a collection of independent works, data or other materials arranged in a systematic or methodical way and individually accessible by electronic or other means.

The Directive standardised the "originality" threshold for copyright protection of databases, limiting such protection to databases which "by reason of the selection or arrangement of their contents, constitute the author's own intellectual creation" (Article 3, EU Database Directive). This requirement is reflected in section 3A(1)of the CDPA and hence also applies to software.

Legal Protection of Software - Patents

In the UK, a patent may be obtained in respect of an invention which is new, involves an inventive step, is capable of industrial or technical application and does not fall within any of the exclusions (Patents Act 1977). The owner of a patent can prevent any third parties from selling the product or process which is the subject of the invention. However, section 1(2) of the Patents Act provides that a patent will not be granted for "a program for a computer" to the extent that the patent relates to the program "as such". This is derived from a similar provision in Article 52 of the European Patent Convention (EPC).

Although under the EPC computer programs are not patentable "as such", it is well established that the application of a computer program may well be patentable if it possesses a technical character. What gives the application of a computer program the necessary technical character and takes it beyond the exclusion is difficult to determine. It should be noted that there exists some degree of inconsistency and uncertainty with regard to the approach taken to software-patenting across Europe by different national courts and patent offices. A proposed Software Patent Directive, which would have harmonised the position with regard to patent protection of software in the EU and resolved at least some of the questions on the patentability of software, was rejected decisively by the European Parliament.

Protection of software – other ways

Other than relying on UK laws, there are other ways in which software owners can and should protect their products. Adopting technical measures is the most obvious one for example, including encryption or the embedding of anti-piracy techniques directly into hardware. It is  also essential to have robust non-disclosure agreements and software contracts in place so that if a licensee infringes important rights the software owner can point to its NDA or licence agreement and take appropriate enforcement action.

EM law specialises in technology law. Get in touch if you have any questions on the above.