Open Source Usage and Delivery Policy

This is the usage policy for 'Use of Open Source Systems' and 'Delivery of Services' on open source technologies. This policy governs the work of both Muellners Foundation and Muellners Inc.

Date Updated: 22.07.2020

Muellners and its affiliate companies, subsidiaries and foreign branches including its Non-Profit Foundation uses 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 initiatives.

A. List of open source projects:

  1. Apache Fineract(earlier Mifos X)

B. OSS licenses to follow:

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 our inclination to release fresh/re-engineered work into open source:

  1. Apache Licenses

  2. AGPL and various versions of GNU GPL

  3. Mozilla Licenses

  4. Creative Commons license

  5. MIT license

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

C. 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. These have been divided into following three types:

  1. Code level changes including system re-engineering, functional and non functional re-engineering, API level developments.

  2. Creating and publishing documentation such as research papers, white papers on OSS projects including but not limited to technical architectural diagrams, workflow diagrams, generic business logic documentation etc.

  3. Creating and publishing baseline documentation on engineered and re-engineered components of an existing OSS project including but not limited to wiki, support forum documentation, technical architectural diagrams, assist documentation, helpbook etc.

D. Who are the participants:

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

  1. Muellners' Research and Development team, system engineers, Management, DevOps engineers, Product engineers and Researchers.

  2. Partners as defined by Muellners Partner Management Desk.

  3. Customers of Muellners: Those who have got 'Technology & Service Delivery Discount' as per Muellners Foundation social discounting applicable to their invoices.

  4. Customers 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 via an email confirmation on tools available on Muellners Development Portal.

  5. Specific OSS initiative's community members interacting with Muellners team with non confidential exchange of information and which results in development of Intellectual property, specific to the said OSS initiative.

  6. Fellows of 'Learn Programme' by Muellners Foundation.

  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.

E. Releasing Work as Open Source:

Work 1:

  1. Code level changes go through OSS project's community pull request mechanism.

  2. Participants release the work according to OSS project's stipulated community guidelines.

  3. Work is approved and merged into OSS project's source code by the maintainers of the said OSS project.

  4. Proper attribution as per compliance to applicable OSS license is required while releasing the work.

Work 2:

  1. Well articulated, cited and referenced work is first published as a draft in Muellners internal document management system. This activity is powered by GSuite & Google For Non Profits association to Muellners Foundation.

  2. Upon a peer review approval, 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, social media sites and its Development Management Portal.

Work 3:

  1. Well articulated, cited and referenced work is published and goes through OSS project's community peer review mechanism.

  2. Participants release the work according to OSS project's stipulated community guidelines.

  3. Work is approved and may be published irrevocably to various outlets of Muellners including but not limited to its Research publication site, Research blog, social media sites and its Development Management Portal.

  4. Proper attribution as per compliance to applicable OSS license is required while releasing the work

F. 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 you and ensures our code is healthy and secure.

  1. Work is created on the fork of specific OSS project, maintained at Muellners Github repository. This may be a public or a private repository depending on the nature of confidentiality involved in the process & proposed timeline of delivering the work.

  2. Work is then pushed to a successful release on Muellners Github repository. If the Work is sizeable in nature, it may be released as a separate branch.

  3. Work is then released in the community and follows specific OSS project's PR mechanism. Upon successful approval which includes but not limited to integration tests, peer reviews and community's approvals, Work is then stated to be released in open source.

  4. Participants and stakeholders can pull the latest Work from the community's latest release.

  5. Participants and stakeholders can also pull the latest Work directly from Muellners Github repository to their locally maintained source code branch.

  6. Participants and stakeholders have to follow the baseline documentation of the Work that is released alongside the work in open source.

  7. In some cases, Work 2 and Work 3 may also be added to Github Readme file of both Muellners repositories or specific OSS project's repository and such action will continue to abide by this 'Policy'.

G. Rules governing direct delivery of Work:

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

  1. Participants and stakeholders MUST abide by the specific OSS project's open source licensing in addition to Muellners Open source usage and delivery policy.

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

  3. Participants and stakeholders MUST agree that the Work 1 is not released directly to their locally maintained repository.

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

  5. Participants and stakeholders MUST agree that (in connection with above point 4 of Rules governing direct delivery of work), Muellners will NOT deploy Work(both in parts or whole) to a local instance or locally maintained repository of specific OSS project. The release of Work MUST always abide by Section E above.

  6. Participants and stakeholders must agree that Work 2 and Work 3 may be released directly to their locally maintained resource. A download from one of the Muellners outlet or the specific OSS project's site hosting Work 2 and Work 3 will be considered as a direct release.