Legal Aspects – What Developers Need to Know

Talking to developers from time to time, I pick up on comments that I think could use some explanation from a pro. I’ve heard from different developers how they either were shafted by the contracting company by not reading the binding contract. Sometimes they read the contract before signing and either refused to do the project or worked with the company to make changes in their “standard” contract. Many times these contracts were written five years ago and have nothing to do with the current project but it’s standard so they pull it out, change the names and viola, a “new” contract. This can get freelance/contract developers in trouble or there are loopholes they find that they can use to put it to the contracting company.

With this in mind, I talked to a good friend of mine who has worked with these types of issues from both sides of the table.

L. Joe Hedges is the founder and director of Springboard IP Counsel, Inc. P.C., an Oklahoma firm dedicated to providing experienced legal and business counsel to intellectual property developers, distributors and owners. Joe has more than 18 years experience in the technology, entertainment and publishing industries, having served in senior legal positions with both Activision Publishing and Gemstar/TV Guide International prior to establishing Springboard.

We asked Joe to provide some insight into a few of the issues that developers encounter in working on a contract basis.

Wheeler: Before signing on the dotted line, what should developers look for in the contract?

Hedges: The obvious would be to make sure the financial terms, how much and when they’ll be paid, are consistent with what was offered. These terms should be reflective of the nature of the work and scope of rights granted in the work product (work for hire, license or some combination of the two).

It is every bit as important, and sometimes more so, to make sure that the performance terms, such as the statement of work, change order procedures, schedule of deliverables/milestones and approval process and standards, as well as other provisions like confidentiality/non-compete, reps and warranties and the ownership of work product, are clearly understood and acceptable to both sides.

Since all projects are different, the relative significance of particular contract terms (both to the developer and the contracting company) will vary based on the specifics of the project.

Wheeler: Why is there always a contract term about ownership of the code?

Hedges: Absent an express agreement specifying otherwise, the author of an original work (including code) is the owner of its copyright interest. That’s why in every development contract there is a provision addressing ownership, often transferring ownership on a work-for-hire basis without consideration of what’s necessary or fair. Developers often end up transferring much more than they need to.

In the context of a development project, you may need to distinguish between source and object code, code written for the project, any pre-existing and licensed code that may be included in the deliverables, as well as tools and utilities, to make sure that the ownership interests, transfers and licenses work for both sides. It’s of vital importance to clearly define and delineate the ownership of IP on a project-specific basis, so that there are no misunderstandings down the road.

Wheeler: What are some of the tricks of the trade that larger firms use against contract/for-hire developers?

Hedges: I don’t think companies try to deceive or cheat developers. All companies, large or small, use form agreements with terms that favor their own interests. In many instances they don’t fully understand the terms of these agreements themselves, and have simply continued using the same form they have always used (and probably can’t remember where it came from).

I have been involved in a number of transactions where a company has declined to change its standard form, even though its terms were actually detrimental to its business interests (although I didn’t point that out at the time!).

Wheeler: Can a developer use the same code in other projects that he/she developed in a different app?

Hedges: That depends on the terms of the agreement, if any, under which the code was written. If the terms aren’t clear, I would strongly suggest consulting an attorney since the ramifications of improper use can be quite severe.

Wheeler: OK, if a developer didn’t read the fine print and signed a contract that says the company owns the code, what can they do if they want to use some of that code for another project?

Hedges: First of all, don’t. That can only compound the problem, not only for the developer but also for the new company they’re working with.  If there is no reasonable work-around, you can always initiate a discussion to see if there is any objection to using the code in question. Many companies, if they are satisfied with your work and the proposed use doesn’t present any competitive issues, will be reasonable in dealing with this type of situation.

Wheeler: What about NDAs and/or non-competes?

Hedges: Developers need to be very careful not to restrict or hamper their ability to take on future projects by agreeing to confidentiality or non-compete obligations that are overly broad or don’t make sense. While companies need and should ask for certain protections when allowing third parties access to their proprietary information and product development, they often do so using contract language that is unreasonable.

By making sure that the term “confidential information” is clearly defined (and that there are carve-outs for information already known or independently developed), and that any field of competition to be restricted is reasonably confined, a developer can expect to be relatively free to take on new project without running afoul of their previous agreements.

Wheeler: When should a developer think about having an attorney look over the contract before signing it?

Hedges: That’s easy – every single time. The biggest mistake that a developer can make is to enter into a contract without the advice of their attorney (and their accountant, as well). Even if the contract is the same as one that has been reviewed by counsel and signed before, each project is different. Issues such as ownership, reps and warranties, tax consequences, non-compete, etc., will change with time and context.

There are a couple of distinct advantages to retaining a lawyer. By leveraging his/her knowledge base of issues and pitfalls from other transactions they’ve handled (and how to avoid and/or resolve them), you at least have some assurance that the right questions will be asked. I can’t tell you how many times I have seen changes to a “standard” form simply because the issue was raised.

You can also achieve a degree of separation from the “deal-making” aspect of the transaction. There can be times when the discussion of ownership, allocation of liabilities, risks and other sensitive issues can become less than friendly. It is helpful to have any residual unpleasantness assigned to your attorney and not you, since you’re the one that’s going to have to work with these people after the contract is done.

Joe can be contacted via email at ljoehedges@gmail.