BOOK VIRTUAL CONSULTATION
- Flat Fee, Project-Based Rate Options
- Flat Fee, Bundled Project Rate Options
- Annual, Project-Based Subscription Options
- Annual Hourly-Based Subscriptions Options
FRACTIONAL GENERAL COUNSEL SERVICES
DIGITAL BUSINESS CARD
INTRODUCTION TO BLOG
- October 2022
- May 2022
- April 2022
- February 2022
- November 2021
- October 2021
- December 2020
- November 2020
- June 2020
- April 2020
- March 2020
- February 2020
- January 2020
- December 2019
- November 2019
- October 2019
- August 2019
- July 2019
- June 2019
- May 2019
- March 2019
- February 2019
- January 2019
- December 2018
- November 2018
- October 2018
- September 2018
- August 2018
- June 2018
- May 2018
- April 2018
- March 2018
- December 2017
- October 2017
- August 2017
- June 2017
- May 2017
- April 2017
- March 2017
- December 2016
- November 2016
- September 2016
- May 2016
- April 2016
- March 2016
- January 2016
- December 2015
- October 2015
- September 2015
- July 2015
- May 2015
- March 2015
- February 2015
- January 2015
- September 2014
- October 2012
- August 2012
- February 2012
- January 2012
- July 2011
- Talk with an Expert Series: Beau Fernald Shares Software Implementation Best Practices
- The Prinz Law Office Adopts New Fixed & Subscription Billing Options
- FTC Announces Settlement with Twitter Over Deceptive Use of Account Security Data
- Arbitration vs. Litigation: Which is Better for a SaaS Contract?
- Introduction to Silicon Valley Software Law Blog
- Introductory Digital Health Contracts Workshop for Lawyers
- Introduction to Software Contracts Workshop for Lawyers
- Intro to Digital Health Contracts for Non-Lawyers
- Intro to Software Contracts for Non-Lawyers
- Introduction to Negotiating and Drafting SaaS Contracts
- SaaS Lawyer Kristie Prinz to Present on Negotiating Digital Health Contracts
- Can software be subject to FDA regulation?
- Silicon Valley SaaS Lawyer Kristie Prinz’s Webinar on “Best Practices for Drafting and Negotiating SaaS Contracts” Now Available
- Silicon Valley SaaS Lawyer Kristie Prinz to Speak on “Best Practices for Drafting & Negotiating SaaS Contracts”
- Why “SaaS Agreements” are not “SaaS Licenses”
- Negotiating Consulting Services Agreements in an Uncertain Economy
- Introduction to Negotiating & Drafting SaaS Agreements
- Best Practices for Negotiating SaaS Agreements in an Uncertain Economy
- Silicon Valley Software Law Blog’s Kristie Prinz to Present Webinar on “Introduction to Negotiating & Drafting SaaS Agreements”
- Silicon Valley Software Law Blog’s Kristie Prinz to Present Webinar on “Best Practices for Negotiating SaaS Agreements in an Uncertain Economy”
- Secrets to Developing a Blog that Effectively Markets Your Law Practice
- Best Practices for Negotiating SaaS Agreements in an Uncertain Economy
- The Intersection of Technology and Legal Practice: Addressing Current Technology Issues without Allowing Them to Overwhelm Your Practice
- Best Practices for Negotiating Development Agreements in an Uncertain Economy
- Accessing Coronavirus Disaster Aid to Sustain Your Software Company Through the Crisis
- Best Practices for Negotiating Master Services Agreements in an Uncertain Economy
- Best Practices for Negotiating SaaS Contracts & Managing SaaS Customer Relationships
- Force Majeure and the Coronavirus Pandemic: What Does Your Software Company Need to Know?
- Practice Tips for Renegotiating Contracts due to Coronavirus Uncertainty and Changed Business Conditions
- Capitalizing on SaaS Sales Opportunities During the Coronavirus Crisis Without Creating New Legal Risks
- Silicon Valley Software Law Blog’s Kristie Prinz to Present Series of Webinars On Negotiating in Uncertain Times
- Silicon Valley Software Law Blog’s Kristie Prinz to Present on “The Intersection of Law & Technology: Addressing Current Technology Issues without allowing them to Overwhelm Your Practice”
- Silicon Valley Software Law Blog’s Kristie Prinz to Present on “Negotiating SaaS Contracts & Managing Customer Relationships”
- Silicon Valley Software Law Blog’s Kristie Prinz to Speak on “Negotiating SaaS Agreements” for Clear Law Institute
- The Prinz Law Office Announces New Alternative Billing Options for 2020
- Last Minute Tips for Procrastinators: What Your Company Needs to Know about the January 1, 2020 Effective Date of the California Consumer Privacy Act (“CCPA”)
- Legal Developments Impacting the Software Industry 2019
- California Passes New Data Broker Law In Anticipation of January 1, 2020 Effective Date of California Consumer Privacy Act (“CCPA”)
- Silicon Valley Software Law Blog Author Kristie Prinz to Present Upcoming Webinar on “Legal Developments Impacting the Software Industry 2019”
- California Finalizes California Consumer Privacy Act (“CCPA”) In Anticipation of January 1st, 2020 Effective Date
- Best Practices for Negotiating SaaS Contracts & Managing SaaS Customer Relationships
- Silicon Valley Software Blog Law’s Kristie Prinz to Present Webinar on “Best Practices for Negotiating SaaS Contracts”
- Is a Company Liable for Software Defects, when a Vulnerability is Discovered but Not Exploited? A Recent Cisco Settlement Suggests Liability May Be Assessed
- Can Your Company Be Sued Over a Software Update? Tesla Suit Signals New Trend in Class Action Suits
- Private Coalition of Health Insurers and Major Tech Companies Announce New Standard for Claims Data Sharing
- Software Industry Concerned About the Potential Impact of AB-5 on Gig Economy
- Facebook Agrees to Record $5 Billion Settlement with FTC on Privacy Practices
- Should Law Enforcement Agencies’ Use of Facial Recognition Software Be Subject to Regulation?
- Silicon Valley Software Law Blog’s Kristie Prinz to Speak on Upcoming Webinar on SaaS Contracts
- Silicon Valley Software Law Blog’s Kristie Prinz to Present Upcoming Webinar on Software Hosting Agreements
- FTC Puts Software Companies and Service Providers on Notice of Broad Enforcement Powers Under Gramm-Leach-Bliley Act Safeguards Rule
- FTC Sends Warning to IoT Companies on the Importance of Secure Software Development with Enforcement Action Against D-Link
- Developers File Suit Against Apple for App Store Practices Following Recent Decision by U.S. Supreme Court
- Supreme Court Rules Against Apple in Antitrust Case to Determine if App Store is Monopoly
- The Prinz Law Office Announces Opening of New San Francisco Office
- Best Practices for Drafting Master Service Agreements & Managing the Service Relationship
- Best Practices for Drafting Master Service Agreements & Managing the Service Relationship
- Silicon Valley Software Law Blog’s Kristie Prinz to Speak on “Best Practices for Drafting Master Service Agreements & Managing the Service Relationship”
- Silicon Valley Software Law’s Kristie Prinz to Speak on “Best Practices for Drafting SaaS Contracts & Managing SaaS Customer Relationships”
- The Prinz Law Office Opens New Palo Alto Office
- The Anticipated Impact of The Foreign Investment Risk Review Modernization Act of 2018 (“FIRRMA”) on the Software Industry
- Software Industry Warns of Fallout from Australia’s Passage of New Anti-Encryption Legislation
- Silicon Valley Software Law Blog’s Kristie Prinz to Speak on “Negotiating SaaS Contracts” for Clear Law Institute
- Recent FTC Enforcement Action Should Serve as Warning to Other Software Companies Claiming Privacy Shield Compliance
- Are “Unethical” App Subscription Practices Ruining the App Store?
- California Agrees to Delay Enforcement of Net Neutrality Law
- Why Software Companies Need to Anticipate Insurance Requirements Before Commencing Negotiations on Significant Deals
- California Governor Signs Net Neutrality Law; Department of Justice Responds with Suit to Block Law
- Why Big Development Projects Can Equal Big Legal Headaches without Well-Drafted Agreements
- Silicon Valley Software Law Blog Sponsor Announces New “Subscription Model” Option for Legal Clients
- Top Mistakes Made in Software Deals without the Representation of Experienced Software Counsel
- Technology and Telecommunication Companies Lobby Congress to Adopt Federal Privacy Bill to Pre-empt California Data Privacy Law
- Silicon Valley Software Law Blog’s Kristie Prinz to Present Webinar on “Negotiating SaaS Agreements: Drafting Key Contract Provisions, Protecting Customer and Vendor Interests”
- What SaaS Companies Need to Know About Source Code Escrow Agreements
- In Aftermath of GDPR, California Passes Consumer Privacy Act of 2018
- California Supreme Court Strikes Blow to Software Industry Reliance on Gig Workers
- California to Consider Bill that Restores Net Neutrality
- Irish Court Has Referred Case to European Court Which Challenges Privacy Shield: Will the EU-U.S. Privacy Shield Framework Withstand Scrutiny by the European High Court?
I am excited to announce that my firm is adopting a number of new options for working with our clients. We received feedback asking for new fixed rate and subscription packages for specific business scenarios, and in response to that feedback we have designed a variety of new packages designed around those requests. These options now can be viewed online at The Prinz Law Office’s Fixed Rate & Subscription Packages. Existing clients who are working with us already under another billing arrangement will be able to switch to a new plan at any time upon request. I am confident that these new options will address new business needs of the technology and life sciences communities we serve. If you have an idea for a billing arrangement that the firm has not yet developed, we invite you to submit your ideas for consideration at email@example.com.
The Federal and Trade Commission (“FTC”) announced today a settlement with Twitter, Inc. (“Twitter”) in which Twitter agreed to pay $150 million for its alleged misuse of user account security data, specifically email addresses and phone numbers, for advertising purposes. The government alleged that the misuse of account data was in violation of a 2011 FTC Order against Twitter, which prohibited the company from misrepresenting the extent to which it maintains and protects the security, privacy, confidentiality, or integrity of any nonpublic consumer information. The government alleged that the misuse of consumer data also violated the EU-US Privacy Shield, and the Swiss-U.S. Privacy Shield.
In addition to the paying a $150 million fine, the government announced that Twitter has agreed to the following:
- Twitter will not profit from deceptively collected data;
- Users will have other options to multi-factor authentication such as apps or security keys that do not require the provision of phone numbers;
- Notify all users that Twitter misused the phone numbers and emails collected for targeted advertising and to provide users with information about Twitter’s privacy and security controls;
- Implement and maintain a comprehensive privacy and information security program which requires an assessment of the potential privacy and security requirements of new products;
- Limit employee access to users’ personal data; and
- Notify the FTC if it experiences a data breach.
With this enforcement action against Twitter, the FTC is clearly making a statement to companies in the business of collecting consumer data that they need to truthfully disclose the purposes for which data used for advertising purposes is collected, and that failure to disclose this information will have potential federal regulatory consequences. SaaS and software companies should take note of this particular enforcement action, and ensure that they avoid engaging in the same practices that were the subject of this enforcement action.
I was recently asked by a client whether arbitration or litigation in a contract was better. The issue had been raised by an attorney on the other side of the contract, who had not only tried to persuade my client to revise the specific clause in that case, but had also provided my client the unsolicited advice that “he should prefer litigation over arbitration” in all cases.
My client, who had elected to include an arbitration clause in his standard terms, was unsure what to do and how to respond, and so he reached out to me for guidance.
While the debate over whether arbitration or litigation is better for a particular organization is not a dilemma specific to the software industry, it is one that clients often raise with me in frustration, hoping that I can advise them that one option is definitively “better” than the other. The answer, like many things in the law, is not so black and white, and it should not be decided without considering the pros and cons of each option.
First of all, let’s assume you have no arbitration clause in your contract and a dispute arises, then the only contractually available forum to hear the dispute will be a courtroom. If your company does not have an in-house legal department with litigators on staff, then you will need to hire a litigation support to handle the litigation process, either from the plaintiff side or the defense side. You will incur costs every time a motion is filed or defended, and you will incur costs for discovery, depositions, mediation, and the trial preparation, all until the case is either settled or a judgment is reached. This process could take years to go through.
On the other hand, let’s assume you have an arbitration clause in your contract and a dispute arises, then the contractually available forum to hear the dispute will be a courtroom. However, your opponent may not want to arbitrate the case, and so your opponent may file in court first, in which case you will have to file to compel the case to arbitration. Alternatively, your opponent may be unwilling to participate in the arbitration, so you may have to file a motion to compel your opponent participate in the arbitration. Once you win any motion in court, you will then have to initiate the arbitration with the private organization that will handle the arbitration, which will generally be AAA or JAMS in the US, but there are other organizations that handle commercial arbitration internationally. This will require you to pay the filing fees, which are often far higher than is required to initiate a case in a court. Once the case is initiated an arbitrator will be appointed to hear the case, and the parties will decide on the format for the case, and the case will proceed outside of court within the private dispute resolution process of the organization selected.
What are the advantages? Well, arbitration is intended to be a commercial process rather than a legal process, so it is much less formal. It also can be faster, as there is no judicial backlog to slow down the process. There are fewer rules governing the process, so it often viewed as less predictable. But fewer rules also means that the process is more easily managed by business-people who are not litigators. The goal of arbitration is generally to get to a rendered decision as quickly as possible, which may be advantageous.
In contrast, the court option is very formal. It can be slow, which may be a negative in some situations and a positive in other situations. And it is governed by rules and precedent, which will require knowledge and familiarity with both to proceed through. Most litigated cases settled, so the goal of litigation may not be to get to a judgment. Instead, the goal may actually be to get to a settlement.
Is one option necessarily cheaper than the other? Arbitration is generally perceived in the business world to be cheaper, due to the faster process and the relaxed rules, but because the process is a private commercial process, the fees for the administration of the case can be higher in some situations and it is still possible to incur legal fees during the process. In contrast, discovery, depositions, and motion hearings can drive up the cost of a litigation process, both in terms of legal hours billed but also in terms of other costs.
It is important to recognize that getting an arbitration award may not actually be better than a mediated settlement to the party owed an award, since a voluntary settlement may be easier to enforce than a decision. On the other hand, the process is private and stays completely confidential and outside of court records, which may be preferred by both parties, and the informality may be less stressful on both sides of the dispute.
In the end, the choice between arbitration vs. litigation is one of personal or commercial preference. You have to expect that a commercial litigator who spends his career in the courtroom is going to prefer to stay as far away from arbitration as possible. In contrast, transactional lawyers are generally going to prefer to stay as far away from litigation as possible.
I generally recommend to clients that they should contemplate the type of dispute that would arise from a particular set of contract terms before deciding how they prefer to resolve that dispute. For example, if a dispute arises, would an informal private solution to resolving the dispute be better than the formality of litigation? Will the other side have significantly more resources to apply towards the dispute? Would the other side benefit from delaying the resolution of the dispute and causing you to invest significant resources in the process? What will be the anticipated filing fees for each side in the dispute?
All in all, arbitration vs. litigation is not a decision that should be made without some careful consideration of the underlying issues and the consequences of each decision. There are valid reasons why parties gravitate to one option or the other. It is up to your business to decide what should be your organization’s preferred standard with respect to a particular type of contract, and whether or not you will be willing to concede your position upon request by a particular client. You may realize that your preferred position is going to be the same in every case, or alternatively, that your position may require review on a scenario by scenario basis.
If you work in the software industry, you may be surprised to discover that digital health software products may be subject to regulation by the Food and Drug Administration (“FDA”). Some software is considered a software as a medical device (“SaMD”) product or software in a medical device (“SiMD”) product.
So, how do you know whether or not a software product you are building is going to be considered a SaMD or SiMD product?
The FDA issued a “Policy for Low Risk Devices” on September 27, 2019, which provides general nonbinding recommendations to clarify its policy on health software that has been deemed not to be a device under Section 201(h) of the FD&C Act. In this policy, the FDA specifically stated that software intended “for maintaining or encouraging a healthy lifestyle and is unrelated to the diagnosis, cure, mitigation, prevention, or treatment of a disease of condition” does not constitute a “device” under section 201(h) of the FD & C Act. According to the FDA policy, general wellness products will not be examined to determine if they are devices and comply with the regulatory requirements for devices. The FDA further defines general wellness products to include products meeting the following requirements: (1) they are intended for only general wellness use as defined in the guidance and (2) they present a low risk to the safety of users and other persons.
In the Policy for Low Risk Devices, the FDA states that a “general wellness product” has the following:
(1) an intended use that relates to maintaining or encouraging a general state of health or healthy activity, or
(2) an intended use that related the role of healthy lifestyle with helping to reduce the risk or impact of certain chronic diseases or conditions and where it is well understood and accepted that healthy lifestyle choices may play an important role in health outcomes for the disease or condition.
The FDA then provides examples of the specific types of uses that would fall under each category.
The FDA also states the test for assessing the degree of risk for general wellness products:
(1) Is the product invasive?
(2) Is the product implanted?
(3) Does the product involve an intervention or technology that may pose a risk to the safety of users and other persons if specific regulatory controls are not applied, such as risks from lasers or radiation exposure?
If all of the above answers are “no,” then the product is deemed to be low risk and not subject to FDA regulation.
The FDA also issued a “Policy for Device Software Functions and Mobile Medical Applications” on September 27, 2019, which provided nonbinding recommendations for regulation software applications intended for use on mobile platforms or on general purposes computing platforms.
In the “Policy for Device Software Functions and Mobile Medical Applications” the FDA clarified that it intended to focus its regulatory oversight to “only those software functions that are medical devices and whose functionality could pose a risk to a patient’s safety if the device were to not function as intended.” The FDA listed three categories of software functions that would be subject to this regulatory oversight focus:
(1) Software functions that are an extension of one or more medical devices by connecting to such device(s) for purposes of controlling the device(s) or analyzing medical device data.
(2) Software functions (typically, mobile apps) that transform the mobile platform into a regulated medical device by using attachments, display screens, or sensors, or by including functionalities similar to those of currently regulated medical devices.
(3) Software functions that become a regulated medical device by performing patient-specific analysis and providing patient-specific diagnosis, or treatment recommendations.
The FDA also clarified that it intended to exercise enforcement discretion for software functions that “help patients. . . . self-manage their disease or conditions without providing specific treatment or treatment suggestions” or “automate simple tasks for health care providers.” The FDA listed four categories of software functions that would be subject to this regulatory enforcement discretion:
(1) Software functions that provide or facilitate supplemental clinical care, by coaching or prompting, to help patients manage their health in their daily environment.
(2) Software functions that provide easy access to information related to patient’s health conditions or treatments.
(3) Software functions that are specifically marketed to help patients communicate with healthcare providers by supplementing or augmenting the data or information by capturing an image for patients to convey to their healthcare providers about potential medical conditions.
(4) Software functions that perform simple calculations routinely used in clinical practice.
The FDA also provided a list of categories of software functions that are not medical devices:
(1) Software functions that are intended to provide access to electronic “copies” of medical textbooks or other reference books with generic text search capabilities.
(2) Software functions that are intended for health care providers to use as educational tools for medical training or to reinforce training previously received.
(3) Software functions that are intended for general patient education and facilitate patient access to commonly used reference information.
(4) Software functions that automate general office operations in a health care setting and are not intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease.
(5) Software functions that are generic aids or general-purpose products.
(6) Software functions that are intended for individuals to log, record, track, evaluate, or make decisions or behaviorial suggestions related to developing or maintaining general fitness, health, or wellness.
(7) Software functions that enable individuals to interact with EHR software certified under the ONC Health IT Certification Program.
(8) Software functions that provide patients with simple tools to organize and track their health information.
(9) Software functions that provide easy access to information related to patients’ health conditions or treatments.
(10) Software functions that provide patients with simple tools to organize and record their health information.
(11) Software functions that are specifically marketed to help patients document, show, or communicate to providers regarding potential medical conditions.
(12) Software functions that enable, during an encounter, a health care provider to access their patient’s personal health record (health information) that is hosted on a web-based or other platform.
(13) Software functions for health care providers certified under the ONC Health IT Certification Program, such as those that help track or manage patient immunizations by documenting the need for immunization, consent form, and immunization lot number;
(14) Software functions that help asthmatics record (i.e. collect and log) inhaler usage, asthma episodes experienced, location of user at the time of an attack, or environmental triggers of asthma attacks;
(15) Software functions certified under the ONC Health IT Certification Program that prompt the health care provider to manually enter symptomatic, behavioral, or environmental information, the specifics of which are pre-defined by a health care provider, and store the information for later review;
(16) Software functions that record the clinical conversation a clinician has with a patient and sends it (or a link) to the patient to access after the visit;
(17) Software functions that allow a user to record (i.e. collect and log) data, such as blood glucose, blood pressure, heart rate, weight, or other data from a device to eventually share with a health care provider, or upload it into an online (cloud) database, or personal or electronic health record (PHR or EHR, respectively) that is certified under the ONC Health IT Certification Program;
(18) Software functions that enable patients or health care providers to interact with PHR systems or EHR systems that are certified under the ONC Health IT Certification Program;
(19) Software functions that meed the definition of Non-Device-MDDS, which are functions solely intended to transfer, store, convert formats, and display medical device data or results, without controlling or altering the functions or parameters of any connected medical device.
(20) Software functions that display patient-specific medical device data.
(21) Software functions that are intended for transferring, storing, converting formats, or displaying clinical laboratory test or other device data and results, findings by a health care professional with respect to such data and results, general information about such findings, and general background information about such laboratory test or other device, unless such function is intended to interpret that data, results, and findings.
The policies provide much more detail about the scope of the regulatory authority to be exercised over software than what can be captured in a blogpost, but this overview at least summarizes the key points of the guidance.
If you are developing a digital health software product, you will want to carefully consider how the FDA will classify your product, and you will likely want to consult with an attorney who focuses in this niche. FDA legal practice is a narrow practice niche which includes a small circle of attorney practitioners, so it may be challenging to find a lawyer who practices in this specialty area outside of Washington, D.C. It is possible that a medical device patent attorney in your area may have this expertise or may be able to make a good referral for you, so that is a possibility you may want to explore.
If you missed the recent webinar by Silicon Valley SaaS Lawyer Kristie Prinz on “Best Practices for Negotiating and Drafting SaaS Contracts,” a recording of the program is now available on demand for viewing. To view the program, please visit this link.
Silicon Valley Software Law Blog Author and SaaS Lawyer Kristie Prinz will be presenting a webinar on “Best Practices for Drafting & Negotiating SaaS Contracts” on Friday, November 19, 2021 at 10 a.m. PST. To attend, please register at the attached link.
Have you ever heard the term “SaaS license” or “SaaS Licensing” being used among lawyers and businesspeople?
There is a misconception that there is such a concept as a “SaaS license.” However, in fact, two principles are actually being confused: the “software license” and the “SaaS agreement.” Why does this matter? Well, if you do not know the type of agreement that you are drafting, you are going to confuse the important terms in the agreement, and this is going to have a huge impact on what you draft or negotiate. In addition, if you do not know what you are drafting, this is going to impact other terms beyond the agreement such as taxes and revenue recognition. So, the bottom line is that it does matter what you draft.
Also, the concepts of “SaaS agreement” and “software license” are completely different. In the case of a software license, the licensor grants to the licensee the rights to use a specific piece of intellectual property, the software, under certain conditions and limitations, and if you exceed the parameters of the grant, you will be infringing on the intellectual property. The license grants licensee the right to use the software for the length of the copyright or other specific period of time and will specify who can use the software, how the software can be used, and under what conditions the software can be used. In contrast, in the case of the SaaS agreement, no intellectual property rights will be granted in the software. Instead, the grantee receives access rights in the software in the cloud and in a bundle of services. The rights that the grantee receives are more along the lines of what someone might receive to intellectual property in content posted on a website on the Internet. The internet user might have the right to view the posted content, but that right does extend to doing anything to the content beyond just viewing it.
In the case of the SaaS agreement, you may have rights to certain services in addition to access rights, such as hosting, maintenance, and technical support by way of the SaaS agreement, but your rights are to services and not to intellectual property in the software. In the case of the software license, the rights to hosting, maintenance and technical support are generally going to be obtained through other agreements.
Another difference between the two concepts is that in the case of the software license, you have more control and the ability to change service providers if a service is not being provided at the level you require. In the case of the SaaS agreement, you are “stuck” if you are unhappy with the quality of any service. So, the quality of the service delivered is far more important in the case of SaaS agreements than in the case of the software license. You cannot just easily move your content if you are unhappy with a particular service, as you have no direct control over the content in the case of the SaaS agreement. In essence, you delegate that control to a third party, the SaaS provider.
So, the “SaaS agreement” and the “software license” are two fundamentally different concepts, and the term “SaaS license” or “SaaS licensing” is just a confusion of those two concepts.
Silicon Valley Software Law Blog’s Kristie Prinz will present a webinar on “Introduction to Negotiating & Drafting SaaS Agreements” on December 14, 2020 at 10 a.m. PST. To learn more about the program or to register, please click here.
Silicon Valley Software Law Blog’s Kristie Prinz will be presenting a webinar on “Best Practices for Negotiating SaaS Agreements in an Uncertain Economy” on December 8, 2020 at 10 a.m. PST. For more information on the program or to register, please click here.
If your software company is like most U.S. businesses, it has been severely impacted by the ongoing coronavirus crisis and the stay-at-home orders that have been mandated across the country. Legislation was recently passed by Congress and signed into law that may make available disaster relief to your software company: the Coronavirus Aid, Relief, and Economic Security Act (the “CARES” Act).
The CARES Act established a new business loan program, the Paycheck Protection Loan Program (“PPP”), which will enable a U.S. software company qualifying as a small business to receive a loan in the amount of 2.5 times the company’s monthly payroll costs. As part of the PPP, software companies (and other small businesses) may be eligible for loan forgiveness on any loan proceeds applied during the eight week period immediately following receipt of the loan towards payroll, rent, utilities, and interest on mortgage and debt obligations incurred prior to February 15, 2020, provided that all employees are kept on the payroll for the eight week period and the documentation verifying the use is submitted to the lender. Any loan proceeds that are not forgiven will have a maturity of 2 years and an interest rate of 1%. The program is described in more detail on this weblink. The interim regulations describing how the program will work are linked here and the FAQ addressing questions and answers is linked here.
To participate in this loan program, your company should submit an application through your primary bank. Alternatively, many online and non-bank business lenders are also participating in the loan program, so working through such a lender may be an available option.
In addition, your software company may be eligible for an economic injury disaster loan advance of up to $10,000. Originally these advances were supposed to be available within 3 days of submitting an application; however, this now been revised to remove the previously defined deadline. Advances should be requested directly through the SBA website at this link: https://covid19relief.sba.gov/#/. The loan advance will not have to be repaid but the amount may be deducted from a subsequently obtained PPP loan.
It is anticipated that the funds allocated to this program are going to run out before all the applications are processed, so companies are being encouraged to submit applications as soon as possible. It is unfortunately not clear how long businesses will have to wait to receive the aid. To date, the Silicon Valley Software Law Blog is only aware of one approved business via a third party report, and has heard of no business actually receiving any aid through these programs.
If you are on a law firm mailing list, it is likely that you have seen emails or alerts in the last few weeks that discuss the concept of “force majeure.”
Why has the concept of force majeure suddenly become a favorite topic of law firms around the country? Well, over the month of March, many state and local governments have imposed stay-at-home orders on businesses and their employees. In addition, there have been mass cancellations and closings, all as a result of the coronavirus pandemic. The economic damage arising from these events is already affecting many contractual relationships, rendering parties unable to perform. For this reason, the boilerplate force majeure clause included in many contracts is now anticipated to take on new significance.
If you are unclear on what exactly a force majeure clause is, this is the clause routinely included in many contracts that specifically addresses what happens if one party cannot perform a contractual obligation due to the occurrence of an event beyond that party’s control. Such clauses generally provide that the force majeure event will not constitute a material breach provided that certain requirements are met.
So, do the events of the last month automatically permit the nonperformance of an obligation by a party to a contract if a force majeure clause exists? As is the case with most contract interpretation issues, the answer is not so black and white.
Since this particular set of circumstances has not happened in the lifetime of most practicing lawyers, it is unlikely that the average force majeure clause specifically contemplated the possibility of a pandemic or a widespread, stay-at-home order over an extended period affecting most businesses and workers across an entire city, county, or state. So, the first question will be: is the force majeure clause in the relevant contract drafted broadly enough to apply to specific circumstances causing the failure to perform? A force majeure clause that specifically addressed “acts of government” may be broad enough to apply. However, a force majeure clause that only contemplated “acts of God” or ” acts of nature” may not. So, the specific wording of the force majeure clause will be critical. Also, the application may be subject to interpretation, if the applicability depends on words like “beyond the reasonable control of either party” or “epidemic.”
Assuming that the definition of force majeure is defined broadly enough to apply to the particular circumstances many businesses and workers have faced over the last month, then the next question to determine will be whether the conditions were met for the force majeure clause to apply. Many force majeure clauses impose requirements on the affected party that must be met for the force majeure clause to apply. Have these requirements been strictly followed? Is that answer subject to interpretation?
Then, assuming that the force majeure definition applies and the conditions were met, then the next question is whether or not there were any carve-outs for the particular obligation that has not been performed, which render the clause inapplicable? One carve-out that I see from time to time is failure to make a payment.
Finally, assuming that the force majeure definition applies, the conditions were met, and there were no carve-outs that apply, the question will be whether the continuation of the event for an extended period then enables the other party to terminate. It is not uncommon for a force majeure clause to specify that if the event continues for more than thirty or sixty days, then the performing party will be able to terminate.
Of course, there may be other clauses in a particular contract beyond just the force majeure clause that may apply to excuse or simply address a failure or delay in performance. Additionally, if a party is facing the likelihood of not being able to perform, that party always has the option of simply approaching the other party directly and attempting to renegotiate the contract to specifically address the changed circumstances and contemplate a particular resolution. In many cases, this may actually be the preferred way to tackle an unforeseen situation along the lines of what many businesses are facing as a result of the coronavirus pandemic. However, if the other party is not open to renegotiation or other options are just not available, a force majeure clause may provide the contractual answer to the deal with the current circumstances of your business.
If your software company is like many, you are probably already contemplating the renegotiation of certain contracts due to the uncertainty and changed business conditions arising from the coronavirus pandemic.
However, the renegotiation of contracts will inevitably open your software company up to the possibility of having to agree to terms and conditions far less favorable than what you previously agreed to. Furthermore, if not carefully drafted, any modification to an existing agreement could create legal issues that did not previously exist, leaving your software company in a vulnerable position should your company end up in a legal dispute with the other party down the road.
So, what are some practice tips for the successful renegotiation of contracts in a period of economic and business uncertainty?
First and foremost, approach contract re-negotiations as an opportunity to clarify any vague or uncertain terms in the previously executed contract. It is critical in periods of economic and business uncertainty to fully contemplate in the contract the parties’ intentions. So, a renegotiation is the perfect time to address any such issues that have come to light with the contract since execution. You definitely do not want to spend the time and money on renegotiating only to leave in the contract all the problems that have previously come to light with it, any one of which could result in a contract dispute down the road. Also, you want to think through all the possible scenarios that could arise and make certain the contract fully addresses those possibilities. For example, right now, many cities around the world are in lockdown for a period that has been assigned an expected end date. What happens if the date gets pushed back by three months? How does this impact the relationship? What happens if the date gets pushed back by six months? How does this impact the relationship? Thinking through the implications on the contract of potential scenarios and ensuring they are appropriately address in the contract is key.
Second, approach contract renegotiation with the intention of ensuring that the terms will be a “win” for both parties. In other words, both sides of the contract should obtain a benefit from the renegotiation, so that one side is not making all of the concessions on the mere promise of a future relationship. For example, if one side is seeking new payment terms, consider whether the other party would benefit from a longer contractual commitment. Good relationships require mutuality for both sides to remain satisfied with that relationship. If one side feels forced to agree to terms against its interest, then the relationship is likely to be negatively impacted on an ongoing basis.
Third, anticipate the possibility that the contract renegotiation does not truly resolve the issue prompting the renegotiation and develop a fallback solution that will enable the parties to easily go their separate ways without the necessity of further negotiations or proceedings. Contemplate what terms would need to be included that would allow for a clean and painless parting of ways if the issues do not end up being resolved by the modification.
Fourth, make sure you are really contemplating the full impact of the proposed modification(s) on every single clause of the contract, and not a single clause or set of clauses in the contract. Perhaps the single most common mistake I see with contract modifications is that parties fail to contemplate how a modification affects an entire agreement and draft documents that add a lot of uncertainty into the terms. Even a minor modification has the potential to impact all or nearly all of the clauses in a previously executed document. Thus, make sure you have taken the time to fully contemplate the impact of a proposed modification before agreeing to it.
Fifth, make sure you identify the specific contract you are modifying, and the specific clauses you are modifying, as well as what specific modifications you are making. Also, clearly state what happens specifically to the clauses you are not modifying. The worst contract modifications are unclear as to the contract version being modified and/or the specific clauses being modified, and are not clear as to the effect on other clauses. An effective contract modification is one that does not create new uncertainty.
The bottom line is that even a seemingly simple modification proposal requires careful contemplation beyond just merely the request proposed. While it might be tempting to cut corners with a contract renogotiation in order to save on legal fees or expedite the signing of a contract modification in an uncertain economic climate, such decisions often lead to disputes with previously good relationships that would never have arisen otherwise. It generally pays to take the time do a contract modification the right way.
Although many businesses are concerned about the potential economic fallout of recent shelter-in-place orders in Silicon Valley as well as more limited office and business closings across the United States, the coronavirus crisis is presenting a unique sales opportunity to savvy SaaS companies, given the fact that much of the United States workforce has suddenly been forced to work remotely.
How can your company capitalize on the sales opportunities now presented by the increased demand for software-as-service solutions while avoiding the legal pitfalls that can arise from economic uncertainty?
First and foremost, increased customer demand presents an opportunity to improve poorly drafted contracts, which can be more easily renegotiated in conjunction with a customer-initiated request. If your customer is looking to add user access or other services as a result of the new focus on a remote workforce, then you may want to update your customer contract at the same time, particularly given all the predictions of a post-coronavirus recession. It would be in your company’s best interests to have a strong contract in place with your customers in the event of any recession, since poor economic conditions tend to result in contract cancellations by customers. If you have never had your customer contract reviewed by a lawyer with SaaS contracts expertise, now might be a perfect time to do so in conjunction with meeting any new customer demand, so that your business is better prepared to weather an economic downturn and customers looking for loopholes to walk away from your agreement.
Second, if your customer is looking to add authorized users at new locations, ensure that you are addressing the new sales by properly amending your existing contract as contemplated by the SaaS lawyer who originally drafted the contract. More often than not, I see companies making huge mistakes with subsequent SaaS sales, where they execute amendments that incorrectly override key terms in their original contracts or add significant legal loopholes into the original contracts. Obviously a poorly drafted amendment can completely undo any investment you made in a well written original agreement, and can create legal disputes where you previously had none. So, you definitely want to exercise a high degree of care to ensure that any new sales are appropriately addressed by a correctly drafted amendment.
Additionally, you need to consider whether any implementation services will be required to make these additions, whether the possibility of future implementations was contemplated by the original contract, and how the delivery of implementation services might be impacted as a result of the coronavirus pandemic or any economic conditions that might arise as a result of the pandemic. In the prior recession, implementation was one of the most commonly disputed issues between software companies and customers.
Third, if your customer has gone entirely remote, you need to anticipate a greater demand for various types of support services, which also creates new customer sales opportunities. For example, perhaps instead of one-size-fits-all free standard support, there may now be a customer demand for multiple levels of paid, enhanced support services. However, if your company suddenly decides to completely revamp support services in response to new customer demand, you definitely need to make sure such changes have been contemplated in your original contract, and to the extent they have not, make sure the contract again is appropriately amended to address a complete revamp of your support offering.
Fourth, you may find that your customer now has new custom functionality or feature development needs in response to changing service demands by the customer’s own client base, which is similarly responding and trying to adapt to the same crisis. If you are fortunate enough to have this type of opportunity arise, then you need to ensure that ownership of custom functionality features was sufficiently contemplated by the original contract with your customer, not only with respect to whether or not those features can subsequently be made available to your entire customer base but also with respect to the specific terms for costs, timetable, and specifications for development. To the extent these issues are not fully addressed by your original contract, you will want to make sure they are properly addressed by separate agreement. In light of the current crisis, you will want to ensure that any potential delays that might arise due to the coronavirus crisis have been properly addressed in the terms.
Fifth, the new circumstances may present new customer demands for live and recorded remote training that did not exist previously, which may be able to be sold at different price-points. However, again, if such an opportunity for sales presents itself, you should ensure that your original contract contemplated the possibility of different levels of training for a fee being purchased by the customer. If not, then you will want to ensure that your agreement is properly amended to reflect the new training service offerings. And of course, if your customer is seeking training to be provided by a particular instructor, you will want to ensure that the possibility of that instructor falling seriously ill to coronavirus has been contemplated and any risks properly addressed.
Sixth, the new remote circumstances may present customer demands for enhanced levels of service in terms of available bandwidth and other service enhancements, which you also may be able to make available to customers at different price-points. Should this arise, you will again need to ensure that the possibility of different levels of service was contemplated by the original agreement, and if not, appropriately amend the agreement to address this possibility.
Finally, the new remote circumstances may present opportunities to sell new professional services to your customers that you had not previously considered. Should an opportunity of this nature arise, then you will need to ensure that the possibility of future professional services was contemplated by the original agreement, and if not appropriately amend the agreement to address this possibility and then potentially draft a separate professional service agreement that addresses the contemplated services required by the customer.
All in all, the coronavirus crisis is presenting a unique business opportunity for cloud-based SaaS providers to deliver more services to a workforce suddenly forced to work remotely. However, to capitalize on the opportunity to meet the demands of a newly remote workforce, SaaS companies will need to apply a high level of care to the technical drafting of their contracts. Otherwise, to the extent they cut corners, they are likely to pay the price by attracting customer disputes in a subsequent weak economy.
The Silicon Valley Software Law Blog’s Kristie Prinz will be presenting a series of webinars on negotiating in a very uncertain economy, sharing practice tips developed and lessons learned from the last recession. I will be kicking off the series with a webinar on “Best Practices for Negotiating Master Services Agreements in an Uncertain Economy” on April 6th, followed by a webinar on “Best Practices for Negotiating Development Agreements in an Uncertain Economy” on April 13th, and and a webinar on “Best Practices for Negotiating SaaS Agreements in an Uncertain Economy” on April 20th. I will be announcing the next webinars in the series soon. To register for any of these programs, please check out the webinar notices at The Prinz Law Store Website.
Silicon Valley Software Law Blog’s Kristie Prinz will present a webinar on “The Intersection of Law & Technology: Addressing Current Technology Issues without Allowing them to Overwhelm your Practice” on April 17, 2020 at 10 a.m PST/ 1 a.m. EST. For more information on the program, please check out this link:https://prinzlawstore.com/2020/02/silicon-valley-technology-lawyer-kristie-prinz-to-present-webinar-on-the-intersection-of-technology-and-legal-practice-addressing-current-technology-issues-without-allowing-them-to-overwhelm-your-p/
Silicon Valley Software Law Blog’s Kristie Prinz will be presenting on “Negotiating SaaS Contracts & Managing Customer Relationships” on March 31st, 2020 at 10 a.m. PST/ 1 p.m. EST in a webinar sponsored by The Prinz Law Office. To attend, please register at: https://prinzlawstore.com/2020/02/best-practices-for-negotiating-saas-contracts-managing-saas-customer-relationships/
Silicon Valley Software Law Blog’s Kristie Prinz will be presenting on “Negotiating SaaS Agreements: Drafting Key Contract Provisions, Protecting Customer and Vendor Interests” for Clear Law Institute on March 23, 2020 at 10 a.m. PT/1 p.m. ET.
The Prinz Law Office is pleased to announce its new alternative billing options for 2020. As of the New Year, the firm has dramatically increased its alternative billing options so that clients will have a lot more choices for standard fixed fee packages: clients will now be able to choose from as many as five different levels of standard fixed fee services for many of regularly requested services. This will be in addition to all the subscription options and fixed hour options, which were announced previously in 2019. For more information about all the new alternative options now available, please contact Kristie Prinz at firstname.lastname@example.org.
If your company is like many, you have known about the upcoming effective date of the California Consumer Privacy Act (“CCPA”), but are still making last minute preparations in advance of it going into effect.
If you are one of many procrastinators out there just starting to think about the law, the Silicon Valley Software Law Blog wanted to recap some highlights for you.
- Your business is subject to the law, regardless of its location, if any one of the following is true:
- Your company has gross annual revenues in excess of $25 million.
- Your company buys, receives, or sells the personal information of 50,000 or more consumers, households, or devices.
- Your company derives 50 percent or more of its revenues from selling consumers’ personal information.
- The CCPA creates new rights for California consumers: (a) the right to know; (b) the right to delete; (c) the right to opt out; and (d) the right to non-discrimination.
- You must provide notice to consumers at or before the point of data collection of the personal information to be collected and the purposes it will be used.
- You must provide clear and conspicuous notice to consumers of the right to opt out of the sale of personal information, which includes providing a “Do Not Sell My Personal Information” link on the website or mobile application.
- You must respond to requests for consumers to know, delete, and opt-out within specified timeframes (generally 45 days). Privacy settings to opt out must be treated as a validly submitted opt out request.
- You must verify the identity of consumers who make requests to know or to delete, regardless of any password-protected account settings with the business.
- You must disclose any financial incentives offered in exchange for the retention or sale of a consumer’s personal information, explain how the value of the personal information is calculated, and explain how the incentive is permitted under the CCPA.
- You must make available to consumers at least two or more designated methods for submitting requests, including at a minimum a toll-free phone number, and if you maintain a website, a website address by which to submit requests. However, a business that operates exclusively online and has a direct relationship with the consumer from who it collects personal information is only required to provide an email address.
- You must retain records of all requests and responses to requests for at least 24 months; provided that businesses that buy or sell personal information of more than 4 million consumers annually have additional reporting obligations.
Also, if your business qualifies as a “data broker” you are required to register with the Attorney General by January 1, 2020. How do you know if your business is a “data broker”? Your business knowingly collects and sells to third parties the personal information of a consumer with whom the business does not have a direct relationship. Three categories of businesses are excluded from these obligations: (i) consumer reporting agencies to the extent they are covered by the Fair Reporting Act; (ii) financial institutions to the extent they are covered by the Gramm Leach Bliley Act; and (iii) entities covered by the Insurance Information and Privacy Protection Act.
The CCPA, its amendments, and regulations define more compliance obligations that businesses should be familiar with, but this list is a good starting point in advance of the effective date.
Obviously, even if your business is not subject to these laws, these privacy requirements will now constitute the best practices for doing business in California, so all businesses should seriously consider incorporating these privacy practices into their standard privacy practices and procedures. The Silicon Valley Software Law Blog will continue to keep you updated as these new laws begin to be implemented.
Software companies in the business of brokering data are on notice: the state of California intends to keep you on a tight leash.
In anticipation of the January 1, 2020 effective date of the California Consumer Privacy Act (“CCPA”), California took yet another bold step to protecting the personal information of Californians when it passed a new data broker law on October 11, 2019, which applies to anyone in the business of collecting and selling the personal information of consumers: AB-1202 establishes a new compliance framework for data brokers.
Under the new law, data brokers will be required to register with the Attorney General, pay a registration fee, and provide their name, physical address, email, and website address, which will be publicly displayed online. Any data broker who fails to register will be (a) subject to injunction and liable for civil penalties, fees, and costs at a rate of $100 for each date that the data broker fails to register; (b) liable for an amount equal to the fees due during the period it failed to register; and (c) the expenses incurred by the Attorney General in the investigation and prosecution of the action.
What businesses are defined as “data brokers” under the law? The law defines “data broker” to mean a “business that knowingly collects and sells to third parties the personal information of a consumer with whom the business does not have a direct relationship.” The law specifically excludes three categories of businesses from the definition of “data broker”: (i) consumer reporting agencies to the extent they are covered by the Fair Reporting Act; (ii) financial institutions to the extent they are covered by the Gramm Leach Bliley Act; and (iii) entities covered by the Insurance Information and Privacy Protection Act. “Personal information” is defined to have the meaning provided in subdivision (o) of Section 1798.140, so publicly available information may be excluded to the extent the data is used for a purpose that is compatible with the purpose for which the data is maintained and made available in the government records or for which it is publicly maintained
So, if your company is in the business of selling data in any capacity, not only do you need to prepare for the January 1, 2020 launch of the CCPA, you also need to prepare to register with the state of California as a data broker. Businesses will be required to register on or before January 31st following each year when your business meets the definition of a “data broker.”
Silicon Valley Software Law Blog Author Kristie Prinz will present an upcoming webinar on November 21, 2019 on “Legal Developments Impacting the Software Industry.” The event will be hosted by The Prinz Law Office and will explore what software companies need to know about the key legal developments affecting the software industry in 2019. To learn more about the event or to register, please check the event page: https://prinzlawstore.com/2019/10/legal-developments-impacting-the-software-industry-2019/.
In anticipation of the California Consumer Privacy Act (“CCPA”) going into effect on January 1, 2020, California Governor Gavin Newsom has just signed into law seven amendments to the statute, and the California Department of Justice published the text of its new regulations to be adopted in furtherance of the CCPA.
The signed bills are as follows: AB 25, AB 874, AB 1146, AB 1355, AB 1564, and AB 1130. The text of the published regulations are made available here. The deadline to submit written comments is 5 p.m. on December 6, 2019. California is accepting comments submitted in accordance with the instructions posted on this Office of the Attorney General website: https://www.oag.ca.gov/privacy/ccpa.
So now that there is a little more statutory and regulatory clarity on what exactly will be going into effect on January 1st, 2020, software companies are in a better position to start preparing for the law to take effect.
So, what does your software company need to know about complying with the California law as of January 1, 2020, as the California privacy laws collectively stand today?
First of all, your business will be subject to the law if at least one of the following are true:
- Your company has gross annual revenues in excess of $25 million;
- Your company buys, receives, or sells the personal information of 50,000 or more consumers, households or devices;
- Your company derives 50 percent or more of its revenues from selling consumers’ personal information.
“Consumer” is currently defined as a natural person who is a California resident. “Personal information” is currently defined as any information that “identifies, relates to, describes, is capable of being associated with, or could reasonably be linked, directly or indirect, with a particular consumer or household” and includes not only name, address, and social security number, but also purchasing history or tendencies, biometric information, internet activity, geolocation data, employment information, and education information. However, publicly available information and de-identified or aggregate consumer information is now specifically excluded from the definition. “Business” is currently defined to include for-profit businesses as well as other legal entities.
Second all, California consumers are going to have certain new rights that your business will be responsible for ensuring:
- A Right to Know (a) the specific pieces of personal information the business has collected about the consumer; (b) the categories of personal information it has collected or sold about that consumer; (c) the purpose for which it collected or sold the categories of personal information; and (d) the categories of third parties to whom it sold the personal information.
- A Right to Delete personal information held by your business or by a service provider of your business; provided that, however, there will be some exceptions, where it is necessary for your business or service provider to do any of the following: (a) complete the transaction for which the personal information was collected, fulfill the terms of a written warranty or product recall conducted in accordance with federal law, provide a good or service requested by the consumer, or reasonably anticipated within the context of a business’ ongoing business relationship with consumer, or otherwise perform a contract between the business and the consumer; (b) detect security incidents; protect against malicious, deceptive fraudulent, or illegal activity; or prosecute those responsible for that activity; (c) debug to identify and repair errors that impair existing functionality; (d) exercise free speech, ensure the right of another consumer to exercise that consumer’s right of free speech, or exercise another right provided for by law; (e) comply with the California Electronic Communications Privacy Act; (e) engage in public or peer-reviewed scientific, historical, or statistical research in the public interest that adheres to all other applicable ethics and privacy laws, when the deletion of the information is likely to render impossible or seriously impair the achievement of such research, if the consumer has provided informed consent; (f) to enable solely internal uses that are reasonably aligned with the expectations of the consumer based on the consumer’s relationship with the business; (g) to comply with a legal obligation; or (h) to otherwise use consumer’s personal information, internally, in a lawful manner that is compatible with the context in which the consumer provided the information. If you or your service provider does not delete consumer’s information upon request, you must inform the consumer as to why and notify the consumer of any rights he or she has to appeal the decision, and you must do it within the timeframe you would have had to delete the information.
- A Right to Opt Out of the Sale of personal information. “Sale” is defined to include selling, renting, releasing, disclosing, disseminating, making available, transferring, or otherwise communicating orally, in writing, or by electronic or other means, a consumer’s personal information by the business to another business or a third party for monetary or other consideration. The proposed regulations provide more clarification on the practices businesses should follow to ensure this right to opt out of the sale. In the case of children under the age of 16, your business cannot sell their personal information unless they have opted-in to the sale. In the case of children under 13, a parent or guardian must opt-in on behalf of the child. The proposed regulations further define the rules related to the protection of children.
- A Right of Non-Discrimination. Your business will be prohibited from discriminating against a consumer for exercising his or her rights under the CCPA. Discrimination will be defined to include denying goods or services to the consumer, charging different prices or rates for goods or services, providing a different level or quality of goods or services to the consumer, or suggesting that the consumer will receive a different price or quality of goods or services; provide that you will be able to charge a different price or rate, provide a different level or quality of goods or services, or offer financial incentives if the difference is reasonably related to the value provided to the business by the consumer’s personal data, so long as the business practice is not unjust unreasonable, coercive, or usurious in nature. The proposed regulations further define how the right of non-discrimination will be implemented.
Third, businesses will now have other new business obligations to consumers, including the following:
- Provide notice to consumers at or before the point of collection of the categories of personal information to be collected from them and the purposes they will be used.
- Provide clear and conspicuous notice to consumers of the right to opt-out of the sale of personal information in the form of a “Do Not Sell My Personal Information” link on their website or mobile application.
- Respond to requests from consumers to know, delete, and opt-out within the specified timeframe (generally 45 days). The proposed regulations require businesses to treat privacy settings to opt out selected by a consumer as a validly submitted opt out request.
- Make available to consumers at least two or more designated methods for submitting requests for information, including at a minimum, a toll-free phone number, and also specify other business practices for handling requests by consumers.
- Verify the identity of any consumer making a request to know or delete. Password protected account settings are not considered sufficient verification. The proposed regulations require a business unable to verify a request to comply to the greatest extent it can even if it denies a request.
- Disclose financial incentives offered in exchange for the retention or sale of consumer’s personal information (as specified by the proposed regulations), including a short summary of the incentive, a description of the summary and the categories of personal information impacted, an explanation of how a consumer can opt-in to the incentive, a notice to consumer that he or she has the right to withdraw at any time and how he or she can exercise this right, and an explanation of why the incentive is permitted under California privacy law.
- Retain records of all requests and responses to those requests for at least 24 months; provided that businesses (alone or in combination) collecting, buying or selling the personal information of more than 4 million consumers annually are subject to extra recordkeeping obligations.
- Train employees or contractors handling consumer requests on compliance with California privacy law and directing consumers to exercise their rights under California privacy law; provided that businesses collecting, buying or selling the personal information of more than 4 million consumers are subject to higher training obligations.
Fourth, businesses are now going to have to reconcile the requirements of the European Union’s General Data Protection Regulation (“GDPR”) with California’s privacy laws. In particular, California’s Department of Justice has advised businesses to be wary of the following:
- Data inventory and mapping of data flows to demonstrate compliance with the GDPR may have to be re-worked to reflect the different requirements of California.
- Processes and/or systems set up to respond to individual requests for access to or erasure of personal information will need to be reviewed in order to apply different definitions of what constitutes personal information and different rules on verification of consumer requests.
- Contracts with service providers or data processors adopted to comply with the GDPR may need to be rewritten to reflect the requirements under California law.
Regardless of whether your software company is going to meet the threshold to be subject to the new California law when it goes into effect, it would be prudent to start incorporating these new requirements into your company’s privacy practices and procedures, since they will at the very least become the new best practices for businesses serving California consumers effective January 1, 2020. It goes without saying that software companies who will be subject to the law when it goes into effective need to take steps to become compliant immediately, as the law is set to go into effect in less than 75 days.
The Silicon Valley Software Law Blog will continue to follow any further rulemaking and privacy law amendments as they are proposed and/or adopted by the State of California.
Silicon Valley Software Law Blog’s Kristie Prinz will be presenting a webinar on “Best Practices for Negotiating SaaS Contracts & Managing SaaS Customer Relationships” on October 8, 2019 at 10:00 a.m. PST/ 1 p.m. EST. The webinar will address the following issues:
- What makes an effective SaaS customer contract?
- What are the essential terms in a well-drafted SaaS contract?
- What are the common issues that arise in SaaS negotiations? What are the best strategies to resolve them?
- What are the best practices to manage the customer relationship?
The Prinz Law Office is sponsoring the event, which will be intended for lawyers as well as business people.
To register, please sign up at the Prinz Law Store website.
If you are in the software business, you likely recognize that you can be sued for materially breaching contracts, infringing third party IP, and data breaches but you may not realize the extent of your liability just for making the sale of a software product deemed to contain a security flaw in the first place, even if the security flaw was never exploited and only identified.
Increasingly, however, just the act of selling software later deemed to be “defective” due to security flaws has resulted in liability to companies.
As The Silicon Valley Software Law Blog has been reporting, the Federal Trade Commision (the “FTC”) has recently imposed fines and put in place ongoing oversight on companies for this type of issue.
But as Cisco just discovered, if the sales were made to a federal or state agency, the mere act of making the sale can also result in significant liability. Cisco has agreed to pay $8.5 million to settle a case originally filed in New York Western District Court in 2011 involving the sale of video surveillance technology to a variety of government organizations, including but not limited to Homeland Security, the Secret Service, the Army, the Navy, the Marines, the Air Force and the Federal Emergency Management Agency.
According to The New York Times, the Cisco case was initiated by the Justice Department in the Federal District Court for the Western District of New York, and the allegations were based on violations of the False Claims Act, which addresses fraud and misconduct in federal government contracts. Fifteen states and the District of Columbia joined in the suit. As The New York Times reported, the argument made by the government was that the software had no value because if failed to serve its primary purpose of security enhancement. According to The New York Times, the flaw was identified back in 2008 by a Cisco subcontractor, who brought it to the company’s attention at that time. However, as The New York Times reported, the subcontractor was subsequently terminated, and when he realized two years later that the vulnerability was still not fixed, he contacted the FBI. The New York Times reported that Cisco continued to sell the software with the flaw until July 2013, when if finally notified customers and fixed the flaw.
While the Cisco case applies only to sales made to government, a class action suit is pending right now on similar facts, where the sales were made to non-government consumers.
As was announced in this press release class and discussed in this firm blogpost, a class action lawsuit was initiated late last year against Symantec for critical defects in its security products under the Norton Brand. It is not clear as to the status of that litigation.
The bottom line: if you are selling software that provides security functionality, you need to have internal systems in place to identify security flaws and quickly fix the flaws, particularly if the software is being sold to a government organization. However, if you are selling to the general public, you may still be liable for sales of the software containing security flaws, whether liability is assessed through the FTC or through class action litigation, regardless of the terms of your contract for those sales.
When your company releases its next software update, you may want to consider the potential legal implications of the release. There seems to be a new trend in class action litigation: suits over software updates.
As Reuters first reported, an owner of a Tesla vehicle has filed a lawsuit against Tesla, Inc. claiming that a software update fraudulently limited the battery range of older vehicles, which reduced the distance that they can travel without recharging the vehicles. Reuters reported that the lawsuit was filed in a Northern California federal court and seeks class action status for owners of Model S and X vehicles around the world.
According to Reuters, the lawsuit claims that the software update was released with the intention of avoiding liability for defective batteries.
CNET reports that the affected owners claim to have lost some eight kilowatt hours of capacity after the software update, which occurred back in May, 2019, and that the affected cars are older model S and X vehicles, which have batteries that should still be covered under the eight (8) year warranty on the batteries. InsideEvs explained the argument as Tesla “enter[ing] [owners’] garages and replac[ing] a 40-gallon tank for a 20-gallon tank.”
Tesla is not the first company to be sued for a software update and how the update affected the performance of a device. Apple has also been the subject of numerous suits in the past few years on a similar issue. This Business Insider article reports on the legal controversy involving Apple regarding an update affecting battery performance. Class action suits were also filed against Microsoft over its Windows 10 upgrade strategy. See this Consumeraffairs.com article.
While these cases all pertain to software that controlled performance of a device, whether batteries or computers, it seems clear that with the increasing reliance on software functionality across so many industries, lawsuits over software updates are likely to continue.
So, the next time your company contemplates a software update or upgrade, it may be prudent to to contemplate the legal implications of the release and whether or not it is likely to result in litigation. You also may want to reconsider the sufficiency of your legal agreements in place with the parties to whom you are sharing the updates or upgrades before making available the new software. Software companies are clearly on notice that they may be sued for updates or upgrades, if they are alleged to have a negative impact on customers or users after the release.
The CARIN Alliance, which is a coalition of companies from the health and tech industries, has just announced the release of a new standard for sharing health claims data in conjunction with the Blue Button Developers Conference. The announcement is linked here.
The newly released standard is linked here: CARIN Blue Button Implementation Guide CI Build.
According to FierceHealthcare, the standard was developed by working group comprised of alliance members and includes more than 240 claim data elements. FierceHealthcare reports that 20 organizations, including Apple, Anthem, Blue Cross Blue Shield, Cambia Health Solutions, Google, and Humana have agreed to test an application programming interface (“API”) employing the standard in anticipation of a product lunch of the standard next year.
CNBC reports that the significance of the news is that this is the first time that industry has agreed to standards for sharing claims data to third party developers, and the Alliance aspires not only to make the data available to consumers but also to provide fraud detection functionality and functionality to help consumers avoid paying bills with errors in them.
FierceHealthCare reports that the new standard “builds” on Blue Button 2.0, which was released by the Centers by Medicare and Medicaid Services (“CMS”) last year and is an API enabling Medicare beneficiaries to access to their Medicare claims data. A web page dedicated to Blue Button 2.0 is linked here. FierceHealthCare reported on the Blue Button 2.0 initiative by CMS here.
Obviously the development of new digital health standards is a victory for the digital health industry, which has arguably been slow to develop industry standards along the lines of what exist in the tech industry generally.
The Software Industry is closely following legislation in California that, if passed, could have a huge impact on Gig workers and the software companies that rely on them.
The legislation at issue is AB 5, which would codify and expand the California Supreme Court’s recent decision in Dynamex Operations v. Superior Court (2018) 4 Cal. 5th 903. The text of the proposed legislation is available here.
According to The Intercept, the bill was sponsored by Lorena Gonzalez, a Democratic assemblywoman from San Diego. The Intercept reports that that California is losing an estimated $7 billion in payroll tax annually due to the misclassification of employees as independent contractors, so the state is eager to close the loophole.
Obviously, Uber and Lyft, directly oppose the legislation, since it would directly impact their current Gig worker business model. In fact, The Los Angeles Times has reported that Uber and Lyft have actually paid drivers to organize protests against the legislation.
For Uber and Lyft, the obvious concern is that the passage of AB-5 in California could prompt other states to pass their own versions of the legislation, or even, that similar legislation could be passed at the federal level, which could potentially expand the impact of the legislation far beyond the borders of California.
Both The Intercept and The Los Angeles Times are reporting that Uber and Lyft have each warned investors of this potential risk in recent regulatory filings. Indeed, an investment publication, Investorplace, warns that the passage of the bill will have a very detrimental impact on both companies.
The bottom line is that software companies who have built business models around the Gig worker model may soon be forced to either cease operations in California or, alternatively, to change their models for the state, if AB-5 is passed and signed into law, so if your company has been developed around this model or you are building a company relying on this model, you will want to follow this legislation closely as it moves through the California legislature. The Silicon Valley Software Law Blog will continue to track the developments on this legislation.
Multiple media outlets are reporting today that the Federal Trade Commission has agreed to settle its case against Facebook on its privacy practices for $5 Billion.
The Wall Street Journal reports that the vote by FTC commissioners was 3-2 in favor of accepting the agreement and split along party lines with the Republican majority favoring the settlement. According to The Wall Street Journal, the matter next goes the the Justice Department’s civil division for final review.
According to the Mercury News, assuming reports are correct, this will be the largest fine imposed to date by the U.S. government on a tech company. The Washington Post reports that the fine is more than 200 times higher than any previous fine.
Interestingly enough, The Wall Street Journal is reporting that the fine obtained by the FTC exceeds what the European Union could have obtained under its privacy laws.
The Washington Post predicts that the settlement will impose serious consequences on Facebook that go far beyond just a $5 billion fine. However, The Washington Post acknowledges that the dissenting commissioners opposed the settlement because they wanted some assessment of personal liability against CEO Mark Zuckenberg; commissioners reportedly decided to accept a settlement without any such assessment in order to ensure that the matter did not end up in litigation.
While controversial, the FTC’s enforcement action in this matter still sets a significant precedent for the software industry with respect to the consequences of not protecting data uploaded to or generated by software. Software companies are on notice: the FTC is closely following your privacy practices and may assess fines in the billions of dollars against you if you fail to take sufficient steps to protect user data.
As The New York Times and The Washington Post recently reported, facial recognition software is being heavily utilized by government agencies, who are using the software to search state driver’s license databases, despite the fact that most of the photos in the databases are of citizens who have never committed a crime and have never given any sort of consent to the searches. The reports have raised concerns about the lack of regulation and oversight currently with respect to the use of facial recognition software by law enforcement.
According to a report by The New York Times, since 2011, the FBI has run nearly 400,000 facial recognition searches of federal and local databases, including DMV records. The Washington Post reports that the FBI is currently running about 4000 searches per month.
Moreover, The New York Times and The Washington Post are reporting that in states offering driver licenses to undocumented immigrants, Immigration and Customs Enforcement (“ICE”) is using the software to conduct searches on undocumented immigrants.
The Washington Post reports that twenty-one (21) states and the District of Columbia allow federal investigators to scan driver’s license photos, and that those searches generally require no more than an email request to conduct the search.
A number of lawmakers in Washington are raising concerns about the recent revelations, and two cities, San Francisco and Somerville, MA, have now imposed a ban preventing police and public agencies from using the software. The Washington Post reports that a privacy coalition has petitioned the Homeland Security Committee for the Department of Homeland Security (“DHS”) to stop using the technology.
What are the arguments being raised in favor of greater regulation of law enforcement’s use of the technology?
First and foremost, proponents for greater regulation argue that running facial recognition searches against photos of law-abiding citizens is a huge privacy violation. Secondly, they argue the scope of it use by law enforcement is too broad, since it has been used not only for the identification of criminal suspects but also to find witnesses, victims, and bystanders. Third, they argue its use often constitutes a breach of trust, since states encourage undocumented immigrants to submit their information to the databases and then proceed to to tun it over to ICE. Fourth, they argue that use of the software heightens the risk of misidentification and false arrest due to inaccuracies with how certain facial features are detected.
All in all, it is clear that law enforcement considers facial recognition software to be a valuable investigative tool. However, there are clearly some valid concerns with how the software is being used that warrant further consideration. Should law enforcement really be able to conduct these types of searches without a warrant? Should ICE be able to conduct searches of undocumented immigrants who have been encouraged to submit information for inclusion in a database? What kind of checks should be in place on law enforcement’s use of software that that has inherent inaccuracies?
The Silicon Valley Software Law Blog will continue to follow these issues as Congress and privacy advocates debate them.
Silicon Valley Software Law Blog’s Kristie Prinz will be presenting an upcoming web on “Negotiating SaaS Agreements: Drafting Key Contract Provisions, Protecting Customer and Vendor Interests” on August 9, 2019 at 10:00 a.m. PST/1:00 p.m PST for Virginia-based Clear Law Institute. The sponsor is offering a 35% discount off the registration fee with the discount code KPrinz200577.
The Prinz Law Office has issued a press release on the event, which can be viewed here.
To register for the event, please see the Clear Law Institute website here.
Silicon Valley Software Law Blog’s Kristie Prinz will be presenting a webinar on July 25, 2019 for CLE provider Strafford a webinar titled “Drafting Software Hosting Agreements: Service Availability, Performance, Data Security, Other Key Provisions.” Ms. Prinz’s co-presenter will be FieldFisher partner Laura Berton.
The Prinz Law Office has issued a press release announcing the upcoming engagement, which can be viewed here.
To register, please visit the Stafford Publications website link here.
The Federal Trade Commission (“FTC”) has put software companies and software service providers on notice it intends to interpret the Gramm-Leach-Bliley Act’s Safeguards Rule broadly to apply to businesses which make available software or services that serve financial, payroll, and accounting purposes and collect sensitive data on consumers and their employees.
The FTC recently announced its settlement of a complaint filed against LightYear Dealer Technologies, LLC which does business as Dealerbuilt, which required Dealerbuilt as condition of the settlement to develop, implement and maintain an information security program that incorporates the minimum requirements specified by the FTC and submit to third party compliance assessments and annual certifications over a period of the next 20 years.
The FTC’s specified minimum requirements for Dealerbuilt’s information security program included the following:
- Develop, implement, maintain and record in writing an Information Security Program;
- Make available the written program, evaluations of the program, and updates on the program, to the company’s board of directors or governing body, or if none exists, the senior officer responsible for the program at least once per annual period and after any data breach;
- Identify an employee or employees responsible for the coordination of the program;
- Provide written assessment annually and after any data breach of any potential data breach risks;
- Develop written safeguards to ensure data security including the following:
- Training of all employees at least once every annual period on how to protect personal information;
- Technical measures monitoring networks, systems to identify attempted data breaches;
- Access controls on databases containing personal information, which (a) restrict the ability to connect to only approved IP addresses; (b) require authentication to access the databases; and (c) limit the access of employees to only those databases as necessary to perform their duties;
- Encrypt all social security numbers and financial account information;
- Implement policies and procedures for secure installation and inventory on an annual basis
- Perform assessment annually and after any data breach of the sufficiency of safeguards and modify the program as necessary;
- Conduct test annually and after any data breach of effectiveness of safeguards, which shall include vulnerability testing every four months and after a data breach, and annual penetration testing, as well as after any data breach;
- Ensuring that contracts with any service providers ensure compliance with safeguards; and
- Evaluate and make adjustments to program upon any changes to operations or business or in event of any data breach. or on an annual basis.
The FTC Order also mandates that an information security assessment be conducted initially and biennially by a third party professional approved by the Associate Director for Enforcement for the Bureau of Consumer Protection at the FTC, and that the assessor will be required to provide the documents relevant to the assessment to the FTC for review within 10 days following the completion of the initial review and then on demand. Furthermore, the Order requires the senior corporate manager or senior officer of Dealerbuilt to submit annual written certifications to the FTC, and that within a reasonable time following any discovery of a data breach, or at least 10 days following the provision of first notice of any data breach, Dealerbuilt must send a report to the FTC of any data breach, which meets certain specified requirements. Also, the Order permanently enjoins all individuals affiliated with Dealerbuilt from violating any provisions of the Safeguards Rule, and makes the Order applicable to all businesses connected to Dealerbuilt, which Dealerbuilt is to be broadly interpreted and Dealerbuilt is required to identify in detail via compliance reports, accompanied by sworn affidavits.
The FTC also imposes broad recordkeeping requirements on Dealerbuilt through the Order, requiring Dealerbuilt to create and retain for the next 20 years accounting records of all revenues collected, personnel records, consumer complaint records and responses to those records, and any documents relied upon to prepare mandate assessments and to demonstrate full compliance with the order.
Finally, within 10 days of any request by the FTC, Dealerbuilt is required to furnish compliance reports to the FTC or other requested information accompanied by sworn affidavits.
What prompted this broad enforcement action by the FTC against DealerBuilt? According to the FTC Complaint, a series of security failures resulted in the breach of a backup database through a storage device beginning in late October 2016, which resulted in the breach of personal information of nearly Seventy Thousand consumers, which included full names and addresses, telephone numbers, social security numbers, drivers license numbers, and birthdates of consumers as well as wage and financial account information of dealership employees. The FTC Complaint further alleges that Dealerbuilt failed to detect the breach and only learned of it after a customer called its chief technology officer demanding to know why customer data was publicly available on the Internet.
The FTC Complaint alleged that Dealerbuilt was a financial institution as defined by Section 509(3)(A) of the Gramm-Leach-Bliley Act, 15 U.S.C. Section 6809(3)(A) as a result of being “significantly engaged in data processing for its customers, auto dealerships that extend credit to customers.” The Complaint alleged that the “failure to employ measures to protect personal information” constituted an “unfair act or practice” and that the failures to (a) “develop, implement, and maintain a written information security program”; (b) identify reasonably foreseeable internal and external risks to the security, confidentiality, and integrity of customer information” and “assess the sufficiency of any safeguards in place to control those risks”; and (c) to design and implement basic safeguards and to regularly test or otherwise monitor the effectiveness of such safeguards” constituted a violation of the Safeguards Rule and an unfair or deceptive act or practice in or affecting commerce in violation of Section 5(a) of the Federal Trade Commission Act.
What should software companies and service providers take away from this FTC enforcement action? First and foremost, the FTC is making a definitive statement that if you are in the business of providing software or software services that have any sort of financial or accounting function to them, you are a financial institution for purposes of Gramm-Leach-Bliley and the Safeguards Rule is going to be deemed to apply to your business. Second, the FTC considers service providers accountable for the protection of any personal data they collect or store. Third, the FTC expects businesses using third party software or providers to have contracts in place with those software companies or service providers imposing security requirements, monitoring requirements, and explicitly requiring them to follow websites reporting on known vulnerabilities. Fourth, the FTC expects businesses to train and supervise employees on how to ensure the security of the company. The FTC specifically points businesses in its announcement to comply with its publication, Start with Security: Lessons Learned from FTC Cases.
Internet of Things (“IoT”) companies are on notice: the FTC is concerned about the the security of software installed to IoT and smart home products and is prepared to take enforcement action against companies to ensure that consumers are protected.
The FTC has just announced the proposed settlement of its case against D-Link filed in January, 2017, which mandates that D-Link put in place and maintain a comprehensive software security program for the next 20 years that incorporates certain specified requirements, including a “secure software development process” that incorporates specified software development safeguards to ensure the security of its devices.
These FTC imposed requirements include the following:
- Specifying in writing how functionality and features secure the devices;
- Engaging in threat modeling to identify potential security risks;
- Reviewing every planned release of code with automated static analysis tools;
- Performing pre-release vulnerability testing on each planned release of code;
- Performing ongoing code maintenance to address vulnerabilities as they are identified;
- Adopting remediation processes to address identified security flaws at any stage of the development process;
- Monitoring research on possible vulnerabilities to devices;
- Setting up a process for receiving and validating vulnerability reports from security researchers;
- Making automatic firmware updates to devices;
- Notifying customers at least 60 days in advance of any decision to stop making security updates to a devices; and
- Providing biennial security training for personnel and any vendors involved with the device software.
In addition to imposing the above requirements on D-LInk, the order gives the FTC the power of oversight to ensure ongoing compliance, and requires D-Link to obtain routine third party assessments by a professional with credentials specified by the FTC to perform in-depth reviews of D-Link’s security practices. The FTC specifically mandates that the assessment meet an approved standard as defined by the FTC: the International Electrotechnical Commission (“IEC”) standard for the secure product development life cycle. The FTC announcement is attached here and its order is attached here.
What prompted the FTC case against D-Link? The FTC complaint filed against D-Link alleged a failure by D-Link to take “reasonable” steps to secure software constituting “unfair acts or practices in or affecting commerce, in violation of Section 5 of the FTC Act, 15 U.S.C. Sections 45(a) and 45 (n)” and misrepresentations regarding D-Link’s security practices constituting a “defective act or practice, in or affecting commerce in violation of Section 5(a) of the FTC Act, 15 U.S. C. Section 45(a).” The FTC Complaint against D-Link is attached here.
What do companies engaged in IoT software development need to take away from this enforcement action? First of all, companies need to be aware that the FTC is applying its regulatory powers against companies to ensure that they are securing software in accordance with any representations made to consumers. Second of all, companies need to be aware that the FTC is looking to certain published standards by the IEC to provide the industry standards for software in this space, so IEC compliance certification may provide the measure of a company’s compliance with its security obligations. Third, the FTC has provided some suggested guidelines for companies to follow in the following publications: Careful Connections: Building Security in the Internet of Things and Start With Security: Lessons Learned from FTC Cases.
Two app developers have filed suit against Apple, Inc. over its App Store practices, following the recent decision by the U.S. Supreme Court in favor of consumers allowing a class action suit on similar issues to proceed. The case was filed in the U.S. District Court for the Northern District of California (San Jose).
According to Bloomberg, the developers’ suit is also a class action suit on behalf of developers nationwide whose products are sold through the App Store. Bloomberg reports that the developers claims are on antitrust grounds and also allege violations of California’s Unfair Competition Law, and that they are represented by a law firm based in Seattle, Hagens Berman, which previously won a $650 million settlement against Apple and other e-book publishing companies on similar claims in 2016.
As the Silicon Valley Software Law Blog previously reported, the U.S. Supreme Court case which just ruled in favor of consumers, presented a legal question as to whether consumers had standing to sue Apple, since developers, rather than consumers, have the direct, contractual relationship with Apple. However, the U.S. Supreme Court decision did not decide on the merits of the case and only decided whether the class action suit could proceed. Clearly, the developers would be presumed to have standing to bring a class action suit and the same legal question would not be relevant.
The timing of these suits coincides with increasing calls in Washington for greater regulation at the federal level of Apple as well as its fellow tech giants Amazon, Facebook, and Google, particularly with respect to federal antitrust law and the handling of consumer data. The New York Times is reporting that the four companies are in the process of assembling an “army of lobbyists” to defend them in Washington, spending a combined total of $55 million in lobbying last year.
Needless to say, the tech industry is under fire for many of its business practices, and it seems likely that some changes are on the horizon, regardless of its best efforts to maintain the status quo. The Silicon Valley Software Law Blog will continue to update you on any developments
The Supreme Court has ruled against Apple in an antitrust case claiming that the App store has created a monopoly over the sale of apps and has used the monopoly to charge consumers higher than the majority price. Justice Kavanaugh delivered the opinion of the Court that the plaintiffs are not barred from suing Apple under antitrust laws under the direct purchaser rule set forth in Illinois Brick Co. v. Illinois, 431 U.S. 720, 745-746 (1977). To view the Supreme Court’s decision, click here.
In this case, Apple had argued that the rule set by the Court in Illinois Brick allows consumers to sue only the party who sets the retail price, which in this case was the app developers rather than Apple. However, the Court found that Apple had misconstrued the rule and found compelling instead that consumers had to purchase the apps directly from Apple and “there is no intermediary in the distribution chain between Apple and the consumer.” In contrast, in the case of Illinois Brick, the company manufactured and distributed product, which was sold to masonry contractors, and those masonry contractors sold the products to general contractors, who then in turn sold them to consumers, so there was a multi-level distribution structure. The Court found that the brightline test stated by Illinois Brick was to allow direct purchasers to sue but to bar indirect purchasers from filing suit, in order to ensure an “effective and efficient litigation scheme in antitrust cases.”
The decision was 5-4 with Justice Kavanaugh having the deciding vote. Justice Gorsuch wrote the dissent, arguing that the majority has replaced “a rule of proximate cause and economic reality with an easily manipulated and formalistic rule of contractual privity.” According to the dissent, “[unless] Congress provides otherwise, this Court generally reads statutory causes of action as “limited to plaintiffs whose injuries are proximately caused by violations of the statute.” In this case, the dissent contends that the developers–and not the plaintiffs– are the parties who would be directly injured by any “monopolistic overcharge.”
The Supreme Court’s decision allows the antitrust case against Apple to progress and increases the likelihood of future App Store business changes on the horizon such as cutting the commission rate charged to developers, allowing developers to collect the fees, or other fundamental model changes.
However, the decision may have other implications that go beyond just the App Store. According to The Washington Post, Silicon Valley tech giants and an industry group called The App Association are raising concerns that this lawsuit may put other platform services at risk. Wired speculates that “a ruling in the plaintiff’s favor could have serious implications for other tech companies with similar business models,” citing Amazon in particular. In the end, The Verge predicts that perhaps the most significant impact that this case will have is to “affect how much power consumers have over digital platforms,” ultimately forcing online stores to be “more accountable toward their users.”
The Silicon Valley Software Law Blog will continue following this case as it moves forward.
The Prinz Law Office, which publishes the Silicon Valley Software Law Blog, has announced the opening of its new San Francisco Bay Area location in San Francisco. The new location will enable the firm to better serve clients in the northern Peninsula, the North Bay, and San Francisco. For more information on the announcement, please click here.
Silicon Valley Software Law Blog’s Kristie Prinz will be presenting a webinar on “Best Practices for Drafting Master Service Agreements & Managing the Service Relationship” on Friday, March 8th at 10 a.m. PST/1 p.m. EST. The Prinz Law Office will be sponsoring the event, which is intended for lawyers as well as businesspeople. To register for the event, please sign up at http://prinzlawstore.com/2019/01/best-practices-for-drafting-master-service-agreements-managing-the-service-relationship/
Silicon Valley Software Law Blog’s Kristie Prinz will be presenting a webinar on “Best Practices for Drafting SaaS Contracts & Managing SaaS Customer Relationships” on February 19, 2019 at 10:00 a.m. PST/ 1 p.m. EST. The Prinz Law Office is sponsoring the event, which will be intended for lawyers as well as business people. To register, please sign up at http://prinzlawstore.com/2019/01/drafting-saas-contracts-managing-saas-customer-relationships/
The Prinz Law Office, which publishes the Silicon Valley Software Law Blog, has announced the opening of its new Silicon Valley location in Palo Alto. The new location will enable the firm to better serve clients throughout the San Francisco Bay. For more information on the announcement, please click here.
Legal commentators have been raising alarms about the significant potential impact of The Foreign Investment Risk Modernization Act of 2018 (“FIRRMA”), since the legislation was signed into law in August, 2018. In case you are unfamiliar with FIRRMA, the legislation dramatically expanded the powers of the Committee on Foreign Investment in the United States (“CFIUS”) to conduct national security reviews of business deals, which obviously could have significant implications on the business community’s ability to close business transactions. The U.S. Treasury has developed a website that highlights for the public key points about FIRRMA and this review process.
In particular, FIRMMA now expands CFIUS review powers to include the following types of business deals:
- A purchase, lease, or concession by or to a foreign person of real estate located in proximity to sensitive government facilities.
- “Other Investments” by a foreign person in any unaffiliated U.S. business that owns, operates, manufactures, supplies, or services critical infrastructure; produces, designs, tests, manufactures, fabricates, or develops one or more critical technologies; or maintains or collects sensitive personal data of U.S. citizens that may be exploited in a manner that threatens national security. “Other investments” is defined to mean an investment that affords a foreign person access to material, nonpublic technical information in possession of the U.S. business, membership or observer rights on the board of directors or equivalent governing body of the U.S. business, or the right to nominate an individual to a position on the board of directors or equivalent voting body, or any involvement other than the voting of shares in the substantive decisionmaking of the U.S. business; the use, development, acquisition, safekeeping, or release of sensitive personal data of U.S. citizens maintained or collected by the U.S. business; the use, development, acquisition or release of critical technologies; and the management, operation, manufacture, or supply of critical infrastructure.
- Any change in rights that results in foreign control of a U.S. business or an “other investment” as defined above.
- Any transaction, transfer, agreement, or arrangement, the structure of which is intended to evade the review of the Committee.
FIRRMA further defines “critical technologies” to include “specially designed and prepared nuclear equipment, parts and components, materials, software and technology covered by part 810 of title 10, Code of Federal Regulations (relating to assistance to foreign atomic energy activities)” as well as “emerging and foundational technologies controlled pursuant to section 1758 of the Export Control Reform Act of 2018. ” While the list of what constitutes an “emerging and foundational” technology has yet to be defined, most legal commentators are expecting the list to include software that does not relate to nuclear technology, particularly in the areas of artificial intelligence, autonomous mobility, augmented virtual reality, cybersecurity, and financial technology. So, while the legislation is new and the full scope of its application and subsequent interpretation has yet to be determined, it is anticipated by most commentators that many software transactions involving foreign investment in a U.S. business will ultimately be deemed to be subject to the new CFIUS review powers.
What does this mean for the software industry? Well, the full impact of the law is yet to be determined and is more the subject of extensive speculation in the legal industry at the moment, but it does mean that software companies could be subject to more federal compliance obligations when they are doing deals that involve foreign investment, that these compliance obligations could slow down or even derail the closing of some deals, and that software companies could potentially be subject to significant fines up to the amount of the deal if they fail to comply with their new obligations. So, it certainly means that U.S. based software companies need to be aware of FIRRMA and need to closely follow any future developments related to the law, in order to potentially comply with it on future deals.
The Silicon Valley Software Law Blog will continue to follow the developments regarding this law and how it is applied and interpreted with respect to the software industry. For more information on how the expansion of CFIUS powers may impact Silicon Valley industries other than software, please check out the blog posting on our affiliated blog, the Silicon Valley IP Licensing Law Blog.
The software industry is raising concerns about the potential consequences of Australia’s recent passage of legislation to provide law enforcement with expansive new powers to compel the disclosure of encrypted data.
According to ITPro, the “Telecommunications and Other Legislation Amendment (Assistance and Access) Bill 2018” was approved by a 46-11 majority in the Australian parliament last month. As The Verge reports, the newly passed legislation grants to law enforcement new notice powers of mandatory technical assistance and technical capability, which “require companies to give access to encrypted data if available, or to build the capacity to provide such access if they are unavailable.” Additionally, as reported by The Verge, the legislation grants a voluntary technical assistance request power “that does not have to be publicly reported.” According to The Verge, the fine for noncompliance can be up to $10 million AUD (approximately $7.2 million USD).
The Verge reports that the new law also uniquely enables the Australian government to approach individuals such as key employees in order to compel their cooperation rather than limiting the enforcement powers to merely compelling cooperation by institutions. The penalty for any individual’s failure to cooperate could result in a prison sentence.
As Wired has reported, the legislation has been strongly opposed by the tech industry on the grounds that “if Australia compels a company to weaken its product security for law enforcement, that backdoor will exist universally, vulnerable to exploitation by criminals and governments far beyond Australia.” Also, as Wired has noted, any company that complies with Australia’s law is likely to then be required to provide the same access to another country. Fortune suggests that the legislation is particularly intended to target What’sApp and Signal.
According to The Verge, Apple’s position on the legislation has been that “encryption is actually a defense against cyberattacks and terrorism” and that “more of it is needed to make citizens safe, not less.” Apple took its concerns directly to the Australian parliament, according to Threatpost, which has posted a letter reportedly submitted by Apple to parliament. Threatpost also reports that Cisco and Mozilla have also been vocal in their opposition to the legislation. Commentator and human rights lawyer Lizzie O’Shea also observes to The Verge that “once these [backdoor] tools exist, then it would be easy for Australian authorities to share them with their counterparts in allied nations,” particularly since Australia is part of the Five Eyes intelligence sharing agreement in which Great Britain, Canada, New Zealand and the United States also participate.
The Australian government’s position, according to The Verge, is that the powers are necessary to defend citizens against terrorism and crime and that the powers will not introduce a “systemic weakness” into the technology. However, a prevailing criticism has been that “systemic weakness” is not actually defined by the legislation. Fortune reports that the Australian Labor Party is already seeking to amend the legislation, particularly to define “systemic weakness.”
Clearly, Australia’s new legislation has the potential to have a far-reaching impact on software companies and individuals working in the software industry. The Silicon Valley Software Law Blog will continue to follow this issue as it develops.
Silicon Valley Software Law Blog’s Kristie Prinz will present a webinar on “Negotiating SaaS Agreements: Drafting Key Contract Provisions, Protecting Customer and Vendor Interests” for Virginia-based Clear Law Institute on February 8, 2019 at 10:00 a.m. PST/ 1:00 p.m. EST. The sponsor has made available a 35% discount off the registration fee with the discount code KPrinz148075. To register, please sign up here: https://clearlawinstitute.com/shop/webinars/negotiating-saas-agreements-drafting-key-contract-provisions-protecting-customer-and-vendor-interests-020819/.
If your company has either pursued Privacy Shield certification, or publicly claimed to be in pursuit of Privacy Shield certification, recent enforcement action by the Federal Trade Commission (“FTC”) should put your company on notice that failure to maintain your certification may render you subject to FTC enforcement activity if you continue to make representations on the Internet or in advertising materials related to Privacy Shield.
The FTC has just announced settlements with four companies, IDmission, LLC, mResource LLC (doing business as Loop Works LLC), SmartStart Employment Screening, Inc., and VenPath, Inc. on allegations related to EU-U.S. Privacy Shield compliance.
The FTC’s complaint against IDmission, LLC, which is a cloud-based technology platform, focuses on the company’s website representations of compliance with the EU-U.S. Privacy Shield framework despite the company’s failure to actually complete the certification process. In contrast, FTC’s complaints against mResource, SmartStart, and VenPath, which are companies providing talent management and recruiting services, employment and background screening services, and data analytics services respectively, all focus on the companies’ website representations of Privacy Shield certification despite failing to maintain the certification.
The settlements now render these four companies subject to direct FTC oversight and monitoring with respect to their advertising and compliance activities going forward.
From this enforcement action, it is clear that the FTC is on the lookout for companies who are making claims about the EU-U.S. Privacy Shield that they are not actually meeting, and that the FTC is prepared to exercise its enforcement authority against any company that fails to meet its representations as they pertain to Privacy Shield.
So, software companies, the FTC is putting you on notice: you need to self-monitor your Privacy Shield certification and ensure that you maintain the certification at all times, and to ensure that you are compliant with certification requirements, particularly if you are making advertising-related representations related to Privacy Shield. The FTC is watching.
According to Tech Crunch, commonly utilized unethical practices include as follows:
- that the apps are too aggressive in obtaining subscriptions;
- that the apps offer little functionality without upgrading;
- the apps provide no transparency around how free trials work;
- and the apps make it difficult to stop subscription payments.
Customer trust is the cornerstone of the App Store’s success. Apps should never prey on users or attempt to rip-off customers, trick them into making unwanted purchases, force them to share unnecessary data, raise prices in a tricky manner, charge for features or content that are not delivered, or engage in any other manipulative practices within or outside of the app.
So, if Apple requires adherence to a code of conduct, why is it alleged that unethical subscription practices are still so rampant on the App Store? And why hasn’t the Federal Trade Commission (“FTC”) stepped in, or more state attorney general offices intervened? It is unclear, since as Forbes argues, the more these practices are allowed to continue, the more the practices are likely to detrimentally affect the entire App Store market. As both Tech Crunch and Forbes have pointed out, the App Store is full of reviewer complaints about the specific practices of various apps, so at least Apple has definitely been on notice that there was a problem. Presumably the FTC and at least one or two state attorney general’s offices have been made aware of these issues as well.
As a Silicon Valley SaaS and software licensing attorney, however, I would encourage App developers profiting off practices that seem questionable or are the targets of a significant number of annual complaints to consider modifying those practices as quickly as possible, as you and your business run the risk of not only attracting a lawsuit by the FTC or an attorney general’s office but you also run the risk of attracting a class action suit on behalf of subscribers who were allegedly harmed by your App. This type of suit is not without precedent, and could come with a significant damage award. Your subscription terms do matter and they need to be viewed as fair and reasonable to your subscribers. You are on notice: these practices are being brought under scrutiny by the press and scrutiny by regulators, states, and class action attorneys is likely to soon follow.
The State of California has just agreed to delay the enforcement of S. B. 822, also known as the California Internet Consumer Protection and Net Neutrality Act of 2018, until litigation is decided regarding whether the FCC can preempt state net neutrality laws is decided by the US Court of Appeals for the District of Columbia Circuit. Attached is a copy of the stipulation and agreement filed in the US District Court for the Eastern District of California. As Ars Techica reported, California has agreed to refrain from enforcement of the law until after the US Court of Appeals case has been decided and any appeals have been exhausted.
As the Washington Post reports, the outcome of the case before the D.C. Circuit could result in the rejection of the FCC’s 2017 rule change, which then would mean that S.B. 822 would become redundant. However, both the Washington Post and Fortune are reporting that the D.C. Circuit could rule on the issue of preemption as well, which could potential impact S. B. 822 and other similar state laws.
If your company is like most, you postpone the procurement of insurance policies until you absolutely have to obtain them, expecting to be able to obtain whatever you need on demand.
However, if your company is in the software space and you anticipate a significant deal is on the horizon, you should be anticipating your needs in advance of actually starting those negotiations, or you may find yourself in a situation where you have to commit to maintaining insurance during the relationship that you may not actually be able to buy on the open market. Why is this a problem? Well, this puts you in the position of potentially breaching the terms of the “significant” deal before you ever start performing those terms, which can obviously have serious consequences for your company’s business if your breach is ever discovered. Since the usual insurance terms in these types of deals require the submission of certificates of insurance as proof of coverage, any failure to procure the insurance required is not likely to stay undiscovered for an extended period.
Notwithstanding the foregoing, even if you do not breach the terms of the negotiated deal, it is far better to negotiate the scope of indemnification risks you will be incurring with advance knowledge of the terms of the insurance policies you already have in place, as you can then negotiate limits of liability within the coverage of the insurance coverage previously obtained.
So, what types of insurance requirements should a software company anticipate when it goes to negotiate a significant deal?
First and foremost, companies should anticipate the requirement of a general commercial liability policy. This is a standard commercial insurance policy that every business, regardless of whether or not in the software industry, should keep.
Second of all, companies should anticipate the requirement of a commercial auto insurance policy to cover the risk that employees or contractors may have an accident while traveling back and forth to a customer or business partner’s work site.
Third of all, companies should anticipate the requirement of an errors & omissions policy to cover the risk that company workers will intentionally or negligently act in a way that harms the customer or business partner.
Fourth, companies should anticipate the requirement of a cyberinsurance policy to cover the risks of hack attacks, data breaches, and third party cybercrimes, as well as notification costs and other costs to remedy a breach after it occurs.
Fifth, companies should anticipate the requirement of an umbrella policy to cover losses in excess of the insurance limits available.
What types of limits of coverage should a software company anticipate? In my experience, larger deals will come with larger expectations, so the more significant the deal, the more insurance your company should be lining up in advance.
The bottom line is that doing some advance planning with respect to insurance before your software company commences negotiations on a significant deal will save your company the worry down the road of being discovered to be in breach of the deal you just closed if you find that meeting the insurance requirements you agreed to is not quite as easy as you anticipated. Furthermore, it will enable you to go into negotiations better prepared to be able to negotiate terms that actually protect your company.
Governor Jerry Brown has signed into law S.B. 822, also known as the California Internet Consumer Protection and Net Neutrality Act of 2018. The law is intended to go into effect on January 1, 2019 and, according to CNN, will establish the “strictest net neutrality protections in the country.”
However, the U.S. government has responded to the California action by seeking a preliminary injunction to block the law from going into effect. A DOJ press release announcing the suit is attached here, in which the DOJ asserts that “Once again the California legislature has enacted an extreme and illegal state law attempt to frustrate federal policy.”
However, according to the Electronic Frontier Foundation, the core argument by the DOJ and FCC articulated in the court filings is not that states cannot pass net neutrality laws but that a pending lawsuit in the D.C. Circuit filed by the California Attorney General challenging the FCC’s repeal of net neutrality should be decided before the legality of the passage of the California Internet Consumer Protection and Net Neutrality Act of 2018 can be decided.
Wired reports that the dispute between California and the federal government “raises novel questions about the relationship between the federal government and the states.” At the heart of the dispute is whether California has the legal right to pass a law on net neutrality, and whether the FCC has the legal right to prevent states from adopting net neutrality laws. While in general pre-emption only occurs when there are incompatible state and federal rules, Wired reports that “[i]t’s not unheard of for the federal government to preempt state or local regulations when those regulations conflict with federal policy, even when the federal policy is not to regulate.” In contrast to the current facts, however, Wired reports that the past example of this type of pre-emption involved a decision by Congress as opposed to a federal agency.
Clearly, California and the federal government are now headed for a legal show-down in federal court. The Silicon Valley Software Law Blog will keep you posted as the legal battle further develops.
If your company has just landed a big development project for a third party, do not underestimate the importance of the agreement in protecting the revenue stream you are being offered in exchange for your development services.
The typical development agreement requires lump sum payments in installments throughout the term of the relationship. Also, the typical development agreement will have at most a statement of work connected with the project and will rarely be accompanied by technical specifications or milestones, with respect to which approval can be sought at the various phases of the development.
Why can this be a problem? Well, if your company agrees to take on a large development project and has not defined contractually in detail the technical specifications and standards required to be performed, or developed detailed milestones that can be tied to satisfaction of particular phases of the project, how exactly can you prove that you earned the money paid in installments if the customer pulls the plug on the project at any stage? How exactly do you prove that you fulfilled your responsibilities with respect to the development project if you never actually reached agreement as to the technical terms of the development project?
The reality is that it can be very hard to enforce an agreement when the key terms of the relationship were never actually memorialized in writing. While the risk of not being able to enforce your agreement may be low in low dollar value development projects, that risk escalates dramatically as the dollar value of the project also increases into the hundreds of thousands of dollars or even millions.
In general, when I see disputes involving development projects, the dispute can almost always be attributed to a poorly drafted agreement between the parties.
So, what can you do to minimize your risks of taking on a development project?
First and foremost, obtain help from experienced technology transactions counsel when your company is first approached with a potential development project. An experienced attorney in this space can guide you through the negotiation process at the early stages, so that you don’t have to renegotiate terms that have already been agreed to by the potential development partner. It can be very hard to get partner buy-in on developing and memorializing good technical terms when the parties are already weeks or months into the negotiation the deal.
Second of all, ensure that the technical specifications and requirements for the project have been defined in detail, and develop milestones throughout the development process, which can be approved. Also, develop a process that is very well-defined within the contract to obtain that approval. If a specific timeline is required at any part of the process, develop terms that reflect the agreed upon timeline as well.
Third, instead of merely requiring payment by installments through the development work, develop payments that are tied to the accomplishment of specific well-defined milestones, in order to ensure that your company is can prove that any payment received was earned a s a result of the successful accomplishment of the applicable milestone(s).
The bottom line is that a big development project should be accompanied by a very detailed, technically-specific development agreement if a company prefers to avoid big legal headaches down the road. It is in your company’s best interest to ensure that any development agreement that the parties execute is drafted to protect the anticipated revenue stream from the development project.
Silicon Valley Software Law Blog Sponsor, The Prinz Law Office, has announced today the launch of a new option for clients: the “subscription model” billing model. The firm will initially be offering daily and half-daily subscription models. The model is anticipated to potentially be a good fit with companies having ongoing legal review or advice needs in the transactional space that can be easily anticipated and scheduled in a pre-set block of time.
For information about how the new subscription model will work, please contact the firm for additional information.
I was recently asked for a list of the top mistakes the average company will make when they enter into a software deal without getting an experienced software lawyer involved early in the negotiations. I thought it was an excellent question, so I wanted to share my thoughts on the issue with this audience.
First and foremost, the most common mistake I run into with all types of technology negotiations, but especially with negotiations in the software space, is that companies handling their own software negotiations often end up negotiating with the wrong contract as the starting point. For example, the parties may negotiate from a software license template when they need a SaaS agreement template instead, or they may negotiate from a master services agreement or a hosting agreement when the deal they were doing actually involved SaaS terms. A knowledgeable software attorney will know and understand that the terms of a well-drafted template will be completely different based on the technology model under negotiation and will be able to ask the right questions in order to identify the right technology model and therefore the necessary baseline terms that need to be addressed in a well-drafted agreement.
Another common issue I run into is that even if the parties choose the right initial type of contract to begin the negotiations with, they begin the negotiation with a template that was designed for an entirely different product or relationship than what is currently being contemplated. Obviously, it is going to require less negotiation to reach a good deal when the starting point for the negotiation is a set of proposed terms that applies to the right type of technology transaction and the particular product or relationship under negotiation. Also, the terms of the signed contract are far more likely to be meaningful when they were developed around the right product and services. Otherwise, they are likely not to include the key deal terms or contemplate any of the issues that could come up between the parties. I see many signed contracts that are little better than a handshake because the terms agreed to are almost completely irrelevant to the transaction. An experienced software attorney is going to be able to ask the right questions to determine whether the contract terms were written for the appropriate product or services.
A third issue I run into is that the contracts do not sufficiently contemplate how the relationship will evolve over time. A standard practice in the industry is to rely exclusively on a list of prices to determine on the fee-related issues in the agreement. What is typically missing is all the terms that explain how the pricelist will be implemented. While this might not be fatal to the relationship if there is some sort of initial agreement on the price to be paid overall, few software business relationships in 2018 are up-front, fixed price relationships. Most relationships now are intended to generate recurring revenue streams and anticipate new fees as new seats, services, and functionality are added. So, a mere pricelist is almost never adequate to support an ongoing relationship. Thus, if an experienced software attorney is not involved with the deal, there is a high likelihood that the contract signed will not have all the necessary terms to explain precisely how all the fees will be assessed going forward.
A fourth issue typically overlooked by a contract negotiated without the assistance of experience software counsel are all the technical concerns about the transaction. In many software deals, the service level is absolutely critical to the transaction. However, more often than not, the service level agreement being relied on by the parties was copied off the Internet and has absolutely no significance or relevance to the service being offered or provided. Also, even where the service level agreement was obtained in a more thoughtful way, it is very common to find the agreement full of terms that are so poorly written or that have so many carve-outs that it is completely unenforceable. In addition, many relationships contemplate the performance of a variety of services which are never addressed in the contract at the technical level required to reach any sort of understanding regarding those services. An experienced software counsel will be able to ask the right questions to understand all the technical aspects of the deal between the parties and will be able to determine all the terms that have been omitted from the contract before it is executed.
A fifth issue typically missed when a contract is negotiated without the assistance of experienced counsel is the contemplation of all the issues that could arise with regard to the suspension of services. In 2018, the service provider frequently has the ability to “suspend” a company’s access to the software and the data stored therein at any time and could just as easily erase all of that data. However, few contracts that I see really address the issue of suspension at the level required to address all possible issues that could arise between the parties. An experienced software counsel will ask the right questions to identify these issues and address them in the contract.
A sixth mistake that I often encounter is contracts that contain elaborately negotiated indemnification clauses but never really contemplated all the related issues such as whether the indemnification could ever be enforced and whether the focus of the indemnification clause negotiated was on the liabilities most relevant to the transaction. An experienced software counsel will be knowledgeable about software indemnification clauses and all the issues relevant to the clauses in order to ensure that the maximum amount of protection is in place.
The bottom line is that an experienced technology transactions counsel understands technology sufficiently to ask enough questions about the relationship envisioned to determine all the key terms that were never contemplated in the agreement, and can add that additional level of skill and expertise to the negotiation of the deal that a general business lawyer or business person simply cannot. Technology deals are fundamentally technical and only someone that understands technology and technical deals sufficiently is going to be able to evaluate proposed terms sufficiently to negotiate them appropriately in order to look after the party’s best interests.
USA Today is reporting that multiple technology and telecommunication companies are lobbying Congress to pass federal privacy legislation that would pre-empt the new privacy law recently passed in California which grants sweeping protections to consumers. In particular, USA Today reports that Amazon, AT&T, Apple, Google, Twitter and Charter Communications are leading the lobbying effort and argue that inconsistent state laws will “make it tough for companies to operate” and would “threaten innovation.”
Of course, as USA Today reports, the lobbying companies are seeking weaker regulations than exist in the European Union or that were just passed in California, with the sole exception of Apple, which relies on a different business model and was reportedly the only company “at the hearing to argue that the bar for federal legislation should be set “high enough” to protect consumers.” As The New York Times reported, the goal of the tech industry is to institute federal rules that would give technology companies wide leeway over how personal information is handled. The Electronic Frontier Foundation describes the tech industry’s goal as “neuter[ing]” California for a weaker law at the federal level.
According to The New York Times, however, the tech industry’s efforts are not limited to just federal lobbying efforts. In fact, The New York Times reported that lobbying efforts are underway in California as well, and that the California Chamber of Commerce and other business and tech groups have just submitted nineteen pages of bill edits to State Senator Bill Dodd, one of its authors. In addition, The New York Times reports that the groups are also asking California to delay enactment for a year.
The bottom line is that the tech and telecommunication industries are actively lobbying at both the federal and state levels to ensure that California’s new privacy law never goes into effect in its current form. Convincing Congress to pass a federal law that they hope to be able to influence and shape has now become the top priority for both industries.
Silicon Valley Software Law Blog Author Kristie Prinz will be presenting a webinar on “Negotiating SaaS Agreements: Drafting Key Contract Provisions, Protecting Customer and Vendor Interests” for Clear Law Institute on 10/26/18 at 10:00 a.m. PST. Clear Law Institute is providing a registration discount for attendees who register with the discount code: KP119433. To register, sign up at the following link:
If you are a SaaS company, you may come across a customer or prospective business partner who insists on the inclusion of a source code escrow agreement as part of the deal terms. If this scenario arises, you may be inclined to immediately agree to the prospective customer or business partner’s terms in order to close the deal you are negotiating. However, what do you need to know as a SaaS company about source code escrow before you agree to include source code escrow in the terms of a transaction?
First of all, you should know that the standard source code escrow product was not designed for SaaS and is probably not going to be very effective for a customer or business partner if they ever need to rely on it. The traditional source code escrow offering was intended for a traditional software product, which is downloaded to hardware and is updated or upgraded on a periodic basis. In the traditional source code escrow agreement, the deposit materials are generally only updated a few times a year. However, in the SaaS product scenario, the product is often updated on a continuous basis, so updating the deposit materials only a few times a year is unlikely to be sufficient. Similarly, in a traditional source code escrow agreement, the backup and storage of the data is unlikely to be addressed. However, in the SaaS agreement scenario, the customer or business partner is unlikely to have access to the data in the cloud, so the party receiving access to the deposit materials is more likely to expect the backup and storage of SaaS data to be a key component of the escrow relationship.
For this reason, many technology escrow companies are offering a special escrow products intended for SaaS only, which provide for the continuous update of deposit materials and include data as part of the deposit materials. The SaaS version of the escrow product is more likely to provide uninterrupted access to the full set of materials that the customer or business partner previously had access to in the cloud, so it is likely to be the better fit for the customer or partner seeking source code escrow as part of the deal terms.
Secondly, you should know that the SaaS version of the source code escrow product will likely be more expensive than the traditional product since it is going to be a more labor-intensive solution. A source code escrow company can expect in a SaaS product scenario to perform significantly more services to ensure that the escrow works if needed than it would have had to perform in a traditional software scenario, given the ongoing nature of the updates and upgrades. As a result, the costs of SaaS escrow are likely to be significantly higher than traditional software escrow, which should certainly be contemplated in the allocation of escrow costs between the parties.
Third, you should know that you may not be able to obtain the rights you are seeking to use the escrowed code in a release scenario. In SaaS, users typically receive access rights rather than license rights to the use of the intellectual property. As a result, a SaaS provider can build products that incorporate open source code and offer access rights to the end product, even though the provider is prohibited from distributing the software otherwise. The SaaS provider can also incorporate third party code into the product that cannot be sublicensed to third parties, even in an escrow scenario. So, it is certainly possible that the SaaS provider will not have the necessary rights in the SaaS product to be able to authorize the license grant to the escrowed materials, which could potentially result in the customer or business partner receiving physical copies of the source code and data but not having the rights necessary to use the copies procured.
Fourth, you should consider that mere possession of a functional copy of the source code and data may not be sufficient for a customer or business partner to continue using the software and applicable data in the event of a release condition. In fact, the customer or business partner may require transitioning services or access to the SaaS provider’s know-how before it is able to resume use of the software. Consequently, transitioning services and know-how transfer may be important considerations that need to be addressed in any escrow terms.
Fifth, you should consider that the very nature of SaaS escrow may result in the escrow provider having control over any collected data uploaded to the SaaS product and that the escrow provider could be vulnerable to a data breach arising from the acts or omissions of an employee or third party. Thus, the deal terms should contemplate the responsibilities and liabilities of the respective parties regarding the data and the potential for a data breach, as well as any available insurance coverage to protect against this risk.
All in all, while escrow products are now available and on the market, which may meet the needs of a prospective customer or business partner seeking source code escrow to a SaaS product, a SaaS provider will have a variety of considerations to contemplate before acquiescing to such demands in a negotiation. In the end, the decision of whether or not to agree to escrow terms should be based on a careful evaluation of all of the above considerations.
After spending months preparing to comply with the European Union’s General Data Protection Regulation (“GDPR”), software companies now have a new U.S. data privacy law to be concerned with. California has just passed a landmark data privacy law of its own: the Consumer Privacy Act of 2018. To view the text of the law, click here.
As USA Today reports on the new law: “[it] is similar to Europe’s General Data Protection Regulation rules, which took effect last month, but goes further, allowing consumers to opt out of their data being shared instead of forcing them to opt in to continue using online services.”
For its part, The New York Times characterizes California’s new law as less “expansive” than the GDPR but “one of the most comprehensive in the United States.” However, Wired describes the new law as “adding to [the GDPR] in crucial ways.” In particular, Wired points to the fact that the GPDR requires opt-ins to collect and store data but in practice the opt-ins actually used do not give consumers a choice other than to opt-in in order to use the service; however, California’s law will prevent companies from denying service to consumers who opt out.
According to Tech Crunch, the key protections of California’s new law are requiring companies to comply with consumer requests to delete data, providing a new consumer right to opt out of data being sold without any sort of penalty being assessed, preserving for companies the right to provide “financial incentives” to collect data, and granting state authorities the right to fine companies for violations.
As you might expect, it is being reported that there were extensive corporate lobbying efforts employed by some prominent companies against the proposed legislation. The New York Times and USA Today are reporting that Google, Facebook, Verizon, Comcast and AT&T each contributed $200,000 to a committee opposing the ballot measure and that lobbyists are expecting businesses to pour between ten and a hundred million dollars into campaigns against the law over the next few months.
All in all, there seems to be a consensus that this legislation is going to have a tremendous impact on data privacy nationwide, despite its limited application to California and the fact that it may still be amended before it goes into effect in 2020.
As for the software industry, the worries about data privacy compliance now shift from Europe to California and potentially the other 49 states. Fortunately, the industry has two full years to prepare for the new California regulation.
If your software company is relying on so-called “Gig workers” to provide a service managed by your app and software platform, then you need to know about a California Supreme Court ruling just issued this week, which is likely to severely limit your ability to rely on the “Gig worker” model going forward in the state of California.
The California Supreme Court held that the following three part test is the standard in California for classifying a worker as an independent contractor: (a) the worker is free from the control and direction of the hiring entity in connection with the performance of the work; (b) the worker performs work that is outside the usual course of the hiring entity’s business; and (c) the worker is customarily engaged in an independently established trade, occupation, or business. The Court emphasized that with respect to the last part of the test, the worker will have made an affirmative decision to go into business, taking such steps as “incorporation, licensure, advertisements” and “routine offerings to provide the services of the independent business to the public or to a number of potential customers, and the like” and will not just be “designated an independent contractor by the unilateral action of the hiring entity.” A copy of the decision is linked here.
According to CNN, California’s test for classifying workers as independent contractors will now be the toughest test in the United States, and the Supreme Court’s ruling will significantly limit the ability of online platforms to treat workers as contractors, except perhaps in cases where the workers are in the same line of business off the platform and also work with other similar platforms.
As the LA Times reported, “[the] decision has implications for the growing gig economy, such as Uber, Lyft, and other app-driven services” but suggested that the implications would go beyond the gig economy to virtually every industry and would prompt California businesses to “immediately question whether they should reclassify independent contractors.”
As a Silicon Valley technology lawyer who has been closely following the litigation testing the Gig worker model, I have anticipated a legal decision that would limit the increasing reliance within the industry on Gig workers to build new business models and have been surprised that we did not already have such a decision. The California Supreme Court’s ruling does put an online business platform’s decision to rely on independent contractors to perform services offered under the platform under significantly more scrutiny that had existed in the past. But I would argue that the implications go far beyond state employment laws. I would argue that perhaps an even more important consequence of this ruling that it imposes very clear liability on the online business company for the acts of the workers arranged through the online business platform. I have long been concerned about the safety implications of procuring services from relatively unscreened independent contractor workers and have expected that this would become a problem for the online business platform model down the road precisely because of the reliance on Gig workers. Indeed, there seem to be now reports on almost a weekly basis of crimes being committed by Gig workers against customers. CNN published a report just this week on sexual assault and abuse cases against Uber drivers. This article just tracked reported sexual assault and abuse cases but there are certainly many more unreported cases that could not be included in the CNN report, since sexual crimes tend to be very under-reported due to the very nature of the crimes. If this report had included other types of crimes, who knows what the number of reported crimes would have been just for Uber? For Uber as well as all of its competitors? I would argue that this case not only has the potential to change the relationship that many online platforms have with workers but also it has the potential to impose greater responsibility on online platforms with respect to worker conduct and keeping their customers safe. It is an open question, however, what imposing the responsibilities of an employer in terms of liability for workers will do to business models that have taken off largely due to the lower cost to operate a model which provides services without taking on all the traditional liabilities associated with providing that service.
The bottom line is that if you are software company operating under the Gig worker model or building a business where you plan to rely on the Gig worker model, you need to be aware of this decision and to start following how it is applied going forward, as it is a significant legal development, and it is certain to have an ongoing impact on your business.
The California legislature is considering a bill that would restore net neutrality on a state-wide level when the FCC repeal of net neutrality takes effect next week.
According to the Mercury News, SB 822 would be “stronger” than the net neutrality rules adopted in President Obama’s administration, which “required equal treatment of all Internet traffic,” and “prohibited the establishment of Internet slow and fast lanes.” SB 822 also prohibits “zero rating”, which as Mercury News reports, is when “Internet providers exempt certain content, sites, and services from data caps.” SB 822 further prohibits public agencies from entering into contracts in violation of the bill.
SB 822 is opposed by the broadband industry on the basis that the industry opposes state-level net neutrality rules, but is supported by the Electronic Frontier Foundation, the ACLU, the mayors of many of the largest cities in the state including San Francisco, Oakland, San Jose, Sacramento, and Los Angeles.
If SB 822 is adopted, California would not be the first state to enact a net neutrality law. The New York Times reported that Washington State signed the first net neutrality bill. The governors of Montana and New York have signed executive orders making net neutrality effective at the state-level, according to reports by The New York Times and The Verge.
If your software company has pursued Privacy Shield certification or is contemplating pursuit of certification, then you should know that an Irish Court has referred a case to the Court of Justice of the European Union, which could potentially invalidate the EU-U.S. Privacy Shield as it previously did with the Privacy Shield predecessor, Safe Harbor, according to a Tech Crunch report.
As Tech Crunch explains, the current case against Facebook was initiated by the lawyer and privacy campaigner Max Schrems, who also initiated the prior compliant which resulted in the judgment by the Court of Justice of the European Union overturning Safe Harbor.
The High Court of Ireland referred eleven questions for consideration to the Court of Justice of the European Union, including several questions (nos. 9 and 10) that specifically deal with the adequacy of the EU-U.S. Privacy Shield. Tech Crunch suggests that this referral could lead to a complete collapse of the EU-U.S. Privacy Shield framework.
With the evident uncertainty over the future of Privacy Shield: does it still make sense to pursue and/or maintain certification if your company has European customers? In light of the fact that the new data privacy rules in Europe (the “GDPR”) go into effect May 25th, which increase the fines for violations, and the Privacy Shield framework remains the best guidance currently available for American companies intending to do business in Europe, pursuit of certification remains a sound business and legal strategy. However, companies need to follow what happens with this challenge and remain cognizant of the fact that Privacy Shield has not yet been tested by this European high court and it is uncertain that it will withstand the current challenge.
I recently presented for myLawCLE on the topic of drafting software hosting agreements. I am pleased to now be able to share a recording of the full, two-hour presentation with interested Software Law Blog readers:
Silicon Valley Software Law Blog Author Kristie Prinz will be presenting a webinar on “Negotiating SaaS Agreements: Drafting Key Contract Provisions, Protecting Customer and Vendor Interests” on June 11, 2018 at 10:00 a.m. The program will be sponsored by Virginia-based Clear Law Institute. To register for the event, sign up at the Clear Law Institute website.
If your business is in the software industry and you are doing any business in Europe, you should be aware of the EU General Data Protection Regulation (“GDPR”), as it will apply to your business when it goes into effect on May 25, 2018. You also may want to consider pursuing Privacy Shield certification before the GDPR goes into effect.
What exactly is the GDPR? This is the law passed by the European Parliament in 2016 which changes the laws relating to data privacy regarding EU citizens. Attached is a copy of the full text of the GDPR.
The GDPR will apply to any business processing the personal data of anyone residing in the European Union, regardless of the location of the business. Article 3 of the GDPR provides:
- This Regulation applies to the processing of personal data in the context of the activities of an establishment of a controller or a processor in the Union, regardless of whether the processing takes place in the Union or not.
- This Regulation applies to the processing of personal data of data subjects who are in the Union by a controller or processor not established in the Union, where the processing activities are related to (a) the offering of goods or services, irrespective of whether a payment of the data subject is required, to such data subjects in the Union; or (b) the monitoring of their behaviour as far as their behaviour takes place within the Union.
Article 4 of the GDPR defines “personal data” to constitute:
any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person.
Article 4 of the GDPR defines “processing” to constitute:
any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction.
Some highlights from the legislation include as follows:
Article 5 of the GDPR provides guidelines on how data should be processed, which includes keeping it in a form “which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed.”
Article 7 of the GDPR establishes the requirements for procuring consent to data processing, which include that “the request for consent shall be presented in a manner that is clearly distinguishable from other matters, in an intelligible and easily accessible form, using clear and plain language” and that the “data subject shall have the right to withdraw his or her consent at any time. Article 8 of the of the GDPR sets forth the conditions for procuring consent from children, including “where the child is below the age of 16 years, such processing shall be lawful only if and to the extent that consent is given or authorised by the holder of parental responsibility over the child.”
Article 9 of the GDPR prohibits the processing of certain kinds of data:”personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership, and the processing of genetic data, biometric data for the purpose of uniquely identifying a natural person, data concerning health or data concerning a natural person’s sex life or sexual orientation.” Article 10 of the GDPR adds to this list the processing of data about criminal convictions unless processed by an official authority.
Article 17 of the GDPR codifies the so-called “right to be forgotten.”
Article 27 of the GDPR requires companies processing data of EU residents outside the European Union to designate a representative of the controller or processor in the European Union, except in the following circumstances:
processing. . . .is occasional, does not include, on a large scale, processing of special categories of data as referred to in Article 9(1) or processing of personal data relating to criminal convictions and offences referred to in Article 10, and is unlikely to result in a risk to the rights and freedoms of natural persons, taking into account the nature, context, scope and purposes of the processing; or
[where processing is by] a public authority or body.
Article 33 of the GDPR requires a data breach notification to be provided to the appropriate supervisory authority within 72 hours of becoming aware of a data breach.
Article 46 of the GDPR limits the transfer of personal data to a third party country or international organization only if “appropriate” safeguards are in place and effective legal remedies are in place which may include “contractual clauses between the controller or processor and the controller, processor or the recipient of the personal data in the third country or international organisation.”
The bottom line is that software companies need to spend some time familiarizing themselves with the GDPR and consider how their business may be impacted by the legislation before it goes into effect in May, 2018. If your company does business in Europe or hopes to do business in Europe in the foreseeable future, this privacy legislation will impact future deals with potential European customers and will certainly affect what you can do with personal data obtained through such relationships going forward.
I was recently asked how to recognize that a software contract is poorly written. Upon consideration, I’ve come up with six signs to watch for in order to identify a poorly written software contract.
In my experience, the first sign of a poorly drafted contract is that contract completely confuses the software licensing and SaaS technology models, so that it’s extremely unclear as to what kind of product that the software provider is actually selling. If the product is a software license, the contract should contain a clear license grant confirming the licensee’s rights in the intellectual property and defining the scope of the license. Any hosting, maintenance, technical support, or other services should be made available by separate written agreement (i.e. hosting contract, maintenance contract, technical support contract, professional service contract) but should not be included in the face of the license agreement. On the other hand, if the product is a SaaS agreement, no license grant should be included in the contract and the contract should instead contain a clear grant of access and use rights. The terms “licensor” and licensee” should be absent from the contract. On the other hand, services like hosting and maintenance will generally be included in the contract as the bundle of services provided to the subscriber via subscription, as well as other services such as back-up, disaster recovery, technical support, and transitioning services. In addition, a SaaS agreement will generally include a service level agreement and an acceptable use policy, and it will address the policies and procedures taken to ensure the security of the platform. These technology models are very clear and defined technology frameworks. If the contract merges and mixes up the models, then this is a good indication that the contract is poorly drafted.
A second sign of a poorly drafted software contract is that the contract fails to discuss the concept of “users” and how they are granted, and just refers to an invoice or schedule that lists a number of “users” and assigns a price to that number. Both software licenses and SaaS agreements can provide rights to “users” but the license grant or the access rights grant needs to contemplate “users” in terms of who is authorized to be a “user” and what rights are provided to a “user”. In addition, the contract should explain how users are made available (i.e. individually or in increments), how they can be increased or decreased during the term or a renewal period, and the costs of each user or the user increments. Where users are not addressed in the contract and are only referenced in a schedule, they don’t actually have any rights in either the software or the services and so it’s unclear what is actually being sold by a software provider.
A third sign of a poorly drafted software contract is that the contract provides for periodic rather than up-front billing but fails to address what happens when those periodic payments are late. Is suspension employed at some point after the payment is late? If so, what kind of notice is provided and how is that notice delivered? Is the data still accessible after suspension? If so, what kind of fee is assessed for removing the data after suspension and in what format is it removed? If the data is in the cloud, how fast is it purged? A well-drafted software contract contemplates the potential relationship problems that might arise and defines how those scenarios will be handled rather than leaving them to be dealt with in the future.
A fourth sign of a poorly drafted software contract is that the contract fails to set customer expectations about either the functionality and features of the software in the case of a software license or, alternatively in the case of a SaaS contract or other software services contract, the quality and nature of the services that will be provided. In software services contracts, the value of the relationship is entirely tied to what is being delivered. Hosting contracts and SaaS agreements should generally have service level agreements which carefully define the service level being provided, provide a guaranty as to uptime and define any exceptions to that uptime, and provide a service credit that can be easily applied in a service failure. They should also address in detail the backup services being provided, the security services employed to keep the host or SaaS platform secure, and the disaster recovery services, as well as any transitioning services made available and how those work. Technical support is going to generally be available in software licenses, hosting contracts, and SaaS agreements, so is all of these cases how those services will work will need to be carefully defined. The bottom line is that these services relationship should be defined in detail and not left for future interpretation. A poorly drafted contract is going to be very unclear about what the software provider is providing under the relationship, which creates enormous opportunities for disputes to arise, since there may not really be anything agreed upon in the contract.
A fifth sign of a poorly drafted software contract is that the contract fails to define specifically what version or module of the product the contract even applies to. Few software vendors sell a single product without at some point making available optional features and services that can be “added on” for an additional charge. Many, if not most, contracts fail to fully describe the functionality, features or services that the contract applies to, which creates the potential for disputes as new functions, features, services, and/or products are made available, as the scope of what the original agreement applied to is simply not clear.
Finally, a sixth sign of a poorly drafted software contract is that the contract fails to contemplate and set expectations about what will be required for implementation, how long it will take, what would constitute a successful implementation, what milestones would arise in the implementation and how it would be verified that they were successfully performed, and any responsibilities the customer must meet at defined steps in the process. In multiple user scenarios and in many data-focused software products, implementation is a lengthy and very involved process, yet most software contracts are completely silent about implementation. This sets parties up for disputes over implementation. A poorly drafted contract is going to leave customer expectations for implementation largely undefined.
This list is certainly not exhaustive but provides some guidelines for what to look for in order to identify a poorly drafted software contract.
In summary, a software contract should provide significant clarity on the product or services being sold so that a layperson should be able to understand from the terms how the product or service will work and what kinds of expectations he or she should have about the product or service, the applicable fees, any set-up required, etc. If a contract raises more questions than it answers, then this is a fairly strong indication that the contract is poorly drafted.
Silicon Valley Software Law Blog’s Kristie Prinz will be featured as a speaker on “Negotiating SaaS Agreements: Drafting Key Contract Provisions, Protecting Customer and Vendor Interests” for a webinar hosted by Arlington, Virginia-based Clear Law Institute on Wednesday, February 21, 2018 from 10-11:15 a.m. PST. The firm has published a press release on the event, which is attached here. To register for the event, please check out the Clear Law Institute website.
Silicon Valley Software Law Blog’s Kristie Prinz will be featured as a speaker for the webinar “Drafting Software Hosting Agreements: Service Availability, Performance, Data Security, Other Key Provisions” for the Atlanta, Georgia-based Strafford on January 23, 2018. The firm has published a press release on the event, which is attached here. To register for the event, please check out the Strafford Publications website
Silicon Valley Software Law Blog’s Kristie Prinz will be presenting a webinar on “Negotiating Software As a Service Contracts” for Clear Law Institute on Wednesday, January 17th from 10-11:15 a.m. PST. The Prinz Law Office has published a press release on the event, which is attached here. To register, please sign up at the Clear Law Institute website.
SaaS attorney Kristie Prinz will be speaking at a webinar on “Best Practices for Drafting SaaS Contracts that Reduce the Customer Sales Cycle & Avoid Disputes” sponsored by The Prinz Law Office. The event will take place on October 26, 2017 from 10:00 a.m. to 11:30 a.m. PST. What you will learn in the webinar: What makes an effective SaaS customer contract? What terms should SaaS customers expect? Common challenges with customer negotiations. What drafting problems frequently result in stalled contract negotiations? Customer disputes? How can better drafting close deals faster? Avoid subsequent customer disputes? No legal knowledge is required to participate, and registration is open to any business. To register, sign up at: http://prinzlawstore.com/saas-customer-agreements/. For more information about the program, please contact Kristie Prinz at 408.884.3577 or email@example.com.
Silicon Valley Software Lawyer Kristie Prinz will be featured as a speaker for the webinar “Negotiating Software as a Service Contracts” for the Arlington, Virginia-based Clear Law Institute on Tuesday, September 12th from 12-1:15 p.m. PST.
Clear Law Institute is making available a special promotional discount of 35% off to attendees who sign up via the Silicon Valley Software Law Blog using this promo code: krpri35.
To register for the event, sign up at this link: http://clearlawinstitute.com/shop/webinars/negotiating-software-service-contracts-091217/.
Silicon Valley Software Law Blog Author Kristie Prinz will be co-presenting a webinar on “Negotiating SaaS Agreements: Drafting Key Contract Provisions, Protecting Customer and Vendor Interests” with Kelley Miller of Reed Smith on August 8, 2017 at 10:00 a.m. PST/1:00 p.m. EDT. To register for this webinar, please sign up at: https://www.straffordpub.com/products/negotiating-saas-agreements-drafting-key-contract-provisions-protecting-customer-and-vendor-interests-2017-08-08.
Democratic Senator Brain Schatz of Hawaii and Republican Senator Ron Johnson of Wisconsin have introduced the “Protecting Our Ability to Counter Hacking Act of 2017,” also known as the “PATCH Act of 2017” in the U.S. Senate Homeland Security and Governmental Affairs Committee, following the recent “WannaCry” ransomware attack, with the intention of requiring government agencies to submit any security holes in software products they discover for independent review in order to determine any vulnerabilities that need to be secured, as reported by HealthCare IT News and Reuters. According to HealthCare IT News, the PATCH Act of 2017 is supported by Republican Senator Senator Corey Gardner of Colorado, Democratic Representative Ted. Lieu of California, and Republican Blake Farenthold of Texas, as well as McAfee, Mozilla, The Information Technology and Innovation Foundation, and New America’s Open Technology Institute.
The text of the PATCH Act of 2017 is available for viewing here.
The bill would require the establishment of a Vulnerability Equities Review Board comprised of permanent members, ad hoc members, and National Security Council members who are neither of the above, if approved by the President and requested by the Board. The permanent members would include the following:
- Secretary of Homeland Security or the designee of the Secretary, who shall be chair of the Board;
- Director of the Federal Bureau of Investigation or the designee of the Director;
- Director of National Intelligence or the designee of the Director;
- Director of the Central Intelligence Agency or the designee of the Director; and
- Secretary of Commerce or the designee of the Secretary.
The Ad Hoc Members would include:
- Secretary of State, or the designee of the Secretary, if the Board considers the matter under the jurisdiction of the Secretary;
- Secretary of the Treasury, or the designee of the Secretary, if the Board considers the matter under the jurisdiction of the Secretary;
- Secretary of Energy, or the designee of the Secretary, if the Board considers the matter under the jurisdiction of the Secretary; and
- Federal Trade Commission (“FTC”), or the designee of the Commission, if the Board considers the matter as relating the the FTC.
The purpose of the Board would be to establish policies relating to “whether, when, how, to whom, and to what degree information about a vulnerability that is not publicly known should be shared or released” by government to a non-government entity and the process by which such information should be shared or released to a non-governmental entity. In other words, as Reuters reported, the bill is intended an attempt to put the process “into civilian control” and remove such decisions from the purview of the National Security Agency (“NSA”).
According to reporting by ThreatPost, this bill codifies the process that the White House has long claimed to have in place to evaluate information on security vulnerabilities, but in fact rarely actually has utilized. According to Threat Post, in the particular case of the WannaCry attack, the NSA did in fact tip off Microsoft of the security issue, which allowed Microsoft to make the patch available to customers in advance of the attack.
While the WannaCry attack was initially reported only to have hit Windows machines, according to reports by ThreatPost, it is now known that medical devices and industrial control systems have also been hit by the attack, including equipment used in medical radiology facilities.
Reuters is reporting today that, for victims who have not paid the ransom and/or recovered their files, French Researchers have developed a last resort workaround, which will successfully unlock the encryption key for files hit by the attack in certain conditions. According to Reuters, Europol has stated on Twitter that its European Cybercrime Centre has tested this tool and confirmed it will successfully recover data in some circumstances. The technical details of this tool can be accessed through the Reuters article.
In light of the popularity of the SaaS model of doing business, it is not uncommon to come across deals in which one software company is buying a third party company’s SaaS assets. While there are many reasons to be wary of these types of deals, regardless of what side of the transaction you are on, it has been my experience that the parties tend to be in a hurry to close the deal and rarely take the time necessary to contemplate the issues that should be considered in connection with the acquisition.
So, what are some of the issues that an acquiring software company should be concerned about in a SaaS company asset acquisition?
First and foremost, if the acquiring software company seeks to acquire the code comprising the SaaS product, then the company needs to verify that the target SaaS company actually owns the code comprising the software product. It has been my experience that entrepreneurs and companies of all sizes frequently overlook this issue and make significant investments in software development without first obtaining the appropriate rights in the products to be developed. I receive at least a few calls each month from C-level executives whose companies have developed a software product using outside developers without the appropriate contracts in place and call me after a dispute arises over ownership of the code in the product. If a problem is identified with the code to be acquired, it should be addressed before the acquisition talks are ever commenced, since once a negotiation begins, it will be much more difficult to procure the necessary rights in the code.
Second of all, if the acquiring software company seeks to acquire the SaaS company’s customers as part of the deal, then the acquiring company needs to verify that the customers are actually bound by subscription agreements that are automatically assignable in the event of an acquisition. Where the customers to be assigned are enterprise-level relationships, the acquiring software company also needs to verify the quality of the contracts in place. In general, SaaS company customer contracts are very poorly drafted and do not include the key terms of the business relationship, which will be of particular concern in cases where the transfer of a particular customer relationship or group of relationships is essential to the deal. Again, if the customer contracts are deemed to be insufficient, then this is a problem that should be resolved in advance of the commencement of acquisition talks.
Third, if the acquiring software company seeks to acquire the hosted software platform as part of the deal and not just the code comprising the software, then the acquiring company needs to verify the terms of the relationship in place with the target company’s host, assuming the target company is relying on a third party host as is typical in the industry. What kind of contract is in place with the host and is it automatically assignable to an acquiring company? Are the terms of the service level agreement governing the relationship sufficient to operate the software platform without service failures and without breaches of the customer contracts in effect? If the host is handling personal health information for the SaaS company, is there an appropriate business associate agreement in place that complies with HIPAA? It has been my experience that most SaaS companies do rely on a third party host for the software platform, and that a significant portion of those companies do not have an appropriate contract in place with the host to provide the expected hosting services that could be assigned to the acquiring company as part of a deal. If a the contract with the host is identified as inadequate, then this is a problem that should again be resolved in advance of the commencement of any acquisition talks with the target.
Fourth, since SaaS products are by their very nature “service” offerings rather than simply code, an acquiring software company may very well seek to acquire the SaaS company workers necessary to provide the services. In any such case, the acquiring company needs to verify that these worker relationships are in fact employment relationships that can be transferred to a successor company as opposed to contractor relationships that may not be transferable to the acquiring company and/or that may pose worker misclassification problems for the acquiring company. Where a problem exists, the acquiring company may want the SaaS company to address the issues in advance of the commencement of negotiations. In general, it has been my experience that SaaS companies are relying largely on independent contractors to provide services for their SaaS platforms, so encountering issues with any acquisition of a SaaS company workforce is to be expected.
The bottom line is that many of the SaaS company assets that an acquiring software company will seek to acquire as part of a SaaS company asset purchase will be accompanied by a certain amount of problems–problems that the acquiring software company may prefer to resolve in advance of any deal discussions rather than as part of the usual, time-sensitive, deal discussions. Anticipating the problems that are likely to be present with a target company’s assets before commencing negotiations can help to ensure a smoother negotiation as well as a smoother transition once the deal is closed.
The Department of Justice has launched an investigation into Uber’s use of the “Greyball” software program, following recent reports about the company’s use of this software to evade local law enforcement officials and regulators in new markets where the service was not yet permitted, according to Reuters. Reuters reports that Uber has received a subpoena from a grand jury in Northern California “seeking documents concerning how the software tool functioned and where it was deployed.”
According to Reuters, the investigation is still in its “early stages” and the nature of any potential federal criminal violation is “unclear.”
Reuters is also reporting that the city of Portland, Oregon is also planning on issuing a subpeona to Uber to force it to disclose the Greyball software. According to Reuters, if Uber does not comply with the subpoena, the city of Portland will “review” Uber’s ability to operate in the city.
Uber’s use of the “Greyball” software program first came under scrutiny as a result of a story by the The New York Times, which was published in early March 2017 and reported on how Uber had used this software program as part of a larger program at Uber known as “VTOS”–an abbreviation for “Violation of Terms of Service.” Following the publication of the report, Uber announced that it had ended the program, as reported by The New York Times.
The Mercury News described Greyball as a tool that “allowed Uber to display a fake version of the app to certain customers” and to “block law enforcement” from requesting rides where Uber was “operating in violation of local rules.
It has been reported that the law firm of Sherman & Sterling has been retained by Uber’s board to conduct an internal investigation into how the software was used. See The Mercury News.
The Department of Justice investigation is the latest in a string of legal problems for Uber this year, which have included legal issues over Uber’s classification of drivers, sexual harassment claims, and a trade secret lawsuit. One cannot help but wonder what the long-term business impact will be of all of these legal problems on the ultimate success or failure of the company.
When a client sends me a software license agreement or SaaS agreement to review or update, I always make a priority of reviewing any terms in the contract involving fees and then carefully reviewing the website and any marketing materials or fee schedules to confirm that the fee terms in the contract clearly match the fees listed outside the contract. Then, I will also confirm that the contract terms clearly articulate how the fees listed on the website and in other marketing materials or a fee schedule are to be calculated. I have generally found it to be rare for the contract terms and website, marketing materials, or fee schedule to match. More often than not, it is clear upon review of all of the supplemental materials that the fee terms of the contract are poorly drafted and make no sense.
So, what are some of the usual discrepancies that I will find?
One common issue I often see is that the marketing materials or the fee schedule suggest that the license or subscription fees are being calculated according to the number of authorized users, but there are no terms in the contract to explain what constitutes an authorized user, what rights the authorized users obtain through the license or subscription, whether authorized users are made available in blocks of users or individually and for what fees, or how you would add or drop authorized users. Whether your software contract is a license or a SaaS subscription, just listing the total fees and total users and not drafting contract terms describing the relationship between the licensee and users or subscriber and users and how that relationship works is completely inadequate. Those terms need to be clearly defined in the contract and not just in marketing materials.
A second issue that I frequently come across upon review is that the marketing materials or fee schedule suggest that there are multiple types of software licenses or SaaS subscriptions being offered to the customer, each of which provides different levels of functionality or services for a different fee, but the terms of the contract only reflect a single level of functionality or services and provide no clarification as to what functionality or services are comprised by that single offering. Whether the software contract is a software license or a SaaS subscription, the contract always needs to define the scope of the license or subscription being offered for a particular fee, and if multiple options are being made available for different fees, the contract needs to carefully describe the base option extended and the add-on option extended and how the various options and the applicable fees work.
A third issue I frequently come across upon review is that a fixed fee amount for “professional services” is listed in the fee schedule or marketing materials. However, often the terms of the contract are completely silent on what professional services are being provided under the software license or SaaS subscription, what the hourly or project rate is for the services and how many hours are being provided, or any other clarification about what constitutes the “professional services” to be provided under the agreement. Moreover, it’s generally unclear as to how fees would be billed for additional professional services.
In general, the problem with many software contracts is that companies are relying on marketing materials and fee schedules to justify fees that are never explained in the contract terms. However, the contract terms are what is binding on the customer–not the marketing materials, vague fee schedule, or other supplemental documents. So, clearly, software companies need to exercise the same sort of drafting caution that I exercise in my reviews, and go through each and every marketing material and fee schedule to confirm that any fee described is carefully explained in the terms of the contract. Where disparities exist, software companies need to identify those disparities and revise their contract terms to address the issues. When they fail to exercise such care in their drafting, they significantly increase the risk of future customer disputes.
My firm is very involved with VC Taskforce, and our big spring event is coming up this Thursday: StartUp World 2017. The event is being held this year at Pillsbury in Palo Alto, and we are pleased to have more than 25 investors participating, including but not limited to the following VC and angel firms: Agile Venture Capital; Kennet Partners; Keiretsu Forum; Monta Vista Capital; Berkeley Angel Network; Artiman Ventures; TrueBridge Capital Partners; HBS Alumni Angels; Illuminate Ventures; Scale Venture Partners; Blumberg Capital; DaVinci Capital Group; SF Angels Group; Manos Accelerator; Streamlined Ventures; Breakout Labs/Ventures; Ulu Ventures; Wingpact; and Portfolia. Tickets are still available. To register, you can sign up at:
If your software company is like most software companies these days, you likely set up a software interface and train your customers on how to use the product at the very beginning of the relationship. You probably even charge some sort of fee for these initial services that you provide. And the set-up process may run anywhere from days to weeks to complete.
Moreover, if you are like most companies, you are probably relying on a software license or SaaS Agreement which is either completely silent or almost completely silent on the specifics on how this “implementation” phase of the relationship will work, except for all of the fees you will be charging for the services. And you probably are charging your customer other fees on top of the implementation fees while the implementation process is ongoing.
If this sounds familiar, you are likely committing one of the most common contracting mistakes I see: leaving your company extremely vulnerable to a dispute over the implementation phase of your company’s software services.
Now, I know it is easy to say “I’ve always done things this way and I’ve never had a dispute.” I hear this from clients frequently as well as the argument “This is the real world. We don’t have the time to spend on such issues. You are just overlawyering.” However, from my side of the desk, whenever there is a customer dispute involving a software license or SaaS Agreement, it virtually always involves a dispute over an implementation process and the financial obligations tied to that implementation process.
Why is this? Well, software companies are largely using software licenses or SaaS agreements copied from other companies to contract with their clients. When they actually hire an attorney to draft a correctly drafted license or “SaaS agreement,” they retain the services of an attorney who lacks industry-specific knowledge about drafting these contracts and who fails to ask the right questions about the software company’s business model or set-up practices. And, in the rare cases where the software company actually does retain a knowledgeable attorney, the company may discount the importance of addressing the implementation process in the contract and not provide to the attorney the necessary information regarding the implementation process in order to enable the attorney to draft the appropriate terms required in the contract.
If you wonder what the “real-world” consequences are of this approach, they are as follows: if something changes at your customer’s company while implementation is continuing, your customer will likely call up an attorney like me to find a way to terminate your contract for material breach, and the attorney will point to the fact that the customer cannot use the software as intended to argue that a material breach has occurred. And then the customer or its attorney will demand a refund of all previously paid fees in conjunction with the breach. Alternatively, if the customer is a bit more aggressive, the customer may just terminate the contract for material breach and hire a litigator to pursue a breach of contract case against your company.
What can your software company do to avoid falling into the “implementation” trap with your software license or SaaS contract?
First of all, if you sell a software product that your customer cannot immediately utilize upon the execution of the software contract, you need to make certain there are well-drafted, company-specific terms regarding your implementation process in your contract. Those company-specific terms should address such issues as the specific milestones for your implementation process, what will constitute the successful performance of each milestone by the software company, what date each milestone will be completed, and what steps are required from the customer during the process and whether failure to perform any step constitutes a material breach or changes the software company’s implementation obligations in any way.
Second of all, if your software company will charge the customer fees for the implementation process or during the implementation process, your contract needs to contemplate how the fees are deemed “earned” in relation to the implementation services performed. It is not uncommon today to see contracts where hundreds of thousands of dollars are being exchanged during the implementation period, but if the contract does not actually articulate how those fees are earned by the software company, it could be argued that the fees were not actually incurred until the implementation process is complete and the customer provides final approval to the successful implementation. Also, if the contract is drafted in such a way that fees are being charged for services and functionality that are unavailable until a future date, this could be used against your company in a dispute to allege the occurrence of a material breach.
Third, if the customer is promised “training” as part of the implementation process, the specific terms of the exact training extended to the customer should be carefully defined. Does the “training” constitute pre-recorded webinars made available over the Internet, or does it constitute live, on-site, seminars taught by instructors on a particular date? Who can attend the “training”? When can they attend? How long will the training sessions last? What will be taught in the training sessions? Who absorbs the fees to provide the training sessions? What happens if the training sessions do not happen as scheduled? It is not uncommon for disgruntled customers to argue that they did not receive the training promised to them and that they were therefore unable to use the software as promised, and argue that this failure constituted a material breach.
The bottom line is that if your software license or SaaS agreement fails to provide detailed, company-specific terms on implementation and your software company does in fact have an implementation process that is necessary before a customer will “go live” with your software product, then you are leaving your software company very vulnerable to potential customer disputes. Taking the time to draft the appropriate customer contract terms before you retain a new software customer can significantly reduce your software company’s risk of a very costly customer dispute down the road.
If your software business makes available an app in the Apple App Store, then you will want to make note of several business changes that Apple has just recently announced.
The first change is that Apple has reduced the App Store affiliate commission from 7% to 2.5%, as was reported by Tech Crunch. An affiliate commission is a commission that is paid to a developer affiliate partner for linking to an App Store download that is purchased by a user of the affiliate website.
The second change is that Apple has increased App Store pricing for apps and in-app purchases in Denmark, Mexico and all territories using the Euro currency, as was reported by MacRumors. According to MacRumors, auto-renewable subscription prices will not be affected.
The third change is that Apple has implemented a value-added tax (“VAT”) rate of five percent (5%) for Taiwan customers, which will also affect apps and in-app purchases, as was also reported by MacRumors.
These changes all reportedly go into effect as of today, May 1st, 2017.
If you are a software developer and you develop code that hackers then use to commit crimes, then you may be a risk for criminal prosecution, as an Arkansas developer named Taylor Huddleston recently discovered according to an article published by The Daily Beast.
According to The Daily Beast, Huddleston developed a remote administration tool called “NanoCore” that is popular with hackers but claims that he intended his tool to be adopted by “budget-conscious school IT administrators, tech support firms, server farms, and parents worried about what their kids are doing online.” The Daily Beast reports Huddleston is now being prosecuted on federal charges of conspiracy and aiding and abetting computer intrusions.
Could going after developers of software used by hackers be a new trend in law enforcement?
The Daily Beast article suggests that this could in fact be a new strategy in law enforcement, and points to the government’s 2012 prosecution of Michael “xVsiceral” Hogue, who had participated in “creating and selling a remote access program called Blackshades” which constituted ransomware, as possible motivation for the strategy, since the government subsequently entered into a deal with Hogue, which enabled U.S. & European authorities being able to successfully prosecute 100 users of the software over a two-year long investigation.
The bottom line is that developers who create code or products that may have legitimate as well as hacking applications should be on notice that they could become the target of a federal investigation or even be federally prosecuted as a result of their development activities. The Huddleston case certainly suggests that software innovators should be considering how their innovations may be utilized once developed before they actually follow through with the development, and certainly should be seeing outside legal counsel on these issues prior to engaging in the development of a product that may have both innocuous and criminal applications. Developers in such circumstances also may want to re-consider the wisdom of engaging in independent development and seek out corporate support for their development project.
If you are in the software industry, you may have heard of a “service level agreement” or “SLA,” but do you really understand what a “service level agreement” actually is or when you might need one?
A “service level agreement” or “SLA” is a technical agreement that defines that parties’ expectations of the level of service that will be provided in a particular service provider relationship and establishes how a customer will be compensated if the service at any given time does not meet the expectations as defined in the agreement. It is usually drafted as a schedule to another agreement such as a master service agreement (“MSA”), software services agreement (“SaaS agreement”) or hosting services agreement rather than standing alone as the sole agreement defining a relationship between two parties. As a tech transactions and software attorney, I would expect to see a service level agreement present in any agreement involving a software as a service (“SaaS”) or hosting relationship; however, a service level agreement could be appropriate in other tech-related service relationships as well, in which metrics or standards for the delivery of the service mattered to the customer and not just the accomplishment of a particular service milestone. For example, a “service level agreement” might be appropriate in a business relationship with a provider of IT services, in a back-up or disaster recovery relationship, or in a data service relationship–these are all scenarios where a customer might have expectations beyond merely whether a particular task was performed or not that one or both parties might want to address in a separate service level agreement.
If you are questioning why it is customary to have a “service level agreement” and not just rely on a standard warranty or material breach clause, consider this: if an interruption in service occurs with a particular relationship and then resumes for any reason, does either the consumer or the provider really want to treat that interruption as a material breach and terminate the relationship? In many cases, the answer is “no.” From the provider’s perspective, the interruption may very well have affected its entire customer base, so of course, the provider doesn’t want to go out of business over a single incident. At the same time, it is frequently not in the consumer’s best interest to treat an interruption as a material breach either. The consumer may believe the service provider is the best provider in its industry to deliver a particular service, either because of the pricepoint, the technology or service offered, or the reputation of the particular provider. Also, the cost in terms of time and resources of finding an alternative provider might be higher than the consumer is willing to take on at that time. There might be no other alternative to the particular provider, or the financial costs of changing providers could be too high. Obviously, there may be legal consequences as well in terms of the cost and expense of enforcing a warranty clause and terminating a contract for material breach that could easily dissuade a particular consumer against exercising such rights.
Thus, for all of these reasons, a “service level agreement” or “SLA” is frequently relied upon by knowledgeable service providers and customers to define the parties’ expectations about the delivery of a particular technical service and to provide an alternative mechanism for compensating service failures outside of the standard warranty/breach framework. Where no such agreement exists, the parties often have no real expectations defined for the service, which more often than not will eventually bring a premature end to the relationship.
What types of terms should you expect to find in a “service level agreement” or “SLA”? As with most technical agreements, it is my view that the terms in a particular service level agreement need to be tailored to the particular relationship between two parties and not just copied from a third party’s agreement, so no single set of terms will be appropriate in all cases. For example, if you are a SaaS company and you rely on a third party to host your software, then the service level agreement you adopt needs to contemplate the service level agreement terms of the third party hosting your software and not be written independently of the hosting relationship. If you are procuring another technical service, you should make sure that the service level agreement reflects the expectations of your business or your customer base. If you don’t have expectations for what you are buying, then you need to do your homework and talk to an attorney, competing service providers, other businesses, etc. to understand the problems you might run into with the particular service and understand what expectations are reasonable for the particular service being procured. The worst drafting mistake you can make in adopting a particular set of terms for a service level agreement is to simply use a third party’s terms rather than customize the terms to the particular relationship, since the third party’s terms will likely have no relevance to your relationship. Having said this, there are some terms that are commonly found in service level agreements. These include such concepts as as “service availability,” “exclusions,” “scheduled downtime,” “uptime,” “service level guarantee,” “service credit,” “business hours,” “priority response times,” and “service level reporting.”
The bottom line is that if you are on either side of a technical service relationship, it is important to consider whether a service level agreement might be advisable to define the parties’ expectations for the relationship beyond just whether or not a particular service is performed. There are no single set of terms that should be adopted in all scenarios, but you need to be knowledgeable enough about what you are buying or selling to develop clear expectations in advance of the commencement of the relationship. As a SaaS company, you are both a buyer and seller of services, and therefore it would be prudent to define expectations for the service not only with your customers but also with your service providers, so that you obtain the services required to meet your customer’s expectations as well.
When SaaS companies and start-ups first contact me, they are often doing so with the idea that there are a few really well SaaS template contracts circulating in the SaaS industry and they seeking the” right” attorney to provide that industry-standard template to them. Alternatively, they contact me telling me that they’ve already put together a draft SaaS contract, and that they just want me to look over and “bless” what they’ve already written based on a particular SaaS company’s contract available for download on the Internet.
In these cases, which are the norm rather than the exception, I often encounter significant push-back when I first suggest to them that they are approaching the SaaS contract drafting process entirely the wrong way. I always explain that a well-drafted SaaS contract should be tailored to their specific business model, and then I proceed to ask them a number of questions about their business model, which they generally aren’t prepared to answer. They often then proceed to get frustrated by all the questions about their business, when all they are actually looking for is the “right” contract template.
If you are in the SaaS industry and have created your customer contract in a similar fashion, or committed the other common software contracting “sin” of caving into pressure exerted by a potential customer and just agreed to their standard agreement terms because you wanted to close a deal with them, then you may want to consider the example of recent litigation against an industry leader, which adopted contract language which was then alleged not to match the company’s business practices.
The litigation at issue involves class action suits against the McAfee brand security software: Williamson v. McAfee, Inc., No. 5:14cv00158 (N.D. Cal. Aug. 30, 2016) and Kirby v. McAfee, Inc., No. 5:14cv02475 (N.D. Cal. May 29, 2014). Both cases focus on the company’s business practices surrounding its use of automatic renewal clauses–a standard practice widely adopted throughout the SaaS industry. The litigation is ongoing: while the court granted final approval of a settlement in both cases, an appeal has been filed. (See posted notice).
The particular contract clause at issue in the Williamson case is a common clause routinely included in SaaS contracts that stated at autorenewal customers would be charged the “then-current” price for the product. However, the Williamson complaint alleged that the actual practice of the company was to charge customers upon autorenewal a higher price for the product than the price that the customer could have purchased the product for elsewhere.
The particular contract clauses at issue in the Kirby case stated that customer would be automatically enrolled in the autorenewal program and that a customer’s credit or debit card could be charged at autorenewal even after it had expired. The Kirby complaint alleged that the actual practice of the company was to import into its billing system updated customer credit or debit card information provided by Visa or MasterCard rather than procuring a new authorization from client when the prior authorization became invalid, and to charge the customer at autorenewal at a higher price than originally paid without the customer’s express consent.
While there are a number of allegations made against McAfee in these class action suits, a fundamental problem alleged was that the terms of service binding the customer did not match the company’s actual business practices, and that the customer did not provide consent to the company’s actual autorenewal practices.
While these particular suits were filed against McAfee, the business practices alleged in these cases are perhaps the current standard of conduct for today’s software industry. Furthermore, I would argue that more often than not terms of service are adopted by companies without any consideration whatsoever of the actual technology and business model for the software or SaaS product, so it is probably rare for the terms of service to match the company’s actual business practices. Thus, it is my assertion that these cases provide an excellent primer of the risks of adopting terms of service that do not match the actual practices of the business. It’s still not clear what the ultimate price tag on this matter will reach on the part of the company, but it’s clear it will be multiple millions of dollars in costs and expenses.
Moreover, these cases demonstrate the importance of consent to having an effective autorenewal clause. State laws applicable to these cases did require the procurement of clear and conspicuous consent to autorenewal, which McAfee is alleged not to have had in these particular sets of facts. Obviously, any deficiency with consent could have easily been addressed through the adoption of better business practices and terms that would demonstrate clear customer consent in compliance with applicable state laws.
The bottom line is that terms of service should not be adopted by a SaaS company without a thorough consideration of the technology, the business model, and the business practices of the company. Even common business concepts like autorenewal accepted across the board within the industry may lead to costly lawsuits if insufficient consideration of business practices is contemplated in conjunction with the drafting of terms of service.
Well, if this is your company’s situation, you may want to rethink how you are operating in light of recent enforcement action by the FTC on corporate data collection practices.
In the stipulated order, VIZIO was ordered to take all the following actions before collecting any further data from consumers:
- Obtain affirmative express consent from consumers at the time of disclosure and upon any material changes.
- Provide instructions at the time of obtaining consent to how consumers may revoke consent.
The stipulated order then gave specific guidelines on what would constitute “prominent” disclosure
The stipulated order also required the destruction of the previously collected data, the mandated creation of an internal privacy program meeting certain requirements, and third party oversight going forward regarding the privacy controls in place at the company.
Clearly, the FTC intended to send a message to the software industry about the collection of consumer data in the case of this particular enforcement action.
However, the FTC’s recent enforcement activities against software companies did not end with VIZIO. In a separate statement, the FTC announced settlements with three other companies in the industry over allegations that they had made deceptive statements in their privacy policies about their participation in an international privacy program. The companies charged in those cases were, Sentinel Labs, Inc., a software company providing endpoint protection software to enterprise customers; SpyChatter, Inc., a company marketing a private messaging app; and Vir2us, Inc., a distributor of cybersecurity software. The FTC alleged in each complaint that the companies violated the FTC Act by making deceptive statements about their participation in privacy programs. Attached are the complaints against Sentinel Labs, SpyChatter, and Vir2us. In these cases, the proposed settlements merely prohibited the companies from making further misrepresentations about their participation in third party privacy or security programs, but are not final orders and still subject to possible amendment.
If you do not change your privacy practices, you are on notice that you may soon be hearing from the FTC.
The average sales contract being signed by a SaaS company has nothing to do with the technology being sold and fails to include all of the key contract terms that need to be in a SaaS contract. Thus, not only does the poor nature of the contract complicate the process of signing up new customers to use the product, but it also dramatically increases the risk that your company will end up in a dispute with the customer that does sign your contract.
What can be done by SaaS companies to ensure that their contracts are not creating more business problems than they solve? The Silicon Valley Software Law Blog’s Author and Attorney Kristie Prinz will be presenting a
webinar addressing these and other important issues on March 24, 2017. The webinar will address such questions as
- What makes an effective SaaS customer contract?
- What terms should SaaS customers expect?
- Common challenges with customer negotiations.
- What drafting problems frequently result in stalled contract negotiations? Customer disputes?
- How can better drafting close deals faster? Avoid subsequent customer disputes?
Tickets are still available to attend this webinar, and the program will be appropriate for lawyers and businesspeople alike. To sign up, please click on the following link: https://www.eventbrite.com/e/best-practices-for-drafting-saas-contracts-that-reduce-the-customer-sales-cycle-avoid-disputes-tickets-29989175431.
I have some remaining complimentary passes available for tomorrow’s panel presentation on “Negotiating Service Level Agreement Key Terms” hosted by Strafford Publications. If you would like to attend, please send me a request today at firstname.lastname@example.org and I’ll see if I can still reserve you a complimentary pass.
Bitmanagement Software GmbH recently filed suit against the US Navy, alleging willful copyright infringement of its 3D virtual reality software “BS Contact Geo” and demanding $600 million in damages. A copy of the complaint has been posted by Business Insider at the attached link. Bitmanagement’s complaint alleges that the software license agreement entered into with the US Navy authorized the installation of the software on 38 machines “for the purposes of testing, trial runs, and integration into Navy systems” but that the US Navy decided it wanted to deploy the software on a wider scale and proceeded to install the software on more than 558,000 computers while it entered into negotiations with Bitmanagement to purchase additional licenses.
The initial reporting on this case in such publications as PC Magazine, The Register, and ars Technica suggested that the US Navy had flagrantly infringed the intellectual property rights of this German software company on a massive scale and that the damages were likely to be significant. However, the US Navy has now filed a response to Bitmanagement Software complaint, in which it denies that the license limited the US Navy to installation of the software on 38 personal computers and alleges instead that the Navy instead procured concurrent-use network licenses and was authorized to install the software on its network.
As a software licensing attorney who has had occasion to review many European software licenses, the nature of the US Navy’s response to facts that seem on their face to be quite clear-cut and entirely favoring the plaintiff software company leads me to question whether the license agreement at the heart of this dispute is as poorly drafted as many of the European license agreements I have reviewed in my practice over the years. While I have no direct knowledge of Bitmanagement Software’s standard licensing terms or the terms entered into by Bitmanagement Software specifically with the US Navy, the mere fact that the Navy raised an argument in its response that it “procured concurrent-use networking licenses” suggests that the software agreement might not have had a clear license grant that clearly stated the scope of the grant and that the agreement might have just contained a fee schedule, which did not specifically define how the fees were calculated. If this were in fact the case, the US Navy lawyers may just have interpreted the software license in such a way to favor the US Navy rather than engaging in willful copyright infringement as the plaintiff software company claims.
It has been my experience that many software companies around the world do not fully appreciate the significance of two key terms in every software license: the license grant itself and the payment clause. It is not enough to state in a software license that you are granting a license for a particular purpose. Rather, you have to actually define the parameters of the license grant. For example, does the license authorize the installation of the software at a specific workstation at a specific location by a single employee? Or does the license authorize the installation of the software at a specific workstations at a specific location by an unlimited number of employees? Alternatively, does the license authorize installation of the software on an unlimited number of workstations at several locations of the business by an unlimited number of employees? Or does the license authorize installation of the software on a server for concurrent use by a certain number of workstations of an unlimited number of employees? As you can see the same grant to install software can be interpreted a number of different ways if all the different parameters are not carefully considered.
However, when you have a vaguely drafted software license that only “grants” a license or, alternatively, grants a very broad right to “use” the software, you have an additional interpretation problem in that it is unclear the scope of use that is in fact granted. While the drafter might have intended “use” to mean merely the right to “install and run” the software, “use” might be interpreted to authorize not only “installation” and “running” but also “copying” and “distribution” provided the “copying” is limited to making archival backup copies or copies to other internal hardware and the distribution is similarly limited to with the licensee organization.
The other common problem I run into in reviewing software licenses is the vague drafting of license fees and payment terms and over-reliance on a fee schedule that simply lists prices based on number of licenses granted. Obviously, if you charge a set fee per license and neither the license grant nor the payment terms are specifically drafted, then the licensee is going to interpret the fees due and payable in the manner most favorable to the licensee. Frequently I see licenses, where the licensor likely intended to charge by the number of authorized users at a business but doesn’t specifically state how the fees are to be calculated, and obviously in these instances, the licensor is not likely to collect the volume of fees it intended to collect.
As previously stated, I have no knowledge of the software license at the heart of this dispute, so I am only speculating as to how this relationship might have deteriorated to the point of filing a $600 million lawsuit. However, my own experience suggests that the contract which was the basis of this relationship may have been poorly drafted with respect the key terms of the license grant and license fee terms, and the choice of language in the response to the complaint makes me more suspicious that these problems I often see in my own practice could have been an issue in this relationship. The bottom line is that key clauses in software licenses need to be drafted very precisely, regardless of which side of the contract you are on, and where terms are left vague, you may very end up in court having to pursue or defend copyright infringement claims which could have easily been avoided if only a better contract had been negotiated upfront.
If you are a cloud service provider or a software provider who offers maintenance services to enterprise-level companies, then your company has likely had occasion to negotiate indemnification clauses relating to data breaches. Moreover, your company has probably had to provide warranties around data security or employee bad acts that would provide some protections to your customers in the event of a data breach.
But have you ever taken the time to really consider what the cost of a possible data breach might actually be for your company?
Network World recently published an article looking at the results of a 2016 data breach study conducted by the Ponemon Institute and IBM and determined that the total average cost for a breach is now $7 million, and that average cost per compromised record is now $221. Network World further reported that the same study concluded that the average cost of a data breach of more than 50,000 records was $13 million.
Obviously, these costs are significant enough that unlimited liability indemnifications relating to data breaches have the potential to generate significant expenses, as do actions for breaches of warranties relating to data security.
So, what can software companies do to protect themselves against data breach liabilities?
First and foremost, companies need to take data security seriously and enact policies and procedures that prioritize data protection.
Second of all, companies need to carefully negotiate clauses related to cyberrisk and cyberliability with the expectation that a data breach will occur that is going to trigger the application of all such clauses down the road. In particular, if you agree to take on unlimited liability of all costs related to a data breach, you need to be prepared to cover the expected costs that will arise from any such data breach. Similarly, in negotiated services contracts, companies need to take the time to carefully define the full scope of services they provide with respect to data protection and data security in such a way that a data breach will not constitute a material breach so long as the services are fully performed in accordance with the defined scope of services.
Third of all, companies need to purchase cyberinsurance in order to ensure that they have sufficient coverage in the event of a data breach. While cyberinsurance is a relatively new insurance product which has in the past often had many gaps in coverage, Tech Republic suggested in an article published today that the newer policies are starting to close some of the earlier policy gaps to coverage. However, Tech Republic reported that companies should still watch for coverage limits in cyberinsurance policies for regulatory actions, cost of call monitoring, credit monitoring, forensic investigations, hacks that began prior to the coverage term, and attacks that have third party consequences.
The bottom line is that software companies need to have contractual and insurance protections in place to protect the businesses against the consequences of the inevitable data breach that affects their business. With data breaches as well as costs on the rise, companies of all sizes need to be prepared to deal with the fallout of a cyberbreach when it occurs.
The Prinz Law Office is pleased to announce that Silicon Valley Software Law Blog’s Kristie Prinz will be speaking at an upcoming webinar on “Negotiating Service Level Agreement Key Terms” on December 21, 2016 from 10 a.m. to 11:30 PST. For more information about the webinar, please see the firm’s press release on the event published below:
The Prinz Law Office is pleased to announce that Silicon Valley Software Law Blog’s Kristie Prinz will be speaking at an upcoming webinar “Negotiating Software as a Service Contracts” on December 19, 2016 from 1 to 2:15 p.m. EST. For more information, please see the firm’s attached press release.
HP reopened a new front in the controversy between the printer hardware business and digital rights management software when it reportedly downloaded digital rights management software to customer printers as a recent security update. Fortune reported that HP’s actions were first recognized by a Dutch printer cartridge vendor after some 1000 customers contacted the company to inquire about the sudden problem.
The controversy received national attention when the Electronic Frontier Foundation (“EFF”) went public with its concerns and published a letter to HP. A link to EFF’s letter is published here. A story published by Tech Crunch on the controversy is linked here.
The publicity surrounding the controversy has reportedly already prompted HP to “reach out” to EFF and do some public back-peddling on the issue. Wired is reporting that HP has said it will release an “optional firmware update” that will remove the software within the next two weeks. The Wall Street Journal actually published an interview with HP, where the company apologized for “how it handled” the software update but at the same time indicated that “HP would continue such practices, which may prevent some third-party supplies from working.”
The whole episode calls to mind the Lexmark lawsuit filed against Static Control challenging the circumvention of Lexmark’s printer DRM software, which I once wrote about in a New York Law Journal publication. Wired likewise referenced the Static Control case, which Lexmark ultimately lost, and reported that Lexmark simply changed its strategy and pursued and won its next case on patent rather than copyright law grounds.
According to Wired, this whole controversy has been driven purely by HP’s bottom-line: revenues in its printing business are incrementally dropping, as are sales in printing supplies. HP is trying to preserve its revenue share in the industry for as long as possible. However, as EFF clearly articulated, HP runs the risk of losing its existing customer base in the process. HP’s efforts at damage control suggest that the company has recognized that there is a fine line that they are walking between preserving a revenue share and sending customers elsewhere.
Will this controversy open a new legal front over the use of digital rights management software with printing cartridges? This episode suggests that printer companies would still like to put out of business competitors on the cartridge supply front, and ensure that their customers buy their “authentic” cartridges only. With that in mind, why wouldn’t they pursue new legal routes to the same end?
In the current situation, however, HP has apparently relented to some degree and has said it will be making available an update, and Wired is reporting that the Danish manufacturer has already designed new chips to circumvent HP’s security update, so one way or another, customers should be able to go back to using third party printer cartridges in the near future. Whether the next stop for HP will be to pursue the issue in litigation is yet to be determined. The Silicon Valley Software Law Blog will keep you posted of any new developments as they unfold.
The Federal Trade Commission has today announced the approval of its final order resolving its complaint against the San Francisco-based software company Vulcan on deceptive and misleading conduct allegations that Vulcan had purchased a browser extension game and replaced it with a program that caused the automatic installation of applications on the game users’ mobile devices without their permission. According to the Federal Trade Commission (“FTC”), Vulcan’s unfair and deceptive acts and practices in replacing a legitimate game with the new program severely disrupted the ability of the 200,000 users of the game to subsequently use their mobile devices and put their sensitive information stored on the device at risk. The FTC’s complaint also contained a false claims allegation over the inaccurate promotional and advertising claims made by the replacement program. The original FTC complaint filed against Vulcan can be viewed here.
In its Order, the FTC prohibits Vulcan from offering “a product or service or materially change a Covered Product or Service” unless the company has disclosed “clearly and conspicuously” in advance of any downloading or installation the types of information the product or service will access and how the information will be used to perform related services, and the nature of any material change to a covered product or service. Also, the FTC expressly prohibits Vulcan from making a number of specific deceptive advertising claims. The FTC Order has been made available for viewing here.
The Vulcan enforcement action by the FTC makes a clear statement to software companies that the government is monitoring the nature of the software being distributed to consumers as well as the advertising claims made in connection with such software for any conduct that may rise to the level of an unfair and deceptive trade practice. Any software company contemplating the replacement of an app previously installed by users with their permission with another an unauthorized app are on notice that the FTC does not approve of the practice and will exercise its enforcement authority against you once your conduct is brought to its attention.
Are your SaaS customers really signing an agreement that is effective for your business? How do you even know if your SaaS company is working with a customer agreement that is sufficiently protecting your business?
The Silicon Valley Software Law Blog’s author Kristie Prinz is presenting a webinar on June 13, 2016 at 10 a.m. PDT on “Best Practices for Negotiating and Drafting Effective SaaS Customer Agreements” which will explore these topics of concern for SaaS companies. At this webinar, you will learn the following:
- What makes an effective SaaS customer contract?
- What terms should you include in your SaaS customer contract to protect your business?
- Common drafting problems in SaaS customer contracts
- What drafting problems frequently result in customer disputes?
- How can these drafting problems be avoided?
Ms. Prinz’s practice focuses on advising early stage and small to mid-sized businesses on the negotiation and drafting of complex commercial transactions in the software, hardware, Internet, health technology fields of practice, as well as other related high tech and life sciences fields. Ms. Prinz is a regular speaker, media contributor, and author on technology law, intellectual property and entrepreneurship issues. Ms. Prinz has developed particular expertise in advising SaaS companies in negotiating and drafting their customer agreements. Ms. Prinz is a graduate of Vanderbilt Law School and is licensed to practice in the states of California and Georgia. To register to attend this webinar, please sign up here: link.
If your software company leases office spaces, then you may have some familiarity with the legal issues involving whether or not the space is compliant with the Americans with Disabilities Act (the “ADA”), but have you ever considered whether your software product itself is ADA compliant?
If the answer is no, then it may be time to allocate some resources toward the issue of ADA compliance.
A California judge last month granted summary judgment to a blind plaintiff who had filed a lawsuit against Bag’n Baggage on the grounds that he was unable to shop online at the company’s website because the website lacked features for aiding the disabled. According to The Wall Street Journal, Bag n’ Baggage was ordered to update its website, pay the plaintiff Four Thousand Dollars ($4,000.00) in damages, and pay attorneys’ fees which are expected to exceed One Hundred Thousand Dollars ($100,00.00). Forbes reports that the plaintiff in the Bag n’Baggage case has filed nine lawsuits in San Bernardino County Superior Court and two in federal court, presumably on the same issue.
However, according to Forbes, this California ruling is not an isolated case, and it comes just a month after a federal judge ruled against Harvard University and the Massachusetts Institute of Technology in similar cases, rejecting their arguments that the cases should be dismissed or stayed pending DOJ regulations being adopted. Tech Crunch also reports that the Department of Justice itself has launched investigations which included the issue of website accessibility against the NewSeum in Washington D.C. and the Quicken Loans Arena and has settled with several universities: Florida State and the University of Montana. In addition, Tech Crunch reports that the Department of Justice has already entered into settlements with the online grocer PeaPod and H & R Block, which have required the businesses to make applications accessible to vision-impaired users.
According to Tech Crunch, given the fact that law firms are already sending out demand letters threatening to sue unless the business makes their website ADA compliant, it is not much of a stretch to anticipate that the same firms will soon start focusing their efforts altogether towards software and mobile applications.
What can software companies do to protect themselves from potential ADA claims about their software products? Tech Crunch suggested that companies arrange for testing their products with WCAG 2.0 and Section 508 of the Rehabilitation Act and test usability by built-in screen readers, as well as actively consider accessibility in the design plan. Obviously, software companies need to be following legal decisions on the issue of ADA compliance in the Internet and software industries and take steps to act on the guidance that comes out of those decisions relating to the ADA compliance issue.
The good news for software companies is that courts have not found uniformly against businesses on the issue of websites being ADA compliant, so in the event your company is sued, there is some precedent that may provide a viable defense to your business. Forbes reports that the U.S. Court of Appeals for the Ninth Circuit held in 2015 in Earll v. eBay that ebay.com, was not a “place of public accommodation” under the accessibility requirements of Title III of the ADA and that it came to the same conclusion in 2015 in Cullen v. Netflix, Inc. Forbes also reports that the Third and Sixth Circuits found in the 1990s that the ADA only applied to actual physical structures. However, at the same time, Forbes acknowledges that the Eleventh Circuit, the First Circuit, and the Seventh Circuit have reached the opposite conclusion.
So, the bottom line, is that for now at least, software companies need to be proactively adopting plans to make their software products accessible to the disabled, and to be taking steps to maintain compliance with federal and state laws applicable to accessibility issues. If your software company has not been considering how the ADA or similar state laws might apply to its products, now is the time to start evaluating these issues.
Microsoft has just opened a new chapter in the software industry’s pushback against alleged federal government overreach by filing a constitutional challenge over indefinite government gag orders when the government subpoenas information from customer cloud accounts. Microsoft’s complaint alleges that the orders violate First Amendment free speech rights and Fourth Amendment rights regarding unreasonable government search and seizure of property.
According to The Wall Street Journal, Microsoft is claiming that a gag provision under the Stored Communications Act “has significantly expanded the government’s power to conduct secret investigations.” The Wall Street Journal reports that Microsoft’s position is that the government “has exploited the transition to cloud computing to expand its power” and that the fact that private information is moved from a file cabinet to the cloud does not fundamentally change the constitutional rights that people have to that private information.
The text of the Stored Communications Act is codified at 18 U.S. Code Chapter 121, Section 2703(b) of the Stored Communications Act states as follows:
(1) A governmental entity may require a provider of remote computing service to disclose the contents of any wire or electronic communication to which this paragraph is made applicable by paragraph (2) of this subsection—(A)without required notice to the subscriber or customer, if the governmental entity obtains a warrant issued using the procedures described in the Federal Rules of Criminal Procedure (or, in the case of a State court, issued using State warrant procedures) by a court of competent jurisdiction; or(i)uses an administrative subpoena authorized by a Federal or State statute or a Federal or State grand jury or trial subpoena; orexcept that delayed notice may be given pursuant to section 2705 of this title.
Reuters reports that the Microsoft claims it has received 5624 legal orders under the Stored Communication Act, of which 2576 also contained a gag order, and that most requests involved individuals rather than companies.
According to The Economic Times, Microsoft has decided to pursue this challenge because its business model is increasingly relying on cloud services and Microsoft is concerned that the government’s actions are going to discourage the public from further adopting the cloud business model. The Economic Times is also reporting that Microsoft is citing as precedent for its case a ruling in 2014 where U.S. Magistrate Judge Paul Grewal rejected a Department of Justice request to have an unlimited gag order over the search of a Microsoft Hotmail account and said that a limited gag order might be appropriate, as well as a Supreme Court ruling that police must announce themselves when they serve a warrant.
Who is likely to prevail here? As you might expect, Forbes was able to find experts on both sides of the issue. However, Forbes raised an interesting point that if a court were to find in favor of the government on this case, it sets a precedent for other governments to expect similar access, which could be problematic.
It’s safe to say that Microsoft’s filing of this case on the heels of the very public debate regarding the Department of Justice decision to order Apple to decrypt the San Bernardino terrorist smartphone is a strategic move on Microsoft’s part intended to capitalize on the current public sentiment against the federal government for its perceived intrusion on individual privacy rights. The software industry has clearly decided that the time is right to draw a line in the sand on government overreaching into its industry. It is unlikely that the government is going to be able to sidestep a showdown in this case in the same way it was able to do in the Apple dispute.
The U.S. Justice Department announced yesterday that the third party who came forward and convinced the FBI that it could unlock the San Bernardino terrorist’s encrypted iPhone successfully unlocked the encrypted iPhone, ending the standoff between Apple and the FBI. The government informed the court in its filing yesterday that it had successfully retrieved the data stored on the encrypted iPhone and no longer required assistance from Apple.
According to Silicon Beat‘s reporting, at least one founder of an advocacy group, Tiffiniy Cheng, co-founder of Fight for the Future, is predicting that this standoff “will go down in history as one of the FBI’s biggest public relations failures.” This general perception that the government has been the big loser in this matter has been the prevailing view among many commentators.
The Wall Street Journal, however, suggested in its reporting that a contrarian view has developed that “Apple’s credibility could be questioned” since clearly the iPhones do have security flaws that can in fact be exploited. Also, The Wall Street Journal reported that this contrarian view suggests that the episode may “complicate the government’s position the next time” it seeks court-mandated help from a software company over an encryption issue.
The government has been silent on the source of the encryption unlocking assistance it has received; however, Tech Crunch and International Business Times reported that the mysterious third party was the Israeli company Cellebrite, which the government has a long history of working with.
Regardless of the identity of the third party providing the assistance, as The New York Times has reported, the very fact that a security flaw was uncovered that Apple was unaware of may serve as a wake-up call to Apple that it may want to rethink its policy on refusing to pay hackers that identify security flaws in its software. According to The New York Times, it is a standard practice in the industry to pay hackers who identify security flaws that could be exploited for malicious purposes–a practice that Apple has refused to adopt–which has caused a huge underground market to develop for the sale of information on Apple security flaws.
In the meantime, while this particular chapter in the encryption battle has been closed, the Department of Justice’s appeal in the New York case over the unlocking of an iPhone continues on. There is no word yet if the solution uncovered in the San Bernardino iPhone matter will also work with the iPhone in the New York case, although Reuters is reporting that Apple has already raised that question in New York court filings. Also, as the Silicon Valley Software Law Blog reported previously, a potential encryption fight over WhatsApp also remains on the Department of Justice ‘s plate that has yet to be resolved. Thus, it seems likely the debate over the encryption issue will be renewed in the foreseeable future over another software encryption matter.
While legal observers may be disappointed to see that fight postponed for another day, I would argue that Americans should be relieved that the right result was finally achieved in this case.
Silicon Valley Software Law Blog author Kristie Prinz has been invited to present a webinar on “Negotiating Software as a Service Contracts” for Clear Law Institute on May 6, 2016 at 10 a.m. PST/1 p.m. EST. For more information on the event or to register, please visit the Clear Law Institute website at http://clearlawinstitute.com/.
It is reported that “an outside party” has identified to the FBI a possible method to unlock the iPhone used by one of the San Bernardino terrorists. The government has asked for time to determine if the proposed method is successful.
The Department of Justice filing is posted here.
Today’s developments would suggest that the Department of Justice and FBI may be coming to the same conclusions that the Silicon Valley Software Law Blog reached last week: that the best course of action in this matter would be for the government to accept third party help to decrypt the locked terrorist iPhone and to drop the legal action against Apple. While the Department of Justice has succeeded in creating a huge public relations victory for Apple by taking its encryption dispute to the courts, it has done little to advance its own interests, creating instead a very public controversy over the issue of federal government overreaching and setting itself up for a expensive court battle over free speech that could be headed to the Supreme Court. Perhaps the realities of the situation have set in and the government is taking the prudent course of action after all. While legal scholars may be disappointed in this development, finding an alternative solution to end this dispute is going to be best for law enforcement and ultimately best for the American people as well.
The Justice Department set off a huge public debate earlier this year when it sought court intervention to force Apple to assist law enforcement in unlocking an iPhone that belonged to one of the San Bernardino terrorists, and the issue is of particular interest to members of the software industry here in Silicon Valley, where there is tremendous pro-Apple support. In fact, it is difficult to go anywhere in Silicon Valley as a technology lawyer without being asked about the case.
However, since the case first became news, it’s become more clear that, contrary to the initial reporting on the case, the government’s fight does in fact go beyond just this one case with Apple, and that winning the legal battle, should the Justice Department be able to do so, may not succeed in achieve the intended result.
According to Tech Crunch’s reporting on the case, a court order was filed on February 16 requiring Apple to create the software necessary to unlock the iPhone and that “within hours the court had granted the request.” The government relies on a 227 year old law, the All Writ’s Act of 1789, as the basis for its legal argument. Popular Mechanics explains the government’s argument in this article.
Apple then decided to fight back by disputing that the All Writs Act gives the government the authority to compel Apple to act in this case and by raising a very public Free Speech challenge to the Court. The New York Times reported that the FBI has used the All Writs Act to successfully obtain data in the past from Apple, but that Apple is arguing that the difference in this case is that the government is trying to use the power to compel the provision of decryption services. In other words, the argument is that government wants to conscript a private business into the performance of services against its will. The New York Times further explained the First Amendment argument that Apple is articulating, explaining that the precedent is a Northern District of California case decided in 1996, which agreed that a UC Berkeley graduate student’s code was speech and protected by the First Amendment. Forbes reports that Apple also cites Universal City Studios Inc. vs. Corley, a case in which magazine publisher Eric Corley published DeCSS, a program that permitted people to decrypt DVD content, and the Second Circuit U.S. Court of Appeals ruled that computer programs and code are a form of protected speech under the First Amendment.
An impressive number of amicus briefs have been filed in support of Apple’s position, which have been made available for public viewing by Apple on its website.
While the government’s request was initially reported as an “isolated case”, it has since become apparent that the case was not really so isolated. CNN reported that Apple is in fact being pressured by federal law enforcement to hack iPhones in at least thirteen different cases across the country. Moreover, as reported by CNN, it came to light that the government had previously launched a second court case over the same issue, when the New York judge assigned to the case ruled against the government that the All Writs Act could not be used to force Apple to unlock a specific device. The Verge explains that while the ruling will not be precedent on the California case, it does give Apple a stronger argument to appeal any ruling that would go against the company and it “illustrates the dangers of trying similar cases in different courts simultaneously.” According to The Verge report, a key difference between the two cases was the “specificity of the request” since whereas the New York case only requested general assistance in unlocking the phone, the California case detailed “extensive specifications” for how to break the lockscreen protections.
In addition to the New York case, The New York Times is reporting that the Justice Department is right now considering taking legal action against WhatsApp, which is owned by Facebook, over yet another encryption issue, in which a federal judge had approved a wiretap, but the criminal investigation was thwarted by encryption in the application. According to The New York Times, the circumstances surrounding the WhatsApp dispute are even more significant as unbreakable encryption would put the “future of wiretapping” at risk.
When looking at the encryption standoff in its totality, it’s hard not to wonder why the federal government ever thought it was a good strategy to go to the courts with this fight instead of continuing to keep the issue out of the press. Despite the fact that the California case is dealing with the aftermath of a terrorist attack that arose on California soil, Apple remains today an incredibly popular company which is incredibly skilled at conducting a masterful P.R. campaign. Apple’s use of this controversy to harness public support for the company has been nothing short of brilliant. While certainly the American public favors the government taking actions to defeat terrorism, there also remains a general fear of government overreach that began with the last Bush administration and intensified with the Snowden revelations. As the New York Times observed, the debate that the government initiated by launching a court battle over the issue is probably not exactly what “Mr. Obama had in mind.” Even if the government were to achieve a legal victory in this matter, which seems perhaps less certain now after the New York ruling, the public relations victory seems to have already been won by Apple. Moreover, it’s hard to accept the argument that the government had no other possible course of action, when once this matter was made public, it was reported by multiple news outlets that John McAfee publicly offered to encrypt the iPhone for free. It seems like the country would have been much better served by the government making a more effective effort to decrypt the iPhone on its own without resorting to compelling a third party to act on its behalf.
To make matters worse, the engineering community is already publicly discussing a Plan B of simply not cooperating with the government even if it wins. The New York Times reported this week that Apple employees are contemplating the possibility of “quitting their jobs” rather than undermining “the security of the software.” Given the unpopularity of the government action in this standoff within the software industry and the high demand for engineers with the skills to do the development work in question, taking such an action would be unlikely to harm their careers. As The Verge reported, such an act of rebellion could “make the FBI’s goal nearly impossible to achieve.”
All in all, it seems hard to see how the government really comes out ahead in this controversy. The wisest course of action might very well be for the Department of Justice to swallow its pride, accept third party help, and move on. There is no question that such a next step would the more prudent use of limited taxpayer dollars. But since when has the current administration ever been judicious with taxpayer dollars?
The Federal Trade Commission’s pursuit of Lumos Labs over advertising claims made about its Luminosity brain training software programs has sent a clear cautionary signal to the health software industry that the FTC intends to exercise regulatory authority over advertising in the space to monitor companies’ health-related advertising claims for deceptive advertising issues.
The FTC reached a settlement this week with Lumos Labs on its deceptive advertising claims against the company. A copy of the FTC’s press release on the settlement is attached here.
The FTC’s complaint attached here alleged that the company’s claims about the health benefits of training with Luminosity’s mobile apps and subscription-based software services were not substantiated by science at the time that the claims were made, in violation of Sections 5(a) and 12 of the FTC Act, 15 U.S.C. § 45(a). Also, the complaint alleged that testimonials about the benefits of the program were solicited in conjunction with a contest with prizes–a fact which was not disclosed in violation of Section 5(a) of the FTC Act, 15 U.S.C. § 45(a). The FTC alleged these violations caused consumers to suffer substantial injury and unjustly enriched Lumos Labs.
As part of the settlement, Lumos Labs has agreed to pay a fine of Two Million Dollars ($2 Million) to the FTC. In addition, Lumos Labs agreed to turn over its customer list and to provide email and subscription-based notices to consumers notifying them of the settlement and giving them visible notice of their rights to end their subscriptions when they renew. The FTC agreed to lift a $50 million judgment against Lumos Labs conditioned upon the accuracy, completeness, and truthfulness of the financial statements provided by the company to the FTC. A copy of the full order is attached here. The Washington Post reports that the FTC anticipates spending the majority of the fine on consumer refunds.
The FTC action against Lumos Labs highlights the increased popularity of software in the health technology space and provides a clear signal that the FTC intends to exercise its regulatory powers against software companies making health claims for advertising purposes that have not been scientifically proven. Indeed, the FTC recently posted to its website some general guidelines for companies making health claims, in which it advised software companies procure clinical studies to support their health claims about their software products. A quick search of “health claims” on the FTC’s website underscores the apparent seriousness in which the FTC is taking the issue of regulating product health advertising claims.
The bottom line: software companies making health claims about their products are on notice that the FTC will be closely watching how you are advertising your product. So, companies in the health software industry need to make FTC compliance a high priority for their businesses.
The Prinz Law Office has just launched a new meetup group on Copyright, Software, Internet & Social Media and the Law in conjunction with the High Tech Section of the Santa Clara County Bar Association. The firm anticipates having remote as well as in-person events. If you are interested in the subject, the firm welcomes your participation. We are currently seeking potential speakers, so if you have a related topic you would like to talk on, we invite you to let us know. For more information on the meetup, please check out the link below:
Copyright, Software, Internet & Social Media, and the Law
San Jose, CA
11 Copyright Law Gurus
This group is a meetup for people interested in the intersection among copyright, software, Internet and social media, and the law. It focuses on copyright developments and le…
In the event you missed the program featuring co-presenters Silicon Valley Software Law Blog’s Kristie Prinz and Reed Smith’s Kelley Miller and produced by Stafford Publications in September, 2015, the webinar is available now for viewing by our blog readers at the following link: View Webinar. CLE credit is available for the program only when viewed at the Strafford Publications website.
Silicon Valley Software Law Blog Author Kristie Prinz will be featured as a speaker for the webinar “Negotiating Software as a Service Contracts” for the Arlington, Virginia-based Clear Law Institute on Monday, November 2nd at 10 a.m. PST/1 p.m. EDT. For more information, contact the Clear Law Institute.
The Silicon Valley Software Law Blog’s Kristie Prinz will be a featured speaker at the upcoming CLE program “Negotiating Software as a Service Contracts” on Tuesday, September 8th from 1:00 p.m.-2:30 p.m. EDT. For more information on the upcoming program, please click here.
As I posted yesterday to my blog at Silicon Valley IP Licensing Law Blog, the U.S. Supreme Court has just issued an opinion in the Commil vs. Cisco Systems case, leaving the software industry to consider how the ruling will impact member software companies.
Industry reaction to the ruling has been somewhat muted thus far, despite the fact that the Computer & Communications Industry Association (“CCIA”) representing companies such as Microsoft, Google, Facebook, Amazon, and Intuit had filed an amicus curiae brief in the matter in support of the dissenting view, taking the position that “The adoption of the expansive new version of inducement liability urged by Commil and the government would pose serious consequences for CCIA members and the technology industry as a whole.” In particular, the CCIA had taken the position that”[E]vidence of a good-faith belief of invalidity is clearly relevant to an accused inducer’s intent. . . .if a claim is invalid, “there is nothing to be infringed.” According to the CCIA brief:
Under [the Commil] theory, mere knowledge of a patent is enough for a manufacturer or service provider to be held to have induced a customer to infringe. . . .By this reasoning, a person would intentionally induce infringement when enabling others to practice a technology even though he believes it to be unpatentable.
What were the “serious consequences” anticipated by the CCIA if the decision reached yesterday were eventually issued?
In its amicus curiae brief, the CCIA articulated two key concerns. First, the CCIA warned that the ruling adopted yesterday by the majority would increase the leverage that patent monetization entities have against technology companies. Second, the CCIA warned that the ruling adopted yesterday by the majority would erode the clear standard of demonstrating intent to induce imposed by the Grokster decision.
Obviously, the Grokster decision relates to copyright infringement, and this is a patent infringement case, so I question how significantly yesterday’s ruling will impact copyright law going forward. However, there is no question that the decision may further incentivize patent monetization entities, since they will have more reason in the future to pursue additional damages for inducement liability on relatively weak patents.
As I asserted in my Silicon Valley IP Licensing Law Blog posting yesterday, however, this decision may have the most significant impact going forward on how patent litigation defense is conducted, since I would argue that the corporate calculations on how to deal with weak third party patents that could be enforced against them may not really change that much as a result of this ruling. Companies have always had to decide how to proceed with product development when a weak third party patent is identified that they potentially could be deemed to infringe, and I would argue that the calculations of whether or not the patent invalidity defense will be available in cases where an induced infringement claim is made will likely not have a significant impact on a company’s overall decisionmaking process going forward.
Privacy groups are raising alarms in response to the Senate Intelligence Committee’s Introduction of a new cybersecurity bill: the Cybersecurity Information Sharing Act of 2015 (“CISA”). The text of the current bill has been made available for viewing at this link.
According to a National Journal report discussing the proposed legislation, the bill “is intended to help forestall cyberattacks like the one that crippled Sony Pictures last year.” The two key features of the bill are data sharing with regard to cybersecurity and liability protections for companies that participate.
As you might expect, the opposition to this bill already being raised is that it imposes new surveillance pressures on companies and provides virtually no protection to the individual. The Electronic Frontier Foundation (“EFF”) has already posted a scathing statement of opposition to this bill on its website, arguing that the bill grants to companies very broad powers to protect information systems with the sole restriction that no “substantial” harm arises from the action, and that it also authorizes companies to the broad powers to conduct monitoring on information systems which can broadly be used to conduct surveillance of individuals. The EFF’s position is as follows:
This fatally flawed bill must be stopped. It’s not cybersecurity, but a surveillance bill.
Wired reports that the concern of other privacy advocates is that the bill would permit the sharing of personal data that goes beyond just stopping cybersecurity threats, but to also allow sharing for the stated purpose of preventing terrorism, the imminent threat of death or serious bodily harm, and even the investigation of crimes having nothing to do with cybersecurity.
After reviewing the text of the proposed bill myself, I would agree with the vocal opposition on this bill that there is a reason that the Senate Intelligence Committee is proposing this type of legislation that has little to do with preventing cyber attacks: to increase the surveillance powers of the federal government and to encourage broader corporate cooperation and participation in these surveillance activities. I would also argue that this type of legislation, if enacted, has the potential to disproportionately affect cloud-based software and Internet companies, co-opting them into providing enhanced governmental surveillance of their customers.
I can understand why Silicon Valley’s tech community might be hesitant to take a position in opposition to a bill that California’s own Senator Diane Feinstein has been supporting, but I would argue that this is an issue that the software industry, and particularly, the cloud industry, should step up to the plate on and strongly oppose, given the fact that data collection is such an integral part of the online software business and revenue model. This type of legislation, if passed, has the potential to put such companies in the undesirable position of conducting what amounts to surveillance activities on its customers on behalf of the government, which is not a position that most Silicon Valley companies would probably like to find themselves in. It takes the surveillance gathering that has been going on since 9/11 to an entirely new level.
The Silicon Valley Software Law Blog will keep you posted on developments with this legislation as they arise.
As a software attorney advising SaaS companies in contract negotiations, I am frequently asked for advice on negotiating indemnification clauses. While clients all have different risk tolerances when it comes to the issue of indemnification, it is always challenging to advise parties on either side of the negotiating table, as it is difficult to provide clients with any concrete guidance of what their actual risk may be.
The San Francisco Business Times recently published an article shedding some light on what the actual risk may be to parties on both sides of a data breach, which as any attorney in the software industry knows, is often the concern that prompts the most contentious indemnification negotiations in any SaaS contract discussion.
According to the San Francisco Business Times, the insurance brokerage Aon estimates that 80% of commercial privacy breaches around the world result in $1 million or less in direct costs and damages. On the other hand, the San Francisco Business Times reported that Aon estimates that approximately 15% of privacy breaches cost approximately between $1 million and $20 million, with the average cost of those larger breaches running about $7 million.
So what are the significance of these liability estimates to parties negotiating an indemnification clause in a SaaS contract negotiation?
The significance is that a particular group of industry experts are estimating the liability risk for parties on either side of the transaction to generally be at $1 million or less per transaction, with only a small portion of the cases rising significantly above this, and that where the breaches result in greater than $1 million in damages, the loss averages about $7 million. Thus, for indemnification negotiation purposes, this information suggests that most customers of SaaS services are not going to incur more than $1 million of damages in a privacy breach, and that on the flip side, most SaaS providers will not suffer more than $1 million of damages on a privacy breach affecting a particular customer.
Of course, insurance companies such as Aon do offer cyberinsurance which will provide some insurance against such risk, which is why Aon is in the business of making predictions about the cyber-liability risk to businesses: to sell cyberinsurance and evaluate its own risks as an insurer.
For my purposes, however, as a software transactions attorney, these numbers provide some helpful guidance as to how parties on either side of a deal should be evaluating their real risks for the purpose of indemnification clause negotiations. While as a customer, an unlimited liability indemnification for a privacy breach might be nice, these numbers suggest that something far less would likely be sufficient to protect your company. On the flip side, as a SaaS provider, these numbers suggest that your actual risk in the case of an unlimited liability indemnification on a particular customer contract will probably not exceed $1 million, which is far less than the numbers might be envisioned by the phrase “unlimited liability.” All in all, this data is useful to consider in the context of any SaaS contract negotiation, regardless of whether you are negotiating on the side of customer or the service provider.
The Federal Communications Commission (“FCC”) adopted new rules today on the issue of net neutrality, affirming the government’s right to increase its regulatory powers over the Internet.
In a press release issued to announce the new rules, the FCC identified the following as the key provisions of the rules to be adopted:
- Application of the rules to all methods of accessing the Internet;
- Institutes a ban over three practices determined to harm the Open Internet: (i) blocking access to legal content, applications, services, or non-harmful devices; (ii) impairing or degrading lawful Internet traffic on the basis of content, applications, services, or non-harmful devices; and (iii) favoring some lawful Internet traffic over other lawful traffic for consideration;
- Establishes that internet service providers cannot “unreasonably interfere with or unreasonably disadvantage” consumers in selecting, accessing, and using the lawful content, applications, services, or devices of their choosing;
- Ensures that the FCC will have the authority to address questionable practices by internet service providers on a case-by-case basis and provides guidance as to how the FCC will provide the standard in practice;
- Requires broadband providers to disclose in a consistent format promotional rates, fees, surcharges, and data caps, as well as packet loss as a measure of network performance, and network management practices that can affect services;
- Requires internet service providers to engage in reasonable network management that is primarily used for and tailored to receiving a legitimate network manages rather than business purpose;
- Authorizes FCC to hear complaints and take enforcement action upon any determination that the “interconnection activities” of internet service providers are not “just and reasonable”;
- Reclassifies broadband service as a telecommunications service over which the FCC has regulatory authority; and
- Specifically authorizes the FCC to allow investigation of consumer complaints, protect consumer privacy, ensure fair access to poles and conduits in order to deploy new broadband networks, protect the disabled, and bolster universal service fund support.
USA Today reports that the new FCC regulations will be published in the Federal Register in a few weeks and become law sixty days after publication.
As anyone who has followed the net neutrality issue is aware, today’s move by the FCC is considered highly controversial. While the Obama administration has characterized the net neutrality debate as a “fairness” issue in order to increase Internet access for all, opponents have warned against the dangers of allowing the government to exercise greater regulatory powers over the Internet. CBS is reporting that it conducted a recent poll on Americans’ views on the issue, and that a majority of Americans they polled were against the concept of net neutrality. However, industry groups have been far from unified on the net neutrality issue. Netflix and Twitter have been reported to have supported the net neutrality vote, as has the NTCA Rural Broadband Association. Comcast has also been reported to have gone on record as supporting net neutrality. However, several major internet service providers apparently oppose the FCC’s actions and are reportedly prepared to take legal action to challenge the new rules.
So, what does the move today mean for the software industry? While there has been minimal commentary on the subject, the implications are largely going to be in the cloud and SaaS space, which is completely Internet-dependent. There is no question the greater access to the Internet and fewer limitations over bandwidth are all positive developments for online software companies, as they could result in a larger potential customer base. On the other hand, greater government regulation over the Internet will likely translate into more government regulation over cloud-based and SaaS business activities and practices, which will inevitably result in greater compliance and legal costs for those companies, which will have to address FCC rule making, investigations, and legal actions. All in all, while the move should in theory be beneficial to the software industry, like with many big ideas, the practical consequences of the FCC action will likely not prove to be beneficial to the software industry as a whole.
In the meantime, the expectation is that we will see legal challenges filed to block the enforcement of these rules, so perhaps the only certainty is that the FCC action will provoke a legal battle over the future of net neutrality. Clearly, the action today puts front and center the debate over who should have the authority to exercise control over the Internet.
As a software company, do you make a special point of sending all your price schedules, payment terms, and price-related clauses to software counsel for review before you send them out the door to your potential customer?
If your company is like most, my expectation would be that you are probably handling all such issues internally since those are not purely legal terms and you are probably trying to save money on legal fees.
However, when a dispute arises over software licenses or SaaS agreements, what is usually at the heart of the dispute? If you guessed that it is those pricing terms that your company is handling internally to save money on legal fees, then you would be correct. It is precisely those clauses that will typically be the basis for the customer dispute.
Why is this? Well, one problem that often arises is that the pricing terms were not considered as part of the overall drafting of the contract. For example, if you are selling a multi-user license or SaaS Agreement, you have to draft the whole agreement to work with the multi-user model. If you just take a single-user software license and add a price schedule for 90 users as an attachment, then your contract is not going to work. It is still going to be a contract for a single user that is charging for 90 users. Also, if you a charging for a particular add-on service at a flat fee rate, and your contract is not set up to describe the terms and conditions being provided for the services charged, then there is a high likelihood that there is going to be an issue over the fee you are charging at some point in the future. The attorney needs to understand each and every fee you intend to charge a customer and how the fees will be charged in order to properly draft the contract. If the attorney is kept in the dark on these issues, there is likely going to be a problem with how the contract is structured and drafted.
Another problem that arises on a recurring basis is over implementation and costs that the software user may have to pay while implementation continues. When you haven’t considered the timing and amount of payments that may be due while implementation is ongoing, you are setting the scene for a potential dispute to arise. Again, if software counsel were to review your contract before it goes out the door, this issue would most likely be flagged and addressed before it ever arises and the attorney might raise with you suggestions on how to structure the fees differently to ensure that the issue never arises.
A third problem that comes up frequently is the adding on of terms onto a price schedule that conflict with terms that the attorney carefully drafted in the agreement. You should not make a practice of adding extra terms into a price schedule, and in particular, you definitely want to refrain from adding conflicting terms into a schedule. If software counsel had had the opportunity to review the draft contract before it went out the door to the customer, the attorney would have reviewed the contract specifically looking for conflicting terms and this issue would be caught and fixed.
Finally, a fourth problem that often arises is charging fees that just don’t make sense in the context of a particular agreement. For example, if you are negotiating a SaaS agreement with a customer and charging an annual maintenance fee, when maintenance fees are generally included as part of the recurring subscription fee of the SaaS agreement, or alternatively, charging on a monthly basis for a license that would generally be licensed on a one-time basis, then you are likely to run into an issue with the pricing either in negotiation or as soon as the customer becomes disgruntled. Software counsel reviewing the contract would be alert to any such issues and would flag the problem before the contract is sent out the door.
The above examples are just a few of the scenarios that can arise over how pricing terms are structured if they are not run by software counsel before they are sent out to a prospective customer for review.
The bottom line is that those pricing terms you may not want to talk to your outside software counsel about are precisely the terms that you should be consulting him or her about, as those are the terms that are most likely to result in a contentious legal dispute. Fees in software contracts need to be carefully structured in conjunction with the rest of the contract, and where that is not happening, mistakes are most likely being made, any one of which could blow up into dispute with a customer.
When I am first retained by a software company, I inevitably have a conversation with my contact at the company about their technology model. Nine times out of ten the client either will be unable to answer the question or will say that they are working under one technology model and send you contracts that reflect the exact opposite.
Why do I ask the question? Drafting an appropriate software contract (or even reviewing and providing feedback on a particular software contract is going to be dependent on whether or not the terms reflect the model. If either the client or the drafter are unclear on the model, then the contract is not going to be a high quality contract.
In software contracts, perhaps the single most common issue that gets confused is the difference between a software license and a software-as-a-service agreement. But the concepts are very different. In a software licensing model, the software company offers a physical piece of software via cd-rom or electronic download from a website to be downloaded, installed, run, and operated on a piece of hardware that is typically physically on site at a particular company or residential location. There may be one user or multiple users of the software. The software may be installed on a single piece of hardware or multiple pieces of hardware. There may be services associated with the software that are offered to the licensee such as implementation, customization, training, maintenance, and technical support. In some cases, the company may even offer separate hosting services. However, the software itself is made available to the licensee as a tangible product.
What is different about the software-as-a-service model? In the SaaS model, the software company generally makes no tangible software product available to its users, and the product itself is only available “on the cloud” as a hosted platform. As in the licensing model, there may be one user or multiple users of the platform. But the platform itself is only accessible through the cloud. Thus, the quality of the various services provided is critical because the ability to access and use the hosted platform is entirely dependent on the quality of the experience delivered. In the SaaS model, there is no separate maintenance service provided because that is all expected to be included as part of the hosted platform service package, along with the hosting and technical support. You may still have separate implementation, customization, and training services, however, that are made available separately from the hosted platform. The key feature of this model, though, is the very fact that you are offering a “service” model rather than a “tangible product” model.
What is the primary issue I see contractually? More often than not, companies say they are offering a “SaaS” model but their contract is in fact based on the software licensing model. What alerts me to this fact? Usually it’s the presence of a license grant to the software and the lack of any clauses explaining all the various services provided pursuant to the platform. It’s also not uncommon to see a maintenance agreement attached to the agreement, which is not what I typically expect to see in the hosted platform model. Also, there is often a lack of attention to any of the issues or concerns that you would have in a model where you never receive a physical product, and where you have absolutely no control over data security, your ability to save or download the data on the platform, or how well you can access the platform in the first place. Another problem that you may see is a lack of concern over how you are charged for accessing the model when some sort of set up process is involved. Obviously, if you are being charged on a monthly basis for accessing a platform and a set of related services, you don’t want to be charged until set-up is complete and you can access the platform and immediately use it. This is less of an issue in a licensing model where the fee is usually billed once and not charged again during the life of the product.
The bottom line is that these two models are very distinct business and technology models and the contract will absolutely not be correctly set up if the appropriate technology model is not determined and/or understood in advance of drafting. The same is true in contract reviews: it is impossible to provide accurate feedback in reviewing a contract if the technology model is not thoroughly understood before the review is started. Everything starts with the technology model.
So, if you retain an attorney like me to work with your software company on contracts and you are asked about your technology model, be prepared to answer the question. Thoroughly sorting out the terms as they relate to the model is critical to the proper drafting or proper revision of your contracts, and spending billable time on this issue is time very well spent, as the job cannot be done properly otherwise.
There seems to be a common universal belief among many companies that there is a single form agreement circulating among software lawyers with the perfect terms that can just be cut and pasted into their agreements if they can just find the right attorney who can furnish that ‘perfect’ form agreement. I have lost count of the number of times I have been told by clients that they don’t need anything from me other to provide said ‘perfect’ template. A few have even equated my or another attorney’s ability to provide them with the ‘perfect’ form template to the level of expertise of the attorney.
The reality, of course, is that merely cutting and pasting from a form agreement–even a very well-written form agreement–is precisely the wrong way to draft this type of agreement. In fact, I would take this one step further and take the position that it is precisely the wrong way to draft all technology agreements. Furthermore, it is my opinion that an attorney’s willingness to provide any document purported to be a ‘perfect’ software template is likely to be inversely correlated to his or her level of drafting experience in the space. I certainly was far more comfortable with the idea of furnishing a template in response to a client request of that nature as a very junior and inexperienced attorney than I am today, when I know better. I’ve seen all too well how companies may take the ‘perfect’ template provided and rely on it for years and years without understanding that the form required many long hours of attorney customizations and revisions before it was ever put into use for their business.
While there absolutely are standard terms that you will find in all software agreements–whether SaaS or software licenses–which may form the basis of high quality software template for either the software license or SaaS model, a well-drafted contract is more than just an assortment of the “right” terms, it reflects the actual product offering to customers. Thus, the drafter needs to not only know and understand how to draft these contracts but also have a very high level understanding of what the product offering to customers is. Otherwise, the contract will be of a very poor quality, regardless of how good the lawyer was that put the original form agreement together that the contract may be based upon.
For example, in the enterprise license model, a company may purchase a license allowing a set number of user rights. In such a model, a well-drafted license would at least explain what constitutes a user, how users can be added and deleted, what rights the users have to the various license grants made (which should go beyond the simple ‘use of the software’), the cost of purchasing new users, and the cost of purchasing the initial set of users. But the decisions on how to structure each of these terms would be entirely dependent on the business model and product offering made available by the specific software company. Thus, if the terms selected are being cut and pasted from an unrelated form agreement, it is almost certain that the terms chosen will be wrong and make no sense.
The same problem occurs with the cutting and pasting of SaaS agreements. In the enterprise model, again, you may similarly have users with different access rights, which are the SaaS equivalent to a license. Your enterprise customer may want to start with 100 users and anticipate needing to add 100 more in a period of months. Your enterprise customer may also anticipate losing some users and want to get some sort of credit for the users lost. You may have different pricing based on when the timing of the purchase of new users. Given all these different drafting and business model choices that can be made, if the terms selected are simply being cut and pasted from an unrelated form agreement, again, it is almost certain that the resulting agreement simply will make no sense.
The structural choices in how you draft these kinds of agreements do not end with the user rights. For example, there are choices that the drafter has to make based on what type of data is being collected by the product, where the data is being stored, the level of risk to the company if the data is accessed by a third party, and what needs to happen to the data at the end of the relationship. Also, there are choices that need to be made based on whether use of the product depends on importing pre-existing data into the software and effectively reading such data. It is not uncommon for enterprise customers to have much higher requirements with respect to data than a small business client would generally have. Fees, technical support, and training are other common areas of significant variation from product to product.
The bottom line is that a well-crafted software license or SaaS agreement will be structured around the technology, features, functionality, and business model of the applicable product and will not be based merely on a set of “perfect” terms from any template. As a software company, that means that if you retain an attorney to advise you on your contracts, your attorney should absolutely be pushing you to provide significant details about how the technology, features, functionality, and business model of your product work, among other issues. If you are not getting those kinds of questions from your lawyer, then it is highly likely that the terms of any contracts that your attorney reviews or drafts for you will reflect a similarly low level of understanding about those same concepts.
The Wall Street Journal reported this week that apps on the market overall are not providing users with even basic privacy protections.
The report focused on research conducted by the Global Privacy Enforcement Network, which is a coalition of privacy officials from 19 countries, including the U.S. Federal Trade Commission, and determined that 60% of the 1211 different apps reviewed raised privacy concerns, as they did not disclose how they used personal information, they required that the user give up significant personal data in order to download the app, and their privacy policies were posted in font too small to be read on a smartphone screen. In addition, they found that 30% of the apps provided no privacy information whatsoever, and 31% requested access to person data without advising users whether or not the personal data was necessary for the app to function. Just short of half of the apps had privacy policies that were not smartphone-friendly in terms of their readability.
The big story on the Internet today is about the new app-based ride service Uber: California regulators have just notified Uber and its competitors, Lyft and Sidecar, that the services are illegal under California law.
An article by Forbes Contributor Mark Rogowsky offers a fairly comprehensive explanation of California’s problem with these services. Apparently the issue raised is a violation of Section 5401 of the California Public Utilities Code, which involves how charter party carriers of passengers are compensated. The letter advised each company that they could petition the CA legislature to change the applicable law, but until the law was changed that California would be enforcing state law.
Tech Crunch published the reactions of each of the affected companies to the notice letter.
I agree with the commentators who are struck by the irony by the fact that California of all states is imposing the roadblock that threatens to shut down these services. Clearly, there are a lot of businesses in the state that unhappy with all the attention that these new business models are attracting, but it is more than a little surprising that the California government itself–undoubtedly the greenest of the 50 state governments–is the one that is threatening to shut down the business model. I suspect that new legislation is going to get rushed through the California state legislature to fix this little snafu in a hurry. What do you think?
California has just enacted a smartphone kill switch law, which will require all smartphones sold in the state of California as of July, 2015, to have kill switch features enabled as the default settings on the smartphone.
SB 962 requires all smartphones:
manufactured on or after July 1, 2015, and sold in California after that date, include a technological solution at the time of sale, which may consist of software, hardware, or both software and hardware, that, once initiated and successfully communicated to the smartphone, can render inoperable the essential features, as defined, of the smartphone to an unauthorized user when the smartphone is not in the possession of an authorized user.
The bill requires that the technological solution utilized must be able to withstand a hard reset and must prevent reactivation on any wireless network except by an authorized user. Resold phones will be exempt from this requirement, as well as any model of smartphone on the market prior to January 1, 2015, which cannot reasonably be re-engineered to support the manufacturer or operating system provider’s technological solution.
The bill imposes a civil penalty of not less than $500 nor more than $2500 for each knowing violation of the bill’s requirements, and enables enforcement by the Attorney General, a district attorney, or any city attorney.
California’s move follows the adoption of similar legislation by Minnesota earlier in the year, as reported by Cnet. According to Cnet, Minnesota’s law differs from the new California law, however, in that the kill switch feature is not required to be turned on as a default setting when the consumer first sets up the phone.
USA Today reported that the cell industry’s trade group, CTIA-The Wireless Association, has opposed the idea of kill switch legislation, and alleged that this was largely due to the group’s self-interest in perpetuating the lucrative market for cell phone insurance.
Overall, despite industry opposition to the bill, the reaction to this legislation has been positive. Some media analysts have predicted that California’s move will cause all smartphone makers to adopt the kill switch as a default on all smartphones, given the size of the California market, and that this will all but eliminate smartphone theft in the country, since anyone who steals a smartphone will be left with a dead phone as soon as the owner realizes it is gone.
However, interestingly enough, the Boston Globe took a contrarian view on the legislation, arguing that it was unnecessary and could have “unintended consequences.” In particular, they raised concerns about a provision in the law that allows governments to deactivate cell phones thereby “micromanaging the tech market.”
As someone who worries about government interference with private markets, I went back to the text of SB 962. Based on my reading of the bill, the law only references preexisting California law in Section 7908 of the Public Utilities Code and does not actually provide any new government rights to the smartphone marketplace. So, while the Boston Globe’s point is well-taken about the dangers of government encroachment into the private marketplace, I do not personally see from my reading of the legislation how that is really an issue in this particular case. Certainly there is an argument that can be made that this law is unnecessary, as smartphone makers were already introducing these safety mechanisms on their own, but obviously the legislation now eliminates the option not to include the features as a default setting on smartphones and it is challenging to come up with an argument as to why this is bad for consumers or the marketplace generally.
All in all, I think California got it “right” this time and applaud the decision to pass the legislation.
California has just added a new type of clause to the list of clauses that violate public policy in the state: the non-disparagement clause.
Governor Jerry Brown has just signed AB 2365, which prohibits companies from including nondisparagement clauses in consumer contracts, including online terms of service.
The bill–nicknamed the “Yelp” bill–prohibits now the inclusion of any clause for the sale or lease of consumer goods and services from which waives the consumer’s right to make a statement about the seller or lessor or its employees and agents, or concerning the goods or services. The bill also makes it unlawful to “otherwise penalize a consumer for making any statement protected under the bill.”
AB 2365 imposes penalties of $2,500 for the initial violation and $5,000 for each subsequent violation, as well as an additional penalty of $10,000 if the violation was “willful, intentional, or reckless.” The bill authorizes the affected consumer, the Attorney General, or the district or city attorney to file the claim.
The San Francisco Business Times is reporting that that this bill was adopted in direct response to a Utah case of a couple who received a demand of $3500 from retailer that they had criticized online.
As you might expect, Yelp has already publicly responded by applauding the signing of the law bearing its nickname.
This law has widespread implications for virtually any company engaged in business on the Internet, and any business entering into contracts, where the consumer or lessee is based in California. Thus, if you do business in the U.S., you now have a new constraint on what you can put in any contract or legal document, including Internet document, that your company adopts or signs.
While it goes without saying why Yelp would support the enactment of this kind of legislation, as an technology transactions attorney who drafts and negotiates contracts for a living, I find this level of government intrusion into private contracts absolutely appalling, as its application is going to go far beyond the narrow set of circumstances that the law was enacted to address. Plus, the impact of the adoption of this bill is going to be very far-reaching and force companies in all 50 states–not just California–to modify their standard contracts, even their service contracts.
Perhaps it is time to take this issue to Congress–at which point we in the business world will then have the opportunity to see just how far the Yelp lobby’s influence actually extends.
The Federal Trade Commission has announced that Google has agreed to refund customers’ unauthorized in-app purchases made by their children in the Google Play Store pursuant to a settlement over a complaint filed by the Commission alleging violations of Section 5(a) of the FTC Act, 15 U.S.C. Section 45(a) prohibiting unfair or defective acts or practices affecting commerce. Attached is the FTC press release of the settlement. In particular, the complaint alleged that Google’s practice had been to bill Google account holders for children’s activities in applications without obtaining the prior consent of the Google account holder, and that the refund process to get the unauthorized charges reversed had been difficult.
The total amount of refunds Google is anticipated to make pursuant to this settlement exceeds $19 million. According to the FTC, Google has also agreed as part of the settlement to procure express, informed consent from customers before charging them for any items sold in a an app going forward.
The move by Google to settle the FTC’s complaint follows a similar move by Apple earlier in the year to settle the complaint initiated by the FTC on similar grounds. Like Google, Apple agreed to refund all unauthorized in-app purchases made by children and to change its billing practices to obtain express, informed consent from customers before charging them for items sold in a mobile app, according to the press release issued by the FTC following its settlement with Apple. The estimated cost of the refunds in the Apple case was estimated to be at $32.5 million.
In looking at the outcome of these two cases, I can’t help but question whether the Federal Trade Commission’s regulatory involvement in the smartphone app business is a good development for the industry or not. On one hand, there were clearly a large number of angry Americans who were billed for unauthorized charges through their smartphones and apparently not getting relief from either Google or Apple. So, clearly from that perspective, the outcome was the right one for consumers.
But isn’t the real problem here the smartphone app platforms themselves for both companies and the fact that neither company was responding to customers who were getting billed for unauthorized changes by fixing the platform? Should that have required government action to fix? Shouldn’t the private market have been able to accomplish the same action?
I personally am a little troubled by the fact that the FTC seems to be inserting itself in the digital world to the degree that it seems to be doing. Even though the outcome was the right one for consumers in this particular case, I wonder if we should all be concerned with the FTC’s continued interference with the digital marketplace.
As for the companies themselves who were the subject of the complaints: clearly the industry has been generating revenues from unintended purchases. Is that really the way that the industry should be conducting business? Perhaps the industry itself should step up to the plate and make more of an effort to remedy the way that purchases are made on a smartphone to eliminate accidental purchases altogether.
The U.S. District Court for the District of Maryland has awarded damages in excess of $163 million in a FTC case against a “scareware” software company, Innovative Marketing, Inc. and its founders.
The FTC alleged violations of Sections 5(a) and 13(b) of the Federal Trade Commission Act (“FTC Act”), 15 U.S.C. §§ 45(a) and 53(b) for deceptive conduct in the sale of the software. To market and sell the software, the defendants misrepresented to victims that they had run scans of their computer and found security or privacy issues, including viruses, spyware, system errors and pornography. Defendants also placed misleading ads for their software on Internet advertising networks, who started receiving complaints about the company. The security or privacy issues to be found were pre-determined in advance of the scan run, and the software that was sold to fix the “problem” did nothing. Apparently more than one million consumers were conned by the scheme.
The court found that the defendants had engaged in unfair or deceptive acts or practices affecting commerce, and held the founders as well as the company itself jointly and severally liable for the damage award. The court also issued a permanent injunction against one of the founders from marketing computer security software and software that interferes with consumers’ computer use.
The FTC has just announced proposed changes to its existing rules protecting children’s online privacy and is currently accepting public comment to the proposed rules through September 10, 2012. The proposed changes would amend the Children’s Online Privacy Protection Rule (“COPPA”).
In particular, the FTC is seeking to make modifications to the following language:
- Revise the definitions of “operator” and “website or online service directed to children” in order to specify that the operator of a child-directed site or service which incorporates into the site or service any plug-ins that collect personal information from visitors to the site should itself be subject to COPPA.
- Revise the definition of “website or online service directed to children” to specify that (a) plug-ins or ad-networks are covered by COPPA if they know or have reason to know that they are collecting personal information through a child-directed website or online service; (b) websites that appeal to both adults and children under 13 years of age may screen all visitors’ ages in order to provide COPPA’s protections only to users under age 13; and (c) all child-directed sites or services that knowingly target children under 13 or whose content primarily appeals to children under 13 must treat all users as children.
- Revise the definition of “personal information” to clarify that a persistent identifier will be treated as personal information “where it can be used to recognize a user over time, or across different sites or services, where it is used for purposes other than internal operations,” and revise the definition of “support for internal operations” in order to specify that activities such as “site maintenance and analysis, performing network communications, use of persistent identifiers for authenticating users, maintaining user preferences, serving contextual advertisements, and protecting against fraud and theft” will not constitute as the “collection of personal information,” provided that the information collected is not used or disclosed to contact a specific individual, including through the use of behaviorally-targeted advertising, or for any other purpose.
The full text of the proposed new rules is attached here.
In all honesty, while I’m all in favor of protecting children on the Internet, I’ve never been a big fan of COPPA. In my role as counsel to start-ups and small businesses, clients often come to me for advice on COPPA compliance, and the truth of the matter is that the language is cumbersome to read and interpret, and the rules are difficult to implement. Moreover, I question the practical application of COPPA in this day and age where kids are so wired at a very young age and there is so much quality educational content available to kids.
So, with that being said, I think further clarification of how the FTC is reading the rules on the enforcement end is welcome and long overdue.
However, at the same time, the FTC is clearly trying to expand the reach of COPPA, and if implemented, any expansion is going to pose an additional hardship on affected start-ups and small businesses. Huffington Post writer Larry Magid argues that the FTC has greatly underestimated the number of businesses that would potentially be affected by these new rules. I know in my practice alone I’ll have a number of start-up and small business clients who would be affected by any new rules in this space. Are the changes really going to have the effect of better protecting kids or are they just going to add to the administrative burden already facing start-ups and small businesses in the website and software services space?
The good news is that there is still time to review the proposed language and communicate your thoughts to the FTC, so I would encourage website and software service providers to get involved in the process and voice your opinions while this is still just a proposal.
The purpose of the initiative is to urge Congress to adopt a Consumer Privacy Bill of Rights, which codifies the following:
- Individual Control: Companies should give consumers control over the personal data that they share and how companies collect, use, or disclose that data. They should be given clear and simple choices that enable them to make meaningful decisions about data collection, use and disclosure. Companies should give consumers the opportunity to limit or withdraw consent that are as easy as the methods for granting initial consent.
- Transparency: Consumers have the right to easily understandable and accessible information about companies’ privacy and security practices. Companies should provide clear descriptions of what data they collect, why they need the data, what they will do with the data, when they will delete or de-identify it from customers, and whether and for what purposes they may share the data with third parties.
- Respect for Context: Consumers have the right to expect that companies will collect, use, and disclose personal data in ways that are consistent with the context that consumers provide the data. Important considerations for context are the age and sophistication of customers. Children and teenages should have greater protections than adults.
- Security: Consumers have a right to secure and responsible handling of personal data. Companies should maintain reasonable safeguards to control risks such as loss, unauthorized access, use, destruction, modification, and improper disclosure.
- Access and Accuracy: Consumers have a right to access and correct personal data in usable formats in a manner that is appropriate to the sensitivity of the data and the risk of adverse consequences to consumers if the data is inaccurate.
- Focused Collection: Consumers have a right to reasonable limits on the personal data that companies collect and retain. Companies should collect only the personal data they need to accomplish purposes specified under the context, and they should dispose or de-identify personal data once they no longer need it.
- Accountability: Consumers have a right to have personal data handled by companies with appropriate measures in place to ensure they are adhering to the Consumer Privacy Bill of Rights. Companies should be accountable to enforcement authorities and to consumers and companies should hold employees responsible for adhering to these principles. Where appropriate, companies should conduct full audits. If companies disclose data to third parties, they should ensure at a minimum that the recipients are under contractual obligations to adhere to these principles.
The initiative also asserts that the legislation should provide the FTC and State Attorneys General with the specific authority to enforce the Consumer Privacy Bill of Rights.
My initial reaction to the President’s announcement is mixed. As a consumer of the Internet who spends 95% of my day online, I am sick and tired of getting tracked all over the Internet. I find it very annoying to have advertisements pop up for somewhere I have shopped or thought about shopping online, and as soon as another advertisement pops up, I inevitably check all my computer settings and delete cookies and do what I can to stop being tracked. However, it seems as though nothing works–or at least nothing works for long. So, I agree that all this Internet tracking is overly intrusive and an annoyance.
At the same time, as an attorney in the Internet and Software space, I am strongly concerned by the fact that the President is proposing more government regulation over the Internet and more enforcement authority over the Internet. I agree with many of my legal counterparts who believe that the intrusion of more government regulation over the Internet is a hornet’s nest: the Internet has no borders, so if the United States government is allowed to police the Internet to a greater extent than it is currently doing, why shouldn’t other governments be allowed to do the same? And where do you draw the line? Philosophically, I think there is a very good argument that the federal government should not be empowered with the ability to step up its regulatory and enforcement authority over the Internet.
Putting aside my general concern over the federal government increasing its regulatory and enforcement powers in the Internet space, my next concern is that we may be imposing a HIPAA like regime over all businesses and not just the ones that handle personal health information. Is that really a good idea? Moreover, my understanding is that as a result of The Affordable Care Act, the government is now trying to coerce companies to turn over HIPAA information to the Department of Health and Human Services. If this is in fact happening, what is to stop the government from doing the same thing with other personal information once they have further regulatory authority? It’s bad enough that I’m being tracked by businesses all over the Internet, but the idea that Uncle Sam might be doing it is even worse.
And, then there is the concern that this initiative would be duplicating existing laws. We already have a law to protect children’s personal information on the Internet: the Children’s Online Privacy Protection Act (“COPPA”). We also have state privacy legislation that presumably this law would supersede.
Finally, as a lawyer for software and Internet companies, you have to be concerned about how this new privacy initiative will impact their existing business models. Many of my clients rely on the collection of this personal information to drive their revenues, as the websites rely on advertising and the sharing of data to make money. Will this new initiative have the ultimate effect of putting some Internet and software companies out of business?
Of course, at the moment, these are just my initial reactions to the President’s announcement. His initiative is merely a proposal to demonstrate to consumers who are likely voters that he is looking out for their well-being in an election year. Indeed, the initiative does not even rise to the level of a bill being introduced to Congress. Moreover, I would argue that the initiative contains largely “feel-good” language without any real teeth, so for now, my concerns about what happens next are simply speculation on my part about what Congress could do with the initiative, or alternatively, what the Federal Trade Commission might do on its own accord without any legislation being passed in Congress.
Still, as much as I personally dislike being tracked all over the Internet, I am troubled by the signals that the President is sending us through his announcement and concerned that expanding consumer privacy protection powers is just the first step to a further expansion of U.S. government regulatory powers over a global Internet. While at a personal level I would like to draw the proverbial line in the sand on Internet tracking, I worry about what the impact of actually allowing the federal government to draw a line in the sand for us will be on the further development of the Internet. For those of you who brush off this question, you should remember that the Internet does not have physical borders. So, where exactly do we draw the line between the U.S. government’s regulation of the Internet and another government’s regulation of the Internet? I think we need to stop to consider these questions very carefully before we start contemplating the further expansion of federal powers over the Internet–even if those powers may be directed at reigning in a business practice that many of us find intrusive and annoying.
Now that SOPA and its companion bill PIPA have been tabled thanks in no small part to the statement made by the online community in organizing the SOPA blackout, the focus shifts to the Online Protection and Enforcement of the Digital Trade Act (the “OPEN Act”), H.R. 3782, which was introduced by Rep. Darrell Issa (R-California) on the same day as the SOPA blackout as an alternative to SOPA and PIPA. As PC World reported, supporters of the OPEN Act include Google, Facebook, LinkedIn, and Twitter, but as you might expect, the Motion Picture Association of America opposes the bill as being too easy on internet piracy.
What are the key provisions of the OPEN Act? Well, unlike in SOPA, the OPEN Act gives the International Trade Commission (“ITC”) enforcement action and focuses on foreign-based websites that willfully promote the violation of copyright law. If the ITC finds that a website is “primarily and willfully” promoting the violation of copyright law, the OPEN Act allows the ITC to issue a cease and desist order against the website and to render the infringing site unable to make a profit off of the infringing activities. Congressman Issa has set up an interactive website, where you can read the full text of the bill and comment on the provisions. Also, he has provided a summary and explanation of the bill, which you can read here.
Obviously, the OPEN Act provides a far less drachonian approach to dealing with infringing foreign websites than what was contemplated by SOPA, which would have allowed full websites to be completely “erased” from the Internet. Instead, the OPEN Act’s approach goes to the heart of the problem: cutting off the ability of infringers to make a profit off of their infringement. So, in that respect, the OPEN Act is definitely improvement over SOPA. Also, there is an argument that the ITC is a more appropriate body to hear these kinds of disputes, since the agency already has been tasked with the job of addressing unfair import disputes, where intellectual property violations are involved. Furthermore, this bill focuses on the problem of infringement by foreign websites, so it targets the real source of concern over infringement as opposed to usurping existing methods of dealing with domestic infringers.
On the other hand, you certainly can argue that the process of pursuing an ITC hearing may be too cumbersome for some U.S. businesses to pursue, where they are being infringed by a foreign website. And, of course, it fails to address the issue of how to deal with infringement by foreign websites where those websites are not openly profiting off the infringement. Furthermore, it’s not clear yet exactly how this new solution for dealing with infringement would interplay with the existing methods of dealing with infringers.
All in all, however, I think the OPEN Act is a much more palatable proposal for dealing with infringers, and that this bill is a far better working document than what we had on the table with SOPA and PIPA. At the same time, I think that the whole concept of adopting new legislation to deal with online infringers is still a work in progress warranting further consideration before any new legislation is adopted. I personally am still not overly happy with the Digital Millenium Copyright Act (“DMCA”) and would have liked to have seen more consideration given to that bill before it was adopted. I would argue that we need to stop and give further consideration to the whole body of copyright infringement law before we start adopting new legislation to deal with the same problems that the prior legislation attempted to deal with.
My colleague Professor Eric Goldman of Santa Clara School of Law reviewed this proposed legislation back in December, and had some very interesting comments to add to the discussion, which were republished by Ars Technica. His overall assessment was that the OPEN Act was an improvement over SOPA and PIPA and should be the working document for a new bill, but that it still required significant work before adoption.
I think it is safe to say that there is a general feeling out there that current copyright law does not provide enough protection against offshore infringers. As a practitioner in this space, I regularly have to tell clients what their options are to deal with offshore infringement and inevitably they are less than satisfied with the options available to them to deal with this type of problem. I think the question for us all is how best to fill in the gaps in existing law that make stopping offshore infringement out of reach for so many domestic copyright owners. I would agree with Professor Goldman that we aren’t quite there in coming up with a workable solution to these issues.
A number of prominent websites have organized an anti-SOPA protest tomorrow, and are set to blackout for the day. A blackout instructions website has been set up to advise Internet website owners on what to make your website go dark on the designated January 18th protest day.
The Los Angeles Times is confirming that Mozilla, Reddit, Word Press, Boing Boing and the English language version of Wikipedia have confirmed their participation in the organized blackout. Twitter has announced that it will not take part in the organized blackout.
In case you have not been following the SOPA controversy and were not up-to-speed on the fact that a blackout day was being organized, the Stop Online Privacy bill was introduced in late October, 2011 by the Republican Congressman Lamar Smith of Texas, which would allow the Attorney General of the United States to seek a court order against internet service providers to cause them to make a website disappear from the Internet. CNET
has published an excellent overview of the current controversy. The bill was designed to allow U.S. companies to shut down offshore infringers, and as you might expect is being championed by the Motion Picture Association of America and the Recording Industry Association of America, which of course, are highly invested in stopping the loss of profits to online privacy.
While few in the Internet world would disagree that online privacy is bad, the controversy over SOPA is over the concern that large companies are going to be able to censor or blacklist smaller Internet players and simply be able to “erase” their very existence from the Internet. Net Coalition.com has assembled a list of parties who oppose SOPA. The list includes companies, prominent individuals and educators, public interest gorups, industry associations, websites and online services, cybersecurity and engineering groups, and international human rights advocates.
The text and a summary of the bill is posted here.
Where do I come down on this issue?
Like most attorneys who represent clients in the Internet space, I have found myself on both sides of this issue. It is not unusual to have a client come to me with a complaint about a third party infringing my client’s copyright on the Internet, and to find myself in the frustrating position of having to advise my client of the limited options available for dealing with the infringement. It is particularly frustrating when I am talking to a client who has limited resources and cannot afford the investment of resources that is going to be required to really go after the infringer.
In fact, even I have run into situations where my copyrighted works were being infringed on the Internet and I had to make a decision about how to best deal with the infringement.
At the same time, however, I am very concerned by the fact that Congress wants to further legislate in this area. I agree with many of my fellow Internet law experts that we should oppose in general the encroachment of government regulation of the Internet, and this bill appears to be very serious encroachment. Moreover, I am concerned about how a bill like this would be used. It is almost certain that the small content publisher on the Internet would be at a serious disadvantage in defending itself against SOPA-based actions. Large companies with large teams of lawyers would be in a position to effectively censor smaller entities on the Internet, since the accused would not be financially able to defend themselves. It is highly likely that a bill like this which would allow parties to “erase” websites from the Internet would be misused for the economic benefit of one party over another.
Of course, there is another issue. Given the fact that the very nature of Cyberspace is borderless, should a U.S. attorney general really be able to police websites offshore? If so, shouldn’t the equivalent officials for other governments be able to do the same thing? What kind of standard are we setting for the rest of the world to follow? I’m not sure we want certain countries’ political leaders to start erasing American websites from the Internet.
The bottom line is that the implications of this bill go beyond the intent of just getting offshore infringers that cannot be shut down off the Internet. The effects of this bill could be very far-reaching, and take us a step closer to the day when virtually every activity on the Internet is subject to government oversight and regulation–not only by the U.S. but also other governments around the world.
So, as we approach the observation of SOPA Blackout Day, give some thought to what the Internet is going to be like if government officials have the power to “erase” a website from the Internet. Will such blackouts be an advancement of justice or an encroachment on our rights?
Companies distributing applications on the Apple App store should take note: multiple companies today have stopped selling content from their applications sold on the Apple App store, suggesting that Apple is taking steps to enforce its new rules to collect its royalty on direct sales from applications being sold on the App Store.
The Financial Times reported that Apple began notifying companies last week that it intends to enforce its new policy and to collect its standard royalty rate on direct sales made even through a mere link in the application to the app owner’s website.
The Wall Street Journal reported its decision to no longer sell content directly from its application to customers and also reported that Kobo, Inc., a Canadian e-book retailer, made a similar announcement, and that Google Books was no longer in the App Store as of Sunday night. Today’s iPhone likewise reported that Amazon discontinued sales of e-books from its Kindle e-reader as of today, and The Financial Times added Spotify and Rhapsody to the list of companies who had removed features to sell products from their applications.
The reports suggest that many of these companies had previously included a link within their applications to a separate store on their websites and had not been paying the Apple royalty on direct sales that had been redirected to their websites from their applications.
Based on the actions just taken by these large companies, it seems clear that all companies who are distributing applications from the App store need to take note of these signals coming out of Apple and from large companies doing business with Apple and anticipate future enforcement activity against their companies if they are selling products through their applications on the App store without paying Apple its royalty on the sales. Apparently just having a link within the application to a store outside of the application may be enough to trigger the Apple royalty.
Silicon Valley entrepreneurs have a tendency to want to offer equity to anyone who they hire when they are first getting off the ground, and some developers prefer to receive equity in the business over an IOU that they may or may not be able to collect on.
However, when an entrepreneur calls me saying that he or she wants to offer equity to a developer he or she barely knows but wants to bring on board for the project, I always suggest that he or she consider another option: a collaboration relationship.
In my recent posting to the Silicon Valley IP Licensing Law Blog, I explained why collaboration agreements should be contemplated by many software start-ups hiring their first developer.
Disputes over development projects are extremely common in even the best of economies, but are particularly common in today’s world, where most companies are on a tight budget and developers are always on the lookout for better paying opportunities.
In fact, development disputes are becoming so widespread that I receive calls now almost daily about yet another web or software develpment dispute. Surprisingly, in almost every case, the purchaser of the development work has overlooked a critical aspect of the project: the purchaser has neglected to request an assignment of the copyright for the work developed.
My recent post on the Silicon Valley IP Licensing Law Blog explored why you should require a copyright assignment agreement before you start a development project. Requiring a copyright assignment when you start the development project ensures that you will obtain the rights to the work you are paying for when the project is completed. Otherwise, the chances are high that the developer will terminate your license to use the work as soon as a dispute arises, and you will lose not only the cash you invested in the project but also your rights to use the work.
I receive a call nearly every day from an entrepreneur who has a great idea for a new software start-up company, and is concerned about how to protect that idea before he or she is able to launch it.
Unfortunately, for such entrepreneurs, there is no application that can be filed that can protect mere ideas. However, entrepreneurs should still take steps from the moment they first conceive the concept for their business to protect the intellectual property they develop. On the firm’s sister blog, The Silicon Valley IP Licensing Law Blog, I discussed what software entrepreneurs can do to protect their start-up ideas before they actually get them off the ground.
Blog Author: Kristie PrinzRead More
UPCOMING LIVE PROGRAMS
- Best Practices for Negotiating and Drafting SaaS Contracts (2021)
- Best Practices for Drafting Master Services Agreements and Managing the Service Relationship
- Legal Developments Impacting the Software Industry
- Best Practices for Negotiating SaaS Contracts and Managing SaaS Customer Relationships (2020)
- Best Practices for Negotiating SaaS Contracts and Managing Customer Relationships (2019)
- Best Practices for Drafting SaaS Contracts and Managing Customer Relationships (2019)
- Best Practices for Drafting SaaS Contracts that Reduce the Sales Cycle and Avoid Disputes (2017)
Why Not to Refer to a “SaaS Agreement” as a “SaaS License”
- Antitrust Regulation
- App Store Changes
- California Privacy Legislation
- Criminal Investigation
- Data Breach
- Development Tips
- Digital Health
- Employment Litigation
- EU Regulation
- FCC Regulation
- FDA Regulation
- FTC Regulation
- Internet Legislation
- ON-DEMAND PROGRAMS
- Patent Litigation
- Privacy Shield
- Small Business Legislation
- Smartphone Applications
- Software Agreement Drafting
- Software Controversies
- Software Crimes
- software implementation
- Software Legislation
- Software Litigation
- Software Start-up Tips
- Start-up Software Company
- State Regulation
- Talk with an Expert Series
- Upcoming Event Notice
- UPCOMING LIVE PROGRAMS
- Upcoming Speaking Engagements
- US Privacy Legislation
- The Prinz Law Office Adopts New Fixed Rate & Subscription Billing Packages
- FTC Announces Settlement with Twitter Over Deceptive Use of Account Security Data
- Introduction to Silicon Valley Privacy Law Blog
- Introduction to Digital Health Workshop for Non-Lawyers
- Introductory Digital Health Contracts Workshop for Lawyers
- The Prinz Law Office Adopts New Fixed & Subscription Billing Options
- Kristie Prinz to Speak on “Best Practices in Negotiating Drafting and Managing Sublicenses”
- Kristie Prinz to Present Webinar on “Negotiating Consulting Services Agreements in an Uncertain Economy”
- Kristie Prinz to Present a Webinar on “Introduction to Negotiating & Drafting SaaS Agreements”