Open Source Policy

The developers at FINN.no are encouraged to use open source software. We benefit from freedom to review the source code, fix errors, and improve the code. Active participation in the open source community is valuable not only to FINN's employees, public image, hiring, and karma; it also improves the source code and adds value for everyone.

All changes we make to an open source project must be committed back to the project. Changes to open source code that are deemed unsuitable for sharing must lead to a design review. This design is strongly recommended to be changed in order to be more suitable for contribution back to the project.

FINN encourages publishing of open source code. This leads to:

• Better code quality
• Higher developer competence
• Positive FINN branding
• Easier reuse of software across Schibsted

Code written by employees at FINN on company time belongs to FINN and cannot be freely distributed without permission. Consider the size and scope of the code, and consult with your nearest leader or the Enterprise Architect group. The EA group may escalate to the Chief Technology Officer (CTO). An overview must be maintained in each repository. This overview must contain:

• A primary maintainer / owner in the README
• Names of the involved employees in the README
• A brief description of the project (typically a URL) in the README
• Which licence the code is published under in the LICENSE file

The maintainer of the project must

• Answer pull requests and issues
• Decide if the project is maintained or should be archived
• Keep the code and libraries up to date

To be published, code must bring value to:

• FINN
• The Open Source community

When forking an external project, the fork should be made in FINN’s organization only if we intend to maintain the fork. If the fork is made only for submitting a fix, the fork should be made on the user’s own profile. Published code must NOT:

• Contain business critical information
• Breach contracts or agreements between FINN and FINN's users or customers
• Contain information that may lead to weakened integrity for FINN's users or customers
• Contain information that may lead to weakened security of FINN's data, users, or customers

Published code must have at least one maintainer at FINN. The maintainer must show the project love. If the maintainer stops loving their project, or leaves FINN, the maintainer must either find a replacement maintainer (not necessarily within FINN), or declare the project inactive/end-of-life/dead. FINN should have a process (preferably automated) to catch projects where the maintainer is no longer associated with FINN. Smaller projects should be published under the FINN organization on GitHub (https://github.com/finn-no). Larger projects consisting of multiple repositories may be candidates for separate organizations, with a clear reference to FINN.no.

Code must be published under licences approved and deemed popular by OSI (www.opensource.org). The licence must not hinder FINN's opportunities to further develop the code so that a later version cannot be published. Normally, code shall be published under MIT. If the project incorporates FINN branding elements like color schemes, fonts and logos, use the Apache License 2.0.

FINN is positive towards monetary sponsoring of open source projects. Decisions to sponsor (and the exact sum to sponsor with) must be determined on a case-by-case basis by the Technology Leader Group (TLG).