|
|
||
|---|---|---|
| .gitignore | ||
| LICENSE | ||
| platform-2025.md | ||
| README.md | ||
Shared Platform for OSI Reform
Item 1: Repeal the Open Source AI Definition (OSAID)
We commend the OSI leadership and staff for addressing the controversial topic of “Open Source AI”. Nevertheless, the OSI's push to adopt its Open Source AI Definition (OSAID) has been a mistake. The OSI acted too quickly to impose an overly ambitious policy compromise on the community. OSAID undeniably created a rift in the FOSS community; that rift seriously damaged the OSI's reputation, authority and influence. Meanwhile, OSAID shows no signs of having any positive policy influence on machine learning practitioners, the FOSS community, or regulators.
If elected, we endeavor to persuade the OSI to acknowledge this error and repeal OSAID. We are not dogmatic on this point; we are open to a compromise that recharacterizes the elements of OSAID as a nonbinding and preliminary set of recommendations.
OSI should also commit to a substantial period of time for careful study and ongoing community discussion — perhaps as long as 5 or 10 years — before adoption of a formal definition of "Open Source AI".
Item 2: Adopt a process for formal review of previously approved licenses
Review and approval of license submissions remains a core part of OSI's mission. Supervision of this process by the outgoing License Committee chair (Pam Chestek) has been outstanding. Nevertheless, a deficiency remains: throughout its nearly 30 years of existence, OSI never adopted any procedure for reviewing or appealing past license approvals by the Board.
This is not theoretical. Some licenses approved in OSI's earliest years were likely not conformant to the OSD even at the time of approval. Some other approved licenses are no longer compatible with software freedom or do not reflect the FOSS community's present-day values and principles.
We propose that OSI adopt a formal procedure enabling community members to initiate review of an approved license to ensure that it meets the OSD and assures software freedom. We are open to the form this would take. For example, the OSI could convene a separate, impartial body (perhaps initially led by the outgoing License Committee Chair) charged with a careful, deliberate and de-politicized reexamination of sufficiently-dated license approvals challenged by members of the Open Source community.
Item 3: Remove “code of silence” from Board Member Agreement
OSI's Board Member Agreement states that:
Directors can expect each other to Disagree during Board deliberation but support publicly all Board decisions, especially those that do not have unanimous consent.
New Directors are required to formally bind themselves to this Agreement.
While obviously well-intentioned, the quoted provision goes too far. Under it, Directors agree to a code of silence — a self-imposed gag order covering all issues (great and small) for which the Board did not have unanimous consent. We insist that this provision be reformulated with less sweeping and more conventional language, for the following reasons:
-
It conflicts with transparency and democratic values which are core to the mission of any FOSS nonprofit.
-
Director candidates are permitted to run on platforms (like this one) that oppose current, standing decisions of OSI's Board. It seems ridiculous to require newly elected Directors to immediately (and perhaps permanently) cease discussing their platform with the public and their own electoral constituency.
-
The provision's temporal reach appears to stretch 27 years into the past, and probably for the lifetime of a Board member into the future.
-
A Director's duty of care and loyalty may sometimes require them to be a public whistleblower.
-
We are unaware of any other nonprofits (including but not limited to FOSS nonprofits) that impose any equivalent code of silence on their Directors.
Item 4: Directors should be allowed to use FOSS for Board activities
The OSI leadership has told candidates for the 2025 Board elections:
OSI board activities require the use of proprietary software and agreeing to Google's terms of service.
This is profoundly wrong on multiple levels. A FOSS organization should not make service as a Director contingent on a willingness to agree to proprietary licenses.
We are not demanding that OSI immediately cease use of proprietary software; we know well the complicated challenges and tradeoffs regarding proprietary vs. FOSS usage. But it is entirely reasonable to expect OSI to accommodate individual Directors and staff who refuse to agree to proprietary terms of service and opt against use of proprietary software in their FOSS volunteer efforts.