A buddy of mine used to work as tech support for a software company which did not, at the time, have an app (he’s now in the dev dept. for the same company). He approached me and asked my thoughts about developing an app for the company, and then selling it to them.

My initial reaction? Of course not!

Obviously, he required a bit more explanation than that, so I figured I’d discuss it just a little bit here as well. See, my buddy thought that because he wasn’t (yet) in the development department, developing an app wouldn’t be within his job description, so he’d be in the clear for doing something like that and then own the rights such that he could sell the app to his company.

So, why couldn’t he? In brief, his employment agreement.

Granted, he never got me a copy of the agreement, so either he never found it and he just moved on, or he found it and read what I assumed he would find in it: a clause stating that he, the employee, agreed that any intellectual property he developed in relation to his employment would be the property of his employer.

Now, some employers—particularly those in the IP development industries—have much broader language (meaning it encompasses a lot more situations) that could include literally any intellectual property you develop, whether or not related to your work, on your own time, or with your own tools. Those agreements mean that the stuff you create would belong to them, and they’ll thank you for your hard work on their way to the bank.

When I worked at Barnes & Noble, there was a similar, albeit far more limited, language stating that I agreed any intellectual property I developed at or for work would be the property of the company. Since I wasn’t into tech development, I couldn’t care less. But, it made even more sense for them to include it when I started because that was right before they launched the Nook eReader device. While it wasn’t specific to me, I know that they wouldn’t have wanted their employees, who would have access to the device and its software, creating competing products.

Myth 1: If what I want to create has nothing to do with my job description, my employment agreement doesn’t cover it and it’s my IP.

This is a toughie, because it’ll always depend on the language of your specific employment agreement. As game developers, you have a further difficulty in coming to a job with previously developed intellectual property, and that’s something you’ll need to address when reading over your development or licensing agreement. This applies both to whether you’re working as an independent contractor or as an employee. If you don’t know the difference, check out the video I did for New Media Rights on the topic here (2nd video).

As a developer, particularly in the app or games industry, you are frequently going to be entering into agreements with people to develop technology for them. In return for paying you to do that work, they will likely expect to be the owners of that end product or technology, because they need that ownership to function as a business—either for promoting it on their own or to sell it later on down the line.

Trouble arises when the language of the contract is vague with regard to PRIOR TECHNOLOGY or tools. Since you’re not about to reinvent the wheel every time you go work on a project, you’re bound to have your own tools and techniques to make work go faster so you can be sure to pay your internet bill on time. But, you want to be on the lookout for clauses in a contract that purport to grant ownership rights in literally ALL the technology included in the end product, as that could potentially mean that you’re giving away your rights to your own intellectual property (tools, software, etc.) to your client.

How to deal with it? You guessed it: ask a lawyer to look over you agreement and see if the phrasing creates any grey area in which they could argue ownership over your stuff in court. Phrasing like that can sometimes be negotiated out, unless the point of the agreement is that you’re developing the product like an engine or something for which they intend (and pay big bucks) for you to transfer your prior technology rights to them.

Myth 2: No one reads the contract anyway.

Now, I know you’re likely too savvy to be swayed by this myth, but it bears at least a few sentences of warning (or, after having written it, a few paragraphs).

It can take months to years to finalize a contract, true. And it’s also true that after everything’s inked and signed, no one reads the damn thing because…well, because it’s an 80 page contract full of legalese! BUT…you know who does read it? The person looking for a way out.

It could be a client who, nine months and several hundreds of thousands of dollars in, realizes that their idea is complete crap and they don’t want to foot the bill for the rest of the project. That’s right, it could be that it has nothing to do with you, the developer, who has met all the milestones and even surpassed expectations. But, when one party (a person in the contract) wants out of the deal, they’re going to have their lawyers scour the contract and find some loop hole or technicality (e.g. ‘all modifications must be in writing and signed by both parties’, and some weren’t) to get them out of the deal.

Then again, it could be that the client is difficult to work with, communicate with, or maybe they want to add on things which weren’t in the original deal, and are incredibly difficult/expensive to add. Oh, and, of course, they don’t want to pay extra for it. At that point, you may want to just cut your losses and move on to a better-looking gig that’s guaranteed to pay you. But, you’ll run into problems if you’re in breach (violating the terms of the agreement), so you’re going to want to know that your interests (and exit plan) are accounted for in the agreement, among many other things.

Finally, a jury or judge would be potentially a reader of the contract (or, more likely, an arbitrator). You generally want to avoid that when you can, since it’s highly doubtful that they will have any experience in your industry, let alone understand the trends or customs in which you conduct business, so they’ll only have the contract for reference. This is another reason to make sure it says what you want it to say.

Take-Aways:

 

1. Read your employment (or development) agreement to see what it says about IP ownership.

If you work for a tech or software company, it’s highly likely that there will be broad language in there transferring rights to your employer for things you develop. It may be that you just have to wait until you’re no longer employed by them to make that project (depending on whether there are other provisions in there, such as a non-compete clause), because you don’t want to chance them owning your work.

On the other hand, you could also request to add into the agreement something like a list of your previous technology or intellectual property, so that it’s clear where the boundaries are of their ownership, at least so far as stuff you’ve already developed.

There are many ways to approach it, but the best way is with an attorney who will look out for your interests.

2. Read your employment agreement to see about an exit strategy.

Discuss with your lawyer about possible exit plans so that you have a tolerable way out in case things go south. In addition, you’ll want to ensure that the contract has a way for you to not be totally screwed if the other side backs out. Just food for thought.