Software Development Agreement
Who really owns the intellectual property?
By Michael E. Young
Whether you’re a developer or a client, one of the most important things to cover in your software development agreement is who owns what intellectual property, or IP, rights. Surprisingly, most developers and their clients either don’t know or have conflicting views on the subject.
Imagine you’re a client who’s just obtained an advantage in the marketplace with new software. Then you discover your developer now works for one of your biggest competitors on a similar software project. Or, let’s say you’re a software developer. At the end of a project, the client is happy with your work but makes an off-the-cuff remark about owning the new software lock, stock, and barrel.
You wonder if the client understands that’s not how it works.
There are two competing interests at play. The client wants ownership while preventing the developer from reselling the software to others. On the other hand, the developer wants to keep ownership because some code can be recycled and used on projects for other clients instead of having to reinvent the wheel from scratch.
So, how do you balance these com-peting interests in a software development agreement? One method is to use a combination of licensing with non-competition provisions. The developer retains IP ownership, licenses the software to the client, and agrees to restrict the purposes for which the code can be recycled. Often, this means the developer is agreeing that, for a period of time, the developer will not use the software to compete with the client or recycle the code and sell it to one of the client’s competitors.
What if the developer doesn’t own some of the code used in the software? The general rule of thumb is you can’t convey what you don’t have. When it comes to software development, there’s often some code the developer does not own. For example, a developer’s license has been purchased from a third party, the developer is using open source licensed code (e.g. GNU General Public and Creative Commons licenses), or some of the code has been taken freely from the public domain.
In other words, there may be multiple tiers of intellectual property rights associated with a single piece of software. And if those are not clearly identified in the software development agreement, it’s a recipe for confusion, hard feelings, and litigation.
What if the developer is the company’s employee? Even if employees are doing software development for an employer, it’s risky to assume the software is the employer’s intellectual property as a work made for hire for two primary reasons. First, certain criteria must be satisfied before the software is considered a work made for hire. Second, the employee(s) developing the software may have licensed some of the code, used open source code, or taken code from the public domain.
Employers can reduce these risks by taking preventative steps before development begins. These actions can include written employment agreements that cover works made for hire, implementing employment guidelines to ensure the work-for-hire criteria are satisfied, and establishing a clearly defined project scope of work to identify the coding resources for the project and related intellectual property rights.
IP ownership is negotiable. Whether you’re an independent contractor, client, or an employee involved with a software development project, it’s important to understand the intellectual property rights are frequently negotiable, i.e., there’s no one-size-fits-all standard to apply across all projects. Before negotiating, work with your software lawyer to identify what you must have, what would be nice to have, and what you can live without. This makes it easier to cut a deal where each party gets what they want from the project. TBJ
Originally published on mikeyounglaw.com, this article
has been edited and is reprinted with permission.
MICHAEL E. YOUNG is an internet business lawyer based in the Dallas suburb of Plano. To learn more, go to mikeyounglaw.com.