Open Source Rules and Strategy

1. Purpose
2. Contact
3. Project Publication Process
4. Rules

Purpose

These open source rules aim to make your OSS efforts more sustainable and successful by reinforcing development habits that improve our software, coding literacy, and craftsmanship. The rules offer guidance and clarify expectations regarding project quality, security, compliance, and usefulness beyond FREE NOW (see also our OS philosophy/principles in Appendix 1). They also aim to protect FREE NOWs competitive advantage (see Appendix 2).

Contact

Please contact the FREE NOW Open Source Review Group for open source related questions and suggestions. For more details on how FREE NOW organizes open source, see Appendix 3.

Project Publication Process

To publish your project on GitHub.com, please follow these steps:

1. Read all of these rules and make sure your project complies with them.
2. Email the Review Group about your project with the following information:
   • Project name and link
   • Do you plan to promote your project internally and externally, to build a community of users and contributors?
   • Does this project have any internal FREE NOW dependencies? (If “Yes,” stop here.)
   • Who is your target audience?
   • How many hours per week will you devote to maintaining and growing the project?
   • What does this project solve for potential users, and how is it different (better, faster, simpler) than existing solutions?
   • Did you requested internal feedback?
3. The Review Group will review your project and offer feedback and guidance to support your publication bid.
4. The Review Group might ask you to present your project, but in most cases will request information over email/Slack.
5. For your project to go live, you must receive the following approvals from the Review Group: security, code quality, documentation, and agreement that the project does not risk our competitive advantage.
6. Upon receiving the Review Group’s approval, you can push your project to the [FREE NOW organization](https://github.com/FREE NOW).

Rules

All open source projects published MUST comply to rules 1-9. Non-compliant projects must be deleted from github.com. To publish a new project, you MUST also follow rules 10.

1. All projects MUST include an MAINTAINERS file listing at least two active maintainers by name and contact email.

2. You MUST create a meaningful README.

3. You MUST include a CONTRIBUTING.md guidelines file.

4. You MUST create a license file and state that the Apache 2.0 license applies to all code owned by FREE NOW. If you use third-party OSS, you MUST only use license-compatible projects/software. You MUST honor the original licenses used in those third-party projects in the license file.

5. You SHOULD semantically version project artifacts. You MUST tag all versions in GitHub with the exact version name: e.g., 0.1.0.

6. You SHOULD sign every commit.

7. You MUST create a SECURITY.md file in the main root folder of your repository.

8. Your repositories MUST NOT, at any time, include FREE NOW specifics such as credentials and private identifiers.

9. You SHOULD review all merge requests for implanted security backdoors and vulnerable code fragments regardless of who is making the pull request. User impersonation is easy.

   In addition to the above rules, the following also govern new open source projects you wish to publish on a FREE NOW-owned GitHub organization.

10. You MUST create an entirely new Git repository before pushing the project to GitHub.

Appendix

1. Appendix 1: Philosophy/Principles
2. Appendix 2: Potential risks to FREE NOW’s competitive advantage
3. Appendix 3: How FREE NOW organizes open source
4. Appendix 4: Apache 2.0 license
5. Appendix 5: How to honor non-FREE NOW third-party OSS components
6. Appendix 6: Why you must create a new repo

Appendix 1: Philosophy / Principles

OSS development is integral to our engineering practices and culture for these reasons:

• Facilitates skills acquisition (coding, communication, project management, product mindset) that benefits internal and personal development.
• Engages highly skilled external contributors who improve our software quality and relevance.
• Brings about knowledge exchange and innovation through collaborative partnerships with other companies.
• Sends a positive “giving back” massage to a community upon which we rely.
• Implicitly shows developers why working for FREE NOW will be an enriching and challenging experience, and therefore serves as a highly authentic “employer branding” asset.

Appendix 2: Potential Risks to FREE NOWs Competitive Advantage

Anything that risks FREE NOWs competitive advantage is not permissible for publication on github.com. This typically means technologies we build that are intrinsic to generating or reinforcing the uniqueness of our customer experience. This could include (but is not limited to):

• Confidential source code
• Allocation algorithms
• Internal data-sets

We advise you to take a conservative approach and reach out to our Legal team for any ambiguous cases.

Appendix 3: How FREE NOW organizes open source

Currently the OSS Review Group is in a growing phase. We are actively seeking members for our OSS Review Group. Processes are not yet in place. The list below is merely a seed to grow on.

What the OSS Review Group does:

• Purpose:
  • Guide FREE NOW technologists to create high-quality projects that meet our standards.
  • Offer peer review and feedback.
  • Develop policies and processes that reinforce open source development based on quality, end-to-end ownership, broad usefulness, and innovation as key values.
• Responsibility:
  • Meet every quarter to approve/reject projects awaiting public release.
  • Manage all FREE NOW GitHub organizations. The group has the right to remove non-compliant projects from GitHub.
• Membership:
  • Membership Process: Please mail the OSS Review Group if you would like to become a member.

Appendix 4: Apache 2.0 License

Include the LICENSE file in the root folder of your repository. Replace the [yyyy] field with the year that you created the project, and do not update it. Do not provide multiple years.

Appendix 5: How to honor non-FREE NOW/third-party OSS components

Copyleft: Copyleft is a legal obligation that FREE NOW must fulfill when you modify and/or distribute and/or make third party material publicly available (so-called “copyleft trigger”).

Examples: changing the program code, uploading to public GitHub, sending it to someone else from another company. Copyleft may oblige FREE NOW to license its modifications also under the license whose copyleft was triggered. In legal terms, “modification” can be interpreted very broadly—e.g. whole libraries or code that you added (so-called “scope of copyleft”).

For Modification + Internal and/or Publishing, do not use reciprocal licenses that trigger the copyleft already during internal modification—e.g. RPL or APSL 2.1, AGPLv3.

For Modification + Publishing:

• See above (RPL, ASPL 2.1, AGPLv3, etc.).
• Do not use licenses with strict copyleft, e.g. GPLv2, GLPLv3, unless you have clearance from Legal.
• If you use licenses with limited copyleft (e.g. LGPLv2.1, LGPLv3, MPLv2, CPL), please make sure you can fulfill their specific requirements to restrict the copyleft from taking over FREE NOW’s or other third-party’s code. → reach out to Legal.

License Template for Multi-Licensed Projects without Copyleft

“This {name} Project is in general licensed under the following Apache 2.0 license except the files named underneath (see corresponding notice files below)

(Insert FREE NOW Apache 2.0 from Appendix 4 above)

Notice file for (path)/(other file)

(Insert license text & copyright notice from the original file here)

Notice file for (path)/(other file)

(Insert license text & copyright notice from the original file here)

(…)