| < Day Day Up > |
Joint WorksOpen source prides itself on being a cooperative development process. Communities of engineers work together over the Internet to write software. In this way, they may create collective works. But they may also, without realizing the difference, create an entirely different kind of work: The result of collaborative development may become a joint work rather than a collective work .
Obviously, joint authors of a work don't have to collaborate on each word of the final product. They can divide their activities to create a unified work ”perhaps chapter by chapter, perhaps plot line by plot line, perhaps one writes the music and the other the words, perhaps they cooperate in more subtle ways. They may intentionally decide not to reveal which author did which portion of the work. Joint authors usually manifest their intent to create a joint work by documenting in a contract between them the specific relationship that they intend to forge while working together on the work. Proof that something is a joint work requires proof of the intention of the authors, but that proof isn't always easy to provide for the authors who contribute to informal open source projects. There is a very important legal difference between a collective work and a joint work. Each contribution to a collective work is owned by its author, and that author has the exclusive right to decide how that contribution is to be licensed. A contribution to a joint work is owned by all of its authors jointly. In the United States, unless they agree otherwise , each of the joint authors may separately license a joint work ”and all of its parts ”without the consent of any of the other joint authors, and every author must account to the other authors for their share of the profits derived from the license. Consult local law to determine whether one owner of a joint work may license without the consent of the others or must account to the others for his or her licensing revenue. For most projects, whether the software is a collective work or a joint work will be unimportant as long as the contributors all continue to agree on a licensing strategy. Only when disagreements occur and the licensing strategy is to be changed ”what in open source circles is called relicensing ”does it matter how the parties formally agreed to collaborate. Relicensing a joint work is, in some ways, easier than relicensing a collective work because any one of the authors can do it without consulting the others, but it may leave some contributors angry with the results. |
| < Day Day Up > |
| < Day Day Up > |
Assigning OwnershipThis book is about licensing, but there is an alternative to licensing that is occasionally employed by open source projects to ensure that the projects themselves have the right to license contributions. Authors are encouraged to assign their entire ownership interest in open source software (and occasionally the ownership interest in any patents embodied in that software) directly to the project. This assignment is an effective way to ensure that the project itself has the authority to license the software. You will recall that the owner of intellectual property may dispose of it as if it were real or personal property, including by sale or gift. Once transferred to a new owner, it is the new owner who has the exclusive rights described in this chapter. This technique of copyright assignment is generally neither useful nor necessary, because an open source license can convey all rights as effectively as an assignment. There are only a few limited occasions when an assignment is preferable. First, as I shall explain more fully in Chapter 12 on open source litigation, only the owner of a copyright, or an exclusive right under copyright, or the owner or exclusive licensee of a patent right (e.g., in an explicit territory or field of use) has the right to sue to enforce those rights or licenses. (17 U.S.C. § 501[b]; 35 U.S.C. § 281.) Second, since intellectual property is inheritable upon death of the owner, the owner may prefer to assign a valuable copyright or patent rather than burden his heirs with something they may not understand, appreciate, or know how to manage. Copyright law in the United States requires that copyright assignments be in writing. (17 U.S.C. § 204[a].) Similar provisions apply to patent assignments. (35 U.S.C. § 261.) As an exercise in legal drafting, an assignment usually includes the formalities needed to satisfy the writing and filing requirements of copyright and patent law. One risk to the original author of assigning a copyright is that the author loses the right to license it yet again under different terms to different licensees . (I discuss dual licensing strategies in Chapter 11.) Once copyright ownership is assigned, the new owner has the exclusive right to decide on licensing strategies, and the original owner has no rights left (unless he or she receives a license-back, about which I will say nothing more in this book). Another risk of assignment is that many open source projects have informal structures, often without a legal corporate entity behind them. Assigning a copyright to an informal entity leaves in doubt just who has the authority to commit to licensing decisions. Indeed, if a project makes licensing decisions that the original copyright owner dislikes, that original owner will have no legal basis to object and will be obligated to honor the express provisions of the written assignment that he or she signed. Other than the infrequent situations described above, there is little advantage to open source projects to receive assignment of copyrights and patents. Everything that an open source project needs, including the rights to make copies, create derivative works, and distribute the software, is provided by any of the open source licenses described in this book as readily as by an assignment. Contributors and the open source projects that receive those contributions can usually accomplish their objectives with an open source license instead of an assignment. Since a license accomplishes much the same thing in open source as an assignment, I will not bother describing the special language that would be needed for an assignment to make it legally effective. Nor will I describe how to draft an assignment that includes a license-back to the original owner. These are questions best directed to your own attorney. |
| < Day Day Up > |
