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.

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.

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.

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.

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.

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.