|
| 1 | +## Title |
| 2 | + |
| 3 | +InnerSource License |
| 4 | + |
| 5 | +## Patlet |
| 6 | + |
| 7 | +Two companies that belong to the same group want to share software source code with each other but they are concerned about the implications in terms of legal liabilities or cross-company accounting. An **InnerSource License** provides a reusable legal framework for the inter-company agreement within the group, which opens up new collaboration options. |
| 8 | + |
| 9 | +## Problem |
| 10 | + |
| 11 | +When two companies within a group want to share code with each other, they need an agreement about the terms and often a legal contract. Creating such agreements on a per project basis takes effort and creates a barrier for sharing. i.e. a team/company might decide not to share their source code with another company in the group because it seems complicated. |
| 12 | + |
| 13 | +Barriers for sharing can lead to silos and duplication of effort in rebuilding similar solutions in multiple parts of the group. |
| 14 | + |
| 15 | +At the time of sharing the source code, it can not be reliably predicted what the value of sharing will be. Hence if the activity of sharing has any significant cost, the companies are unlikely to do it, as they are concerned about the return on investment. |
| 16 | + |
| 17 | +## Context |
| 18 | + |
| 19 | +- A large group with many companies (subsidiaries) that want to share code. (when the group gets larger, the value of this pattern increases) |
| 20 | +- These companies are legally independent units. |
| 21 | +- Multiple of these companies/subsidiaries are developing software, and are using services of the other companies. They have a motivation to contribute to each other’s source code. |
| 22 | +- Certain size of developers (crowdsourcing and ecosystem effects of InnerSource) |
| 23 | + |
| 24 | +## Forces |
| 25 | + |
| 26 | +- **Level of effort** required to write formal agreements, especially if they need to take into account technical, legal, and business perspectives. |
| 27 | +- Enterprises have many **internal regulations,** any agreements have to comply with these regulations, e.g. security, privacy, procurement processes, etc. The volume of regulations can make it difficult to assess whether sharing software between two companies is compliant with these regulations, especially when there is no standard procedure. |
| 28 | +- If any of the companies in the group has a **business model** that depends on proprietary code and accounting of licensing fees within the group |
| 29 | +- **Company culture** that isn’t used to sharing code |
| 30 | +- Freedom over using the software leads to competition, and spread of ownership |
| 31 | + |
| 32 | +## Solutions |
| 33 | + |
| 34 | +Creating an **InnerSource License** customized to the needs of the group in question (and their companies). This license needs to be generic enough to be applied to the most important inter-company relationships. |
| 35 | + |
| 36 | +It is important to write the InnerSource License such that it truly allows for OpenSource-like collaborations across organizational boundaries. Therefore the 4 freedoms of free software should be integrated into the license. |
| 37 | + |
| 38 | +The License is written as a formal legal document, and can be used as part of contracts between the subsidiaries to govern the code sharing agreements. |
| 39 | + |
| 40 | +## Resulting Context |
| 41 | + |
| 42 | +With the InnerSource License, we have a tool to share code between companies within our group. |
| 43 | + |
| 44 | +## Known Instances |
| 45 | + |
| 46 | +DB Systel created their own InnerSource License, see [DB Inner Source License][db-inner-source-license]. They used the [EUPL][eupl], as that offered an open-source-like starting point, and then worked out the constraints and additional rules required in their specific company context. |
| 47 | + |
| 48 | +The first companies within the DB AG are using their InnerSource License. |
| 49 | + |
| 50 | +One positive effect that is already showing is that it simplifies the conversation, especially if some of the involved parties don’t know the InnerSource concept that well yet. Licenses are a well-known concept, therefore having an InnerSource License is a great discussion starter. |
| 51 | + |
| 52 | +The experiments are also uncovering that there are further collaboration challenges that need to be solved in order to lead to a true InnerSource contribution and collaboration model. |
| 53 | + |
| 54 | +The mentioned collaboration challenges include: |
| 55 | + |
| 56 | +- making InnerSource licensed projects discoverable |
| 57 | +- building communities for collaboration on projects, just like in Open Source |
| 58 | + |
| 59 | +It is worth mentioning that so far the software shared under this InnerSource license is mostly tooling, infrastructure, and tools lower in the stack. |
| 60 | + |
| 61 | +## Status |
| 62 | + |
| 63 | +Proven |
| 64 | + |
| 65 | +The experiment listed under **Known Instances** is running since 02/2020. |
| 66 | + |
| 67 | +The initial experience shows first positive effects but more experience is needed to fully evaluate the pattern. |
| 68 | + |
| 69 | +## Author(s) |
| 70 | + |
| 71 | +Cornelius Schumacher (DB Systel GmbH) |
| 72 | + |
| 73 | +Schlomo Schapiro (DB Systel GmbH) |
| 74 | + |
| 75 | +Sebastian Spier |
| 76 | + |
| 77 | +[db-inner-source-license]: https://github.com/dbsystel/open-source-policies/blob/master/DB-Inner-Source-License.md |
| 78 | +[eupl]: https://joinup.ec.europa.eu/collection/eupl/eupl-text-eupl-12 |
0 commit comments