TECHNOLOGY, OUTSOURCING, AND COMMERCIAL TRANSACTIONS
NEWS FOR LAWYERS AND SOURCING PROFESSIONALS

Does your website or application collect user data? Does your company sell that user data to other third parties, such as advertisers? Does your company disclose this practice to your users in a privacy policy or terms or use? If you answered yes to these questions, you are most certainly not alone. But is your disclosure sufficient? That is the question a new challenge is poised to answer.

As 2018 comes to a close, we have once again compiled all the links to our Contract Corner blog posts, a regular feature of Tech & Sourcing @ Morgan Lewis. In these posts, members of our global technology, outsourcing, and commercial transactions practice highlight particular contract provisions, review the issues, and propose negotiating and drafting tips. If you don’t see a topic you are interested in below, please let us know, and we may feature it in a future Contract Corner.

In Part 1 of this series, we provided an overview of data (or knowledge) commons and some key issues to consider, but how does one actually create and manage a data commons? To find your feet in this budding field, build on the theoretical foundation; address the specific context (including perceived objectives and constraints); deal with the thorny issues (including control and change); establish a core set of principles and rules; and, perhaps most importantly, plan for and enable change.

Although the EU’s General Data Protection Regulation (GDPR) has been in force for more than six months, many organizations are still getting to grips with some of the practical requirements, including ensuring that their contracts comply with Article 28, which mandates a number of key clauses if personal data is being processed under the service agreement.

With potentially hundreds of in-scope contracts, customers and suppliers alike have developed standard-form data processing addendums (DPAs) or similar contract documents in order to address these Article 28 requirements. DPAs are fast becoming the preferred approach for both new agreements and existing contracts.

You may have heard of the “tragedy of the commons,” where a resource is depleted through collective action, but knowledge is different from other resources—knowledge can be duplicated, aggregated, integrated, analyzed, stored, shared, and disseminated in countless ways. Given that knowledge is a critical resource for seemingly intractable problems, the opportunity of the commons (or the tragedy of the lack of commons) is worth thoughtful consideration.

Imagine that you or a loved one is suffering from a terminal or debilitating disease and that data and knowledge are out there, waiting to be combined and harnessed for a cure or a transformational treatment. Imagine that self-interest (including attribution), legal restrictions (including intellectual property protections), inertia, complexity and difficulty of collective action, and other weighty forces are between you and that breakthrough discovery. Though not a new concept, commons have been garnering attention lately as an alternative framework for catalyzing groundbreaking research and development, particularly when relevant data and knowledge are scattered and particularly in the life sciences community. But before we all throw away our patents and data-dump our trade secrets, there are some thorny aspects to governing a data (or knowledge) commons. For example:

  • A commons is essentially its own society. Anyone who has been part of a homeowners’ association knows that collective governance is almost always muddy. Aligning incentives, objectives, and values can be challenging.
  • Founders may have trouble relinquishing control or enabling change. Participants may become confused or upset if rules or priorities change.
  • Commons are not as well understood and tested. They must coexist with, and within, other systems that may be more rigid and rules-based. Participants may be logistically, intellectually, and otherwise tied to traditional methods and may prefer semi-exclusive zones rather than open collaboration.
  • It may be difficult to measure the effectiveness or value of commons.
  • Policing activities (e.g., authentications or restrictions) may be burdensome. And once the cat is out of the bag, it’s difficult to undo uses or disclosures.
  • Commons managers may not be willing to take on certain responsibilities or liabilities that would make participants more comfortable.
  • Different types of information and tools have different levels of sensitivity and protection. Certain information, like personal data, is highly regulated.

Scholars have taken theoretical frameworks built for natural resources and adapted them to the data commons setting. Key findings include that data commons must be designed to evolve and that communities with high levels of shared trust and values are most likely to succeed. Whereas governance through exclusivity (e.g., patents) is useful when trust levels are low, a resource sharing governance model (e.g., commons) can be effective when trust levels are high.

If you’d like to know more:

  • We will be hosting a webinar with one of the aforementioned scholars—Professor Michael J. Madison, faculty director at PittLaw—on Tuesday, December 18, 2018, from 12:00 pm to 1:00 pm ET. Register and join us for the discussion.
  • In a subsequent post, we will provide some tips and considerations with respect to drafting policies, standard terms, data contribution agreements, and other governing documents for data commons.

Knowledge sharing has long been an important element of academic research. And now collective sharing and governance of data assets throughout the scientific community, including for-profit participants, is gaining momentum. During their webinar, Out in the Open: The Knowledge Commons Framework, Emily Lowe, Ben Klaber, and Professor Michael J. Madison, faculty director at PittLaw, will discuss issues related to knowledge commons. Topics will include the following:

  • A fundamental overview of knowledge commons, including the framework’s strengths and weaknesses
  • Standard requirements regarding data contribution, access, use, sharing, protection, and attribution
  • How to decide if a knowledge commons framework is right for your business, and if so, how to implement it successfully

Drafting and negotiating the data protection provisions in services agreements can be one of the trickier and more time-consuming aspects of the contracting process. One of our prior Contract Corner series from 2014 discussed the importance of documenting security requirements and monitoring security commitments, addressing security incidents, and key issues to consider when drafting liability provisions. In this Contract Corner, we revisit some of these issues based on the latest contracting trends that we are seeing for services agreements and dive into additional considerations when addressing key data safeguard provisions.

Assess and Define the Data

At the outset of the contracting process, it is important for the deal team and the key stakeholders to evaluate and properly define the types of data that the service provider will access or process as part of the services. A sound understanding of the scope of data involved in a services transaction helps establish expectations up front and will drive a contract that contains the right level of security requirements and an appropriate allocation of liability for security breaches. The contract should then reflect the output of this internal assessment through carefully crafted defined terms that will flow throughout the data safeguard provisions.

The California Consumer Privacy Act (CCPA) was signed into law this summer, as described in our prior post and this LawFlash. The CCPA creates a variety of new consumer privacy rights and will require many companies to reassess and modify their business processes in the collection and use of personal information. This comprehensive new privacy law, similar in some ways to the EU’s General Data Protection Regulation (GDPR), will therefore require many organizations doing business in California to implement new policies and procedures to be in compliance by the January 1, 2020, deadline.

The landmark CCPA is also a work in progress. To help guide companies and institutions through the challenges presented by the CCPA, Morgan Lewis has set up a CCPA resource center that will be continuously updated with content as new developments arise.

One such development is a recent set of amendments passed by the California Legislature. To help explain the current state of the CCPA, the recent amendments, and issues that remain to be debated and clarified, our colleagues Reece Hirsch, Mark Krotoski, and Carla Oakley will be hosting a webinar on October 16 at 1:00–2:00 pm ET.

We hope you register for this webinar and visit the CCPA resource center to stay up to date on important developments in this new regulatory environment.

Authored by Barbara Murphy Melby, Christopher C. Archer, and Jay Preston

In Part 1 of this Contract Corner on Software as a Service (SaaS) agreements, we discussed ownership and use issues in SaaS transactions where the application is provided and hosted as a dedicated instance with common base software (sometimes with customization or variation) but running as a separate instance in a dedicated environment.

In this Part 2, we will look at ownership and use issues in transactions where the application is provided and hosted in a multitenant environment, with one common application layer and hosting environment that is logically partitioned by customer.

As noted in Part 1, when thinking about ownership and other intellectual rights in SaaS deals, we generally consider the following categories, discussed in more detail below. As with any solution there can be variations and customer-specific needs that drive different requirements.

Authored by Barbara Murphy Melby, Christopher C. Archer, and Jay Preston

In the typical SaaS scenario, the SaaS vendor provides, maintains, and hosts (either itself or through a hosting SaaS vendor) the desired application layer, and grants the customer and its authorized users access to the application functionality via the internet. At a high level, there are two variations of this scenario:

  • The application is provided and hosted as a dedicated instance, with common base software (sometimes with customization or variation) but running as a separate instance in a dedicated environment.
  • The application is provided and hosted in a multitenant environment, with one common application layer and hosting environment that is logically partitioned by the customer.

In this Contract Corner series, we will look at ownership issues in SaaS solutions in two parts, with different perspectives based on whether the solution utilizes a dedicated instance (Part 1) or a multitenant environment (Part 2).