Open Source Policy

Summary: The policy outlines the definitions of various participants and stakeholders, including natural persons, third parties, and entities affiliated with Open Constitution AI Network. It also details the licensing requirements for accessing different types of content on the CouncilPost platform. Additionally, it describes the process for producing work as open source and provides guidelines for using GitHub in relation to open-source code. The policy emphasizes compliance with specific OSS project licenses and rules regarding the release and delivery of work by participants and stakeholders. Participants are required to follow these rules when contributing to or utilizing open-source work on the CouncilPost platform.

You, or your here means

Natural Persons, and

Natural Persons affiliated to Legal Bodies, which are part of Open Constitution AI Network AI Network Tenancy.

''Third Party'' here means an affiliated object of observation, maintained by a Legal Body, outside the ownership control of Open Constitution AI Network and its constituent fiscal host bodies e.g Muellners CouncilPost.

Thank you for choosing to be part of our community at CouncilPost.

We are committed to open source best practices and benchmarking commercial open source standards. If you have any questions or concerns about our Open Source Policy, or our practices, please raise a ticket at Open Constitution AI Network AI Governance Center.

Read relevant OSS licenses:

A few important OSS(open source software) licenses that CouncilPost association often attributes the platform re-engineering to, either as part of existing licensing of an open source project, third party Intellectual property compatibility or when we release re-engineered work into open source:

• Open Constitution AI Network AI license

• MIT license

• Creative Commons license

• Mozilla Licenses

• AGPL and various versions of GNU GPL

• Apache Licenses

Note: Please refer to the OSS license attributed to a specific FOSS IP component of the CouncilPost platform. You MUST abide by it as an extension of your adherence to this policy.

A. CouncilPost Platform IP Lifecycle Case:

A1.

A2. Content published on the CouncilPost platform uses AI, augmented by human editors in feedback loops on peer-reviewed open research.

The service name, media type, and governing license for beneficiary access to this content, powered by the Open Constitution AI Network IP pool, is described in the table below:

Accessing the CouncilPost platform via a machine entity:

A government member, public body or any organisational tenant may need to access the CouncilPost platform through a machine-to-machine interaction for beneficiaries affiliated with them:

B. Work includes the following:

Work Contributions include but are not limited to bug reports, issue triage, code, documentation, leadership, business development, project management, mentorship, and design. Work is recognized when the contributions are made through the contributor license clarification mechanism, set up on the CouncilPost platform through an OAuth mechanism.

WORK 1: Machine instruction level

At the application level, source code changes, including system re-engineering, functional and non-functional re-engineering, and API-level developments, are defined in any of the projects listed above.

WORK 2: Primary Documentation on CouncilPost maintained OSS project:

Creating and publishing documentation such as research papers and white papers on a part or whole of an OSS project (both engineered or re-engineered), including but not limited to technical architectural diagrams, workflow diagrams, generic business logic documentation, wiki, support forum documentation, assist documentation, help book etc.

WORK 3: Derivative Documentation on CouncilPost-supported FOSS project:

Create and publish baseline documentation on independently engineered components, including but not limited to wiki, support forum documentation, technical architectural diagrams, assist documentation, helpbook, etc.

C. Who are the participants:

HELP TEXT: This policy and its contents apply to the following participants and stakeholders:

1. Employees, independent contractors, and service providers are part of the Open Constitution AI Network and its constituent registered agents or fiscal host bodies, including but not limited to the Research and Development team, system engineers, Management, DevOps engineers, Product engineers, and Researchers.

2. Natural persons who are CouncilPost Association members, including but not limited to individual contributors, Learn fellowship members, Ambassador Council members, Fellowship Grant Recipients, officers and electoral appointees to the Open Constitution AI Network bodies, e.g. C.W.C, Open Council bodies, Board and Board committees. All Open Constitution AI network E residents in the EU automatedly receive membership to the CouncilPost Association.

3. Natural persons who are voluntary subscribers may or may not be affiliated with the Network tenant legal bodies as defined in the Open Constitution AI Network E Tenancy Program, including but not limited to those subscribers, affiliated to E-tenant and who become naturalised citizens of the Open Constitution AI Network.

4. Open Constitution AI Network and its constituent registered agent or Fiscal Host bodies: Those who have voluntarily provided consent to merge their project delivery(either as a whole or in parts of their delivery) in accordance with the Open Constitution AI Network’s open source charter.

5. All levels of Sponsors to Open Constitution AI Network: Those who have sponsored with a paid or in-kind donation to promote open source work on one or many OSS initiatives, and where the grants are tracked through the Open Treasury.

D. Producing Work as Open Source:

Work 1:

1. Code level changes go through the OSS project's community pull request mechanism as defined on the specific GitHub repository - e.g. CouncilPost Journal, CouncilPost Media APIs, CouncilPost Content Processors.

Work 2:

1. Well-articulated, cited and referenced work is published after going through the CouncilPost's community peer review mechanism.

2. Upon peer review, work is then released with a properly attributed OSS license, depending on the type of Research.(ref: IP clarification tables above)

Work 3:

1. Well-articulated, cited and referenced work is published after going through the CouncilPost's community peer review mechanism.

2. Upon a peer review, work may be published irrevocably, including but not limited to its CouncilPost Journal, under the applicable OSS license.

3. Proper attribution to the applicable open source license of the maintainer organisation is required while releasing the work, regardless of whether the license is required to do so. This ensures that the CouncilPost gives credit to the original creator.

4. Primarily, Work 3 shall be released as per statement 2. Participants may choose to release the work according to the maintainer organisation's stipulated community guidelines.

E. Role of Github:

GitHub is home to a great deal of open-source code that we release. Because GitHub is a third-party site, we have a few requirements and pieces of guidance concerning its use. They are to ensure we use the service in a way that makes sense to all of us. This ensures our code is healthy and secure.

When Work 1 is derived, it is created and maintained on the fork of a specific OSS project, maintained as a CouncilPost's Github public repository.

CouncilPost platform repositories are public. Participants and stakeholders can pull the latest Work to their locally maintained source code branch directly from the CouncilPost's public release on its GitHub repository.

Work is also contributed to upstream source code(if any), and participants should follow the specific OSS project's PR contribution mechanism when opening a pull request. Members should ensure that successful approval takes place, including but not limited to integration tests.

Members should ensure that PR does not go stale due to inactivity. If a PR does not reach any conclusion, members should close the PR and open another one.

When Work 1 is an independently engineered component(Not a derived work), it is created and maintained on an independent project fork.

Any Work is then pushed to a successful public release on CouncilPost's Github repository. If the Work is sizeable, it may be released as a separate branch.

Participants and stakeholders can pull the latest Work from their locally maintained source code branch directly from the CouncilPost's public releases on the platform components and their GitHub repository.

In some cases, Work 2 and Work 3 may also be added to the GitHub Readme file of both CouncilPost's public repositories.

G. Release and delivery of Work:

For the above-mentioned participants and stakeholders, the following rules apply in connection with their compliance with this Open-source policy of the CouncilPost:

1. Participants and stakeholders MUST abide by the specific OSS project's open-source licensing in addition to this policy content.

2. Participants and stakeholders MUST abide by the Section: Role of Github for transitional delivery of Work 1, whether it is sponsored or pro bono in nature.

3. Participants and stakeholders MUST abide by the Section: Role of Gitbook for transitional delivery of Work 2 and Work 3, whether it is sponsored or pro bono in nature.

4. Participants and stakeholders MUST agree that Work 1 is released publicly and not directly to any single stakeholder's locally maintained repository or computing resource.

5. Participants and stakeholders MUST agree that the release of Work 1 is not subject to any local installation requirements but is prepared in close connection with the FOSS project's minimum viable computing resources requirements.

6. Participants and stakeholders MUST agree that (in connection with clause 4 of this Section G) the CouncilPost will NOT deploy Work(in part or whole) to any local instance or locally maintained repository.