You are here

Project Governance

The FOSSology Governance model is based on the Meritocratic Governance model used by the Apache Software Foundation as described at OSS Watch.

FOSSology® Governance Document – July 15, 2016

0. Overview

FOSSology® is an open source project with the mission of advancing open source license compliance.

FOSSology is an open source license compliance software system and toolkit. As a toolkit you can run license, copyright and export control scans from the command line. As a system, a database and web user interface are provided to give you a compliance workflow. In one click you can generate an SPDX file, a Debian copyright file, or a ReadMe with the copyrights notices from your software. FOSSology deduplication means that you can scan an entire distro, submit a new version, and only the changed files will get rescanned.

FOSSology operates much like a meritocratic, consensus-based community project[1]. Anyone with an interest in the project can join the community, contribute to the project, and participate in the decision making process. This document describes how that participation takes place and how to set about earning merit within the project community.

1. Roles and responsibilities

1.1. Community

The FOSSology Community consists of those companies, individuals, or groups who use the FOSSology toolkit or system. They are important members of the community and without them the project would have no purpose. Whether as individuals or as part of an organization, FOSSology users want to improve their ability to comply with open source licenses.  That said, anyone can use FOSSology; and there are no special requirements.

The project asks its users to participate in the project and community as much as possible. User contributions enable the project team to ensure that they are satisfying the needs of those users. Common user contributions include:

  • using FOSSology toolkit to describe the content and licensing of their software

  • using the FOSSology system to review and clear their code for release

  • use FOSSology to create SPDX files for your favorite open source projects

  • submit bug reports/code contributions to the tools following the development process set in place

  • adding license texts, which are not yet in the FOSSology database

  • evangelizing about FOSSology (e.g. giving a talk at a conference, a link on a website, writing an article in a (online) journal, and word-of-mouth awareness raising)

  • informing developers of strengths and weaknesses from a new user perspective

  • providing moral support (a 'thank you' goes a long way)

  • potentially providing financial support (currently FOSSology operates with no budget, but it may eventually need one)

Users may be interested in being on the fossology@fossology.org mail list and participating in IRC channel to monitor the progress of the project.  Community members may also join as FOSSology developers and help improve the tools.

1.2. Developers

Developers are community members who contribute in concrete ways to the FOSSology code, documentation and web site.    Anyone can become a Developer.  

Although there is no concrete expectation of participation, Developer contributions are what enables the FOSSology project to move forward and progress. Participation can take many forms but could include:

  • contact the Steering Committee members, get briefed on the current state of affairs, and where help is needed the most.

  • join the fossology-devel@fossology.org mailing list and participate in the discussions.

  • Participate discussion on the github issues and github pull requests.

  • submit fixes and new features to FOSSology code repositories.

  • submit documentation improvements to the WIKI to help others use FOSSology.

  • submit bug reports/code contributions to the tools following the development process set in place.

  • create content for FOSSology: papers, web site improvements, blogs, etc.

There are no specific skill requirements and no selection process. Anyone can join  simply by signing up for the fossology-developer mailing list.   Permissions will be granted to the git repositories and WIKIs after sustained, high quality contributions.

1.3. Steering Committee

The Steering Committee is made up of Community members or Developers with a sustained contribution over time, and recognized as interested in the long term health of the project. Members of the Steering Committee recommend and appoint new members. A nomination for a new Steering Committee member will result in discussion and then a vote by the existing Steering Committee members. Steering Committee membership votes are subject to consensus approval of the current Steering Committee members.

The Steering Committee is responsible for the smooth running of the FOSSology project and coordinating activities between the Developers and the Community. In addition, Steering Committee members are expected to make substantial contributions to the FOSSology project. Contributions may include amongst other activities:

  • developing new features and fixing issues in the tool.

  • outreach and education to help individuals and companies understand how to use and contribute to FOSSology

  • participating in strategic planning, such as coordinating face-to-face meetings, planning releases or suggesting and approving changes to the governance model

  • responding to specific issues or concerns above and beyond the domain of the various teams   

Steering Committee members will be removed from the committee if they resign, or if they are inactive in participating and contributing to the project for more than 6 months.  

The Steering Committee will make decisions when Community consensus cannot be reached. In addition, the Steering Committee may maintain a private mailing list (fossology-steering@fossology.org)  and archives steering. This list is used for sensitive issues, such as steering committee membership votes and legal matters that cannot be discussed in public. It is never used for project management or planning.

2. Support

All participants in the Community are encouraged to provide support for new users within the project infrastructure. This support is provided as a way of growing the Community. Those seeking support should recognize that all support activity within the project is voluntary and is therefore provided as and when time allows. However, for those willing to engage with the project on its own terms, and willing to help support other users, the fossology@fossology.org mailing list is ideal.

3. Contributions

There are many ways to contribute as per above. Contributions to the tools, website, and any other contribution to the FOSSology project are governed under the relevant licensing guidelines and terms of use of the FOSSology website.

4. Decision making process

Decisions about the future of the project are made with the Developers through discussion with all members of the team who wish to participate in the discussion, from the newest Developers to the most experienced Steering Committee member. All non-sensitive project management discussion takes place in team meetings and on the fossology-devel@fossology.org mailing list.

In order to ensure that the project is not bogged down by endless discussion and continual voting, the project operates a policy of lazy consensus. This allows the majority of decisions to be made without resorting to a formal vote.

4.1. Lazy consensus

Decision making typically involves the following steps:

  1. Proposal
  2. Discussion
  3. Vote (if consensus is not reached through discussion)
  4. Decision

Any team member can make a proposal for consideration by the Community. In order to initiate a discussion about a new idea, they should send an email to fossology-devel@fossology.org or enter the idea into the FOSSology issue tracker. This will prompt a review and, if necessary, a discussion of the idea. The goal of this review and discussion is to gain approval.

In general, as long as nobody explicitly opposes a proposal, it is recognized as having the support of the Community. This is called lazy consensus - that is, those who have not stated their opinion explicitly have implicitly agreed to the implementation of the proposal.

Lazy consensus is a very important concept within the project. It is this process that allows a large group of people to efficiently reach consensus, as someone in support of a proposal need not spend time stating their position, and others need not spend time reading such mails.

For lazy consensus to be effective, it is necessary to allow at least two weeks before assuming that there are no objections to the proposal. This requirement ensures that everyone is given enough time to read, digest, and respond to the proposal. This time period is chosen so as to be as inclusive as possible of all participants, regardless of their location and time commitments.

4.2. Voting

Not all decisions can be made using lazy consensus. There will be some issues about which there is legitimate disagreement that must be resolved by a vote. For these issues, a member of the Steering Committee (issue lead) will initiate a vote via the fossology-devel@fossology.org  email list and will specify a date by which the Developers must vote via the list, allowing a minimum of one week for deliberation. Every member of the Community is encouraged to express their opinion. The issue lead will determine the result by a simple majority of those who voted. If for any reason the FOSSology Developers cannot resolve an issue, they may invoke the assistance of the Steering Committee to resolve.

4.3. Changes in Governance

Changes in governance are handled as follows: Any Developer or Steering Committee member may propose changes to the governance model by submitting a proposed update to the language in this document to the Steering Committee. Within one week of receipt of the proposal, the Steering Committee will designate one of its members to handle the issue and will distribute the proposal for comment on the fossology-developers mailing list. Within three weeks of the distribution, the Steering Committee appointee will convene a General Meeting to discuss. The change may be accepted or rejected by consensus, but if consensus is not reached, the appointee will put the matter to a vote via the General Mailing list allowing two weeks for response. A vote to change the governance model requires a 2/3 majority of those who vote and approval of the Linux Foundation.

5.  Additional Provisions

Participants in the FOSSology Project agree to comply with the terms of the FOSSology Governance, to the license terms of the project, and with all such policies as the Linux Foundation Board of Directors may from time to time adopt with notice to participants.   All participants shall abide by The Linux Foundation Antitrust Policy available at http://www.linuxfoundation.org/antitrust-policy.  All participants shall encourage open participation from any organization, regardless of competitive interests. Put another way, the Steering Committee shall not seek to exclude members based on any criteria, requirements or reasons other than those used for all members.