1. Introduction

1.1. too long; didn’t read (TL;DR)

1.2. Goals

The document should support and enable "permissionless innovation" (ask for forgiveness, not permission) as we want to foster a new default to openness at Baloise.

Despite widespread use, there are still many misconceptions and uncertainties for Baloise employees engaging in Open Source. Questions on legal issues, licensing and what is deemed confidential or internal information is common.

This document is therefore a guide, primarily for Baloise employees, on how to use, adopt, modify and release Open Source code. There are a few references to internal Baloise sites or services, but with an effort to limit our use of internal resources.

1.3. Overview

OS maturity model
Figure 1: OS maturity model

This document is supposed to cover all three engineering driven steps of: using open source, contributing to open source as well as championing an individual open source project enabling an uplift and being ready for strategic investments in that area.

1.4. Code of Conduct

As a general rule, it is the responsibility of each individual employee to ensure his or her behaviour is in keeping with legal and ethical principles. To provide basic behavioural guidelines, we link our to code of conduct(s) containing these essential ethical and legal rules.

In summary - "Do the right thing!"

1.5. Stakeholders

in alphabetical order by role / name

Table 1. Stakeholder
Expectation Name Role Github Twitter LinkedIn

Learn and share are our first steps afterwards the sky is the limit.

Urs Bienz

Head of Finance & Risk

đź”—

đź”—

Open innovation in its many forms is critical for our success and open-source is the digital manifestation of this idea.

Alexander Bockelmann

Chief IT Officer

đź”—

đź”—

We can reduce dependencies on providers and become more attractive for highly qualified employees.

Pascal Bonny

Lead IT Switzerland

đź”—

In future we will only succeed if “open-source” is our default way of thinking and acting. The majority of why we exist and what we provide as an insurer is meant to be a common good anyway: safety and reliability.

Adrian Honegger

Head of Group Strategy & Digital Transformation

đź”—

đź”—

Sharing knowledge and collaboration across industries and borders helps us to achieve a higher quality and leads to more innovation.

Clemens Markstein

Operations & IT

đź”—

I’m looking forward to great ideas by "outsiders", who help us improving customer experience.

Thomas Schöb

Head of Claims

đź”—

đź”—

2. Solution Strategy for handling open source

2.1. Using existing open source

In general open source components can be used in Baloise projects, but everyone has a responsibility to ensure that we respect and comply the individual Licensing obligations.

We recommend checking the project’s maturity, activity and heterogeneity of community before (heavily) relying on it. Websites like e.g. OpenHub can help quickly identifying relevant metrics (source code history, level of activity, number of contributors, etc.) of most relevant open source projects.

2.2. Contributing to existing open source projects

We encourage participation in open source projects and strive to have as few rules for this as possible, we expect participants to follow common sense on what code and information they contribute - if in doubt, contact the Open Source Team, or talk to your lead in charge.

2.2.1. Common contribution rules

  • Do not share customer data or confidential Baloise information

  • Code that cannot be contributed upstream:

    • confidential source code

    • functionalities that give us an edge over competitors

  • Remember that the Baloise Group legally has ownership over your contributions as you are an employee of Baloise

2.2.2. Non-code contributions

Contributions such as reporting issues, writing documentation, reviewing code and participating in project maintenance such as creating roadmaps, backlog refinements etc.

These activities are all allowed and encouraged as part of your employment at Baloise.

2.2.3. Code contributions

Upstream code contributions are also encouraged and are a natural extension of our dependency of open source projects in our tech stack. Through contributing bug fixes and feature enhancements to the upstream open source project our code changes will be integrated in future releases lowering the merging and maintenance effort of our own code. Code contributions can generally be divided into 2 categories:

  • Contributions triggered by a work task: e.g. a dependency (library, module, project, product) has a bug or a shortcoming which blocks your work

  • Contributions on your own initiative

Both are allowed and do not require a review. Simply ensure that

If the upstream project requires a Contributor License Agreement (CLA) for your contribution please contact the Open Source Team as we want to make sure adressing this agreement globally on a corporate level rather than on an individual one.

2.3. Releasing new open source projects

This is the process for how Baloise employees release a new open source project on the Baloise or Baloise-Incubator Github Organization. The process is simple and the Open Source Team is ready to help you every step of the way.

The level of ownership as in many open source projects and communities is also for us based on meritocratic principles. Meritocracy in open source projects means that the people who earned respect through positive contributions are empowered to make relevant decisions within the community.

2.3.1. Overview

Releasing a new open source project is a simple and fast process when you are already following Baloises rules of play:

  1. Get Sign-off: Ensure you have organizational buy-in from your lead and that your project is possible to open source

  2. Be Compliant: Ensure your project is compliant with rules of play and open source best practices

  3. Prepare your repository: Clean up and refactor your code to work outside the Baloise environment.

  4. Get Reviewed: We recommend getting feedback from the Baloise Open Source Team for reviewing your project before releasing it

2.3.2. Get Sign-off

Ensure your lead and team are onboard with open sourcing your project, that everyone understand the time and effort required, and that there is no competitive disadvantages to Baloise.

Get acceptance from your team and your lead

Make sure your team lead is informed about open sourcing a project, and that your lead is supportive of this. Open sourcing code is a process which requires time and effort, so make sure your lead and your team understand that some of your work hours will be spend maintaining this project and the community around it.

What cannot be open sourced?

Anything that risks Baloise’s 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

  • functionalities that give us an edge over competitors

If you are in doubt, reach out to the Baloise Open Source Team or talk to your lead.

2.3.3. Be Compliant

Compliance covers the area of ensuring that we follow a safe and consistent practice for sharing and collaborating.

Rules of play

All open source projects must comply with the open source specific rules of play, which applies to code that any Baloise employee releases. There are 3 areas which the rules cover:

  1. Including the right files for licensing, documentation and ownership of the project

  2. Following the right procedure for how you create and release code

  3. Respecting and assigning copyright

Include the required assets

Use new-project as a boilerplate for the files required for your project. These files are needed to correctly communicate ownership and guidelines for the project:

  1. Create a meaningful README.md file, this is your most important piece of documentation

  2. Include a docs/CODEOWNERS file with contact information who is maintaining the project

  3. Include a CONTRIBUTION.md file with guidelines on how to contribute

  4. Add a LICENSE.md file, license must be the Apache License 2.0 with the copyright set to Baloise Group. For non-source code content we recommend using CC BY 4.0 (e.g. plain license TXT)

  5. Ensure you only use Licensing-compatible code/dependencies

The Open Source Team can help you setting this up during an initial review.

Use proper procedure for collaboration

When the project has been released as a public project on Github the following workflows are expected of you:

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

  2. Ensure that no credentials, private identifiers or personal data is at any time present in your repository

  3. Enforce code-reviews with at least 2 sets of Baloise eyes on all code to minimize the risk of implanted security backdoors and vulnerable code.

  4. Ensure there is an active team of maintainers of at least 2 people from Baloise taking ownership of the project

Community best practices

Besides the rules of play, there is also a set of best practices which we highly recommend you implement.

  1. Have a Code of Conduct and enforce it to create a safe environment for collaboration

  2. Set clear expectations for responses - let users know if your time is limited

  3. Ask for help and be open to what kind of contributions would help your project

  4. Be mindful of your documentation

opensource.guide has plenty more resources and recommendations for maintainers.

Copyright and ownership

Default ownership of all code released by Baloise employees are copyright Baloise Group and must be released under the Baloise GitHub organizations (baloise or baloise-incubator).

The recommended namespace to use is com.baloise.open.*. Reasons for this namespace are:

  • the scope of the organizations was set to Baloise group level which implies the namespace com.baloise.

  • clear and unique identification of artifacts maintained by us under open-source licenses: .open.*

  • ease of use for source code scanning and license compliance tools

2.3.4. Prepare your repository

Preparing a repository for open sourcing goes beyond ensuring it is in compliance with the rules above. This can include refactoring and documenting your code better to ensure that users and potential contributors can make sense of it.

  • Ensure you do not have any tokens, passwords or confidential data in your code

  • Ensure the code doesn’t require any Baloise-specific infrastructure or access, so users can use it in their own environment

  • Ensure your code is clear and commented so newcomers can see what is going on

  • Ensure your dependencies are updated and do not have any known security issues

  • Ensure that it is easy to get up and running, not just on your machine

2.3.5. Get Reviewed

When you have checked off the compliance checklist and prepared your code for release, request a review from the Open Source Team who will help you setup a Github repository and sign-off on open sourcing your code.

2.3.6. Release

When all the above points are in order and the review has been passed, the project is released on Baloise-Github Organizations marked as an Incubator project.

Incubator projects

New projects shall be flagged as an "incubator project" until their maturity has been proven.

Incubator project
Figure 4: Incubator projects - visual flag

In addition to that the projects version number must reflect this status using a leading 0 in its major version; e.g. 0.47.11.

Maturity metrics

All of the following maturity metrics shall be met before leaving the "incubator project" status

  1. project is used in- and externally of Baloise

  2. project has released 3+ minor versions of itself

  3. project has 10+ stars and a minimum of 2 codeowner

3. Cross-cutting Concepts

3.1. Licensing

For both using and releasing Open source Software, there is the challenge of understanding and respecting the licenses of your project dependencies. The purpose of this section is to outline what licenses to avoid, which ones you can freely use and which licenses come with special requirements.

3.1.1. Summary

  • Any dependency with a permissive license can be used

  • Copyleft licensed code can be used if you plan NOT to distribute outside Baloise

  • Make sure to investigate the specific terms of the copyleft licenses, when building components meant for distribution

  • You cannot use AGPL licensed code

  • You cannot use unlicensed code

  • Use Creative Commons licenses for non-source code content

3.1.2. Overview

OSS license spectrum
Figure 2: OSS license spectrum

Overall there are 3 types of licenses which you can use:

  • Permissive licenses

  • Weak copyleft licenses

  • Strong Copyleft licenses

And 2 types which you cannot use in any way:

  • Network protective: AGPL, RPL or variants licensed code

  • Unlicensed code

This document is a general overview and does not represent legal advice. Always check the details of each license and if you are in doubt, get in touch with legal.

3.1.3. Permissive licenses

AFL, Apache, BSD, MIT, MS-PL, ISC, PHP License, and many more.

Code dependency which you are free to use and change without limitations, but must include the license and copyright of the dependency.

Permissive licensed dependencies can be used without issues both for internal and for open source projects.

  • You are free to: use commercially, modify, distribute and sublicense.

  • You must include: copyright and license

  • You cannot hold the author liable.

3.1.4. Weak copyleft licenses

APSL, LGPL, CDDL, CPL, EPL, IPL, MPL and many more.

Code dependency which you are free to use and change, but must include the source code, the license and copyright of the dependency. You can license your own code however you want, and you must only share the source code of the reciprocally licensed dependency.

Beware that each individual license has specific clauses, so check the individual license before use.

  • You are free to: use commercially, modify, distribute and sublicense.

  • You must include: copyright, license, changelog, source code and install instructions

  • You cannot hold the author liable or use authors trademarks

3.1.5. Strong Copyleft licenses

GPL, NPL, OSL, QPL and many more.

Code dependency which require you to license all your code under the same license if you want to distribute it. If only used internally, you have no obligation to release neither source nor binary.

Dependency can therefore be used for internal projects, but not for projects which will be distributed outside of Baloise.

  • You are free to: use commercially, modify and distribute

  • You must include: copyright, license, source code, changelog, original source and install instructions

  • You cannot hold the author liable or sublicense

  • If distributed, you must license your code under the same license.

3.1.6. Network protective licenses

Code licensed under AGPL (Affero General Public License) and RPL, may not be used at Baloise.

Code dependency which triggers the copyleft provision even when it is not distributed. If AGPL or RPL code is used to deliver a web-service such as https://baloise.com, all code and code linked to the service must be licensed and distributed under AGPL.

Use of software licensed under AGPL represents a risk for Baloise, so even for projects which are not directly linked to any of our services, it must not be used as the benefits compared to the risk is small.

3.1.7. Unlicensed code

Code which does not include a license or have no clear ownership cannot be used at Baloise.

As per standard copyright law, any code which is not explicitly licensed, is the property of the author and cannot be used without permission.

However if you wish to use a library which have no license, first of all check with the author to see if the license is simple not distributed with the source code. If the project author has not included a license open a pull request and suggest a license such as Apache-2.0.

3.1.8. Creative Commons licenses

The previously mentioned licence types are primarily aimed for licensing source code. Hence if there is not directly source code involved, e.g. for documentation, pretty often other licenses are used for good reasons.

As for now we recommend using creative commons licensed content. Giving Attribution (by), ShareAlike (sa) - a the naming of copyleft at creative commons - and NoDerivatives (nd) licensed content can be used at Baloise with respect to the indiviudal requirements of that license.

If the content is licensed with a NonCommercial (nc) e.g. CC BY-NC 4.0 attribute you can not use that content at Baloise without further clarification.

Creative commons license spectrum
Figure 3: Creative commons license spectrum by Shaddim via Wikimedia Commons

A set of the licences are published and standardized by Creative Commons (CC) is an American non-profit organization.

3.2. Certificate of Origin

3.2.1. Developer Certificate of Origin (DCO)

Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.


Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

Technically by default you sign the DCO by using --signoff within your commit(s).

3.2.2. Contributor (License) Agreement

CLAs are often asked for when participating in larger communities.

signed on corporate level

We should make sure building an index of signed CLAs on corporate level at here. So far contributing to these organizations is covered

signing new ones

As an individual you should avoid signing CLAs on your own within the corporate context. Please contact the Open Source Team if you require a CLA for a contribution to a project or organization. We’ll make sure to get an official one on coroporate level.

Individual ones signed / discussed so far:

3.3. Digital Sustainability

Digital sustainability is a concept to target longevity of digital artifacts such as software. It explains why open source licensed code is necessary but not sufficient condition to be sustainable on the long run. Sustainable digital artifacts need to meet ten basic conditions regarding the digital good and its ecosystem:

  1. Elaborateness of digital artifacts is determined through their modularity, integrity, accuracy, robustness, and other characteristics regarding the quality of their substance.

  2. Transparent structures signify technical openness allowing access to the inner structures of digital artifacts, such as source code, standard specifications, content, or data structures.

  3. Semantic information makes complex digital artifacts more easily intelligible to humans and machines through comprehensible structures and meta data.

  4. Distributed location means data, software and other digital artifacts are stored and operated on multiple sites, e.g. through replicated data storage or peer-to-peer technology.

  5. Open licensing regimes grant anyone the right to use and modify digital artifacts at no cost and for any purpose, thus providing improvements and enhancements without limitations.

  6. Shared tacit knowledge of digital artifacts means there are many individuals and organizations that know through their experience how to understand, use, and modify the digital artifacts.

  7. Participatory culture signifies permeability of contributions throughout the entire lifecycle of digital artifacts, enabling peer-review processes on all levels.

  8. Good governance means the digital artifact and its ecosystem is not controlled by a single individual or organization, but governed decentralized by its contributors and other stakeholders.

  9. Diversified funding allows cost covering of infrastructures, contributions, and other spending from various financial sources .

  10. Contribution to sustainable development means sustainable digital artifacts must provide positive ecological, social or economic effects.

4. Design Decisions

4.1. Open Source Team

It’s good practice having dedicated people being responsible for handling open source matters within a company.

For now we go with a lightweight approach of an open source program office:

5. Glossary

acronym English Deutsch

CLA

Contributor License Agreement

DCO

Developer Certificate of Origin

FOSS

Free and open-source software

freie und quelloffene Software

FLOSS

Free/Libre and open-source software

freie und quelloffene Software

Inner Source

firmeninterner Open Source

OS

Open-Source

quelloffen

OSD

Open Source Defintion

Definition von Open Source

OSI

Open Source Initiative

Open Source Initiative

OSS

Open-source software

quelloffene Software

6. Attributions

in alphabetical order

arc42

arc42, the Template for documentation of software and system architecture.

By Dr. Gernot Starke, Dr. Peter Hruschka and contributors.

Template Revision: 7.0 EN (based on asciidoc), January 2017

© We acknowledge that this document uses material from the arc 42 architecture template, http://www.arc42.de. Created by Dr. Peter Hruschka & Dr. Gernot Starke.

Eclipse Foundation

The Eclipse Foundation provides individuals and organizations with a commercially focused environment for open source software innovation.

In the era of digitalization, all companies are becoming technology companies. More and more organizations are embracing open source software as a vital element of business technology strategy.

The Eclipse Foundation provides a mature, scalable and commercially focused environment for collaboration and innovation that enables companies to leverage the strategic value of open source.

© We acknowledge that this document uses material from the Eclipse Foundation published under EPL-2.0.

Research Center for Digital Sustainability

Institute of Information Systems at the University of Bern

The Research Center for Digital Sustainability is situated at the Institute of Information Systems at the University of Bern and was founded in 2014 with the support of the CH Open Association.

© We acknowledge that this document uses material contributed by Dr. Matthias StĂĽrmer Head of the Research Center for Digital Sustainability - Institute of Information Systems at the University of Bern.

Zalando

Zalando SE, Open Source

Scaling Open Culture - Contributors

Repo Version: 2084231478080ed4e6f034569c7e3c4ac57f6ca1

© We acknowledge that this document uses material from Zalandos Open Source Documentation published under MIT.

License

This document itself is published under CC BY 4.0 - please feel free to use it (and give attribution)!

CC BY 4.0
Figure 4: Baloise Open Source - Licensed under