Log in

No account? Create an account
CLAs and Release Votes within the Apache Software Foundation - Nick [entries|archive|friends|userinfo]

[ website | gagravarr.org ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

CLAs and Release Votes within the Apache Software Foundation [May. 23rd, 2010|04:21 pm]
There has been a fair bit of discussion of late, both within the Apache Software Foundation and outside of it, about whether some of the processes and proceedures are a help or a hindrance. With this in mind, I thought I'd write something about how I see things.

Note - this is a personal view. While I am a member of and PMC chair within the ASF, it's my view, not an official foundation statement. It's based on lots of discussions, talks and mailing list posts, but please do shout if you think I've got something wrong...

There are three main things that people seem to moan about around the ASF. The first I won't really dwell on, that of "why can't I use ${latest_tool_of_the_moment}. As the hard-worked ASF infrastructure crew will happily tell you, you can use anything that can be supported, maintained, bug fixed and generally looked after 24/7 by volunteers scattered around the globe. If you want something new, be prepared to help look after it!

The other two main things seem to be around CLAs, and release voting. These two offer some very important protections for everyone - users, developers, committers and the ASF. The need for these are documented at http://www.apache.org/dev/, but as there's a lot to read there, I'll try to give my view on why they matter.

Firstly, a question. What are two of the easiest ways to close down an open source project?

The answers, I feel, are to either sue the release manager, or to sue whoever holds the source code.

For the first, think how long your project would last if the release manager was sued for a very large sum of money, and anyone else who might consider signing up was threatened with a similar lawsuit too? With no releases, one key community member out of action through a lawsuit, and everyone else worried, the answer is alas not all that long. Personally, I think it's great that I'm both allowed (and encouraged!) to work on open source at work, whilst also well enough paid that I can afford to spend part of my free time coding, mentoring etc within open source. However, it does also mean I have enough to loose... And having been an Apache release manager in the past (for Apache POI), I'm very glad that the ASF protected me. But how?

If you do a release of some open source code on your own, and someone has it in for your project, then you could be at risk. One of the key reasons for founding the ASF was to provide protection for this. What you want, should something bad like this to ever happen, is for some ASF lawyers to turn up in court and say "stop suing this poor contributor, sue us if you're going to sue anyone", and have the judge agree. For that to work, the release needs to have been done by the ASF. That's where the release votes and rules come in.

What you're after, therefore, is for the ASF to stand up and say "that's our release". The ASF wants lots of good open source software to be out there and being used, so wants to support your release, but tat the same time, doesn't want to take needless risks. The release requirements are therefore basically that enough people who provide oversight have OK'd the release, and that as far as is possible, all the code in the release is allowed to be. Therefore, we see the requirement that 3 PMC members have +1'd the vote, the source has appropriate headers, notice files and licenses are clear, the build is open and repeatable, and dependencies are all ok. (The PMC, or project management committee, is the ASF board's eyes and ears on the project). Largely above and beyond that, what each project wants to do in terms of releases is up to them. Things like betas, release candidates and numbering all lies within the project, based on how the community wishes things to work.

Now, on to the CLAs, or Contributor License Agreements. There are two of these, the iCLA (for individuals), and the CCLA (for companies). These are actually fairly simple documents, and all relate to the core Apache License v2.0. For an individual, it is basically "I understand what it is to release software under the apache license, and what rights I wave to do so, and I'm happy and able to do so". For a company, it's basically "I understand what it is to release software under the apache license, and what rights I wave to do so, and I'm happy for my employees to do so". These provide the foundation, and the software users (the community) with the protection that someone can't turn around a year later and say "I know I said I was contributing under the apache licenese, but I've changed my mind, and now I'm going to sue you".

Many other foundations are happy to accept contributions under their licenses (be that the ASL, GPL or whatever) without requiring that those making significant contributions formally state (via a CLA) that they understand the license, and are OK with their contributions being under it. However, within the ASF, we like to be very sure on these things (which is part of what allows our software to be used so widely without lots of legal checks being required first). As such, we ask people to file a CLA before they contribute, just to confirm they're happy with how their contributions will be used.

So, we see two key parts of Apache policy, the release process (checks and votes), and the CLAs, are both there to protect the project and the community. They happen to protect the ASF too, but they're mostly about protecting everyone!

As an aside, if much of this is new to you, I can't recommend enough attending a "The Apache Way" talk somewhere. You'll find them at all Apache Cons, at all Apache Bar Camps, and many other things, and are a great way to learn about things like this, both what the proceedures are, and why they exist. It's much of how I learnt these things!