Mailing List

Popular Articles

Recent Articles

Follow Us

Archive for May, 2017

Bipartisan Bill Introduced in Senate that Seeks to Prevent Attacks on American Cyber-Networks

Written by on Friday, May 19th, 2017

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.

Category: Software Legislation  |  Comments Off on Bipartisan Bill Introduced in Senate that Seeks to Prevent Attacks on American Cyber-Networks

Negotiating the Purchase of SaaS Company Assets: Key Problems to Anticipate in any Deal

Written by on Wednesday, May 10th, 2017

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.

Category: Software Agreement Drafting  |  Comments Off on Negotiating the Purchase of SaaS Company Assets: Key Problems to Anticipate in any Deal

Investigation Reportedly Launched by Department of Justice into Uber’s Use of “Greyball” Software

Written by on Saturday, May 6th, 2017

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 Timeswhich 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.

Common Software Agreement Fee Drafting Problems and How to Fix Them

Written by on Wednesday, May 3rd, 2017

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.

Category: Software Agreement Drafting  |  Comments Off on Common Software Agreement Fee Drafting Problems and How to Fix Them

Invitation to Join VCTaskforce at StartUpWorld 2017

Written by on Tuesday, May 2nd, 2017

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:


Category: Upcoming Event Notice  |  Comments Off on Invitation to Join VCTaskforce at StartUpWorld 2017

Does Your Customer Software License or SaaS Agreement Leave Your Software Company Vulnerable to a Legal Dispute Over Implementation?

Written by on Monday, May 1st, 2017

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.


Category: Software Agreement Drafting  |  Comments Off on Does Your Customer Software License or SaaS Agreement Leave Your Software Company Vulnerable to a Legal Dispute Over Implementation?

Apple Implements App Store Affiliate Commission and Pricing Changes

Written by on Monday, May 1st, 2017

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.

Category: App Store Changes, Smartphone Applications  |  Comments Off on Apple Implements App Store Affiliate Commission and Pricing Changes

Copyright 2008-2017 The Prinz Law Office.

The Prinz Law Office | Silicon Valley | Los Angeles | Orange County | San Diego | Atlanta | Tel: 1.800.884.2124

Silicon Valley Office: 2033 Gateway Place, Suite 500, San Jose, CA 95110 (408) 884-2854. Los Angeles Office: 3110 Main St., Building C, Santa Monica, CA 90405. (310) 907-9218. Orange County Office: 100 Spectrum Center Drive, 9th Floor, Irvine, CA 92618. (949)236-6777. San Diego Office: 4455 Murphy Canyon Road, Suite 100, San Diego, CA 92123. (619)354-2727. Atlanta Office: 1000 Parkwood Circle, Suite 900 Atlanta, Georgia 30339. (404)479-2470

Serving Silicon Valley, San Jose, San Francisco, Los Angeles, Santa Monica, Silicon Beach, Irvine, Anaheim, Orange County, San Diego, Atlanta. Licensed in California & Georgia.