In these days of economic uncertainty, it’s more important than ever for developers to contribute to open source projects. There are plenty of reasons to work on open source: to keep your skills up-to-date (especially if you are unemployed, underemployed, or want a better job), to make a difference in a community where your efforts are valued, or just to keep the open source project moving forward. Every snippet of code contributed builds a better mousetrap, but you also need to safeguard yourself from lawsuits.
Yes, lawsuits! Whether you contribute small bug fixes or entire code modules, every developer needs to be aware that some people do not look at such donations in the spirit of generosity. Being fired, being sued, or even having the foundry sued are just some of the consequences you could face if your employer finds out that you have become a committer.
“Contributing to open source projects without employer approval could be grounds for termination, lawsuits, or a promotion, depending on where you work,” says Ron Gula, CEO and CTO of Tenable Network Security, who runs the Nessus Project.
Adds Michael Overly, an attorney at Foley and Lardner, “An employer could go after the foundry for damages – and even potentially the end users of the open source product enhanced by its ‘stolen’ intellectual property. If the employer’s [intellectual property (IP)] is uploaded and contributed without its consent, the employer can sue the foundry and each end user directly for IP infringement.”
Part of the problem is the question, “Who owns the code?” and this can be a surprisingly complex issue.
“The general rule under the US Copyright Act is that the developer will own the copyright in and be the ‘author’ of the code unless (1) the developer is an employee and the code has been written ‘within the scope of employment’ of the developer, or (2) the developer has signed an agreement transferring the developer’s rights to the company,” says Frederic M. Wilf, an attorney at Morgan Lewis & Bockius.
Winning or losing a lawsuit over intellectual property hinges largely on the business or even the anticipated business of your current employer, says attorney Daniel Appelman, partner at Montgomery & Hansen.
“The test for what relates to the business or anticipated business of the employer is pretty easy to pass,” he clarifies. “One would look at the current products and services of the employer and also its business plan for new products and services going forward. If the invention at issue relates to either of those, then under California law, the employer owns the invention even though it may have been developed by the employee on his/her own time and without using the employer’s facilities.”
And what about the basics? Do you use your own computer? Work only on your own time? Use only your personal resources?
“Where did they get their ideas, programming, and tools?” asks Overly. “This is always a gray area. If the IP is developed using knowledge or tools gained from an employer, there is a strong presumption the IP belongs to the employer.”
What about using knowledge gained on the job? Watch out there, too.
“Even if the development is done during off-hours, the employee must carefully segregate in his/her mind what they learned from their employer and the employer’s intellectual property and what is truly the employee’s development, ideas, etc.,” says Overly.
Of course, many such issues could be avoided entirely by simply communicating with your employer prior to contributing code.
“If the developer is an employee, then the developer should not contribute any software or other code to an open source software project without first hashing out the issues with the employer,” says Wilf. Contractors shouldn’t assume that these issues don’t apply to them. “If the developer is not an employee, then the developer does not have that issue and the developer is free to contribute code to an open source software project, so long as the contribution does not interfere with any other contract the developer has signed, and so long as the developer does not use any trade secrets or confidential information of any other person or company,” Wilf adds.
He cites the fairly well-known case of Computer Associates International, Inc. v. Altai, Inc., 982 F.2d 693 (2d Cir. 1992), in which a former employee of Computer Associates copied portions of software that he had written for Computer Associates into new software written for his new employer, Altai. “Once Altai was sued, it removed the copied code from the new software, and revised the new software using programmers who did not have access to the Computer Associates code,” says Wilf. “However, the court noted that the programmer may have incorporated Computer Associates’ trade secrets into the new Altai software in portions of the Altai code that did not directly copy the Computer Associates code. So, in the open source context, a developer must be careful not to use or reuse any source code developed for an employer or customer without written permission of the employer or customer, and the developer must be careful not to use any trade secrets of a former employer or customer for any other person or purpose.”
Wilf says there are many examples of developers being sued, but most of these cases are settled out of court. “One example is a group of programmers wanted to form a software company that competed with the software company that employed them at that time. They used their own time, money and other resources to develop their own, competing software. However, they did so while still employed by their original employer. After the software was written, they quit their employer and opened their new shop to sell competing software. They were promptly sued by the employer. The court ordered them to turn over the code to their now-former employer. Lesson: Quit first, then develop competing software, and don’t use any of the former employer’s code or trade secrets.”
“Unfortunately, the many examples rarely go to a published decision,” adds Wilf. “I based my comments on several cases, including Plains Cotton v. Goodpasture Computer and CA v. Altai.
And if you think you’re safe because you have your employer’s approval, have you considered all of the logistics?
Gula suggests, “Think of some simple things, like can the employer’s corporate e-mail be used? Is the employer entitled to audit the code contribution to make sure there is no conflict of interest?”
In an interview a few years ago, Ward Cunningham, developer of the first wiki, then the director of committer community development at the Eclipse Foundation and now CTO of AboutUs.org, said, “[Eclipse has] a code submission process and part of that is getting approval from your employer. Developers tend to be optimists who want to solve problems and aren’t so worried about what could happen.”
The bottom line: You aren’t an idiot to contribute to an open source project. It’s a wonderful thing that you do so. But give some thought to the consequences of open source involvement when you are also bound by an employer’s legal restrictions.
About Shawna McAlearney
