Quantcast
AlleyWatch Daily Pulse Email   

3 Reasons Why You Don’t Own the Code that You Create

 

ip

Code is protected by copyright, which protects the creator, in this case the developer, of original works of authorship. The nice thing about copyright is that protection arises automatically. Although the creator has to register the copyright in order to pursue a case of infringement, he or she does not have to register the original work of authorship in order to start having protection.

The copyright rules run contrary to the interests of technology startups, however, where ownership of the code by the company, and not the creator, is of paramount importance in order to get funding and ultimately sell the company. Think also of situations where it doesn’t work out among the founders. If a founder leaves the company and owns some or part of the code, the company would then be infringing on the intellectual property rights of a former, and quite possibly disgruntled, founder. What a disaster!

For the company, and not the creator, to own the code, one of three factors must be present:

1. The developer writes the code under a “work made for hire” contract. You should know if someone is under a “work made for hire contract” because the contract will say as much. Work made for hire, from the moment of creation, belongs to the company that engaged the developer. Employment and independent contractor consulting contracts generally will have “work made for hire” language in them. If you have this kind of contract, you need to look at the details as to what is covered by the “work made for hire” language.

2. The developer assigns the IP rights to another party, such as the company he or she is working for (either as an employee or independent contractor). Employment and independent contractor consulting contracts should have language assigning the “inventions” and “copyrightable materials.” Same thing here, if the developer has this kind of contract, you need to look at the details as to what is covered by the assignment language. While this kind of agreement works to assign the copyright to the company that has engaged the developer, the “work made for hire” language provides longer and stronger protection for the company than just the assignment language. “Work made for hire” or “work for hire” is specific language that you want to include in your company agreements.

3. The developer is employed and the code he or she writes is related to the scope of his or her employment. State employment laws generally provide that assignment of code and other inventions to the employer is automatic, when the invention is made within the scope of employment.

But here is where it gets murky. First, there has been a lot of case law about whether someone is an employee or independent contractor. That has to do with how much “control” the employer has over the programmer, such as providing a computer, providing an office, having regular office hours and the company managing how the programmer does his work. Without a contract in place, whether the developer is an employee or independent contractor can make all the difference.

Second, is the work within the scope of employment? Factors to consider include not only job title and responsibilities, but also whether the employee is working at the office, on company equipment, and during regular business hours. Those factors, if present, would suggest the work is within the scope of employment.

Third, is the new development is related to the business of the employer, or is it a logical extension of the company’s business? The more the new code relates to the company’s business, the more likely it would be within the scope of employment.

Employment laws covering the assignment of inventions of employees vary from state to state. Texas, for example, heavily favors the employer, whereas California has a specific statutory exemption (California Labor Code Section 2870) that favors employees, providing generally that inventions made on the employee’s own time, on his own equipment, without using any confidential information or trade secrets of the employer, and which are unrelated to the business of the employer, shall belong to the employee.

For aspiring entrepreneurs who want to form their own companies, the best thing they can do (from an IP perspective) is quit their jobs in order to ensure a current employer does not own the technology that they are creating. Because that is not always practical, especially in the very early idea stage, the second best thing entrepreneurs can do is follow the model of California Labor Code Section 2870.

For startup technology companies, the best thing you can do is make sure that every officer, technical employee and independent contractor has signed a contract assigning all inventions and copyrightable materials to the company, and with respect to copyrightable materials, as “works made for hire.” IP issues are a major part of investor due diligence and legal problems that technology companies run into. Furthermore, in financing transactions companies will have to represent and warrant to the investors that they own all intellectual property necessary for the business without infringing the rights of others, and that all officers, technical employees and independent contractors creating intellectual property have signed appropriate invention assignment agreements, copies of which you will need to provide. Make sure your startup has clear ownership of the code and other intellectual property rights from the beginning.

This article originally appeared on Venture Docs, an online platform for automating the creation of important legal documents for startup companies, investors, crowdfunding portals and attorneys.

Photo credit.

Print Friendly
 

About the author: Bo Sartain

Bo is a practicing corporate attorney with the law firm of Haynes and Boone, LLP.  Bo’s legal practice focuses on the representation of investors and issuers in company formation, private equity and venture capital preferred stock and preferred LLC membership interest equity financings, and the representation of buyers and sellers in mergers and acquisitions. Formerly, Bo was a Systems Engineer and the founder and CEO of a startup software-as-a-service company.

You are seconds away from signing up for the hottest list in Silicon Alley!

Don't miss any of the stories shaping entrepreneurship. Sign up today.