Via SmartBear
-----
Open source is all fine and dandy, but before throwing yourself –
and untold lines of code – into a project, make sure you understand
exactly what’s going to happen to your code’s copyrights. And to your
career.
I know. If you wanted to be a lawyer, you would have gone to law
school instead of spending your nights poring over K&R. Tough. In
2013, if you're an open source programmer you need to know a few things
about copyright law. If you don't, bad things can happen. Really bad
things.
Before launching into this topic, I must point out that I Am
Not A Lawyer (IANAL). If you have a specific, real-world question, talk
to someone who is a lawyer. Better still, talk to an attorney who
specializes in intellectual property (IP) law.
Every time you write code, you're creating copyrighted work. As Simon Phipps, President of the OSI Open Source Initiative
(OSI) said when I asked him about programmer copyright gotchas, "The
biggest one is the tendency for headstrong younger developers to shun
copyright licensing altogether. When they do that, they put all their
collaborators at risk and themselves face potential liability claims.”
Developers need to know that copyright is automatic under the Berne Convention,
Phipps explained. Since that convention was put into place, all
software development involve copying and derivatives, Phipps said; all
programming without a license potentially infringes on copyright. “It
may not pose a problem today, but without a perpetual copyright license
collaborators are permanently at risk."
“You can pretend copyright doesn't exist all you want, but one day it
will bite you,” Phipps continued. “That's why [if you want to start a
new project] you need to apply an open source license.” If you want
public domain, use the MIT license;
it's very simple and protects you and your collaborators from these
risks. If you really care, use a modern patent-protecting license like Apache, MPLv2, or GPLv3. Just make sure you get one.
Who Owns That Work-for-Hire Code? It Might Be You
You should know when you own the copyright and when your employer or
consulting client does. If the code you wrote belongs to the boss, after
all, it isn’t yours. And if it isn’t yours, you don’t have the right to
assign the copyright to an open source project. So let’s look, first,
at the assumption that employment or freelance work is automatically
work for hire.
For example, that little project of yours that you've been working on
during your off-hours at work? It's probably yours but... as Daniel A.
Tysver, a partner at Beck & Tysver wrote on BitLaw:
"Software developers should pay close attention to copyright
ownership issues when hiring computer programmers. Programs written by
salaried employees will, in almost all cases, be considered works made
for hire. …
As a result, the software developer itself will be considered the
author of the software written by those employees, and ownership will
properly reside with the developer. However, the prudent developer will
nonetheless have employees sign agreements whereby they agree to assign
all copyrights in software they develop to the software developer. The
reason for this prudence is that the determination of who is an employee
under the law of agency requires an analysis of many factors and might
cause unexpected results in rare cases. In addition, the work made for
hire doctrine requires that the work be done 'within the scope of' the
employee's employment. Generally, programs written by a software
programmer employee will be within the scope of his or her employment,
but this again is an ambiguous phrase that is best not to rely upon."
What if you're a freelance programmer and you're writing code under a
"work for hire" contract? Does your client then own the copyright to
the code you wrote – whether or not it’s part of an open source project
as well? Well... actually maybe they do, maybe they don't.
Tysver continued:
Software developers must be especially careful when hiring contract
programmers. In order for the work of contract programmers to be
considered a work made for hire, three facts must exist:
-
The program must be specially ordered or commissioned;
-
The contract retaining the programmer must be in writing and must
explicitly say that the programs created under the agreement are to be
considered a work made for hire; and
-
The program created must fall into one of the nine enumerated categories of work.
The first element will generally be true when the programmer is hired
to work on a specific project. The second element can be met through
careful drafting of contract programmer's retainer agreement. The third
element, however, can be more difficult. Computer software programs are
not one of the nine enumerated categories. The best bet is to fit the
software program under the definition of an "audiovisual work." While
some software programs are clearly audiovisual works, it is unclear
whether courts will allow this phrase to include all computer software
programs. Thus, a software developer cannot be sure whether the contract
programmer is creating a work made for hire.
It is best to draft an agreement which reflects this uncertainty. The
agreement should state that the work is a work made for hire. However,
the agreement should also state that if the software is not considered a
work made for hire, the contract programmer agrees to assign the
copyright in the software to the software developer.
Finally, when hiring a company to provide contract programming
services, it is important to make sure that the copyright ownership
passes all the way from the individual programmer to the software
developer. Therefore, the software developer should review not only its
agreement with the company providing the services, but also the
agreements by which that company hires individual programmers.
Is he saying that that work-for-hire contract you signed that didn't
spell who got the copyright for the code means you may still have the
copyright? Well, yes, actually he is. If you take a close look at U.S. Copyright law
(PDF), you'll find that there are nine classes of work that are
described as “work made for hire” (WMFH). None of them are programming
code.
So, as an author wrote on Law-Forums.org,
under the nom de plume of morcan, “Computer programs do not generally
fall into any of the statutory categories for commissioned WMFH and
therefore, simply calling it that still won't conform to the statute."
He or she continued, "Therefore, you can certainly have a written
WMFH agreement (for what it's worth) that expressly outlines the intent
of the parties that you be the 'author and owner of the copyright' of
the commissioned work, but you still need a (separate) transfer and
assignment of all right, title and interest of the contractor's
copyright of any and all portions of the works created under the
project, which naturally arises from his or her being the author of the
WMFH." In other words, without a “transfer of copyright ownership”
clause in your contract, you the programmer, not the company that gave
you the contract, may still have the copyright.
That
can lead to real trouble. "I have actually seen major corporate
acquisitions get scuttled because someone at the target software company
had 'contracted programmers' under WMFH agreements but failed to obtain
the necessary written transfer of the contractors' copyrights,” morcan
added.
Rich Santalesa, senior counsel at InformationLawGroup,
agreed with morcan. “What tends to happen is that cautious (read:
solid) software/copyright attorneys use a belt and suspenders approach,
adding into the development agreement that it’s 'to the full extent
applicable' a 'Work for Hire' — in the event, practically, that the IRS
or some other taxing entity says 'no that person is an employee and not
an independent contractor,’” said Santalesa. They also include a
transfer and assignment provision that is effective immediately upon
execution.
“Whenever and wherever possible we [copyright attorneys representing
the contracting party for the work] attempt to apply a Work for Hire
situation,” explained Santalesa. “So the writer/programmer is, for
copyright purposes, never the 'legal author.' It can get tricky, and as
always the specific facts matter, with the proof ultimately in the
contractual pudding that comes out of the oven.”
What I take all this to mean is you should make darn sure that both
you and the company that contracted you have a legal contract spelling
out exactly what happens to the copyright of any custom code. Simply
saying something is a work for hire doesn't cut the mustard.
Now, Add in Open Source Contributions
These same concerns also apply to open source projects. Most projects
have some kind of copyright assignment agreements (CAAs) or copyright
licensing agreements (CLAs) you must sign before the code you write is
committed to the project. In CAAs, you assign your copyright to a
company or organization; in CLAs you give the group a broad license to
work with your code.
While some open source figures, such as Bradley Kuhn of the Software Freedom Conservancy, don't want either kind of copyright agreement in open source software, almost all projects have them.
And they can often cause headaches.
Take, for example, the recent copyright fuss in the GnuTLS
project, a free software implementation of the SSL (Secure Socket
Layer) protocol. The project's founder, and one of its two main authors,
Nikos Mavrogiannopoulos, announced in December 2012 that he was moving the project outside the infrastructure of the GNU project because of a major disagreement with the Free Software Foundation’s (FSF) decisions and practices. “I no longer consider GnuTLS a GNU project,” he wrote, “and future contributions are not required to be under the copyright of FSF.”
Richard M. Stallman, founder of GNU and the FSF, wasn't having any of that! In an e-mail entitled, GNUTLS is not going anywhere,
Stallman, a.k.a. RMS, replied, "You cannot take GNUTLS out of the GNU
Project. You cannot designate a non-GNU program as a replacement for a
GNU package. We will continue the development of GNUTLS."
You see, while you don't have to assign your copyright to the FSF when you create a GNU project, the FSF won't protect the project's IP under the GPL
unless you do make that assignment. And, back when the project started,
Mavrogiannopoulos had transferred the copyrights. In addition, no
matter where you are in the world, as RMS noted, if you do elect this
path, the copyright goes to the U.S. FSF, not to one of its sister organizations.
After many heated words, this particular conflict calmed down. Mavrogiannopoulos now wishes he had made a different decision. “I pretty much regret transferring all rights to FSF, but it seems there is nothing I can do to change that.” He can fork the code, but he can't take the project's name with him since that's part of the copyright.
That may sound as though it’s getting far afield of The Least I Need
to Know About Copyright as an Open Source Developer, but bear with me
for a moment. Because it raises several troubling issues
As Michael Kerrisk, a LWN.net author put it, "The first of these problems has already been shown above: Who owns the project?
The GnuTLS project was initiated in good faith by Nikos as a GNU
project. Over the lifetime of the project, the vast majority of the code
contributed to the project has been written by two individuals, both of
whom (presumably) now want to leave the GNU project. If the project had
been independently developed, then clearly Nikos and Simon would be
considered to own the project code and name. However, in assigning
copyright to the FSF, they have given up the rights of owners.”
However, there's more. As Kerrisk pointed out, “The ability of the
FSF—as the sole copyright holder—to sue license violators is touted as
one of the major advantages of copyright assignment. However, what if,
for one reason or another, the FSF chooses not to exercise its rights?"
What advantage does the programmer get then from assigning his or her
copyright?
Finally, Kerrisk added, there's a problem that occurs with assignment
both to companies and to non-profits. “The requirement to sign a
copyright assignment agreement imposes a barrier on participation. Some
individuals and companies simply won't bother with doing the paperwork.
Others may have no problem contributing code under a free software
license, but they (or their lawyers) balk at giving away all rights in
the code.”
Can You Contribute to a Project? Legally?
The barrier to participation isn't just theoretical. Kerrisk
cites the example of Greg Kroah-Hartman, the well-known Linux kernel
developer. Kroah-Hartman, during a conversation about whether the Gentoo Linux distribution should seek copyright assignments, said, "On a personal note, if any copyright assignment was in place, I would never have been able to become a Gentoo developer,
and if it were to be put into place, I do not think that I would be
allowed to continue to be one. I'm sure lots of other current developers
are in this same situation.”
Other non-profit open source groups take different approaches. The Apache Foundation,
for instance, asks for "a perpetual, worldwide, non-exclusive,
no-charge, royalty-free, irrevocable copyright license to reproduce,
prepare derivative works of, publicly display, publicly perform,
sublicense, and distribute Your Contributions and such derivative
works."
If you have any questions about a particular group—and you should
have questions—check to see exactly what rights the group requires in
its contributor license agreement. Then, if you still have questions
(you probably will) check with the organization or an IP attorney. This
is not a check-mark that you ignore as blithely as all those websites
where you click on “I have read and will adhere to the privacy policy.”
In a literal sense you are committing yourself, or at least the code you
wrote in all those bleary-eyed debugging sessions that required three
cups of coffee.
The assignment of rights is not just a copyright problem for
non-profit open source groups. Several commercial open source
organizations ask you to give them your contributed code's copyright for
their projects. Others, such as Oracle (PDF) asks for joint copyright to any of your contributions for its OpenJDK, GlassFish, and MySQL projects.
Some companies, such as Ubuntu Linux's parent company, Canonical, have backed off on asking for these claims. Canonical, for instance, now states
that “You retain ownership of the Copyright in Your Contribution and
have the same rights to use or license the Contribution which You would
have had without entering into the Agreement." Red Hat, in its Fedora Project
Contributor Agreement now asks only that you have the right to grant
use of the copyrighted code and that it be licensed under either the Creative Commons Attribution-ShareAlike 3.0 Unported License or a variation of the MIT License. If you don't know what is being asked of you, get expert advice.
With all these differences in how to handle copyright disagreements
you might wonder why someone hasn't tried to come with one common way of
handling them. Well, they have: It’s called Project Harmony. However, Project Harmony hasn't picked up a lot of support and its copyright templates have not been widely accepted.
The bottom line isn't that you have to become a lawyer to
code—although I could understand how you might feel that way!—but you do
have to carefully examine what rights you have to your code. You need
to understand what rights you're giving up or sharing with an open
source license and a particular project. And if you're still puzzled,
you need to seek expert legal help.
You don't want to find yourself in a copyright quagmire. Good luck.