License Consistency Working Group Charter

Accepted by the Board, June 16, 2023

This WG is currently in the Formation phase

The purpose of the License Consistency Working Group (LCWG) is to evaluate whether there are licenses currently listed on the OSI website as approved licenses that should no longer be considered OSI-approved licenses. The WG will identify and evaluate the impact on all stakeholders of changing license status or labeling, develop criteria for identifying inconsistent licenses, recommend courses of action to the Board, and finally, should action on one or more licenses be recommended, create a list of licenses on which action is to be taken.

Inconsistent licenses are ones where there is some reason to re-evaluate whether they should continue to be considered valid and approved open source licenses. Most of these will be from the early years of the OSI. It will be a one-time reassessment of the currently approved licenses and is neither a review of all OSI licenses nor a process for “challenging” licenses.

Membership

The WG will be made up of three to six members of the active OSI community. This panel should include individuals who have broad knowledge of open source and non-open source licenses. If possible, the WG should contain at least one lawyer, one software developer, and one member of the board. The WG will choose a Chair from the involved Board members.

Board member Josh Berkus will launch the WG by making a recruitment announcement on Board and License-Discuss lists, as well as sharing it in other locations OSI members frequent.  After 1-3 weeks, Berkus will select a likely WG membership and present it to the board for approval.

If any WG member resigns or fails to regularly participate before the WG's work is complete, the Chair may select a replacement member, subject to ratification by the Board. The Chair may also remove a member who is not performing useful work, subject to ratification by the Board.

Work

The Working Group will perform its work over the course of approximately one year.  This work will mostly be performed asynchronously, using a new mailing list, as well as other online work tools as appropriate (such as the wiki, Github, and GoogleDocs). All WG work products will be public, unless there is a reason why some specific work product must be kept confidential.

The WG will also have regular status meetings, and periodic online work sessions.

Data for this work will come from the work performed by OSI's archival contractor, as well as OSI's various online materials, public and private. The WG will directly collaborate with the contractor and other OSI staff.

The work will be performed in three phases, with some overlap between them.

Criteria Phase

During the Criteria Phase, the WG will develop a set of criteria according to which a license may be judged inconsistent and subject to review.  Such criteria could include elements such as:

• License was never actually expressly approved by the Board
• License does not meet our current understanding of the OSD
• License does not appear to have ever been used

It will be up to the WG to develop the specific set of criteria and methods of determination and review. These may also result in the creation of more than one "class" of inconsistent licenses.  Wherever possible, specific criteria and classes should be illustrated with examples from our actual license archives.

Once the WG has developed a draft set of criteria, they will be presented to the Board for discussion, revision, and approval.

Policy Phase

Once initial criteria are approved by the Board, the WG will develop a set of recommendations for how inconsistent licenses should be handled by the organization. This will include making recommendations on:

• Whether some licenses need to be re-reviewed by the current Board.
• Whether some licenses should be marked as non-open-source, and if so, how.
• Whether some licenses should be marked as otherwise not recommended, and if so, how.
• How the OSI should communicate changes of license status to users and the public.
• How status change decisions should be documented.
• Who should carry out different possible actions.

Policy and action recommendations will be based on an analysis of its impact.  To support this, the WG may need to do research or conduct interviews with users and developers.

Based on the criteria, the WG may need to make other policy and process recommendations. Once the WG has a set of recommendations, they will be presented to the Board for discussion and approval.

Review Phase

Once the outputs of Phase 1 (criteria) and Phase 2 (policy) are approved, the WG will review potentially inconsistent licenses based on the work of the archiving intern and OSI materials.  They will assemble a list of licenses and the criteria by which they were judged inconsistent for submission to the Board. The Board will review, and may authorize action on a license-by-license basis. Depending on the Policy recommendations, the WG may carry out some of these actions.

Once the WG has reviewed all potential inconsistent licenses currently existing, and any required follow-up actions have been carried out, the WG's effort will be completed and it may disband.