9.5. Copyright Assignment and Ownership


Most projects have a single legal entity own the copyright on the entire code base. This is done for various reasons. If the terms of the copyright ever need to be defended or enforced in court, it's much easier if a single entity has the right to do so; otherwise, all of the contributors would have to cooperate, and some might not have time or even be reachable when the issue arises. Also, if the code is the target of a copyright infringement suit, you wouldn't want the individual developers to be personally exposed to liability.

Remember that centralized ownership of the copyright does not make the code any less free. Open source licenses do not give the copyright holder the right to retroactively proprietize all copies of the code. Even if the copyright-holding entity suddenly turned around and started distributing all the code under a restrictive license, it wouldn't cause a problem for the public project. The other developers would simply start a fork based on the latest free copy of the code, and continue as if nothing had happened. Because they know they can do this, most developers do not object when asked to assign copyright to some sponsoring organization.

Different organizations apply different amounts of rigor to the task of collecting copyright assignments. For most, simply getting an informal statement from a contributor on the public list is enough something to the effect of "I hereby assign copyright in this code to the project, to be licensed under the same terms as the rest of the code." At least one lawyer I've talked to says that's really enough, presumably because it happens in a context where copyright assignment is normal and expected anyway, and because it represents a bona fide effort on the project's part to ascertain the developer's true intentions. On the other hand, the Free Software Foundation goes to the opposite extreme: they require contributors to physically sign and mail in a piece of paper containing a formal statement of copyright assignment, sometimes for just one contribution, sometimes for current and future contributions. If the developer is employed, the FSF asks that the employer sign it too.

The FSF's paranoia is understandable. If someone violates the terms of the GPL by incorporating some of their software into a proprietary program, the FSF will need to fight that in court, and they want their copyrights to be as airtight as possible when that happens. Since the FSF is copyright holder for a lot of popular software, they view this as a real possibility. Whether your organization needs to be similarly scrupulous is something only you can decide, in consultation with lawyers.



Producing Open Source Software
Producing Open Source Software: How to Run a Successful Free Software Project
ISBN: 0596007590
EAN: 2147483647
Year: 2004
Pages: 137
Authors: Karl Fogel

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net