ContributorIntroduction

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 decision to go open source 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:

• 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.
• With a real signature on a real document, an invitee will legally start the process of becoming a committer. This "real document" is the Zope Contributor Agreement.
• 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:

  (C) Zope Corporation and Contributors

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.