๐Ÿ†“
Open Source Policy
This is the policy for 'Use of Open Source Systems' and 'Delivery of Services' on open source technologies. This policy governs the work by Muellners group, and its community members.
(Note for editors: This page and policy is scheduled to be updated upon the public release of MF license.)
Muellners Foundation and its affiliate companies, subsidiaries and foreign branches including members from Serenity Partner Program, independent data processors, use a series of open source technologies to deliver their services. Some of these services have a direct relationship with few open source initiatives while other services have an indirect dependency over use of specific open source projects.

Supported 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 dedicated more than 1000 human hours of documented research.)
Public Project
Governing License and Maintainer
Governing License for Foundation's Contributions
Apache Fineract
โ€‹Apache License 2.0 Apache Free Software Foundation
MF License
Mifos X
โ€‹Mozilla Public License Mifos Foundation
MF License
Foundation maintained open source projects: (Note for editors to this section: List only those projects below which are post incubation stage.)
Project Name
Governing License(s)
Project Governing Committee
โ€‹Finscaleโ€‹
MF License
Finscale CWC
Serenity
MF License
Serenity CWC
Open Podcast
MF License and Creative Commons License
Media Council
Fineract Support Wiki
โ€‹Finscale CWCโ€‹
Second.Exchange
MF License and Creative Commons License
Project CWC
Open Bulletin
MF License and Creative Commons License
Media Council
โ€‹Open Researchโ€‹
MF License and Creative Commons License
Steering Council

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:
โ€‹
  • Muellners Foundation license(under Public Review 2022)
  • MIT license
  • Creative Commons license
  • Mozilla Licenses
  • AGPL and various versions of GNU GPL
  • Apache Licenses
โ€‹
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 to your adherence to this policy.

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 OSS project:
Creating and publishing documentation such as research papers, white papers on a part or whole of an OSS 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 FOSS 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.

This policy and its contents apply to following participants and stakeholders:
  1. 1.
    Employees of Muellners - Research and Development team, system engineers, Management, DevOps engineers, Product engineers and Researchers.
  2. 2.
    Employees of Partners as defined in Foundation's Serenity Partner Program, including those who become naturalised citizens of Foundation.
  3. 3.
    Partners of Muellners Foundation: Those who have received 'Technology & Service Delivery Discount' as per Muellners Foundation Pandemic Recovery based Social Discounting applicable to their invoices.
  4. 4.
    Partners of Muellners: Those who have voluntarily given consent to merge their project delivery(either as a whole or in parts of their delivery) in open source. This consent is taken digitally or as part of an Independent Contract between Muellners and customer.
  5. 5.
    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 OSS initiative.
  6. 6.
    Foundation's naturalised citizens - individual contributors, CWC members, Open Council members, Learn fellowship members, Ambassador Council members, and Grant Receipents etc.
  7. 7.
    All levels of Sponsors of Muellners Foundation: Those who have sponsored with paid or in-kind donation to promote open source work on one or many OSS initiatives.
โ€‹

  1. 1.
    Code level changes go through OSS project's community pull request mechanism as defined on the specific github repository - Finscale and Serenity.
  2. 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 FOSS 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. 1.
    Well articulated, cited and referenced work is published after going through Foundation's community peer review mechanism.
  2. 2.
    Upon a peer review, work is then released with properly attributed OSS license to various outlets of Muellners including but not limited to its Research publication site, Research blog.
Work 3:
  1. 1.
    Well articulated, cited and referenced work is published after going through Foundation's community peer review mechanism.
  2. 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 OSS license.
  3. 3.
    Proper attribution to applicable FOSS 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. 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 FOSS projects and steers diverse case studies on these projects. At times, FOSS projects may not be well documented. Foundation then supports the FOSS project by maintaining and releasing a sectional or vertical documentation.

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. 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 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 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 FOSS project's repository and such action will continue to abide by this 'Policy'.

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.

For the above mentioned participants and stakeholders, following rules apply in connection with their compliance to this Open source policy of the Foundation:
  1. 1.
    Participants and stakeholders MUST abide by the specific OSS project's open source licensing in addition to this policy contents.
  2. 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. 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. 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. 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 FOSS project's minimum viable computing resources requirements.
  6. 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.
Also Read Acceptable Usage Policyโ€‹
Export as PDF
Copy link
On this page
A. List of open source projects:
B. Work includes the following:
C. Who are the participants:
D. Producing Work as Open Source:
E. Role of Github:
F. Role of Gitbook and Atlassian Cloud.
G. Release and delivery of Work: