• 1 Workgroup Charter
  • 1.1 INTRODUCTION
  • 1.2 MISSION
  • 1.3 OBJECTIVES
  • 1.4 STRUCTURE AND LEADERSHIP
    • 1.4.1 CHAIR
    • 1.4.2 ELECTION COMMITTEE
    • 1.4.3 STEERING COMMITTEE
    • 1.4.4 PROJECT MANAGER / RELEASE MANAGER
  • 1.5 SUBPROJECTS
    • 1.5.1 TEAM LEADS
    • 1.5.2 LSB SUBPROJECT CONTRIBUTORS
    • 1.5.3 LSB SUBPROJECTS
      • 1.5.3.1 Written Specification
      • 1.5.3.2 Conformance Test Suite
    • 1.5.4 VIRTUAL SUBPROJECTS
      • 1.5.4.1 LSB Conforming Systems
      • 1.5.4.2 LSB Conforming Applications
  • 1.6 LSB CERTIFICATION SUPPORT
    • 1.6.1 Introduction
    • 1.6.2 Specification Authority
    • 1.6.3 Test Suite Maintenance Authority
  • 1.7 LSB Contributor
  • 1.8 COMMUNICATIONS
    • 1.8.1 Email correspondences
    • 1.8.2 Telephone conferences
    • 1.8.3 Workgroup meetings
  • 1.9 AMENDMENTS
  • 1.10 POLICIES

for the Linux Standard Base (LSB) Version 1.0 (Approved September 17, 2003)

The LSB Workgroup is a Linux Foundation (LF) project to develop, through consensus, a standard binary operating environment. The workgroup undertakes multiple interrelated projects managed together. Each LSB “project” (or release) delivers a set of specifications and software deliverables which support the deployment of that specification, such as conformance tests, development environment, and a sample implementation.

The mission of the LSB is to develop and promote a set of specifications that will increase compatibility among Linux distributions and enable conforming software applications to run on any compliant system. In addition, the LSB will help coordinate efforts to recruit software vendors to port and write products for Linux.

The LSB project seeks to develop behavioral standards for operating environments and applications using an open, consensus-based process. This process will include the following features:

• Conduct open meetings
• Publish decisions, meeting minutes and other processes
• Solicit public participation and comment, and respond to such in a fair, courteous manner
• Release documents and software deliverables under open, unencumbered licenses and copyrights
• Operate in a manner consistent with Linux Foundation policies and procedures
  

The LSB workgroup shall be led by an elected chair and governed by a steering committee.

The LSB overall project lead shall be known as the Chair. The chair is responsible for overall project coordination and for representing the LSB to the LF and to the community. This entails overseeing the production and dissemination of roadmap, budget, media, and collaboration.The chair has the following responsibilities and duties:

• Must conduct a workgroup telephone conference at least once per month
• Must conduct a face-to-face workgroup meeting at least once per year but not more than twice
• Must present a roadmap and budget to the workgroup and LF board once per year
• Act as the primary spokesperson for the LSB workgroup
• May nominate a project manager, release manager, and subproject team leaders

The chair is elected by the LSB contributors of the LSB workgroup. The chair's term of office is two years; there is no limit on the number of terms. The chair may be removed through a majority vote of no confidence by either the Steering Committee or the Linux Foundation board of directors.In the event the chair position becomes vacant, an election is to be conducted within 90 days. During the vacancy period, a steering committee member becomes the acting chair. The acting chair is chosen according to the following preference order: written specification lead; specification authority lead; futures lead; test suite maintenance authority lead; conformance test suite lead; sample implementation lead; development environment lead. Should one candidate decline to serve the choice falls to the next in the order: This list may be amended from time to time as the list of active subprojects changes.

An election for chair shall be administered by an ad hoc election committee of LSB contributors, which shall be appointed for this single purpose by the steering committee when the chair position becomes vacant or the term of office expires. The election committee shall have no less than two and no more than six members. The election committee is responsible for selecting one or more candidates for chair at least 30 days in advance of the election date. Election committee members may not be candidates in the election.The slate of candidates is subject to ratification by the Steering Committee.The election committee shall conduct the election via electronic ballot, using suitable means to assure only eligible voters cast a ballot, only one vote per voter is tabulated, and the votes are secret. The voting period shall be sufficiently long to allow a reasonable chance for all eligible voters to cast a ballot. The minimum voting period shall be one week. The election committee shall tabulate the votes and present the results to the steering committee.

The LSB Steering Committee is comprised of the chair and the subproject team leaders, and any other LSB contributor the chair feels strongly should be on the committee. Any of the LSB steering committee members may represent the LSB as a spokesperson. Steering committee members may serve indefinitely as long as they are actively conducting business in the best interest of the LSB. Steering committee members may be removed on a majority vote of no confidence by the steering committee. Individuals may serve as team lead for more than one subproject, but this shall in no event entitle them to more than a single vote on the steering committee. The steering committee shall have a minimum of three members; if there are not sufficient team leaders then the chair shall solicit a general member of the LSB workgroup to fill out the steering committee. A majority vote from the LSB steering committee is required to commence or conclude work (i.e., draft specifications), or make resolutions. A quorum of 50% of the sitting members of the steering committee is required for a valid vote. No interest group (i.e., company or organization) may cast a majority of the votes.

If the LSB chair deems necessary, he may appoint a Project Manager and/or Release Manager to manage an LSB release of the specification and certification materials. The Project Manager and/or Release Manager position does not confer a steering committee seat.

The steering committee may choose to form and disband subproject teams as needed to carry out the purposes of the workgroup. LSB subprojects operate with a reasonable degree of independence, and make their own choices about details of the subprojects. However, they must coordinate with the chair to insure consistency with the objectives of the overall LSB project and that deliverables align with overall project needs.

A subproject shall be coordinated by a team leader. Team leaders are nominated by the chair and approved by a majority vote of the steering committee. Team leaders have a vote in the steering committee. It is permitted for one individual to be team leader for more than one subproject. The team lead shall be responsible for assuring that team activities are conducted in an open manner consistent with LSB guidelines, including but not limited to documenting decisions, tracking issues to resolution using a publicly accessible issue tracking system, maintaining project source code in a publicly accessible repository, conducting meetings, causing meeting notes or minutes to be published, and soliciting participation and input into the activities of the subproject from affected parties.

Individuals are known as LSB subproject contributors if they meet the LSB contributor requirements. A majority vote of LSB subproject contributors is required to commence or conclude work, or make resolutions in a subproject. No interest group (i.e., company or organization) may cast a majority of the votes.

A complete set of subprojects is not defined by this charter. The following subprojects are required:

Responsible for developing and maintaining the LSB specifications.

Responsible for developing and maintaining the LSB conformance test suite.

In order to providing voting representation to key constituencies,the steering committee may create virtual subprojects by a 2/3 majority vote. A virtual subproject has no specific deliverable under this charter and exits as a vehicle to provide a steering committee vote. Virtual subprojects may select a team leader who shall be a member of the steering committee, so long as the subproject has at least two members with LSB Contributor status. The following virtual subprojects are required.

Representatives of producers of current or intended LSB conforming systems, often referred to as “distributions”.

Representative of developers of current or intended LSB conforming applications.

The Linux Foundation operates certification programs to assure conformance with LSB specifications. It contracts with an outside agency which shall be known as the Certification Authority (CA) to administer the program. The CA itself is not part of the LSB project and does not vote on LSB decisions.The terms of the contract with the CA will describe the manner of formal interaction with the LSB project. The contact will channel through named groups. These groups are subsets of LSB subprojects and are not to be considered separate LSB subprojects for purposes of steering committee membership.

The Specification Authority (SA) is a contractually required contact with the CA for problem resolution. The SA is organizationally a task of the written specification subproject, but operates independently and meets as needed to carry out its purposes.The SA is responsible for reviewing and providing final resolution of all Problem Reports (PR) and resolution of appeals of prior resolutions as forwarded from the CA within the timelines and procedures set forth in the contract.The SA is also responsible for preparing the final submission to the steering committee of new candidate specifications from the written specification team; this involves conducting the public review and resolving issues raised by that process. In resolving issues, the SA may direct the written specification team to modify the specification.The SA is responsible for assuring that all logged LSB specification issues from the CA, the Test Suite Maintenance Authority, or from public reviews or public bug submissions are resolved in a timely manner. The SA shall make the results available through the CA issue tracker in the case of CA PRs, and through a publicly accessible LSB issue tracker for all others.

The Test Suite Maintenance Authority (TSMA) is a contractually mandated contact with the CA for test suite problem resolution. The TSMA is organizationally a task of the conformance test suite subproject, but TSMA operates independently and meets as needed to carry out its purposes.The TSMA is charged with resolving Test Suite Deficiencies (TSD) with the SA and the CA within the timelines and procedures set forth in the contract.The TSMA is also responsible for administering the release of new maintenance and enhancement test suite releases.The TSMA is responsible for assuring that all logged LSB test suite issues from the CA, SA, or from public reviews or public bug submissions are resolved in a timely manner. The TSMA shall make the results available through the CA issue tracker in the case of CA PRs, and through a publicly accessible LSB issue tracker for all others.

An LSB contributor is eligible to elect or be elected as the LSB workgroup chair, or serve on the ad hoc workgroup chair election committee.Anyone may be considered a contributor in the LSB meritocracy if they have cumulated twenty or more valid points according to the following table.

A contribution is a submission that results in an addition, change, or improvement to the specification or other project deliverables.The chair may grant voting contributor status to individuals who do not meet the above requirements. A contributor can be expelled from the group by the SC for being partisan in forcing an agenda. Expulsion may consist of loss of voting status up to and including loss of access to LSB resources such as CVS commit privileges, mailing list subscriptions, etc. The circumstances of such an expulsion shall be documented in steering committee records, but need not be published in a public forum.

Each subproject is to have an email distribution list which is archived.

Each subproject is to hold at least one telephone conference bi-monthly (at a minimum; monthly is preferred). The meeting notice should be announced at least three business days in advance. A recurring meeting with a regular meeting time and callin information does not require a separate announcement for each meeting date. Ideally, there should be an agenda posted prior to the meeting, and meeting minutes with attendance and action items recorded should be published on the website.

The LSB workgroup is to hold at least one, but not more than two physical meetings per year. The LSB chair shall arrange the meeting details, give notice in appropriate forums, and publish an agenda. At least sixty calendar days meeting notice is required to allow participants time to arrange travel schedules. Meeting minutes with attendance and action items recorded shall be published on the LSB website.

The LSB Charter may be amended by a two-thirds majority vote of the steering committee, and approval of the LF board of directors.

From time to time the steering committee may enact policies to guide the operations of the workgroup. These policies will be published on the LSB website at http://www.linuxbase.org/policy/.