Open Source Governance

Using existing software components, in particular open source components, is good engineering practice. What’s not to like about high quality software available for free? However, open source code comes with obligations, if you want to use it correctly and securely. Some of these obligations may not be acceptable for our projects, and some obligations are simply impossible to fulfill due to conflicts between different open source licenses.

Thus, we need to approve the use of open source code in our projects and therefore students must first seek this approval before using open source code. This is called open source governance, i.e. we “govern” the process of selecting and including open source code and managing the resulting dependency on third-party code.

To request review and approval of an open source component, please talk to your course or thesis supervisor. An explanation of the rationale behind these rules is provided in our document on Open Source Governance in University Projects.

Open source ground rules

  1. All intended uses of open source code must be declared and approved before actual use; all used open source components need to be listed in a bill-of-materials.
  2. We generally permit permissively licensed components (e.g. MIT, BSD, Apache) in our projects and forbid reciprocally licensed components (most notably the GPL family).
  3. Code must not be copied and pasted from the web, only whole components can be used; in particular copying code from Stackoverflow or gist is strictly forbidden.
  4. A component must have a good pedigree: Established open source foundations provide a good pedigree, random code from the web does not.

Pre-approved components

  • Any open source component managed by the Apache Software Foundation and the Eclipse Foundation is pre-approved.

All other components need to be reviewed and approved before being used.

Likely to-be-approved

We are likely to approve components that fulfill our ground rules, even if they are not the output of Apache or Eclipse projects. Examples are:

  • Components that are developed under the guidance of an organization with good open source governance (e.g. github.com/google)

Unlikely to-be-approved

  • Any reciprocally licensed code (code with a license including a Copyleft clause, e.g. the GPLv2 license)

Bill-of-materials

A bill-of-materials (“Stückliste”) is a list of materials, here open source software components, that are part of the product or project. Each list entry should provide at least the name of the component, the used version, the license of the component, and how it is used within the scope of the product.