Open Source Charter

Muellners Foundation and its affiliate companies, subsidiaries and foreign branches including member bodies from Open Constitution Partner Program, independent data processors, makes use of and supports an ecosystem of open source technologies to deliver and maintain the digital public goods and services on the Open Constitution network.

Some of these services have a direct relationship with Foundation’s open source initiatives while other services have an indirect dependency over use of specific open source projects.
Some services may simply be part of third party maintained distributions, licensed under one of the open source licenses.(as indicated in the charter below)

You, or your here means

Natural Persons, and

Natural Persons affiliated to Legal Bodies, which are part of Open Constitution Partner Program.

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

Thank you for choosing to be part of our community at Open Constitution and its constituent registered agent or Fiscal Host legal bodies, founded by Muellners Foundation and its subsidiaries, affiliates and sister concerns performing economic activity as Muellners ApS(“Muellners”, “we”, “us”, or “our”).

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 Help Center.

A. List of open source projects:

A1. Supported/Assessed Third party Open Source Projects: (Since 2019)

(Note for editors to this section: Only those projects are listed below where Foundation maintains a Dedicated and Managed Services (post incubation stage).

A2. Foundation maintained open source projects:

(Note for editors to this section: List only those projects below which are post incubation stage.)

Read relevant open source licenses:

Few important open source(open source software) licenses that we often attribute our work to, either as part of existing licensing of an open source project or when we release fresh/re-engineered work into open source:

• Open Constitution license(under Public Review 2022-2023)

• MIT license

• Creative Commons license

• Mozilla Licenses

• AGPL and various versions of GNU GPL

• Apache Licenses

Note: Please refer to the open source license governing a specific project and a specific open source component of the project. You MUST abide by it as an extension to your adherence to this policy.

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 1: Machine instruction level

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

WORK 2: Primary Documentation on Foundation maintained open source project:

Creating and publishing documentation such as research papers, white papers on a part or whole of an open source projects(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, helpbook etc.

WORK 3: Derivative Documentation on Foundation supported open source project:

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

C. Who are the participants:

This policy and its contents apply to following participants and stakeholders:

1. Employees, Independent Contractors and service providers to the Open Constitution and its constituent registered agents or Fiscal Host bodies - including but not limited to Research and Development team, system engineers, Management, DevOps engineers, Product engineers and Researchers.

2. Natural persons who are Foundation's naturalised citizens, including but not limited to individual contributors, Learn fellowship members, Ambassador Council members, Fellowship Grant Recipients, officers and electoral appointees to the Open Constitution bodies e.g C.W.C, Open Council bodies, Board and Board committees.

3. Natural persons who are Voluntary Subscribers, who may or may not be affiliated to the Partner legal bodies as defined in Foundation's Open Constitution Partner Program, including but not limited to those subscribers, who become naturalised citizens of Foundation.

4. Partners of Open Constitution and its constituent registered agent or Fiscal Host bodies: Those who have received 'Technology & Service Delivery Discount' as per Muellners Foundation Pandemic Recovery based Social Discounting applicable to their service invoices, in the year 2020-2022.

5. Partners of Open Constitution 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 to the Open Constitution’s open source charter. This consent is taken electronically or through an Independent Contract between Muellners Foundation and partner legal body.

6. Members of other open source project maintainer organisations, interacting with Foundation's community as guests. Public(non confidential) exchange of information and which results in development of Intellectual property, specific to the said open source initiative.

7. All levels of Sponsors of Open Constitution and its constituent registered agent or Fiscal Host bodies: Those who have sponsored with paid or in-kind donation to promote open source work on one or many open source initiatives.

D. Producing Work as Open Source:

Work 1:

1. Code level changes go through open source project's community pull request mechanism as defined on the specific github repository by the Project C.W.C .

2. If the project is maintained by another maintainer organisation, Participants release the work from the Foundation's github source code to the maintainer organisation, according to maintainer organisation's stipulated contributions guidelines. For the Foundation supported open source projects, a periodical sync shall be in place between both upstream and Foundation's fork of source codes.

See an example of a github workflow on one of the open source repository.

Work 2:

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

2. Upon a peer review, work is then released with properly attributed open source license to various outlets of Muellners including but not limited to its Research publication site, Research blog.

Work 3:

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

2. Upon a peer review, work may be published irrevocably to various outlets of Muellners including but not limited to its Open Research portal, Research blog, under the applicable open source license.

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

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

Foundation supports open source projects and steers diverse case studies on these projects. At times, open source projects may not be well documented. Foundation then supports the open source project by maintaining and releasing a sectional or vertical documentation.

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 a derived work, it is created and maintained on the fork of a specific open source project, maintained as a Foundation's Github public repository. Foundation repository is public. Participants and stakeholders can pull the latest Work to their locally maintained source code branch, directly from Foundation's public release on its Github repository

Work is also contributed to upstream source code(if any) and participants should follow specific open source project's PR contribution mechanism in 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.

See an example of a github workflow on one of the open source repository.

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 Foundation's Github repository. If the Work is sizeable in nature, it may be released as a separate branch.

Participants and stakeholders can pull the latest Work to their locally maintained source code branch, directly from Foundation's public release on its Github repository.

In some cases, Work 2 and Work 3 may also be added to Github Readme file of both Foundation's public repositories or supported open source project's repository and such action will continue to abide by this 'Policy'.

F. Role of Gitbook and Atlassian Cloud.

Work 2 and Work 3 shall be documented, maintained and reducted to practice on Gitbook and Atlassian Cloud.

Gitbook change requests shall be used for tracking community peer review.

Atlassian Jira and Atlassian Confluence shall be used for tracking issue based work management and publishing literature.

G. Release and delivery of Work:

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

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

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 the Work 1 is released publicly and not directly to any single stakeholder's locally maintained repository or a computing resource.

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

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