The iOS industry is maturing. Like many industries that mature past their embryonic stage, designers and developers are becoming aware of common growing pains analogous to most any industry. With an influx of capital, widely publicized legal battles and increasing competitiveness, Indie’s are beginning to recognize the importance of cultivating their business as much as their work product. I’ve been lucky enough to ride along shotgun, advising many clients, large and small, on how to tackle some of the business and legal issues that often arise. My goal in this article is to touch on many of the common issues that affect the iOS industry and offer up paths to their solutions. Keep in mind, these paths should not be construed to be individual legal advice. Though it is a disclaimer, it could not be truer; nothing is a substitute for informed competent individualized legal advice from a licensed attorney. An attorney should be a vital part of your business plan just like an accountant should. An attorney client relationship is built on trust. The earlier in your business you retain an attorney, the more fruitful and less expensive the relationship will be long term. I use the words informed and competent in the sentence above because like a developer that knows java but not Cocoa would not be helpful to build an iOS app; an attorney who does not understand your language/business would not be very helpful advising you. If an attorney does not know what it is you do on a day to day basis nor do they understand your business then they will be blind to issues that may greatly affect you. The number one qualification for an attorney you hire should be his knowledge of the issues that affect the industry. Followed up closely by their awareness of your business and how they fit into it.
So let’s get to the meat. Probably the most common question I get asked by developers is about patent trolls and ways to protect against them. I start off with this topic because I believe the best way to protect against patent trolls is a basic step that every new developer, company, startup, or consulting studio should do. That step is incorporation. Whether you are doing this part time as a hobby at night, trying to build a startup, or consulting at night, you’re in business. Running a business comes with necessary risks and liabilities. However, exposing your personal assets and family is an unnecessary risk and one that can easily be avoided through limited liability entities.
So what entity should I chose? Here’s a brief high altitude view of the differences:
C Corporation – Double Taxation on all income whether given as a salary to employees or distributed as dividends to shareholders. Have to adhere to corporate formalities (keeping minutes of board meetings when passing any resolution that effects the company, annual meeting of shareholders, etc.) Most common entity choice for Venture Capitalists due to flexibility in classes of stock/granting of options.
S Corporation – Have to adhere to same corporate formalities as C Corporation. Pass through taxable entity that is limited to 100 shareholders and all must be US Citizens or permanent residents.
Limited Liability Company (LLC) – Flexible pass through entity, income and loss can be allocated disproportionately however must claim income whether left in the company or distributed out.
If you would like a more in depth discussion on the topic go here - http://www.mcstartup.com/blog/2008/3/7/choosing-a-business-structure-llc-vs-c-corp-vs-s-corp.html
Next to incorporating, the best possible way to protect yourself is to have a well drafted, well negotiated contract. I get ask all the time at conferences whether a contract off the internet is sufficient. The problem with a contract or boilerplate language off the internet is that you don’t understand exactly what it could be saying. My contracts professor in law school use to on a daily basis retort to insufficient answers from students that “words mean something!” A contract should be a memorialization of the agreement that you and the other party come to.
A common clause at the end of a contract is called a Merger clause and reads:
“This Agreement, together with all Statements of Work constitutes the complete and exclusive understanding and agreement of the parties with respect to the subject matter hereof and supersedes all prior understandings and agreements whether written or oral….”
A Merger clause is intended to cement the parol evidence rule, a common law rule, which prevents a party from introducing extrinsic evidence to create and clarify an ambiguity or add to the written terms of the contract. Stated simply, the clause means that only the terms written in the contract are your agreement, so you better understand what those words mean. Many developers write detailed proposals at the beginning of a relationship with a client before they understand fully what the client wants. These written proposals often include cost estimations, an explanation of deliverables and some type of time table on delivering the code. Often times, a written proposal is a first blush look at the project and an invitation to open negotiations on a deal; not the product of a finalized deal. However, if you do not have a written executed contract, then the terms of the written proposal and some interpretation of it can end up being seen by a court as your agreement. My advice, hire an attorney to review or draft any agreement.
The second reason a contract from online is a bad idea is that it generally involves zero negotiating. One party gets it off the net and then puts it in front of the other party. That party either does not care to change the agreement or wants to change it. However, the party giving the internet contract is worried to change anything in the agreement because they never understood what it said in the first place. Negotiation is oxygen to a healthy business relationship. The process of negotiation fleshes out assumptions from both parties about the work and generally leaves both parties feeling at the very least their concerns where heard. Negotiation can be the difference between a constructive resolution and repair of a business relationship to one that is completely soured. It is the initial communication between two parties and can even prevent bad relationships from beginning.
So how do I read a contract? What do I look for and what are some common sections of contracts that jump out to me?
I always approach any contract and subsequent negotiation with a risk/reward analysis. Almost all contracts you enter into should be negotiated to some extent. It is very rare that I am reviewing a contract written by one party that has fully contemplated both sides risks and rewards and drafted it accordingly. For every clause in a contract, one party is ultimately taking on some risk or gaining some reward at the other party’s expense. In reviewing a contract for my clients, I want to prioritize what risks are acceptable, somewhat acceptable based on the reward and under any condition unacceptable. From there, let the negotiations begin.
The major sections that first catch my eye in most developer contracts are in order: (1) the dickered terms (things such as price, milestones/deliverables, term, payment time, scope and change in scope); (2) Inventions or Intellectual Property Ownership clauses; (3) Termination; (4) Warranty, Indemnification, Limitation of Damages, Non-Compete/Non-Solitication; (5) Confidentiality; (6) Miscellaneous Sections including Forum/Venue selection.
The dickered terms are of vital importance because without them you may not even have a legally enforceable contract, which is the whole point of having a written contract. The Inventions/Ownership clause is important because it lays out in detail exactly what it is you’re giving away. One of the unique issues in the industry is that many developers work on many different projects and hold many different titles all at the same time. A indie developer may be an employee at a startup or company, have their sandbox they play in at night, developing a coffee or sportsball app, and then have a game they are working on with a couple of their friends from their local cocoaheads meetup. The developer is creating Intellectual Property in all three of these roles, employee, indie developer, partner. The Intellectual Property created in all three roles is related to the mobile or iOS industry, even though they may be topically completely different. The problem with this scenario is that depending on the Invention/Ownership clause in the indie developer’s employment contract he or she may have already given ownership of all the IP they are creating in the 3 roles to the startup/company. This can be a very bad situation, especially if the coffee/sportsball app or game with his friends takes off. The following is only one of many real world examples I have come across that run into this exact problem. I could write another entire article just on differences and the legal meaning of work for hire, assignment and licensing language in Invention/Ownership clauses of contracts. Needless to say, this is a very important section of any contract a software developer/designer signs.
There are many scenarios I could give you where the remaining sections listed above can be as important as the first two discussed. As you can begin to tell, these situations become fact sensitive quickly. For example, if a contract includes a warranty clause that states your code will be bug free and tacks on a termination clause that says you are required to fix the bugs to the client’s satisfaction then you could be spending iOS update after iOS update upgrading their app under the original agreement without pay. This is where having an attorney that understands the industry and what you do on a day to day basis comes in hand.
The last issue I will touch on is the most obvious reason developers seek out an attorney. When should you sue someone? What happens if you get a letter threatening to sue you?
It should go without saying that you should seek legal advice as soon, if not before, you receive a letter threatening legal action. Most definitely, you should seek legal advice before you speak to the client/litigant again. However, I often am surprised by how many developers I speak to that are owed say $10,000.00 from a client who stiffed them after a project was pulled do not pursue legal action to retain the money owed to them. Most of the time, the developer or company says something along the lines of “well it will cost more money to pursue in legal fees then I would ever recover.” This is a common trap/scare tactic used and the majority of the time is completely false. Depending on the situation, many attorneys will take on suing and collecting money owed based on a written contract and charge the client some percentage of the amount recovered as the fee plus court costs. It’s a no brainer and makes no logical sense to not pursue money owed in these situations.
As you can tell, there are many issues and potential pitfalls out there facing the indie developer, startup, or consulting company. I have only scratched the surface on these issues in this article but hope at the very least I have made you more aware and conscious of these issues moving forward. With the maturing of the iOS industry, it is imperative that the indie developer add the hat of business man or woman to their arsenal. With patent trolls abound, competitiveness on the rise and the influx of capital in the industry the stakes have become too high now. No matter whether you are running a startup, a consulting company or you are an indie developer having a relationship with an informed competent attorney is a vital step in the process of moving from Indie to Businessman.