The Apache Software Foundation

You may wonder where all this software comes from. How was it developed? Who developed it? Who paid for it? What can you use it for and under what terms? What if you have a problem? In this section, we’ll talk about the Apache Software Foundation and, along the way, answer all these questions.

History

The Apache Software Foundation started out in 1995 as a group of eight Webmasters called the Apache Group. Their purpose was to continue the development of the public domain HTTP server daemon that was developed by Rob McCool at the National Center for Supercomputing Applications (NCSA) at the University of Illinois at Urbana-Champaign (UIUC). McCool had left NCSA in 1994, and no one was developing the NCSA code base. The problem was, the NCSA HTTP server was the most popular Web server in 1995, and many people wanted to keep using it. The group of Webmasters used e-mail to coordinate the changes each of them made to the NCSA HTTP code. The changes were distributed as patches, generated by the UNIX diff command and integrated using the UNIX patch command. All these patches led to the Apache name: “a patchy server.” Since 1996, the Apache HTTP server has been the number-one Web server on the Internet.

In 1999, the members of the Apache Group formed the Apache Software Foundation (ASF) in order to provide organizational, legal, and financial support for the Apache HTTP Server. The ASF is a membership-based, not-for-profit corporation formed for the following reasons:

• Provide a foundation for open, collaborative software development projects by supplying hardware, communication, and business infrastructure.

• Create an independent legal entity to which companies and individuals can donate resources and be assured that those resources will be used for the public benefit.

• Provide a means for individual volunteers to be sheltered from legal suits directed at the foundation’s projects.

• Protect the Apache brand as applied to its software products from being abused by other organizations.

New Projects

The ASF initiated the Apache XML project in the fall of 1999 with code donations from a variety of sources including IBM, Sun Microsystems, Datachannel, and several individuals. These projects formed the core of the new project. Since that time, the Apache XML project has added several new projects as the XML area has continued to grow. Early in the spring of 2003, some of the projects in the XML project were spun off into a Web Services project, and the Cocoon project became a top-level project as well. This was done to facilitate the foundation’s ability to oversee these projects, and so that the projects could build more cohesive communities around their areas of interest.

The projects are frequently referred to by the URLs of their Websites. The XML project is at http://xml.apache.org, the Web Services project is at http://ws.apache.org, and Cocoon is at http://cocoon.apache.org. The ASF has a number of other projects, including Ant, APR, Avalon, Commons, DB, Incubator, Jakarta, James, Maven, Perl, PHP, and TCL.

What does this mean to you? The software you download from the ASF is owned by the ASF and is licensed to you, as is all software. As you’ll see in the next section, the terms of the license aren’t restrictive. Development of the software is the responsibility of the ASF through individual contributors.

Licensing

The ASF differs from some of the other large open source efforts in a number of ways. One of them is the area of licensing. You may have heard that open source software is viral, meaning that if you use it in your application, you must distribute your application as open source. Whether this is true depends on the license you’re using. The GNU General Public License (GPL) is the primary license that has this property. The GNU Lesser General Public License (LGPL) may also have this property when applied to Java code. This issue is still being resolved at the time of this writing.

The Apache Software Foundation has its own license called the Apache Software License. For your convenience, the entire content of the license follows.

/* ===================================================================  * The Apache Software License, Version 1.1  *  * Copyright (c) 2003 The Apache Software Foundation. All rights  * reserved.  *  * Redistribution and use in source and binary forms, with or without  * modification, are permitted provided that the following conditions  * are met:  *  * 1. Redistributions of source code must retain the above copyright  *    notice, this list of conditions and the following disclaimer.  *  * 2. Redistributions in binary form must reproduce the above   *    copyright notice, this list of conditions and the following   *    disclaimer in the documentation and/or other materials provided  *    with the distribution.  *  * 3. The end-user documentation included with the redistribution,  *    if any, must include the following acknowledgment:  *       "This product includes software developed by the  *        Apache Software Foundation (http://www.apache.org/)."  *    Alternately, this acknowledgment may appear in the software   *    itself, if and wherever such third-party acknowledgments   *    normally appear.  *  * 4. The names "Apache" and "Apache Software Foundation" must  *    not be used to endorse or promote products derived from this  *    software without prior written permission. For written  *    permission, please contact [e-mail].  *  * 5. Products derived from this software may not be called "Apache",  *    nor may "Apache" appear in their name, without prior written  *    permission of the Apache Software Foundation.  *  * THIS SOFTWARE IS PROVIDED "AS IS" AND ANY EXPRESSED OR IMPLIED  * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES  * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE  * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR  * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,  * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT  * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF  * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND  * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,  * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT  * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF  * SUCH DAMAGE.  * ===================================================================  *  * This software consists of voluntary contributions made by many  * individuals on behalf of the Apache Software Foundation. For more  * information on the Apache Software Foundation, please see  * <http://www.apache.org/>.  *  */

There are seven items you need to be aware of:

• You’re free to redistribute the source code and/or binaries of an Apache-licensed piece of software. This is true even if you make modifications to the source code. You aren’t required to make your product open source. You also aren’t required to give out the source code, but you’re allowed to do so if you choose. There are some conditions, and they basically come down to this: You must credit the fact that you used Apache-licensed code. So, if you redistribute the source code to an Apache project, you must include the license file (which appears at the top of every source-code file).

• If you redistribute binaries (including binaries you write that include the Apache code), then you need to distribute a copy of the license file somewhere in your distribution.

• If you make a distribution (including building software that uses the Apache code), then you need to include the clause “This product includes software developed by the Apache Software Foundation (www.apache.org/)” somewhere in the end-user documentation, in the software, or wherever you acknowledge the use of third-party software.

• You can’t use the name Apache or Apache Software Foundation to endorse or promote your product unless you get written permission from the ASF.

• You can’t use Apache in the name of your software product unless you get written permission from the ASF.

• There is no warranty for the software.

Under the terms of the Apache License, it’s fine for you to build a product that uses one or more pieces of Apache software and sell the product in binary form. You don’t have to distribute the source code for your product, and you don’t have to make it open source. You don’t have to pay the ASF, although they would never turn down your donation. As long as you give the ASF a little credit and don’t try to misuse the Apache name, you should have no problems. A number of commercial Java products do this on a regular basis (IBM’s WebSphere application server comes to mind as an example).

Community

Another way the ASF is different from other open source projects is in its focus on community-developed software. For an ASF project, the health and diversity of the development community is as important as the technical quality of the project code. The knowledge and expertise about the code resides in the community of developers.

A good way to keep abreast of developments in the broader ASF community is via the Apache Newsletter at www.apache.org/newsletter/index.html.

The ASF is a virtual organization; it has no central meeting place, so everything happens via the Internet. An Apache project uses several tools to create a virtual meeting place:

• Mailing lists—The most important tool is mailing lists. Usually a project has two or three mailing lists. One mailing list is for users to ask questions, get help, and help each other. Another list is used by the people who are developing the software for the project. This mailing list is public and open to anyone who is interested. There may also be a third mailing list that records all the changes made via the source-code control system, CVS. Sometimes the developer list and the CVS list are the same. The XML and Web Services projects each have a project-wide mailing list called general. This cross-project list facilitates interaction between the various subprojects and the public working area for the project management committee (PMC).

• CVS source-code control system—CVS is an open-source version-control system that allows developers to work in parallel without locking files. If two developers change the same file, then a conflict occurs, and they have to merge their changes. The importance of CVS is obvious. It’s where the code lives, and because people are there for the code, CVS is essential.

• IRC channel—Sometimes a project has an IRC channel where people can gather and discuss issues interactively. This tool can be useful but can also be a barrier to community development unless the IRC session is logged and the logs are posted to the mailing lists.

• Wiki—The ASF also hosts a wiki (a collaboratively edited Website) at http://nagoya.apache.org/wiki/apachewiki.cgi. It’s useful for working on documents in a collaborative manner. Mailing the final document or snapshots of the document to the appropriate mailing list is encouraged.

Roles

There are different categories of involvement with an Apache project, all of them voluntary. The first and most important category includes people who are using the software. Without the users, there is no reason for the project to exist. They use the software, make requests for new features, report bugs, and let the developers know where the software is hard to use or understand. These users are also doing the marketing and sales for ASF projects. If someone has a good experience using a piece of Apache software, they are likely to let their friends and colleagues know about it. So, although most users don’t contribute code, they supply lots of information that shapes the way the code is written.

Some users do a bit more: They send changes to the documentation or to the software itself. Typically these changes are sent to one of the mailing lists as patches (generated using the diff command) to the existing documentation or software, although occasionally someone sends an entire file. One of the committers (explained next) examines the patches and decides whether the changes should be incorporated. If the changes should be incorporated (or modified and then incorporated), the committer makes the changes and commits them to the CVS repository. A contributor can contribute in other ways as well, such as by helping resolve disputes or making significant suggestions for features.

Contributors who consistently make valuable contributions may become committers. The term committer comes from the CVS commit command used to make changes to the CVS repository. The committers form the core development team for the project. Because they have been recognized as doing significant amounts of work, they decide on the direction of the project. In order to become a committer, a person must be nominated by an existing committer. A contributor can ask to be nominated, but a committer must be willing to propose that the contributor be given commit rights. All the committers for the project vote on whether the person should be granted commit rights. If the person receives three +1 votes and no -1 votes, then they are given commit privileges.

Voting

Let’s change topics for a moment and talk about voting. All major decisions for an Apache project are made by voting. Voting is typically used in three areas: major code modifications, project releases, and procedural matters. However, voting is so much a part of the way Apache projects work that it often happens spontaneously as a way of expressing agreement or disagreement on an issue. Depending on the project, a good rule of thumb is that a vote lasts for 72 hours in order to allow people to participate—this is especially important because the committers may be distributed around the world.

Votes are stated using numbers. Voting +1 means you’re in favor, voting -1 means you aren’t in favor, and voting 0 means you’re neutral. In addition, +0 and -0 votes indicate that you’re leaning, but your inclination isn’t strong enough to be in favor or against.

Code modification votes work like this. Someone makes a proposal for a code change they would like to make and requests a vote (people may also vote spontaneously to show that they believe a vote is necessary). At that point, the proposal needs three +1 votes and no -1 votes. In this setting, a -1 vote is a veto. Vetoes should be exercised reasonably, and the person exercising the veto must give a valid technical reason for it. It’s possible to get someone to retract their veto after addressing their concerns.

Code release votes are typically called by the person acting as the release manager for that release. Typically, the project develops a release plan and votes on it using procedural style voting. A twist in the voting on release plans is that +1 is assumed to mean the voter will help make the release happen, whereas +0 and -0 indicate that the voter will not help or hinder the release process. Once all the items in the release plan have been completed, the release manager calls for a vote to make a release. Release votes can’t be vetoed, but they do require a minimum of three +1 votes to be approved.

Procedural votes on issues such as developing release plans are done via a simple majority. There must be more +1s than -1s, and there are no vetoes.

Another voting style can be used: lazy consensus. In such a vote, someone says something like “I’m going to modify the code to do this instead of that unless someone objects within three days.” If no one objects, then the change is made. This process can be used effectively for smaller code changes that may not be important enough to vote on. If another committer believes the change is important enough for a vote, then a vote can be taken. Lazy consensus is mostly used for code modification votes, although it can be used for minor procedural matters. Another name for lazy consensus is silence implies consent.

PMCs

All the top-level ASF projects have a project management committee (PMC). The top-level projects are those that have their own Websites. Of the projects we’ll discuss in this book, the XML project (http://xml.apache.org), the Web Services project (http://ws.apache.org) and Cocoon (http://cocoon.apache.org) are all top-level projects. Xerces, Xalan, FOP, Batik, Xindice, and XML-Security are all subprojects of the XML project, and XML-RPC and Axis are subprojects of the Web Services project. You may hear the term umbrella PMC used to describe the XML and Web Services PMCs (as well as Jakarta) because they form an umbrella over a number of (sub) projects. The subprojects operate as projects in their own right, but many of them don’t want to deal with having their own PMC.

The role of the PMCs is to ensure that the ASF guidelines on voting and culture are followed, to ensure that projects continue to be developed in a reasonable fashion, to help resolve conflicts, and to help take care of administrative or legal issues that might arise. The PMCs don’t determine the direction in which the software is developed. The members of the PMCs are drawn from the committers of the project or subprojects and are voted on by the existing members of the particular PMC.

The PMC for a particular project does most of its business in the project’s general mailing list ([e-mail], [e-mail], [e-mail]). The PMC also has a private mailing list, pmc@, which is used only for sensitive matters.

New Projects

The last issue we’ll address is the question of how new ASF projects (or subprojects) are created. It’s fairly common for groups of developers or a corporation to approach the ASF with the desire to start a project around some piece of code that has been developed.

Remember that the most important criterion the ASF uses in evaluating the proposed project is the health of its development community. After much experience, the ASF has learned that this is the key factor for success. If the project is a closed-source project that wants to become open source, as is often the case with a code base that has come from a company, then it’s very important to have a diversity of committers to the project. If the code base has been developed by a single person, there is a similar concern over the size of the community around the project. Neither of these issues is insurmountable, but if you want your project to be accepted by the ASF, you should be aware that these are among the most important issues.

New project proposals are sent to [e-mail]. The Apache Incubator project is designed to help new projects learn to function within the ASF framework. This includes following the voting guidelines, learning to work in an open community development style, and finding necessary resources and infrastructure within the ASF. The ultimate decision of whether a project is accepted for incubation is up to the ASF board or, if the new project would fall under the domain of one of the umbrella PMCs, the PMC for the appropriate project. If the board or the PMC decides to accept the project, then an ASF member is asked to help shepherd the new project through the incubation process. The project spends some time in incubation, learning to work in the Apache style, before leaving the incubator. The decision on whether a project is ready to leave incubation is a joint one, involving the members of the project, the ASF board or relevant PMC, and the Incubator PMC.