Code Smell in Development Agreements

by Rick Colosimo on January 14, 2016

Code Smell in Development Agreements

I recently answered a Quora question about the Gigster contract for freelance developers. In that answer (reproduced below), I run through some basic considerations that almost always deserve attention – regardless of whether I’m representing the developer or the client.

If you read through the comments, you’ll see a number of problems (undeclared variables (Statement of Work; Company), two variables for the same reference (Company; Gigster), non-DRY language (Section 2.3’s duplication), and unrefactored language (drafting throughout; disconnect between Gigster and Customer acceptance of Deliverables). As I’ve described them above, they will probably sound a lot more familiar to you than they would if I used legalese to describe them – but of course, people who speak in legalese seldom identify these things as problems.

On the other hand, I prefer to write clear contracts that cover the necessary ground – what happens under scenario A, scenario B, and then under all the rest. That way, whether you’re a developer or a company having software developed for you, you can understand what is expected of both sides, with clarity about rights and obligations.

Good fences make good neighbors.

Robert Frost’s “Mending Wall

Having been a litigator early in my legal career, I’ve learned that the most important thing about contract drafting is that if the answer is “well, then you get to sue them for that,” you have no answer. The out-of-pocket costs of a lawsuit are literally easily $25k–50k, and the distraction and lost opportunity are probably just as much. You are dramatically better off avoiding lawsuits.

Some lawyers believe that the path to advantage is in writing terribly one-sided terms (like the assignment below of other “inventions” that don’t constitute deliverables) and then fighting tooth and nail over every clause: this is the stereotypical NY big law firm approach, and I know how to do it like just about every other Ivy League lawyer.

However, I learned in Silicon Valley that a much better approach is to do the “right” deal for the client as quickly and smoothly as possible. As a practical matter, the real risk in a transaction is from operational risk, not a hypothetical risk from two different versions of something that’s not supposed to happen (like arguing over provisions following the default of the United States on government bonds).

I seek advantage in defining the risks you’re willing to accept and clarifying what you’re demanding in return for taking on those risks for the other party. Writing clearer language that is harder to misconstrue reduces the costs of disputes and reduces the chance that you’re going to court. With that leverage, it should help you negotiate your way out of a problem, which is almost always a dramatically better solution than going to court.

If I were representing, as I do in other contexts, a software developer or firm that was taking on an engagement through Gigster, I would have a few significant comments.
In general, the Gigster agreement is typical in form, meaning that it has unclear language, defined terms that aren’t defined, and some clunky spots. Keep in mind that Gigster may or may not be interested in updating the base agreement or creating a side letter amendment for a specific project.
Here are some specific comments and observations I would raise with a client:

  1. Section 2.1 – the assignment of deliverables is fine, but the assignment of all other inventions that “arise in connection with the Contractorervices … including … source code developed or created by Contractor that is not specific to Customer and is generally applicable to other Customer projects and deliverables ….” seems overbroad. As I read this, if DHH were working on a webapp for Gigster, they would claim ownership over Rails. That seems aggressive.
  2. Section 2.2 exempts pre-existing IP of the contractor from the assignment, but the language in this section purports to limit it to pre-existing IP that is disclosed in writing to Gigster before the delivery of the Deliverable. It might contemplate that before such items are included or as they arise, they are disclosed to Gigster on a rolling basis. In any case, this requirement would require some integration into a developer’s workflow.
  3. Section 2.2 also grants a license to use any Contractor Technology in or needed to the deliverables or other inventions, meaning that a developer would not want to use any “real IP” in the course of this agreement; in many cases, a developer would want to prepare a standalone license agreement to monetize that IP or more strictly limit its automatic licensing.
  4. Section 2.3 has a lot of duplicative language about assignment that doesn’t seem to apply to a waiver of moral rights.
  5. Section 2.4 requests written permission but doesn’t clarify from whom. It’s probably meant to be the third-party licensor because Gigster is mentioned in the first sentence, but it’s not clear. Is it the customer? Maybe it is Gigster.
  6. Section 3.1 says the developer (unless it’s milestone-driven) gets paid after “acceptance of the Deliverable by Gigster.” But Section 3.2 sets up a clawback if the Customer rejects the deliverable. In any case, there’s no description of any acceptance process. This is non-standard and a common source of problems for developers and clients alike. Maybe it’s on the project page, but that’s not mentioned here. There should be a formal acceptance procedure and timeline after which objections are waived and a deliverable is deemed accepted.
  7. Section 4.1 is silent on whether Gigster has any payment obligations if it terminates the contract without cause. Typically, some percentage of completion measure is used. This term would cause many developers to either only use this for small projects or to elect milestone payments to reduce their risk. There’s no mention of upfront payments or deposits, so those common methods of reducing risk seem to be unavailable.
  8. Section 7.2 uses the term “Statement(s) of Work,” but it’s not defined and does not appear in the terms of service. Maybe it appears on the Project Page.
  9. Section 7.2 requires that no open-source code be used. It’s broadly defined, and so even sample code found on stack overflow might be implicated. (An argument that many would make is that there are no damages from a breach of that provision if the code in question is unremarkable and perhaps indistinguishable from independently written code. But who wants to fight over this?) The same is true for any code with a GPL-like license that requires licensing of certain derivative works. On its face, this provision would seem to rule out a rails project, and the no third-party code would seem to rule out apps incorporating SDK code without specific permission from Gigster. Hopefully they incorporate those permissions in the project page and specifications.
  10. Section 8 requires indemnification of Gigster by the developer for infringement. However, it extends to all “Inventions,” which includes things not included in the Deliverables (for which indemnification is typical). If a developer invents something, that Gigster takes, that turns out to have been patented by someone else the day before, the developer is now on the hook even though the developer didn’t get paid for that invention or make any intentional distribution of it to the customer or Gigster. I think it’s overly broad and outside the typical scope of an agreement like this.
  11. Section 10 – the non-solicitation is overly broad because it includes contractors and there’s almost no way to find out whether someone falls into that category. It doesn’t include a common safety valve for general, non-directed advertising. Also, the developer can’t work for any Customer without Gigster’s consent. This section uses “Company” as a defined term that is not defined. It’s almost certainly meant to be Gigster but still….
  12. Section 10 also says that a contractor can perform other work unless there’s a “conflict of interest.” That’s not defined and overly vague. Presumably every freelance developer has an inherent conflict of interest with Gigster because they compete with each other.
  13. Section 11 contains a typical arbitration and no-class-action clause. It’s worth noticing but not unusual.

Of course, each of my clients has particular concerns that are unique to them, so this list alone wouldn’t be sufficient to give them advice about any particular engagement. If you’re reading this, these questions may or may not be significant for you, and they almost certainly don’t capture all your issues. Real legal advice deals with your specific facts. Don’t get caught by not getting the real answer.


NY LLC Publish or Perish

by Rick Colosimo on December 24, 2015

Still No News on New York LLC Publishing Requirement

New York state has imposed an unusual requirement on newly formed LLCs. Each LLC is required to publish a legal notice of its formation in newspapers designated by the county clerk for six weeks. Because not all newspapers are designated, there is a noticeable lack of competition in pricing; LLCs publishing in the NYC area regularly budget $1500–2000 for this task.

The publishing rule also includes, under a parallel statute, foreign LLCs qualifying to do business in New York. So forming in Delaware doesn’t solve your problem!

As recently as 2006, the state legislature amended the statute – but they made it more onerous, not less, by increasing the effective penalty for failing to publish. Now, the penalty is that the LLC’s authority to transact business in the state is suspended on the 120th day after formation; BUT contracts are not voided, the ability to defend a lawsuit remains, and, most importantly, limited liability is not lost. And, publication and filing after the 120th day annuls the suspension of authority to do business, meaning it is as if the LLC were never suspended. As a practical matter, it means that any potential problem that arose during the interim is intended to be nullified.

Here’s the specific language:

If within one hundred twenty days after its formation, proof of such publication, … has not been filed …, the authority of such limited liability company to carry on, conduct or transact any business in this state shall be suspended ….

The failure … to … publish[] and … file[] … or the suspension of … authority to carry on, conduct or transact business in this state … shall not limit or impair the validity of any contract or act of such limited liability company, or any right or remedy of any other party under or by virtue of any contract, act or omission of such limited liability company, or the right of any other party to maintain any action or special proceeding on any such contract, act or omission, or right of such limited liability company to defend any action or special proceeding in this state, or result in any member, manager or agent of such limited liability company becoming liable for the contractual obligations or other liabilities of the limited liability company.

NY LLC Law § 206(a)

In 2013, two bills were introduced in the legislature both the senate bill and the assembly bill are “in committee.”

With no relief on the horizon, what should LLCs do? Well, the easy answer, of course, is do the publication. There are services that purport to form your entity with a registered agent address in a cheaper county upstate, or in the Southern Tier, which may work out. You may be required to buy their registered agent service for a period as well, before changing it out to serve as your own registered agent in NY. (And if you’re an out-of-stater, (1) you need a registered agent regardless, which might be your lawyer and (2) why are you forming in New York?)

The more complicated analysis that a company would go through would take into consideration the cost of publishing, determine what alternative use there is for that capital, analyze whether any contracts will be in default or breached if the company is not authorized to do business in New York (hint: most lawyers woudl expect that any bank debt will be in default, so read carefully).

After all that, the founders might sit down and figure out if they create shareholder value by trying to optimize the timing of the publication expense or by doing something that actually creates value. My guess is that many of my clients, and certainly all my more successful ones over the years, realize that they could create a few thousand dollars of value in the time they would spend researching how to finagle the publishing requirement now and incur the legal debt of having a known problem out there just waiting for you, like a bear trap hidden under the snow in your backyard.


Legal debt mirrors technical debt

October 22, 2015

Legal Debt is an Analogue of Technical Debt Shortcuts in coding – not using DRY, not refactoring, not testing – are common sources of technical debt, which require additional effort, in the form of attention, thus time and money, to address. Shortcuts in the formation and operation of your startup create legal debt, which is […]

Read the full article →

Banish “agrees that” from your contracts

July 17, 2015

Ken Adams has written a recent post describing the use of “agrees that” in a contract. One steady comment I make to agreements is getting rid of “agrees that” because it’s worse than ambiguous: it’s entirely unclear and likely to be used in distinctly different (and inconsistent) ways in the same contract. “Agrees that” becomes […]

Read the full article →

Piles of Contracts

July 11, 2015

Man, Ken Adam’s isn’t kidding when he talks about not being impressed by collections of contracts, mostly scraped from EDGAR. I saw a reference to TechAgreements, which I hadn’t heard of before, and now I know why: Here’s a selling point on their page with “Recommended Convertible Notes” (which are all clearly just scraped): “Prepared […]

Read the full article →