how much right do I have on my project, if there are patches by others?
Rick Moen
rick at linuxmafia.com
Fri Jul 6 20:59:11 UTC 2007
Quoting John Cowan (cowan at ccil.org):
> It is, however, how patches are accepted and processed: patch authors,
> if the patch is substantial and is accepted into the original work,
> do meet the definition of joint authorship.
I doubt that. I personally find Catherine and Eric Raymond's analysis
at http://www.catb.org/~esr/Licensing-HOWTO.html#id2790762 persuasive.
(Note that this is within Catherine's legal specialty.) Quoting:
For reasons we will discuss in detail, the "joint work" model probably
does not actually apply to open-source projects. Rather, they look more
like what the law calls "collective works", a new category created by
the copyright-law revision of 1976. One of the purposes of the 1976
revision was to scupper a line of bad case law that overextended the
concept of "joint work", and courts have since shown a marked preference
for narrowing the conditions of joint work even further than statute
required.
A "collective work" is a creative work of a group of individuals who do
not share a common copyright in the result. Individual portions of such
a work may (and often do) have copyrights, and there may also be a
collective-work copyright on the work as a whole. The difference is
practically relevant because, according to 17 USC 201 the holder of the
collective-work copyright is legally privileged to set the distribution
terms for the package as a whole (in the statute, this expressed
negatively as a statement that the collective-work copyright holder
acquires only those rights).
In an unpublished case, Campbell vs. Lavery, 1997 U.S. App. LEXIS 754
(9th Circuit), the court's finding turned specifically whether a
collaboration between two programmers was a collective or a joint work.
The court observed that the project could have been found to be either a
collective or a joint work, depending on the intent of the programmers.
They found it to be a collective work based on the fact that (a) one
party had written only twenty lines of code, and (b) the behavior of
both parties showed no intent that they be regarded as coauthors.
Campbell vs. Lavery is appellate case law indicating that
collaboratively-written software is a collective rather than joint work
when programmers function in identifiable author/contributor roles. An
Albany Law Review article from the same year, A Narrow View of Creative
Cooperation: The Current State of Joint Work Doctrine[1], shows that
Campbell vs. Lavery is no fluke. They cite numerous cases showing that
courts have historically relied on the intent-of-coauthorship test to
distinguish joint works from collective works, and continue to do so
today. For the work to be joint, all coathors must show an intention to
regard and credit each other as coauthors.
This is, of course, not the case in most open-source projects. Community
practice recognizes a strong distinction between people who contribute
patches and co-authors. Indeed, community practice agrees with the
intent requirement normally one becomes a co-author on a project after
applying for that status and having it granted by the existing
author(s), in recognition of major and continuing contributions to the
project.
In fact, if the rights structure of a large project even becomes an
issue, a court might well find it to be joint work with respect to core
contributors but a collective work with respect to patchers. But this
would make little practical difference. When we wrote earlier that
registering copyright on an ordinary patch is probably pointless, we
meant that it wouldn't convey a right to block distribution under either
the joint-work or collective-work theory.
[1] http://cyber.law.harvard.edu/metaschool/fisher/joint/links/articles/lape.html
--
"Zees American words are too much. Zen our culture you'll wrench;
With 'le parking' 'le weekend' & such. Wiz our children we'll be out of touch."
Eef you anglicize French, -- L'Academie Francaise in a nutshell
More information about the License-discuss
mailing list