This document defines the guidelines of the Globus Alliance and its projects. It includes definitions of the various categories of membership, who is able to vote, how conflicts are resolved by voting, and the procedures to follow for proposing and making changes to the Globus codebase. Each individual project may adopt additional guidelines, which may extend but not supersede these Globus Alliance guidelines.
The document comprises ten sections, as follows:
- Roles and Responsibilities: Defines the recognized roles in Globus
- Communication: Defines how users and developers communicate.
- Decision Making: Defines how action items are proposed and voted on.
- Source Repositories: Defines how Globus source code is organized and developed, including Licensing agreements.
- Globus Management Committee Bylaws: Defines the roles and responsibilities of the Globus Management Committee.
- Globus Philosophy: Some comments on the principles that govern Globus projects.
- The Globus Incubator: Describes how new projects are created.
- Other Globus Entities: Defines various committees important to Globus development.
- Globus Intellectual Property: Describes who controls Globus intellectual property.
- About these Guidelines: Describes how these guidelines were derived.
This is a living document. Changes can be made by a 3/4 vote of the Globus Management Committee, after discussion on the General mailing list.
Credits: These guidelines are derived directly from those of the Jakarta project and (for items 6-8) the Apache project within which Jakarta lives, although with some modifications to reflect specific properties of the Globus community. Thanks to Jakarta and Apache for the effort they have put into developing and documenting their processes!
Roles and Responsibilities
The roles and responsibilities that people can assume in Globus are based on merit. Everybody can help no matter what their role. Those who have been long term or valuable contributors to Globus obtain the right to vote and commit directly to the source repository.
Users are the people who use the products of Globus. People in this role are not contributing code, but they are using the products, reporting bugs, making feature requests, helping other users, extending the online FAQ, and such like. This is by far the most important category of people as, without users, there is no reason for Globus. When a user starts to contribute code or documentation patches, they become a Contributor.
Contributors are the people who write code or documentation patches or contribute positively to Globus in other ways, for example by being active on the developer mailing list, participating in discussions, and/or providing suggestions or criticism.
Projects should recognize contributions from volunteers by adding their names to a list of contributors (e.g., on the project wiki or web page, in a text file with the source code). Maintaining an author list in the source code files is discouraged since it can discourage those not listed from contributing.
Contributors who give frequent and valuable contributions to a project of Globus can have their status promoted to that of a “Committer” for that project. A Committer is a Contributor who has been given write access to the source code repository for that project and has a signed Contributor License Agreement (CLA) on file. A Committer gains voting rights allowing them to affect the future of the project.
In order for a Contributor to become a Committer, another Committer can nominate that Contributor or the Contributor can ask for it. Once a Contributor is nominated, all of the Committers for a project will vote. If there are at least 3 positive votes and no negative votes, the Contributor is converted into a Committer and given write access to the source code repository for that project. Before receiving write access, a Committer must also affirm that they have read and understood these guidelines, and agree to abide by their terms, as they may be revised from time to time.
At times, Committers may go inactive for a variety of reasons. A Committer that has been inactive for six months or more may lose his or her status as a Committer. This is typically done through a vote on the mailing list. Any changes in committers should be reported by the chair to firstname.lastname@example.org
A list of our current Committers can be found in our Globus Credits, and the list of Committers for each project can be found on the individual project wiki pages.
Each Globus project is required to name a project Chair via some process defined by the project’s Committers. A project Chair has no enhanced authority, but has certain responsibilities relative to the function of the Globus Alliance. Specifically:
- The Chair should generate, on or before March 31st, June 30th, September 30th, and December 31st of each year, reports concerning the activities of the project during the past quarter, its current status, and future plans.
- The Chair is responsible for forwarding to the Globus Infrastructure group requests to add or delete Committers for the project.
Globus Management Committee
Committers who frequently participate with valuable contributions may have their status promoted to that of a “Globus Management Committee Member.” This committee is the official managing body of the Globus Alliance and is responsible for setting overall project direction.
Globus obtains its strength from the communication of its members. In order for members to easily communicate with each other, Globus has a variety of mailing lists. These lists, with the exception of the announcement lists, are not moderated and anybody is more than welcome to join them. However, you must be subscribed to post to a list.
To reduce the bandwidth demands on everyone, mail should not contain attachments. It is recommended that you place interesting material (such as patches) either within the body of the message or provide a URL for retrieval.
Each project is responsible for its own project website. Projects are also encouraged to use:
- Bugzilla for recording and tracking requirements, plans, and bug reports (and fixes)
- A shared chat room, such as an IRC channel or a jabber room. (Having a “room” in which developers can hang out and users can ask questions has proven incredibly valuable on a number of open source projects.)
- Their area in the Globus Wiki.
See Globus Infrastructure for more details on these and other infrastructure components.
To join the mailing lists, see our Mailing List page.
The following email lists are provided for each project:
- [announce] is a low traffic list, designed to communicate important information, such as final releases of a project’s code, to a wide audience.
- [user] is for users of a Globus product to converse about such things as configuration and operations.
- [dev] is for the contributors to the project. On these lists suggestions and comments for code changes are discussed and action items are raised and voted on. For the developer community, these lists are the center of Globus, where all the “action” is.
- [commit] is where all CVS code commit messages are sent. All committers are required to subscribe to this list so that they can stay aware of changes to the repository.
Globus also hosts some Globus-wide mailing lists:
- [announce] is a moderated mailing list where announcements of releases or major Globus events are made.
- [general] is the Globus-wide mail list used to discuss issues that touch that entire Globus community.
Projects are normally auto governing and driven by the people who volunteer to do the work. This is sometimes referred to as "do-ocracy" -- power of those who do. This functions well for most cases.
When coordination is required, decisions are taken with a lazy consensus approach: a few positive votes with no negative vote is enough to get going.
In the rare event that the Committers to a project cannot agree, the Globus Management Committee works to resolve the deadlock.
Action items include the following:
- Long Term Plans - No vote required.
- Short Term Plans - No vote required.
- Release Plan - Lazy majority vote on each issue, or lazy consensus if issue involves a product change.
- Release Testing - No vote required, once Release Plan is approved.
- Public Release - Majority vote, if no showstoppers are listed in the status file.
- Showstoppers - Lazy consensus until resolved and removed from status file.
- Product Changes - Lazy consensus.
Long Term Plans
Long term plans are simply announcements that group members are working on particular issues related to the Project. These are not voted on, but Committers who do not agree with a particular plan, or think that an alternative plan would be better, are obligated to inform the group of their feelings.
Short Term Plans
Short term plans are announcements that a volunteer is working on a particular set of documentation or code files with the implication that other volunteers should avoid them or try to coordinate their changes.
A release plan is used to keep all volunteers aware of when a release is desired, who will be the Release Manager, when the repository will be frozen to create a release, and other assorted information to keep volunteers from tripping over each other. Lazy majority decides each issue in a release plan, or lazy consensus if the issue involves a product change.
After a new release is built, it must be tested before being released to the public. After the release plan is approved, the Release Manager will announce that a product is ready for testing.
Once the Release Manager determines that testing is complete, and all showstoppers for the release have been resolved, the Release Manager shall call for a vote on the public release. Majority approval is required before the public release can be made. The Committers who approve a public release (vote +1) are expected to provide ongoing support for that release while it is current. The Release Manager must summarize the outcome of the vote before the public release becomes final.
Showstoppers are issues that require a fix be in place before the next public release. They are listed in the status file in order to focus special attention on these problems. An issue becomes a showstopper when it is listed as such in the status file and remains so by lazy consensus.
Changes to the products of the Project, including code and documentation, will appear as action items in the status file. All product changes to the currently active repository are subject to lazy consensus.
Action Item Votes
The act of voting on an action item carries obligations. Voting members are not only stating their opinion, they are also agreeing to help do the work.
Any Contributor or Committer (“member”) may call for an action-item vote on the Developer mailing list. It is preferred that a vote be preceded by a formal proposal offered for discussion purposes. The message announcing a vote should contain a Subject beginning with “[VOTE],” and a distinctive one-line summary corresponding to the action item for the vote.
Each vote on an action item can be made in one of four flavors:
- +1 "The action should be performed, and I will help."
- +0 "Abstain," "I support the action but I can't help."
- -0 "Abstain," "I don't support the action but I can't help with an alternative."
- -1 "The action should not be performed and I am offering an explanation or alternative."
Votes cast by the project's Committers are considered “binding.” When needed, at least three binding +1 votes are required for action-item approval.
An action item may need one of two types of approval:
- Consensus approvalAn action requiring consensus approval must receive at least three binding +1 votes and no binding vetos.
- Majority approvalAn action requiring majority approval must receive at least three binding +1 votes and more +1 votes than -1 votes.
Except for a public release, all action items are considered to have lazy approval until somebody votes -1, at which point the action item is converted to a formal consensus or majority vote, depending on the type of action item.
Note: "Lazy" means the action item has immediate tacit approval, and it is not necessary to tally the vote until a -1 reply is posted. Once a -1 reply is posted, the vote must be tallied and reported before the action item is considered approved. All action-item votes are lazy except for a public release vote.
Any member may vote on any action item or related issue. When voting on an action item, the project's Committers may also include the word "binding" next to their vote, to simplify a tally if it is needed. All binding vetoes must also contain an explanation of why the veto is appropriate.
Note that the rules require that a negative vote include an alternative proposal or a detailed explanation of the reasons for the negative vote. The community then tries to gather consensus on an alternative proposal that resolves the issue. In the great majority of cases, the concerns leading to the negative vote can be addressed. This process is called "consensus gathering" and we consider it a very important indication of a healthy community.
- A +1 vote regarding product code can only be made binding if the voter has tested the action on their own equipment.
- A binding +1 vote on a public release means the project's Committer agrees to provide ongoing support for that release while it is current.
- An abstention may have detrimental effects if too many people abstain.
- Vetoes with no explanation are void. If you disagree with the veto, you should lobby the person who cast the veto. Voters intending to veto an action item should make their opinions known to the group immediately so that the problem can be remedied as early as possible.
- If a Committer believes the explanation for a veto is invalid, an affirmation of the veto can be requested. If some other Committer does not affirm that the explanation for the veto is valid, the veto shall be void.
- If a dispute over a veto becomes intractable, the GMC may consent to arbitrate the matter, and, if appropriate, rescind the veto with a 3/4 majority vote of the GMC members.
- Members who wish to discuss a vote before replying, may open another thread to help avoid premature vetos. Any +/-1s or +/-0s posted to an alternate thread, or any other thread not labeled "[VOTE]", are considered conversational, and do not qualify as an valid action-item vote. A "lazy item" remains subject to lazy approval until a valid -1 reply is posted to the "[VOTE]" thread.
Most action items are subject to lazy approval, and do not require the posting of a formal result.
However, any other majority item that receives any -1 reply (later rescinded or not) must be followed by a "[VOTE-RESULT]" message before the action item is considered approved. Likewise, any consensus item that receives any binding veto must post a "[VOTE-RESULT]" message summarizing the result, and show that each veto was rescinded, before it is considered approved. In either case, the member who requested the vote should also post the result within 120 hours (5 days). Any question regarding the outcome of an action-item vote may be referred by a Committer to the GMC for arbitration.
A Public Release is not considered approved until the Release Manager posts a followup message with the legend "[VOTE-RESULT]" summarizing the replies.
Proposals are not a formal action item; however, the message offering a proposal should contain a Subject beginning with "[PROPOSAL]". It is strongly recommended that a proposal be circulated before calling for a formal vote. Often, once members have had the chance to critique a proposal, an updated copy of a proposal can be reposted as the vote document.
Most other messages posted to the Developer's List usually involve either short-term or long-term plans. Often, a long-term plan will be made in the form of a "[PROPOSAL]". If appropriate, the proposed change or feature may then be entered to the project's STATUS file or TODO list.
Voting on other matters
There are other matters upon which members will vote that do not involve action items. The same general voting structure is used in these cases, except that the "flavors" are taken to mean
- +1 "Yes," "Agree,"
- +0 "Abstain," "No opinion."
- -0 "Abstain," "Unsure."
- -1 "No," "Disagree."
In any software development project there is a natural tension between revolution and evolution. Many software development teams, open or closed, have a team leader who can declare whether the code base is in evolutionary or revolutionary mode. In a volunteer meritocracy, this type of decision is difficult to make and impossible to enforce. Our meritocracy is fueled by voluntary contributions, and so we must allow everyone to contribute, and then base our final product decisions on the contributions we actually receive.
Accordingly, as a matter of Globus policy, these principles are adopted:
- Every committer has the right to revolution. Anyone can establish a branch or separate whiteboard directory in which to experiment with new code separate from the main trunk. The only responsibility a committer has when they do this is to announce their short and long range plans, and allow others who want to help to do so. Committers working on a revolutionary branch have the right to develop their approach free of interference.
- When a revolution is considered ready for prime time, the committer(s) shall propose a merge to the developers list. At that time, the overall community evaluates whether or not the code is ready to become part of, or to potentially replace, the trunk. Suggestions may be made, changes may be required. Once all issues have been taken care of and the merge is approved, the new code may become the trunk.
- All development branches should be unversioned. No branch, evolutionary or revolutionary, should have any official version standing. This allows several parallel tracks of development to occur with the final authority of what eventually becomes the trunk resting with the entire community of committers.
- The trunk is the official versioned line of the project. All evolutionary minded people are welcome to work on it to improve it. Evolutionary work is important and should not stop as it is always unclear when any particular revolution will be ready for prime time or whether it will be officially accepted.
The Project's codebase is maintained in shared information repositories using CVS on the globus.org machine. Only Committers have write access to these repositories. Everyone has read access via anonymous CVS.
All contributions must adhere to Globus Conventions and Guidelines as revised by the GMC from time to time.
License and Contributor Agreements
Our ability to distribute the Globus Toolkit software freely and others' ability to use the software without restriction both require that we address some legal concerns. The central issue is that we must establish clearly our right to distribute all contributions, so that neither we nor our users are at risk of subsequent legal action. Thus:
- All source code committed to Globus repositories must be covered by the Apache License or contain a copyright and license that allows redistribution under the same conditions as the Apache License.
- We require contributors to establish our legal right to distribute the software without constraint by signing either the individual or corporate license agreement:
A full description of the licensing process can be found in Licensing and Contribution Guidance.
In addition, all source files (for code or documentation) must contain copy right information - simply cutting and pasting the below text is suitable.
/* * Copyright 1999-2006 University of Chicago * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */
Each of Globus’ active source code repositories contains a file named STATUS that is used to keep track of the agenda and plans for work within that repository. The STATUS file includes information about release plans, a summary of code changes committed since the last release, a list of proposed changes that are under discussion, brief notes about items that individual volunteers are working on or want discussion about, and anything else that may be useful to help the group track progress. Active STATUS files are automatically posted to the corresponding Developer mailing lists three times per week.
Groups are allowed to create a branch for release cycles, etc. They are expected to merge completely back with the main branch as soon as their release cycle is complete.
A branch is considered "evolutionary" by lazy consensus. Upon any dispute (binding veto), a branch must be converted to "revolutionary" status, and must be assigned a working name that does not imply it will be the next version of the product. Once a release plan for the branch has been approved, and the proposed release is ready for testing, it may be assigned a version name reflecting it is a product release candidate, and merged back with the main branch, as appropriate to the circumstances. Any branch, "evolutionary" or "revolutionary", shall meet the same standard for release approval.
Simple patches to fix bugs can be committed then reviewed. With a commit-then-review process, the Committer is trusted to have a high degree of confidence in the change.
Doubtful changes, new features, and large scale overhauls need to be discussed before committing them into the repository. Any change that affects the semantics of an existing API function, the size of the program, configuration data formats, or other major areas must receive consensus approval before being committed.
Related changes should be committed as a group, or very closely together. Half complete projects should never be committed to the main branch of a development repository. All code changes must be successfully compiled on the contributor's platform before being committed. This includes XML code that is used to build documentation.
The current source code tree for a project should be capable of complete compilation at all times. However, it is sometimes impossible for a contributor on one platform to avoid breaking some other platform when a change is committed. If it is anticipated that a given change will break the build on some other platform, the committer must indicate that in the commit message. A committed change must be reversed if it is vetoed by one of the voting members and the veto conditions cannot be immediately satisfied by the equivalent of a "bug fix" commit. The veto must be rescinded before the change can be included in any public release.
When a specific change to a product is proposed for discussion or voting on the appropriate development mailing list, it should be presented in the form of input to the patch command. When sent to the mailing list, the message should contain a Subject beginning with [PATCH] and a distinctive one-line summary corresponding to the action item for that patch.
The patch should be created by using the diff -u command from the original software file(s) to the modified software file(s). For example:
diff -u Main.java.orig Main.java >> patchfile.txt
cvs diff -u Main.java >> patchfile.txt
or (on Win32) you can use WinCVS for a nice GUI or you can install Cygwin which will enable you to use the bash shell and also installs a lot of other utilities (such as diff and patch) that will turn your PC into a virtual Unix machine.
All patches necessary to address an action item should be concatenated within a single patch message. If later modification to the patch proves necessary, the entire new patch should be posted and not just the difference between the two patches.
Globus Management Committee Bylaws
Globus was first established as an open source software project in 1996. Since that time, the Globus development team has expanded from a few individuals to a distributed, international community. In response to this growth, the Globus community (named the “Globus Alliance" since 2001) established in October 2005 a new source code development infrastructure and meritocratic governance model, which together make the process by which a developer joins the Globus community both easier and more transparent.
These bylaws formalize the roles and responsibilities of the Globus Management Committee (GMC) and other participants.
The GMC is responsible for the strategic direction and overall success of the Globus Alliance, through its projects and products. Globus is a meritocracy, and decision making is delegated to the project Committers whenever possible.
Responsibilities of the GMC include:
- the active discussion of Project issues, strategic direction, and forward progress,
- the consideration and approval of new projects,
- retiring inactive projects and Committers as necessary,
- arbitrating otherwise intractable disputes regarding project voting and vetos,
- the security and reliability of the Globus Web site, mailing lists, code repositories, and related services,
- legal issues involving Globus and its projects, and
- maintaining scope for Globus and its projects
The GMC shall conduct as much business as possible on the Globus General mailing list. Sensitive business may also be conducted on the closed GMC mailing list if prudent. The GMC may also convene regular meetings with a majority of its members attending. These meetings may take place online, via teleconference, or via other means deemed effective by the GMC. The GMC shall post a regular status report to General list, along with minutes of any “off-list” meetings.
Only a GMC member may call for a vote of the GMC or cast a binding vote on a GMC matter.
The voting pool is based on the current GMC membership and voting is performed according to the voting procedures. All GMC members are expected to formally vote or abstain when a vote is called. GMC members who continually fail to vote or otherwise participate may lose their GMC status.
Most GMC actions require a “super-majority vote,” where at least 3/4s of the current GMC members must cast a positive vote for the action to be approved. When computation of 3/4s of the current membership does not produce a whole number, the result shall be rounded the nearest whole number (.5 and higher rounds up).
The term of the GMC Chair is one year. The election of the Chair may take place on the Globus General list or at another meeting with a majority of GMC members in attendance. The Chair is elected by a simple majority of GMC members. All GMC members are expected to vote or to formally abstain. If a tie vote cannot be otherwise resolved, there shall be a simple majority vote of the project Committers on the General mailing list.
The Chair may resign as Chair at any time without resigning membership to the GMC. The Chair may be re-elected to a subsequent term. The exiting Chair retains GMC membership status.
There is no term limit for GMC members. The list of current GMC members is to be maintained in the Globus Project Credits. All GMC members should be active Committers to one or more Globus projects (preferably more).
GMC members may resign at any time. Any member may be removed from the GMC by a super-majority vote of the GMC members.
A project Committer may be nominated for the GMC by a current GMC member. Nominees should realize that participation in the GMC requires a regular and sustained commitment of their time, and is not to be taken lightly. A nominee becomes a GMC member by a successful super-majority vote.
Creation of Projects
GMC members may propose the creation of new projects (via Incubator) and request the evaluation of promotion of projects from Incubator to full Globus project status by the IMP. This is part of the normal Incubation process.
A project that is no longer supported by a dedicated group of committers can be designated deprecated.
There is no "Philosophy Committee." However, we applaud and embrace the following set of six principles advocated by Apache:
- collaborative software development
- commercial-friendly standard license
- consistently high quality software
- respectful, honest, technical-based interaction
- faithful implementation of standards
- security as a mandatory feature
It is our intent that all Globus projects share these principles.
The Globus Incubator
In order for new projects to be created, Globus has a project called the Incubator Management Project (IMP) (http://dev.globus.org/wiki/Incubator/Incubator_Management ) that is responsible for helping new efforts to join the Globus Alliance. The full Incubation process is detailed at http://dev.globus.org/wiki/Incubator/Incubator_Process .
Since the meritocratic rules operate across Globus bottom to top, it is vital for the long-term stability of such a form of government, that the initial set of committers has to know very well the dynamics of such a system, as well as share the same philosophical attitude toward collaboration and openness that Globus expects from its projects.
The IMP is responsible for:
- filtering the proposals about the creation of a new project
- helping the creation of the project and the infrastructure that it needs to operate
- supervising and mentoring the incubated community in order for them to reach an open meritocratic environment
- evaluating the maturity of the incubated project, either promoting it to official project status or by retiring it, in case of failure.
Note that the IMP (just like the GMC) does not perform filtering on the basis of technical issues. This is because Globus respects and suggests variety of technical approaches. It does not fear innovation or even internal confrontation between projects which overlap in functionality.
The IMP filters projects on the basis of the likeliness of them becoming successful meritocratic communities. The basic requirements for incubation are:
- a working codebase—the Apache experience emphasizes that without an initial working codebase, it is generally hard to bootstrap a community. This is because merit is not well recognized by developers without a working codebase. Also, the friction that is developed during the initial design stage is likely to fragment the community.
- the intention to donate or license copyright of the software and the intellectual property that it may contain to Globus—this allows Globus to obtain an irrevocable and permanent right to redistribute and work on the code, without fearing lock-in for itself or for its users.
- an active developer community, and potential user community.
The incubation period normally serves to estimate whether or not the project is able to increase the diversity of its committer base and to play within the meritocratic rules of Globus. This might seem rather easy to achieve, but it must be remembered that in a volunteer and highly selective environment, attracting new committers is not automatic.
Diversity of committership is important for two main reasons:
- it gives long term stability to the project development: in fact, with all the developers affiliated to the same entity, the chance of seeing all of them moving away from the project at the same time is much greater than with a community of individuals affiliated to unrelated entities.
- it gives a greater variety of technical visions: something that guarantees a better adherence to environment and user's needs, thus a higher chance of finding real-life use of the software.
Details of the Incubation process can be found at http://dev.globus.org/wiki/Incubator/Incubator_Process .
Other Globus Entities
After infrastructure and incubator, the foundation hosts several other entities, more or less formalized, open to GMC members and to invited experts or individuals, that do not directly create code but serve specific purposes.
Conference Organizing Committee
The Conference Organizing Committee (aka ConCom) is responsible for the organization of Globus developer events.
The Security Committee is responsible for the handling of potential security holes in the software produced by the foundation that might impact our users. It gets contacted by the finders of the problems before the problem report is made available to the public, to allow the projects to provide a fix in time for the report, thus reducing vulnerability to a minimum. Refer to Security Committee Vulnerability Handling for the process involved in handling the reported vulnerabilities.
Public Relations Committee
The Public Relations Committee is responsible for public relations, including issues regarding management of the Globus brand, and for press-related issues like press releases for major Globus events or dispatching requests for interviews.
The Licensing Committee is responsible for the legal issues associated with licensing and license compatibilities and for the revision of the Globus License
Globus Intellectual Property
For historical reasons, there are some decisions concerning “Globus” over which the Globus Alliance has no direct control, namely its intellectual property. For completeness, we detail here how this intellectual property is managed.
- “Globus,” “Globus Toolkit,” and “Globus Alliance” are all registered trademarks held by the University of Chicago, which thus has the right to decide who can use them and for what purpose. Thus, any organization wanting to use these trademarks to refer to a product needs to obtain written permission from the University of Chicago.
- The Globus Alliance guidelines require that all code included in the Globus repository be either owned by the University of Chicago, or licensed to the University of Chicago under a license that allows the University of Chicago to redistribute that software as open source.
It may be that at some point in the future, it will be desirable to negotiate the transfer of Globus intellectual property to an independent “Globus Foundation.” However, we emphasize that the University of Chicago has always acted as a responsible steward for Globus intellectual property.
About these Guidelines
This section explains how these guidelines were derived from the Jakarta and Apache guidelines.
Sections 1-5 of these guidelines are based closely on the Revised Apache Jakarta Project Guidelines; Sections 6 (Philosophy), 7 (Incubator), and 8 (Other Entities) are based on the corresponding items in the Apache Guidelines.
Jakarta is one of several projects within the Apache Software Foundation (ASF), a legal entity that exists primarily to (a) manage intellectual property such as the Apache trademark and software and (b) provide legal protection to ASF members when acting in an official capacity. ASF structure and policies are described in their bylaws; see also “How the ASF Works.”
We modify the Jakarta structure and policies as follows:
- The project name is Globus, and globus.org is the location for all code and documentation.
- There are no equivalents to the Apache Board and Apache Software Foundation. Instead, the Globus Management Committee (GMC) has ultimate decision making authority.
- Globus code and documentation are either (a) owned by the University of Chicago or (b) owned by other contributors who have signed a contributor’s license allowing the University of Chicago to distribute the code/documentation as part of Globus.
- Globus is not a legal entity, and thus provides no legal protection to Globus users or developers. With respect to (3) and (4), there are certainly good arguments to be made for establishing a “Globus Foundation” as a legal entity that would own Globus IP and provide legal protection to Globus “officers.” However, there are also arguments against such a step. Thus we defer such a move to the future. We also adopt two components that are not internal to Jakarta but defined within Apache:
- We introduce a process similar to the Apache Incubator for developing new projects. (This project is responsible for shepherding new projects and determining whether those new projects are suitable for inclusion in Globus. Criteria include such things as the size and diversity of the contributor base.)
- We introduce a conference committee, security committee, public relations committee, and licensing committee, again similar to those defined within Apache.