History for ContributorIntroduction

??changed:
-
Introduction to Zope CVS Contributions

In autumn 2001, Zope Corporation (ZC) began the major step of opening
the Zope CVS repository to external contributions by trusted community
members.

This was a long, deliberate process for us at ZC. In fact, the
path goes all the way back, in some respects, to the <a
href="http://www.zope.org/Members/paul/BusinessDecision">decision to
go open source</a> back in November 1998. At important steps along
the way we have discussed key points with the community.

We are now at one of those key points. We have formed a strategy, put
the strategy through legal review, and vetted it with some key members
of the Zope community.

Our approach synthesizes elements from Mozilla's approach to
contributions, from how !PythonLab's opened up the Python repository,
and from the culture of the Zope community. Here are the basics of
the approach:

o A group of people makes decisions on who to invite, just like in
the Python community. We at Zope Corporation will start the process
by choosing an initial, small group of invitees to bootstrap the
process.

o With a real signature on a real document, an invitee will legally
start the process of becoming a committer. This "real document" is
the <a href="../Contributor.pdf">Zope Contributor Agreement</a>.

o When an invitee's contributor agreement arrives, and the invitee
conducts their first checkin using their repository credentials, they are
consenting to the joint ownership terms of the contributor
agreement.

"Joint ownership? What's that?" Good question. Here is
the story.

The legal issues are reasonably well understood if we go down the path
that others have blazed for us. However, many of those other
approaches ended up being less than ideal marriages in terms of number
of committers, etc.

There is a balance point between the needs of Zope Corp, the needs of
the contributor, and the needs of the community. It is unlikely that
we can maximize all three, but we certainly are aiming to satisfy all
three beyond a minimum threshold, with each dimension being considered
independently.

Toward that end, we had a discussion with our attorney whereby we
floated a novel (according to him), but reasonably well understood
concept (at least in other works, if not in software). That idea is
"Joint Ownership", rather than "Assignment", or "License".

There apparently is quite a wide body of "Joint Copyright" material in
the world, and a wide body of "Joint Patent" ownership as well. We'd
be looking to mirror the "Joint Copyright" (JC) stuff, with some
interesting twists to account for the software, open source, etc.,
nuances.

Essentially, a committer signs an agreement stating that all code that
the committer submits has been created by her, or that she has
verified that the contributed code violates no rights. She further
agrees that by committing it into the Zope CVS tree, that she is
sharing ownership 50/50 with Zope Corporation. She retains *all
rights* to do *whatever* she wants with the code, no strings attached
whatsoever. Zope Corporation gets the same rights.

We need to recognize that she might have contributed the code only
because it was an open source project, and that she wouldn't have
wanted us to keep an interesting idea closed to the public. Therefore,
we would further stipulate that if we were to use the code in any way,
it would be made available at a minimum under a dual-license, with one
of them being the ZPL, meaning freely and widely available.

Of course, if we reject the code for any reason, and don't use it
ourselves in any way, then she would have to get it out into the world
if she thought we were wrong (e.g., we selected another committer's
patch for a certain problem, etc.). She would be free to do so in any
manner she desired. The point being that we're not obligated to
propagate her code if we don't use it all.

The other change to JC law is that we would require the committer to
waive "notice rights". In other words, there is a provision in the JC
law that requires each holder to inform the other holders whenever
they make use of the copyrighted material. This simply doesn't make
sense (would we have to inform each contributor each time Zope was
downloaded?).

Then, any copyright marks we have would be listed as::

Separately, we'd list everyone who had ever made a contribution to
Zope, without having to keep track of each line and version that they
had affected.

Similarly, it is impractical to accept contributions under a separate
license, even if it is compatible with the Zope license. We don't
want to keep track of which lines are licensed differently than
others, and ensure that we comply with those specific licenses.

It's also important to emphasize the covenant in the agreement where
the contributor acknowledges they won't contribute code over which
they have no rights. In order to "protect" us as much as possible,
the agreement between the committer and Zope Corporation would state
that the committer represents that the contributed code is theirs to
do with as they please, essentially permitting them to split the
ownership between us. They are warranting to us that they have
authority to submit under the terms.

In talking with people about this, we've been asked, "What happens if
you get bought out by Mean Corporation?" In summary, nothing much
that could or couldn't happen now.

First and foremost, everything is still available to everyone with
exactly the same terms. While !MeanCo might choose to stop making
future contributions available under an open source license, there's
nothing that can be done to rescind available rights on existing
software. And MeanCo/ZC could stop making future contributions either
way, with or without being bought by !MeanCo. That is, they could tell
ZC to stop making additional contributions under the ZPL.

Second, under this agreement (and it's really Hadar's nifty idea),
contributors retain half ownership on their contributions. Even if a
MeanCo/ZC found some way to rescind previously-granted rights, all the
contributors would still have rights on their work, which they could
contribute to a fork.

One person asked:

*The half-share in IP confuses me slightly. In your comments you
seem to be saying that it's good because it future-proofs the
Committer's rights to the code. However, in this context, ownership
of code built on the Zope substructure is a moot point if that
substructure is removed. The implication is that there may be a
possibility that the ZPL is not binding on all code to which it has
been applied, because ZC has IP rights on the Zope core.*

This is a very good point/question. Currently, ZPL permits pretty much
any kind of use of the code. With that premise, we wouldn't even have
to ask for joint ownership, just permission to relicense the
contributed code under ZPL.

So, the minute we give the code out in a ZPL'ed package, everyone
(including the current contributor), can use it. However, while the
restrictions are pretty few, some would still prefer to know that as
"joint owners", there's literally nothing that they can't do with
their code.

Ultimately, the real reason to go for joint ownership has nothing
really to do with a current Zope distribution. No matter what happens
in the future, having "assignments" ties the contributor to Zope Corp
(and vice versa) forever. Tracking things, getting updated
wet-signatures, etc., whenever the code might be used differently, can
be problematic at best.

This is about ultimate freedom for the contributor *and* for Zope
Corp., not anything else.

Current releases of code can *never* be changed to a different
license. Only future ones can be (which is something we are not even
contemplating!). However, the option shouldn't be taken out of our
hands, nor should it punish current contributors.

TheJester (Jan 18, 2002 9:02 am; Comment #1) *Editor Remark Requested* --
Why is it that you do not need to sign such a document in order to supply patches
or material via the tracker? The mechanism for acceptance is different,
but, the underlying copyright laws remain (and so do the problems you're trying
to address via the agreement).

klm (Feb 8, 2002 2:07 pm; Comment #2) --
In response to TheJester's question, here's my take. Very small
patches are often not liable to breach any kind of infrignement. For
moderately sized patches and questionable very small ones, the person
applying the patch assesses them for both technical and propriety
concerns. For large patches, Zope Corp may well pursue a release from
the person!

zigg (Feb 26, 2002 12:28 pm; Comment #3) *Editor Remark Requested* --
The contributor agreement does not seem to address one thing that is very important to me -- the guarantee of a disclaimer of liability. The current ZPL contains an acceptable disclaimer, but the agreement does not seem guarantee that future ZPLs will maintain my disclaimer of liability.