Mailing List

Popular Articles

Recent Articles

Follow Us

Invitation to Join VCTaskforce at StartUpWorld 2017

Written by on Tuesday, May 2nd, 2017 Print This Post Print This Post

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 Print This Post Print This Post

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 Print This Post Print This Post

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

Could a Software Developer Whose Code is Used for Hacking Be Convicted of a Crime?

Written by on Saturday, April 29th, 2017 Print This Post Print This Post

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.

Category: Software Crimes  |  Comments Off on Could a Software Developer Whose Code is Used for Hacking Be Convicted of a Crime?

Service Level Agreements: What is a Service-Level Agreement or “SLA” and When Do You Need One?

Written by on Thursday, March 16th, 2017 Print This Post Print This Post

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.

Category: Software Agreement Drafting  |  Comments Off on Service Level Agreements: What is a Service-Level Agreement or “SLA” and When Do You Need One?

Recent Software Class Actions Provide Valuable Lesson on Why SaaS Contracts Should Be Drafted to Fit Company’s Business Model

Written by on Friday, March 10th, 2017 Print This Post Print This Post

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.


Category: Litigation, Software Agreement Drafting, Software Litigation  |  Comments Off on Recent Software Class Actions Provide Valuable Lesson on Why SaaS Contracts Should Be Drafted to Fit Company’s Business Model

Recent FTC Enforcement Actions Should Serve as Warning to Software Industry about Privacy Practices

Written by on Wednesday, March 8th, 2017 Print This Post Print This Post

If your software company is like most, you have probably spent little or no time contemplating what needs to be in your company’s privacy policy.  In fact,  what your company is currently calling its privacy policy was likely copied from a third party website years ago and never given much thought since.  Meanwhile, your company is likely collecting and aggregating user data and looking for new opportunities to monetize it.  Sound familiar?

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.

On February 6, 2017, the FTC announced that VIZIO, Inc. had agreed to pay $2.2 million to settle charges by the FTC and Office of the New Jersey Attorney General that it installed software on its TVs to collect data regarding consumer viewing without their knowledge or consent.  In its complaint against VIZIO, the FTC alleged that VIZIO had manufactured televisions that continuously tracked consumer viewing on the television and transmitted this information back to VIZIO, and also had remotely installed the same proprietary software on previously sold televisions.  In addition to collecting information about consumer viewing, the FTC alleged in its complaint that the software had collected information about the television, IP address, wired and wireless MAC addresses, WiFi signal strength, and nearby WiFi access points.  The FTC further alleged in its complaint that VIZIO had then entered into third party contracts to sell the data collected to third parties for the purpose of measuring the audience, analyzing advertising effectiveness, and targeting advertising to particular consumers.  While VIZIO’s contracts had provided only aggregate data to the third parties, those contracts did provide segmented demographic information by sex, age, income marital status, household size, education, home information, and household value.  According to the FTC Complaint, VIZIO did make a privacy policy available on its website, but the only onscreen notifications provided to consumers were vague and timed out after 30 seconds, never sufficiently informing consumers as to VIZIO’s data collection practices with the software installed on their televisions.   The FTC alleged that VIZIO’s actions in deceptively omitting material facts constituted deceptive acts or unfair practices prohibited by Section 5(a) of the FTC Act.

In the stipulated order, VIZIO was ordered to take all the following actions before collecting any further data from consumers:

  • Prominently disclose to consumers “separate and apart” from the privacy policy specifics on the data to be collected, what would be shared with third parties, the categories of third parties who would receive the data, and the purpose for which the third parties would receive the data.
  • 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.

What conclusions should you as a software company take away from the FTC’s recent enforcement activities against software companies?  Clearly, the FTC is cognizant of the trends in the software industry to monetize data collected from software, to adopt privacy policies without actually customizing them to the practices of their particular company, and to bury privacy notices on websites without actually obtaining clear end user consent to actual business data collection practices.  So, if your company is like most in this space, you are on notice that your practices need to change.  Your privacy policy needs to be customized to the business practices of your particular company, which means that you actually need to take the time to consider each and every piece of information that you are collecting from the public and disclose what you are doing with it.  If your customers expect you to be a part of an international privacy program before they do business with you, you need to actually take the steps requirement to receive the appropriate certification from that organization before you advise consumers and the public that you are a member.  And if your software collects information, you need to make sure that not only your customers but also the parties from whom the information is collected have given their clear consent to your collection practices.  A privacy policy buried in your website is probably not sufficient to cover you legally.

If you do not change your privacy practices, you are on notice that you may soon be hearing from the FTC.

Category: FTC Regulation  |  Comments Off on Recent FTC Enforcement Actions Should Serve as Warning to Software Industry about Privacy Practices

SaaS Contracts: Is Your SaaS Contract Extending Your Sales Cycle?

Written by on Friday, March 3rd, 2017 Print This Post Print This Post

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 asJEL28958-Prinz, Kristie

  • 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:

Category: Upcoming Speaking Engagements  |  Comments Off on SaaS Contracts: Is Your SaaS Contract Extending Your Sales Cycle?

Complimentary Passes Available for “Negotiating Service Level Agreement Key Terms”

Written by on Tuesday, December 20th, 2016 Print This Post Print This Post

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 and I’ll see if I can still reserve you a complimentary pass.

Category: Upcoming Speaking Engagements  |  Comments Off on Complimentary Passes Available for “Negotiating Service Level Agreement Key Terms”

US Navy Responds to Copyright Infringement Suit Filed by Bitmanagement Software

Written by on Tuesday, November 22nd, 2016 Print This Post Print This Post

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.



Category: Software Litigation  |  Comments Off on US Navy Responds to Copyright Infringement Suit Filed by Bitmanagement Software

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.