Starting an indie studio? This is your crash course on video game law
Ben here! I heard about New Media Rights through a story on Joystiq, and reached out to Intellectual Property Attorney Shaun Spalding about writing a brief primer on some best practices for indie studios. As more and more developers self-publish, indies are asked to be experts on not just game development, but things like marketing and law, and those are tricky subjects for anyone to simply jump into. If you found any of Spaulding’s advice useful or interesting, consider making a donation to allow New Media Rights to provide free legal guidance to smaller developers. This stuff can save your company, or your game. Enjoy!
Indie game development is supposed to be fun, right? That’s why people work on projects for hundreds of hours knowing only ten people (who aren’t members of the team) are going to buy or play them.
Learning about the law and business isn’t fun. I know that because I went to law school. So… my job for the next two pages is to teach you in five easy steps what you need to know about this un-fun stuff so you can avoid legal threats and continue to do what you were really born to do: make games.
My non-profit, New Media Rights, helps game developers whose projects go off-the-rails because of legal issues. Penny Arcade Report thought it would be good to talk about a few of the major ones, so you can prevent issues before they happen. I’ve tried to avoid complicated law-talk when possible and concentrate on best practices.
And if you don’t like to read, I’ve also included links to some of the videos we’ve made called LAGD that explain these concepts in six minute chunks. Game developers are visual and auditory learners (that’s why you’re not novelists), so I know reading lots of complex text is probably the last thing you want to do.
As a disclaimer, keep in mind that this is a simplification of complicated rules, and these generalizations only apply in full to people in the United States.
Make sure everyone is on the same page
Most legal problems indie developers face are from who worked on their projects rather than from external sources giving them trouble. That’s why the most important “legal” tip for indie devs make is actually the least legally complicated thing to work out.
Everyone who works on your project needs to understand the scope and nature of the project up front. Someone may have told you, “It’s good to have a contract before you start working together,” but never told you how you actually do that. This should get you started.
Ideally, you could work out the details of the project in a written, formal contract. You could hire a lawyer to do it, or you could find a template and then customize it to fit your own needs. Understand that not all templates are created the same.
If all of that is too formal for your project, that a contract could be in an email thread. After all of the details are finalized in the thread, at the end, you should get everyone to confirm they understand and agree. Email threads can often be just as enforceable as formal, more-lawyerly-worded contracts in certain situations.
If even that doesn’t work for some reason, these details could be discussed in an informal meeting, then you could send a written summary to everyone at the end that they acknowledge and confirm. Any way you work it out, just ensure that everyone is always in the loop about “important details.”
So now that you know how these details can get worked out, here are the three most important of those important details that need to be worked out:
A. Who owns the creative output of each individual working on the project?
Does your company own it or does each individual own their own creative input? Generally, the best thing for the company (if you’re a project manager) would be for the company to own it. Generally, the best thing for an individual would be that they own it themselves. Your job is to figure out what the mid-ground is and then get everyone to agree to it.
B. Who gets paid, how much, and when?
You need to work out who, if anyone, will get paid, and what source of money will that payment come from. Questions include:
Will everyone get a percentage, and if so, how much? When will that payment start? After the game starts selling (revenue), or after the game breaks even after costs (profit)? Will everyone get the same percentage, or will you divvy it based on how many hours everyone puts in? What happens if another person enters the project unexpectedly, will everyone’s percentages change? Is anyone being paid out of pocket by some other team member? If so, will that team member who fronted the money be reimbursed first? Does the amount of money everyone gets change if the game randomly becomes a hit and makes $500,000? Is the percentage that you get counted before, or after the cost of distribution (for example, iTunes and Steam’s percentages)? Blah, blah, blah, etc.
These seem like complicated questions, but they’re actually not. You can really make these arrangements as complicated or non-complicated as you think the project needs. Assuming that you all work well together, these things will probably change on-the-fly several times during the development process as people drop out and join on anyway. As with all of these tips, use your best judgement.
C. Who controls business decisions and creative decisions?
Someone has to be the person chosen to make decisions. Think about it this way, when two partners with equal votes don’t agree about a direction for the project, there’s always a deadlock. When there are three people with equal votes, there is always one person who gets their feelings hurt when he/she loses. To avoid hurt feelings, figure out ahead of time who can make what decisions and stick to it.
Keep in mind, the “final decision maker” doesn’t always have to be the same person in control for all decisions. For example, one person can have the last word on creative choices. Another person can have the last word on money choices. Be flexible. Be realistic.
So once you get all those “important details” locked in, keep in mind that each person should know about them to the extent that those decisions affect that person. If someone new joins on, you should bring that person up to speed in the same thorough way to confirm their agreement to your terms. Just because it may take a little extra time, or just because this person will only be working with you for a week, doesn’t mean that you should cut corners.
Also, if anything substantial changes between your first agreement and what is happening, it’s a good idea to update everyone and get confirmation that the new path you’re on is the new proper path.
So now you know how to do it and what to work out, let’s talk about why this is important.
It’s a fact: people who like each other don’t sue (or threaten to sue) each other. Partners who are happy don’t cause problems. People who are surprised by sudden, unexpected shifts in how the project they’re working on is being run, or how they are being paid, or how they’re credited, will inevitably cause problems. Having a personal blow-up about a project you’ve been working on for weeks and months is the best way to lose a friend.
At worse, you’ve made an enemy for life who can limit your ability to distribute, make money off of, and do public relations for your game. At best, you’ve lost one person who will play your game and wasted your time.
New Media Rights made a 15 minute episode of LAGD that talks about confidentiality, one of the details you could discuss up front. Another episode talks about independent contractors versus employees which may help you to work out how you pay people. If we get to do a season two of our video series, we’ll hopefully have more episodes to all of what we’ve explained above.
Choose the name of your game with care
The easiest problem to fix also happens to be the most common problem that New Media Rights sees: conflicts with names. Some background: in the United States, if you name your commercial product or service something confusingly similar to another related product or service, then you could potentially have legal trouble. Your game could get taken down from the app store, or you could receive a cease-and-desist letter telling you you can no longer distribute your game at all.
This is especially true of you give your game a name just to capitalize off of the goodwill of an existing more popular product. For example, if you want to make a game similar to Tetris, don’t call it “Tetriz,” don’t call it “Tetri Blocks,” and especially don’t call it “Tetris Plus.”
Even though truthfully comparing your game with existing titles is completely allowed, using another game name in your advertising tags just to get traffic could also become a source of legal trouble. More importantly, it could encourage one of these game companies to want to get your game taken down.
Naming products and services is governed by trademark law. Since probably half of the developers who come to us have a trademark problem, we dedicated a whole 18 minute LAGD episode to trademarks.
Is your game company actually a “company” or just yourself and your own personal finances?
Indie game projects are often staffed by a motley crew of friends/Internet acquaintances/strangers. Your programmer and artist may be local, while your sound designer may live in China. Some people may be paid, and some may be volunteers. At the end of the day though, you all proudly call yourselves: Indie Game Company Name.
You put up a website: indiegamecompanyname.com . You print business cards. You get a bunch of hats and other swag with your name on it to give out at PAX. How exciting! Congratulations.
But even with all of this sweet swag, Indie Game Company Name probably still isn’t an independent entity in the eyes of the law. Every state has slightly different rules about this, but the general rule is that your game project is considered a “general partnership.” A partnership is a collection of people, not an independent entity in itself. This means a whole lot of things in terms of taxes, but it means two very important things that I’ll explain here:
Everyone who can control a commercial project and share in the profits is a “partner.” Each partner is personally responsible for the “torts” (intrusions to property) and contractual obligations or debts that other partners enters into.
This is an enormously complicated discussion, but let me hit some highlights of what this could mean for you in the real world:
If your sound designer punches your artist during a meeting, you (the programmer) could be responsible for the sound designer’s medical bills as if you punched him yourself. If your artist drops a computer on your sound designer’s toe and breaks it, you could be responsible for your artist’s carelessness out of your own pocket.
Imagine your artist starts a payment plan on a $5,000 computer and productivity software package in the name of the company without telling you. Even though you didn’t want or approve this, the company is still responsible for paying for it. If the artist can’t afford to make the payments out of her own pocket, then you could be responsible for that debt, out of your own money, as if you bought it yourself. Said another way, if she defaults on her payment, the her creditor could go after you to pay the remaining balance.
Of course, none of these nightmare scenarios about accident-prone sound designers or fiscally-irresponsible artists happen very often. But they happen enough for you to understand that there are alternatives to “general partnerships”, and these include LLCs or Corporations.
We just did a column about general partnerships for our Comics Bulletin column Barely Legal, and by the end of December, we’ll have a 14-page guide on our site all about general partnerships and how to avoid problems with them.
Transfer ownership of intellectual property in writing as soon as possible, so the people who think they own the game actually do own the game
A. Remember Tip #1: work out details about ownership up front:
Well, transferring ownership of intellectual property is one thing that must be done in writing. It can’t be in a verbal agreement. It has to be done in a specific, unequivocal manner as in: “I assign my rights to X” or “I license my right to X” to be effective. Again, you don’t have to rely on a formal contract, you can work that out in an email thread that is carefully written.
You may find that the typical formal agreement used to transfers rights, “an assignment agreement,” is pretty straight forward. With enough research, you may be able to find a template and put together the basic assignment or license language on your own for a small project.
For a large commercial project, it’s extremely unwise to cut corners. After all, the intellectual property is the most valuable thing surrounding the project. If the transfers are not correct, and then someone decides to give problems, then it could mean that you can’t release your game at all, or you may have to pay someone off.
B. Remember Tip #3: whether your company is actually a company:
Let’s go back to that for a second, too. You can’t transfer ownership to something that doesn’t exist. For example, if you transfer ownership to Independent Game Company Name Incorporated and that’s not actually a corporation, that could be a huge problem.
If everyone transferred their ownership to Sam Programmer who began the game as the project lead, and then Sam Programmer drops out of the project while everyone else continues on, that’s also a big problem.
C. The default rules if you’ve been making your game without any ownership discussion at all:
When you’re making a game with more than one person, you’re combining your individual creative work with the group. Depending on the way you work, generally everyone contributing creative work will be considered a “joint author” of the work, with each person having 100% control over the work.
That’s a big problem, because each person literally has 100% control and ownership over the final work. That means one person can unilaterally enter into distribution agreements even if you, as another owner, objects. All they would have to do is account for how much money is made and pay for a share. Joint authorship is, more often than not, a big problem.
Lots of developers come to New Media Rights end up having the same issue: “We didn’t work out who owned what in writing, two artists dropped out of the project, and we’ve lost our ability to contact them to get their written permission to distribute the game. Can we still go ahead and sell it?” Try to avoid being these people if you can help it.
Understanding that people don’t often play by the rules, the law isn’t magic, and that, on balance, the legal system almost always favors the side that has the most resources (typically not indie developers).
New Media Rights exists because legal rules are complicated. More importantly though, we exist because the technical legal rules have almost no bearing on whether or not someone will give you legal trouble. Competitors, large media companies, and people who generally don’t understand these rules and exceptions abuse legal processes all the time.
These rules aren’t enforced all the time either, so it may seem strange that there are sometimes dozens of counter-examples of games that use confusingly similar names, infringe on copyrights, etc. and never get in trouble. If you don’t follow the rules, but you’re not a high profile target, or you’re doing something that no one sees as a problem, then you will probably never run into legal trouble. Even if you follow the rules very strictly, if you are seen as an economic threat to another person or if someone doesn’t like what you’re doing, you’re at risk for legal trouble.
That’s why, even though we put together educational resources like LAGD, the direct work we do defending independent creators is just as important. Every year, we put on a fundraiser to ensure we can keep doing that for another year. Since we don’t have a PR or development department, we rely on people like you in the community to raise awareness about what we do and share this through Facebook, Twitter and all of your other social networks.