🆓Open Source Policy
This is the Open Source Policy of the network.
UPDATED 08 Aug 2023
You, or your here means
Natural Persons, and
Natural Persons affiliated to Legal Bodies, which are part of Open Constitution Network Tenancy.
''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.
Muellners Foundation and its affiliate companies, subsidiaries and foreign branches including member bodies from the Open Constitution Network Tenancy Program, independent data processors, make use of and support 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 on the 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)
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 listed below where the Foundation maintains Dedicated and Managed Services (post-incubation stage)
| Third Party Project | Governing License and Maintainer | Governing License for Foundation's Contributions |
|---|---|---|
Apache Fineract | ||
Mifos X Community App | ||
Wordpress | GNU GPL v2 or later; WordPress Foundation | N/a |
WooCommerce | GNU GPL v3, Autommatic | N/a |
Moodle | GNU GPL | N/a |
A2. Foundation maintained open source service/distribution:
| Service | Governing License(s) | OC License Compatibility with | Project Governing Body |
|---|---|---|---|
Finscale Distribution | Apache 2.0, Mozilla Public License | Finscale CWC | |
Creative Commons | Media Council | ||
GNU GPL | Steering Council | ||
Creative Commons | Media Council | ||
GNU GPL | Treasury Council |
Read relevant OSS licenses:
A few important OSS(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:
Note: Please refer to the OSS license governing a specific project and a specific open-source component of the project. You MUST abide by it as an extension of 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
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 Foundation 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, helpbook etc.
WORK 3: Derivative Documentation on Foundation-supported FOSS project:
Creating and publishing 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:
Employees, Independent Contractors and service providers to the Open Constitution 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.
Natural persons who are the 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.
Natural persons who are Voluntary Subscribers, who may or may not be affiliated with the Network tenant legal bodies as defined in the Foundation's Open Constitution E Tenancy Program, including but not limited to those subscribers, who become naturalised citizens of the Foundation.
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.
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 with the Open Constitution’s open source charter. This consent is taken electronically or through an Independent Contract between the Muellners Foundation and an Open Constitution Network E Tenant.
Members of other open source project maintainer organisations, interacting with the Foundation's community as guests. Public(non-confidential) exchange of information which results in the development of Intellectual property, specific to the said OSS initiative.
All levels of Sponsors of Open Constitution and its constituent registered agent or Fiscal Host bodies: Those who have sponsored with a paid or in-kind donation to promote open source work on one or many OSS initiatives.
D. Producing Work as Open Source:
Work 1:
Code level changes go through the OSS project's community pull request mechanism as defined on the specific GitHub repository - e.g. Finscale.
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 the maintainer organisation's stipulated contributions guidelines. For the Foundation-supported FOSS projects, a periodical sync shall be in place between both the upstream and the Foundation's fork of source codes.
See an example of a GitHub workflow on one of the open-source repositories.
Work 2:
Well-articulated, cited and referenced work is published after going through the Foundation's community peer review mechanism.
Upon a peer review, work is then released with a properly attributed OSS license to various outlets of Muellners including but not limited to its Research publication site, Research blog.
Work 3:
Well-articulated, cited and referenced work is published after going through the Foundation's community peer review mechanism.
Upon a peer review, work may be published irrevocably to various outlets of Muellners including but not limited to its Open Research portal, and Research blog, under the applicable OSS license.
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 Foundation gives credit to the original creator.
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.
Muellners Foundation supports open-source projects and steers diverse case studies on these projects. At times, open-source projects may not be well documented. The Muellners Foundation then supports the open-source project by maintaining and releasing 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 OSS project, maintained as a Foundation's Github public repository. The 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 the specific OSS 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 repositories.
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 the 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 the 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 reduced 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, the following rules apply in connection with their compliance with this Open-source policy of the Foundation:
Participants and stakeholders MUST abide by the specific OSS project's open-source licensing in addition to this policy content.
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.
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.
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.
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.
Participants and stakeholders MUST agree that (in connection with clause 4 of this Section G), the Foundation will NOT deploy Work(both in parts or whole) to any local instance or locally maintained repository.
Also, Read the Acceptable Usage Policy
Last updated
