Header graphic for print

Socially Aware Blog

The Law and Business of Social Media

Friday Links

Posted in Big Data, First Amendment, Litigation, Marketing

We’re trying something new here at Socially Aware: In addition to our usual social-media and tech-law analyses and updates, we’re going to end each work week with a list of links to interesting social media stories around the Web, primarily things that caught our eye during the week that we may or may not ultimately write about in a future blog post.

Here’s our first list – enjoy!

The Internet of Things: Interoperability, Industry Standards & Related IP Licensing Approaches (Part 2)

Posted in Internet of Things, IP

Internet of things synchronized by smart phone isometric poster vector illustration

In an article published here in January we addressed some of the more significant Internet of Things (IoT) -specific standards and initiatives and emphasized the importance of interoperability as central to the growth and success of the products and services that leverage the IoT.  In this follow-up piece, we provide a detailed update regarding one of the leading efforts around standardization, the Open Connectivity Forum (OCF). We also cover three additional industry standards that have particular potential when used in IoT: Bluetooth Low Energy, Wi-Fi (including 5G) and Blockchain.

“Fragmentation is the Enemy”

On February 19, 2016, the Open Connectivity Forum (OCF), a new standards effort for the IoT, was announced. Led by Intel, Qualcomm, ARRIS, CableLabs, Cisco, Electrolux, GE Digital,  Microsoft and Samsung, the OCF reportedly seeks to merge the current efforts towards standards development in the IoT, uniting the former Open Interconnect Consortium with companies at all levels, and is “dedicated to providing this key interoperability element of an IoT solution.” The initiative hopes to circumvent the expenditure of time and resources in building consensus between multiple standards approaches, accelerating innovation and assisting developers create solutions that map to one open IoT interoperability specification.  Emphasizing this point, Qualcomm recently published on its website that “fragmentation is the enemy of IoT.” The OCF sponsors the IoTivity open source project (covered in Part 1 of this Alert) which includes a reference implementation of the OCF specification licensed under the open source Apache 2.0 license.

OCF Intellectual Property Policy

The Intellectual Property Policy adopted by the OCF shows a high level of attention to detail, thoroughness and nuance. Those considering joining would be well-advised to get some help in understanding how these terms will apply to their specific intellectual property portfolio, products, components and services. We have chosen to take a deeper dive into the intellectual property policy for this standard because the details of the policy reveal a number of areas of focus of the founding members.

While the policy imposes obligations on members as well as their affiliates to grant licenses under copyrights and patents, the scope and cost of those licenses will depend on a number of specifics that will vary depending on the precise contours of the final specifications. Members are required to represent that they are authorized to bind their affiliates to the terms of the policy, including parent and sister companies.

1. Patent Claims Captured. The patent claims captured by the policy are limited in a number of ways:

  • The only claims captured are those that would be necessarily infringed by implementing the mandatory portions of the specifications within the bounds of a tightly defined scope that ties specifically to enabling the compliant portions of products to interoperate, interconnect or communicate.
  • Necessary infringement is defined as there being no “commercially reasonable” non-infringing alternative for this enablement. The policy requires that any transfer of these necessary patent claims to unaffiliated third parties must be subject to the terms and conditions of the policy, and transfer or assignment agreements must explicitly address the fact that the transfer or assignment is subject to existing licenses and obligations imposed by standards bodies such as OCF. Those who practice in the merger and acquisition arena will want to take note of the potential issues for both sellers and acquirers in light of these requirements.

2. Patent License Scope. The license scope is also limited in similarly nuanced ways. The license under the above patent claims extends to only those portions of products and services that implement the protocols, functions, APIs and their adaptation layers, input parameters, data structures, services and firmware descriptors that fall within the mandatory portions of the final specification (including mandatory portions of optional components of the specification). Moreover, the policy goes to great lengths to ensure that, unless the final specification is explicit and describes in detail these items where the description’s sole purpose is to enable interoperability, interconnection or communication, no license will apply. This would seem to place a heavy burden on the developers of the specification taking  this into account in developing the details of the specifications.

3. Opt-Out is not true Opt-Out. Another interesting aspect of the policy is that while the policy allows for members to exclude specified patent claims from the royalty-free license, this opt-out mechanism is constrained. Most importantly, members cannot opt out entirely. The policy imposes a requirement to license those excluded patent claims on reasonable and necessary non-discriminatory terms—again, this applies even if patent claims are excluded in accordance with the opt-out framework. The opt-out mechanism also only can be exercised 4 times in any 60 month period.

4. Copyright and Software. While we have focused on patents here due to the policy’s emphasis on the patent rights granted, the policy also imposes obligations to license copyrights. The policy only addresses rights under copyright to contributions made by members to the specification itself. The policy also includes a brief statement permitting members to contribute OCF open source that OCF deems acceptable and non-confidential as well as modifications and additions to such open source software to open source projects. It is not clear what will be considered acceptable and what software will be made non-confidential. It is also not and does not appear to extend to software beyond acknowledging that members may license their software source code that implements the specification under open source licenses and may make contributions of such source code to open source projects. No limitations on which open source projects are permitted appear. This seems odd given that this could result in OCF open source software ending up being contributed to projects that impose license terms that conflict with one another. It seems that OCF may have decided to defer these issues to the future once it has determined what is “acceptable” and what software OCF itself will make available.

5. Rights on Termination. Termination also raises issues for terminating as well as continuing members. Once members join, they may not terminate the licenses they have previously granted to other members prior to termination with respect to versions of the final specification that existed while they were members or contributions to draft specifications that they made which become part of subsequent versions of the specification after their termination. Continuing members are also required to provide more or less reciprocal grants. Continue Reading

Digital Single Market Strategy Update: Europe Proposes Further Harmonisation of Consumer Protection Laws

Posted in Data Security, Digital Content, E-Commerce, Privacy

0329_JS_imageThe European Commission has published two draft directives on the supply of digital content and the online sale of goods that aim to help harmonise consumer law across Europe. In proposing these new laws, the European Union is making progress towards one of the main goals in its Digital Single Market Strategy (announced in May 2015), which is concerned with strengthening the European digital economy and increasing consumer confidence in online trading across EU Member States. According to the Commission, only 12% of EU retailers sell online to consumers in other EU countries, while more than three times as many sell online in their own country. The Commission has also announced a plan to carry out a fitness check of other existing European consumer protection laws.

This article outlines the potential implications of these latest developments, with a particular focus on the UK and Germany.

DIGITAL CONTENT AND ONLINE SALES OF GOODS

This is not the first time that the Commission has tried to align consumer laws across the EU: the Commission’s last attempt at a Common European Sales Law faltered in 2015. But the Commission has now proposed two new directives dealing with contracts for the supply of digital content (“Draft Digital Content Directive”) and sales of online goods (“Draft Online Goods Directive”) (together, the “Proposed Directives”). The Online Goods Directive will replace certain aspects of an Existing Sales of Consumer Goods and Associated Guarantees Directive (“Existing Goods Directive”), whereas the Digital Cotent Directive introduces a new set of rights for consumers when they buy digital content across the EU.

Part of the issue with previous EU legislative initiatives in this area is that “harmonised” has really meant “the same as long as a country doesn’t want to do anything different”. This time, the Proposed Directives have been drafted as so-called “maximum harmonisation measures”, which would preclude Member States from providing any greater or lesser protection for the matters falling within their scope. The Commission hopes that this consistent approach across Member States will encourage consumers to enter into transactions across EU borders, while also allowing suppliers to simplify their legal documentation by using a single set of terms and conditions for all customers within the EU.

The Proposed Directives will need to be adopted by the EU Parliament and Council before becoming law. Member States would then have two years to transpose the Proposed Directives into national law.

Continue Reading

How to Protect Your Company’s Social Media Currency

Posted in Digital Content, DMCA, IP, Litigation, Marketing, Section 230 Safe Harbor, Terms of Use

03_21_Signs_Today’s companies compete not only for dollars but also for likes, followers, views, tweets, comments and shares. “Social currency,” as some researchers call it, is becoming increasingly important and companies are investing heavily in building their social media fan bases. In some cases, this commitment of time, money and resources has resulted in staggering success. Coca-Cola, for example, has amassed over 96 million likes on its Facebook page and LEGO’s YouTube videos have been played over 2 billion times.

With such impressive statistics, there is no question that a company’s social media presence and the associated pages and profiles can be highly valuable business assets, providing an important means for disseminating content and connecting with customers. But how much control does a company really have over these social media assets? What recourse would be available if a social media platform decided to delete a company’s page or migrate its fans to another page?

The answer may be not very much. Over the past few years, courts have repeatedly found in favor of social media platforms in a number of cases challenging the platforms’ ability to delete or suspend accounts and to remove or relocate user content.

Legal Show-Downs on Social Media Take-Downs

In a recent California case, Lewis v. YouTube, LLC, the plaintiff Jan Lewis’s account was removed by YouTube due to allegations that she artificially inflated view counts in violation of YouTube’s Terms of Service. YouTube eventually restored Lewis’s account and videos but not the view counts or comments that her videos had generated prior to the account’s suspension.

Lewis sued YouTube for breach of contract, alleging that YouTube had deprived her of her reasonable expectations under the Terms of Service that her channel would be maintained and would continue to reflect the same number of views and comments. She sought damages as well as specific performance to compel YouTube to restore her account to its original condition.

The court first held that Lewis could not show damages due to the fact that the YouTube Terms of Service contained a limitation of liability provision that disclaimed liability for any omissions relating to content. The court also held that Lewis was not entitled to specific performance because there was nothing in the Terms of Service that required YouTube to maintain particular content or to display view counts or comments. Accordingly, the court affirmed dismissal of Lewis’s complaint.

In a similar case, Darnaa LLC v. Google, Inc., Darnaa, a singer, posted a music video on YouTube. Again, due to allegations of view count inflation, YouTube removed and relocated the video to a different URL, disclosing on the original page that the video had been removed for violating its Terms of Service. Darnaa sued for breach of the covenant of good faith and fair dealing, interference with prospective economic advantage and defamation. In an email submitted with the complaint, Darnaa’s agent explained that she had launched several large campaigns (each costing $250,000 to $300,000) to promote the video and that the original link was already embedded in thousands of websites and blogs. Darnaa sought damages as well as an injunction to prevent YouTube from removing the video or changing its URL.

The court dismissed all of Darnaa’s claims because YouTube’s Terms of Service require lawsuits to be filed within one year and Darnaa had filed her case too late. In its discussion, however, the court made several interesting points. In considering whether YouTube’s Terms of Service were unconscionable, the court held that, although the terms are by nature a “contract of adhesion,” the level of procedural unconscionability was slight, since the plaintiff could have publicized her videos on a different website. Further, in ruling that the terms were not substantively unconscionable, the court pointed out that “[b]ecause YouTube offers its hosting services free of charge, it is reasonable for YouTube to retain broad discretion over [its] services.”

Although the court ultimately dismissed Darnaa’s claims based on the failure to timely file the suit, the decision was not a complete victory for YouTube. The court granted leave to amend to give Darnaa the opportunity to plead facts showing that she was entitled to equitable tolling of the contractual limitations period. Therefore, the court went on to consider whether Darnaa’s allegations were sufficient to state a claim. Among other things, the court held that YouTube’s Terms of Service were ambiguous regarding the platform’s rights to remove and relocate user videos in its sole discretion. Thus, the court further held that if Darnaa were able to amend the complaint to avoid the consequences of the failure to timely file, then the complaint would be sufficient to state a claim for breach of the contractual covenant of good faith and fair dealing.

Continue Reading

HIPAA and Health Care Apps: Is Your App Covered?

Posted in Data Security, Privacy, Product Liability

Blue Touchscreen Smart phones with colorful medical application icons

Health care apps are one of the most important and growing segments in the ecosystem known as the Internet of Things (IoT). After the recent amendments to the Health Insurance Portability and Accountability Act (HIPAA) that—among other things—broadened the definition of a “Business Associate,” many technology companies found themselves wondering whether they were, or were not, subject to HIPAA. Health and Human Services (HHS) recently issued some guidance, Health App Use Scenarios & HIPAA, that attempts to provide some clarity on these issues for app developers.

HIPAA, while broad in some ways, is actually somewhat narrow in its application. It does not apply to all medical information. Instead, it primarily focuses on “Covered Entities,” or CEs. A CE is a health care provider that conducts certain transactions in electronic form, a health care clearinghouse, or a health plan. If your company does not meet those criteria, then it is not a CE, and not subject to HIPAA as a CE.

While that analysis is an important step, it is not the final step in assessing whether HIPAA impacts your app. A company that does not meet the definition of a CE can still be a “Business Associate,” or BA—in essence a service provider for a CE—if it receives, maintains, or transmits Personal Health Information (PHI) on behalf of a CE. As we will see, the “on behalf of” language is critical.

In the emerging realm of health care apps, another distinction with its own set of acronyms is also important—the difference between an EHR and a PHR. Electronic Health Records (EHRs) are electronic records that are, in essence, created or maintained by a CE or a BA. They are official records that facilitate medical treatment, and they are subject to HIPAA and other medical record requirements. At their core, they are provider-centric records.

Personal Health Records (PHRs) are a related but distinct concept. PHRs are medical records that typically are electronic, but consumer-facing and not necessarily part of a patient’s medical file. While related to EHRs and interoperability (that is, the ability of all necessary health care providers to be able to review and place a patient’s medical information into an electronic chart), the purpose of PHRs is to inform patients rather than to serve as the basis for treatment, which is the purpose of an EHR. This distinction is important in understanding the guidance that HHS recently provided.

The first scenario that HHS evaluates in its guidance is one that is becoming increasingly common:

A consumer downloads a health app to her smartphone. She populates it with her own information. For example, she inputs blood glucose levels and blood pressure readings that she obtained herself using home health equipment.

In this scenario, HHS concludes that the app developer is not a BA, and therefore HIPAA doesn’t apply, because the consumer is using the app to create a PHR, and the health care providers are not involved. This scenario is common in the personal health space, and likely applies to some of the health and fitness trackers on the market.

The second scenario is also a common one, but it has more of a connection to health care providers:

A consumer downloads a health app to her smartphone that is designed to help her manage a chronic condition. She downloads data from her doctor’s EHR through a patient portal, onto her computer and then uploads it into the app. She also adds her own information to the app.

Despite the connection to an EHR, HHS does not believe that the app developer is a BA within HIPAA, even though it is receiving PHI from a CE. In this case, the app developer was not hired by the CE to “provide or facilitate” the service; hence, it is not operating “on behalf of” the CE, and in essence the EHR information becomes a PHR once transmitted to the app.

The third scenario moves closer to the HIPAA line, but still does not cross it:

A doctor counsels a patient that his BMI is too high, and recommends a particular app that tracks diet, exercise, and weight. The patient downloads the app to his smartphone and uses it to send a summary report to his doctor before his next appointment.

Despite the transmission of medical information to a CE, and the doctor’s recommendation of the app, HHS does not believe this app developer is a BA. This is again due to the “on behalf of” language in the definition of a BA. In sum, the transmission of information to a CE, by itself, does not make the app developer a BA.

Interoperability is a key issue with EHRs, and at times entities will enter into Interoperability Agreements, as explained by HHS in the next scenario:

A consumer downloads a health app to her smartphone that is designed to help her manage a chronic condition. A health care provider and the app developer have entered into an interoperability arrangement at the consumer’s request that facilitates the secure exchange of consumer information between the provider EHR and the app. The consumer populates information on the app and directs the app to transmit the information to the provider’s EHR. The consumer is able to access test results from the provider through the app.

Despite the transmission of medical information to a CE, as well as an interoperability agreement, the app developer in this case is still not a BA because the agreement was initiated by the consumer. Therefore, even in this scenario, the transmission is not “on behalf of” a CE.

The next scenario presented by HHS moves past an agreement initiated by the consumer, and into a scenario that does trigger HIPAA, according to HHS:

At direction of her provider, a patient downloads a health app to her smartphone. The provider has contracted with app developer for patient management services, including remote patient health counseling, monitoring of patients’ food and exercise, patient messaging, EHR integration and application interfaces. Information that the patient inputs into the app is automatically incorporated into provider EHR.

The key factor for HHS in this scenario is that the provider contracted with the app developer for patient management services that involve creating, receiving, and transmitting PHI, and the app is part of those services.

Finally, HHS provided a scenario that is essentially a split or hybrid scenario:

A consumer downloads to her smartphone a mobile PHR app offered by her health plan that offers users in its network the ability to request, download and store health plan records and to check the status of claims and coverage decisions. The app also contains the plan’s wellness tools for members, so that they can track their progress in improving their health. The health plan analyzes health information and data about app usage to understand effectiveness of its health and wellness offerings. App developer also offers a separate, direct-to-consumer version of the app that consumers can use to store, manage, and organize their health records, to improve their health habits and to send health information to providers.

In this case, the portion of the app that is offered by the health plan triggers HIPAA and the developer is a BA, but this does not extend to the direct-to-consumer side of the business. If the app developer keeps the data separate, then, according to HHS, “the developer does not need to apply HIPAA protections to the consumer information obtained through the ‘direct-to-consumer’ app.” It appears that HHS is unofficially recognizing a hybrid designation for app developers, though the concept is, in actual terms, one more appropriately applied to CEs.

HHS offered a series of questions that app developers who are not CEs can ask to determine whether they are a BA:

HHS offered a series of questions that app developers who are not CEs can ask to determine if they are or are not a BA:

  • Does your health app create, receive, maintain, or transmit identifiable information?
  • Who are your clients? How are you funded?
    • Are your clients covered entities?
      • e.g., hospitals, doctor’s offices, clinics, pharmacies, or other health care providers who conduct electronic transactions;
      • health insurance issuers; health or wellness program related to a health plan offered by an employer
    • Were you hired by, or are you paid for your service or product by, a covered entity? Or another business contracted to a covered entity?
    • Does a covered entity (or a business associate acting on its behalf) direct you to create, receive, maintain or disclose information related to a patient or health plan member?

Even though an app developer may not be covered by HIPAA, HHS notes other existing guidance regarding apps, including direction from the Federal Trade Commission. This guidance, as well as any applicable laws, should be considered if HIPAA is not applicable.

As the IoT becomes more ubiquitous, novel apps will appear allowing us to gather and process more health information. App developers who wish to create health-related apps should factor this guidance in early so that they can understand the rules of the road and determine whether HIPAA applies.

The HHS guidance can be found here.

A Negative Review May Be Protected Activity Under U.S. Employment Law

Posted in Employment Law, Labor Law

Yelp, Inc. is more accustomed to being on the giving—rather than the receiving—end of a negative review. That changed recently when a Yelp customer service employee, Talia Ben-Ora, posted an open letter to Yelp’s CEO on her blog, lamenting her daily struggle to survive in the Bay Area on low pay. Ben-Ora spent much of the letter discussing wages, benefits, and the financial challenges faced by her co-workers:

Every single one of my co-workers is struggling. They’re taking side jobs, they’re living at home.… Another wrote on those neat whiteboards we’ve got on every floor begging for help because he was bound to be homeless in two weeks…. Let’s talk about those benefits, though. They’re great. Except the copays.… Twenty bucks each is pretty neat, if spending twenty dollars didn’t determine whether or not you could afford to get to work the next week.

I got paid yesterday ($733.24, bi-weekly) but I have to save as much of that as possible to pay my rent ($1245) for my apartment that’s 30 miles away from work because it was the cheapest place I could find that had access to the train, which costs me $5.65 one way to get to work. That’s $11.30 a day, by the way. I make $8.15 an hour after taxes…. I woke up today with stomach pains. I made myself a bowl of rice.

…As I said, I spend 80% [of my income on rent]. What do you spend 80% of your income on? I hear your net worth is somewhere between $111 million and $222 million. That’s a whole lotta rice.

Shortly after Ben-Ora posted the letter, Yelp terminated her employment. Yelp’s CEO stated that her termination was not related to the letter, but Ben-Ora’s post has the online world buzzing and Yelp is not receiving positive reviews.

There may be many valid reasons for terminating an employee. Employers should note, however, that the National Relations Labor Board has become increasingly aggressive in protecting an employee’s right to discuss wages and working conditions in a public forum, even when that discussion involves disparaging the employer. Under Section 7 of the National Labor Relations Act (NLRA), protesting an employer’s labor policies or treatment of employees is considered protected activity, and this protection extends to non-unionized employees as well. While there appear to be no reports of legal claims by Ben-Ora, commentators have raised the question of whether this type of posting might be legally protected under the NLRA.

The Ben-Ora incident is therefore a reminder of the risks employers may face—both legally and from a public relations perspective—in terminating an employee who has recently protested wages on social media.

Privacy Shield vs. Safe Harbor: A Different Name for an Improved Agreement?

Posted in Big Data, Data Security, European Union, Privacy

The European Commission (the “Commission”) and the U.S. Department of Commerce issued the draft legal texts for the much anticipated EU-U.S. Privacy Shield (the “Shield”), set to replace the currently inoperative Safe Harbor program (“Safe Harbor”). The new agreement is aimed at restoring the trust of individuals in the transatlantic partnership and the digital economy, and putting an end to months of compliance concerns of U.S. and EU companies alike. The draft will be discussed with EU data protection authorities (“DPAs”) and adopted by Member States representatives before it becomes binding.

The publication of the Shield documents, on February 29, 2015, came at a time of high expectations and a certain tension. Last October, the European Court of Justice (the “ECJ”) invalidated the Commission’s decision 2000/520/EC and effectively shut down the Safe Harbor framework, which until then allowed thousands of European companies to send personal information to U.S. companies that had committed to protecting personal information.   As a result, thousands of U.S. and EU companies were suddenly left in a legal limbo.  In response to the risk of enforcement against companies relying on Safe Harbor, and to address the concerns raised by EU DPAs, the Commission announced in early February that a new political agreement had indeed been reached with the U.S. government. It also made good on its promise to make the details of the agreement public by month’s end.

At first glance, the Shield bears a strong resemblance to Safe Harbor, which misled some commentators to denounce it as a mere duplicate in disguise.  However, the Shield introduces substantial changes for data protection, including additional rights for EU individuals, stricter compliance requirements for U.S. organizations, and further limitations on government access to personal data. From the perspective of U.S. companies, it appears that the Shield may actually signify a shift to heavily monitored compliance. In this sense, the question may no longer be “How good is the Privacy Shield for privacy?” but rather “How burdensome will it become for businesses?”

This alert takes a closer look at the Shield and highlights some of the key differences from the Safe Harbor and other available data transfer mechanisms.

Some of the key takeaways include:

  • Safeguards related to intelligence activities will extend to all data transferred to the U.S., regardless of the transfer mechanism used.
  • The Shield’s dispute resolution framework provides multiple avenues for individuals to lodge complaints, more than those available under the Safe Harbor and alternative transfer mechanisms such as Standard Contractual Clauses or Binding Corporate Rules.
  • An organization’s compliance with the Privacy Shield will be directly and indirectly monitored by a wider array of authorities in the U.S. and the EU, possibly increasing regulatory risks and compliance costs for participating organizations.
  • The Department of Commerce will significantly expand its role in monitoring and supervising compliance, including by carrying out ex officio compliance reviews and investigations of participating organizations.
  • Participating organizations will be subjected to additional compliance and reporting obligations, some of which will continue even after they withdraw from the Privacy Shield.

Overview

The Commission made public all the documents that will constitute the new agreement, namely: a draft Adequacy Decision, FAQs, a Factsheet, Annexes detailing the principles and various compliance mechanisms, and a Commission Communication describing the current developments in the broader context of transatlantic discussions of the past few years.

In its press release, the Commission stated that the Shield “reflects the requirements” set by the ECJ in its ruling from October 6, 2015 (the “Schrems ruling”). As a reminder, key concerns of the Schrems ruling included: (1) the indiscriminate and excessive government access to EU citizens’ personal information, and (2) the lack of judicial redress mechanisms for EU citizens for privacy related complaints.

According to the Commission, the Shield will provide for “strong obligations on US companies” as well as “robust enforcement” mechanisms to ensure that such obligations are complied with. It will lay down “clear safeguards and transparency obligations on US government access.” Thirdly, it will ensure effective redress of EU Citizens’ rights by means of “several redress possibilities.” Finally, an annual joint review mechanism will allow the Commission, the U.S. Department of Commerce, and the European DPAs to monitor how well the Shield functions. Continue Reading

Now Available: The March Issue of Our Socially Aware Newsletter

Posted in Advertising, Compliance, Copyright, Discovery, E-Commerce, Endorsement Guides, Eurpoean Union, FTC, Terms of Use

03_01_Mar_SociallyAware_COVER1aThe latest issue of our Socially Aware newsletter is now available here.

In this issue of Socially Aware, our Burton Award-winning guide to the law and business of social media. In this edition, we offer tips for a successful—and legal—advertising campaign; we examine a New York State Appellate Division opinion significantly limiting a personal-injury-case defendant’s access to the plaintiff’s social media posts; we review a court decision highlighting potential risks for companies seeking to exploit works licensed under the Creative Commons regime for commercial use; we take a look at an FTC report intended to help companies minimize the legal and ethical risks associated with their use of big data; we consider the complications that a federal district court opinion may create for companies hosting user-generated content; we explore the FTC’s guidance for businesses that publish advertising that could be confused with editorial content; we discuss seven key things to consider when drafting the terms and conditions for a mobile app in Europe; and we describe the key provisions of the European Commission’s proposed directives concerning a business’s online sale of goods or digital content to consumers.

All this—plus an infographic illustrating the state of the U.S. online music industry.

Read our newsletter.

Employer Surveillance of Internet and Email Use in the Workplace in Germany

Posted in Data Security, Employment Law, Privacy

iStock_000058091672_MediumIs an employer allowed to access an employee’s email account when the employee is on sick leave? To what extent is control permissible when an employee is suspected of illegal activities, e.g., of leaking trade secrets? In Germany, these questions are at the crossroads of data privacy and telecommunications law with their respective administrative and even criminal sanctions. The proper rules and best practice examples have been recapped in a guideline (the “Guideline”) issued in January 2016 by the Conference of Data Protection Authorities of the Federation and of the States in Germany (“DPA Conference”).

Private use excluded, employers may dispense with employee consent

To the extent that private email and Internet use is banned or restricted by the employer, only data privacy law applies.  Thus, concerns relating to the Telecommunications Act, employment law, or the Telemedia Act are not applicable if all private use is prohibited. Internet protocol data may be accessed without prior consent, e.g., in order to verify compliance with the restrictions on private use or to protect the network. However, access even to IP addresses should take into account the proportionality principle. According to the Guideline, the employer should, as a first step, evaluate Internet protocol data on an anonymous basis, followed by individual spot tests where necessary.

With regard to emails, the employer is not required to obtain the employee’s consent and may review the content of professional emails relevant to a specific business transaction or as pre‑defined by other specific categories. A constant review of all professional emails is not permissible. Consequently, for employees on leave, out of office messages are the method of choice to inform recipients that the individual may not respond (rather than having someone else check the emails). Alternatively, it is permissible to completely reroute emails if the demands of the workplace require such a solution. Full surveillance of an employee’s online activity is generally prohibited, unless there is a reasonable basis for believing that the employee’s use of the IT services violates the law and the proposed measures are proportional.

Private use of workplace IT triggers telecommunication secrecy consent requirement

Employers should carefully consider whether they wish to permit private use of their workplace IT systems or whether such use should be limited or banned altogether. To the extent that private use is permitted, the DPAs view employers as telecommunication service providers who are bound by the stringent rules of telecommunication secrecy. The chance that the employee’s inbox contains private emails (when private use is allowed) will prevent the employer from accessing the professional account altogether, unless such access is permitted by the employee on a case-by-case basis. Accordingly, to the extent that employees are entitled to use the Internet for private purposes, the employer is prohibited from reviewing the employee’s Internet usage (i.e., who accessed which website at what time and for how long). In contrast, where private use by employees is prohibited, the employer may review such Internet usage without prior consent of the employee.

While a number of lower courts disagree with the DPAs’ view, the question has not yet been decided by a German Federal Court, and employers should follow the DPAs’ interpretation. In practice, sanctions are limited to fines; however, in theory, improper access to private email or to an employee’s private use of the Internet could result in criminal liability.

Permission for private use may be construed where employers fail to sanction private use

The DPA Conference points out that failure to lay down the rules of use will often amount to permission for private use. The same is true for a ban of private use that is not effectively monitored and sanctioned. If an employer tolerates private use for a significant period of time, this conduct may give rise to an (unwritten) company practice, binding the employer for the future. As a consequence, the DPA Conference prompts employers to lay out the rules of workplace use of the IT services in writing, either in the employment contract, a corporate guideline, or, where a works council is established, in a works agreement. The employer may subject permission to specific conditions, e.g., limitations in time, rules of conduct, and general rules limiting the employer’s access to employee emails or Internet data.

Consent is valid only where it is genuinely free

The Guideline does not elaborate on the conditions of consent by the employee. On the European level, the Working Party 29 (WP 29) recognizes consent in the employment context to the extent that it is genuinely free (see Opinion 15/2011 on the definition of consent, dated July 13, 2011, p. 13). Notably, the WP 29 considers consent invalid where it is a condition of employment, such as consent required in the employment contract. Where it is provided in an ongoing employment relationship, consent is valid unless “it is not possible for the worker to refuse.” This conforms to a decision by the Federal Labor Court of December 11, 2014 (docket no. 8 AZR 1010/13, juris). In this decision, the Court held that employee consent provided in an ongoing employment relationship is valid unless concrete evidence indicates pressure or coercion or otherwise a lack of choice.

New Guideline dispenses with requirement of consent by third‑party communication partners

For access to an employee’s email account, the DPAs have, in the past, also required the thirdparty’s consent, i.e., the consent of the sender of an email to the employee. Interestingly, the DPA Conference has now confirmed in its Guideline that employers may dispense with consent of the third‑party sender or recipient, which is naturally hard to obtain in practice. When access to emails is required by the course of business, the DPA Conference states that the employer can rely solely on the employee’s consent.