Licensing Model: Joint Copyright Assignments

[Lawrence E. Rosen]

Mitchell Baker wrote:
> There are a number of factors that might lead to a (joint) copyright 
> assignment might be seen as desirable.  
> 
> First, the definition of "derivative work" "collected work and 
> "compilation" are complex, as shown by the recent extended  
> discussion 
> on this list regarding the definition of derivative work.  Also, I 
> suspect a software release contains some elements  that are  
> "separate 
> and independent works in themselves" required for a  
> collective work and 
> some elements that are not separate and independent works and would 
> therefore lead to a "compilation."  And in addition, these 
> complex terms 
> are applicable in the U.S., but grow ever more complex in an 
> international setting.  So an absolute reliance on a precise 
> characterization under U.S. law has some drawbacks.

There are a couple of interesting points you raise here.  

Remember, first, that under U.S. copyright law at least, the term
"compilation" includes collective works.  17 U.S.C. §101.  So I don't
think it makes much sense to worry about whether contributions to an
open source project are or are not separate and independent works.  In
either event, aggregating software into a compilation *or* a collective
work is permitted by every open source license because of OSD #1:

   Free Redistribution: The license shall not restrict any 
   party from selling or giving away the software as a 
   component of an aggregate software distribution containing
   programs from several different sources. The license shall
   not require a royalty or other fee for such sale.

True, it is important in the open source world to determine whether a
"derivative work" has been created, and there has been a lot of
discussion of that topic on license-discuss and elsewhere.  Yes, that
term is complex, and U.S. law may be different from that of other
countries.  I try to solve that jurisdiction problem by specifying a
jurisdiction in all my licenses.  In any event, lawyers know how to
argue such cases.  See Dan Ravicher's excellent article on this topic,
which I'm copying as an attachment to this email.  There are many smart
attorneys like Dan who are qualified to help open source projects and
proprietary vendors analyze whether they are creating derivative works.

> Second, the ability to change the open-source terms under 
> which the code 
> is licensed is quite important.  Over time, new needs will arise, 
> whether it's dealing with patent issues, DCMA issues or other as yet 
> unanticipated new developments.  It is possible to maintain a source 
> tree with many different licensors and then seek their 
> approval for each 
> such change.  But this is extraordinarily difficult with a 
> large number 
> of contributors and risky to count on.

You raise a VERY IMPORTANT point here.  Over time, as software evolves,
so too do licensing strategies and business models.  For these reasons,
as well as the ones you mentioned, it is essential for licenses to be
able to evolve as well.  

Does the law or the OSD require a project to seek a contributor's
permission before the project can license or re-license a collective
work or a compilation that contains that contribution?  Certainly not if
the contribution arrived under an open source license, again because of
OSD #1, because every open source license must allow anyone, anywhere,
for any reason whatsoever, to make and distribute copies of the
software.  An open source license to the contribution is all a project
needs to authorize as many copies of that contribution as they want to
make.

Many open source licenses even allow open source (and proprietary)
projects to create derivative works under any license terms whatsoever.
The Apache, BSD, MIT, X11 and Academic Free License all have that
property.  So once again, licensing or re-licensing of derivative works
of such software is simply not an issue for projects to worry about.

[I say this as a legal comment without regard to the possible ethical
issues of a project re-licensing open source software.  Projects agonize
about their licenses in order to satisfy the expectations of their
contributors.  But the law and most licenses give them permission to
re-license all they want.  Perhaps that's a form of "forking"?]

The only wrinkle comes with reciprocal licenses like the GPL and the
Open Software License, and to some extent the Mozilla Public License.
Those licenses impose downstream obligations on derivative works that
may not be consistent with re-licensing of those derivative works.  Some
projects (Apache comes to mind), for that very reason, refuse
contributions given to them under the GPL or similar licenses.  

My point here is that there is no reason whatsoever to conflate the
topics of "copyright assignments" and "project re-licensing."  As is
always the case in open source, the provisions of the license(s) under
which they receive contributions are sufficient to determine the
project's future licensing alternatives.

If there is a reason to insist on copyright assignment, it doesn't arise
from *this* problem.

/Larry Rosen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Software DW Analysis.pdf
Type: application/pdf
Size: 119284 bytes
Desc: not available
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20030415/1f157f8f/attachment.pdf>