├── Annexes ├── Allow-List.txt ├── Approval-Process-Flowchart.svg ├── Approval-Process.txt ├── Approval-Request.txt ├── BOM.txt ├── Contribution-Permission.txt ├── Copyleft-Policy.txt ├── Deny-List.txt ├── FOSS-in-ToU.txt ├── FOSS-in-external-development.txt ├── GPL-Encryption.txt ├── Identified-Licenses.txt ├── Purchase-Contract.txt └── SaaS-Licenses.txt ├── LICENSING ├── OS-Policy_Master.txt ├── README.md └── Supplements ├── Acknowledgments.txt ├── Container-Compliance.txt ├── Container-Content.svg ├── Container-Layers.svg ├── Container-Top-View.svg ├── Copyleft.txt ├── Derivative-Work.txt ├── FFT-library-EN.eps ├── FFT-server-EN.eps ├── How-To-Rebuild.txt ├── How-To-Scan.txt ├── License-Choice-Flowchart.svg ├── License-Choice.txt ├── License-Compatibility.txt └── Third-Party-Rights.txt /Annexes/Allow-List.txt: -------------------------------------------------------------------------------- 1 | %########################################################################### 2 | % 3 | % Annex to the OSADL Open Source Policy Template 4 | % 5 | % Copyright (c) 2019,2020 Open Source Automation Development Lab (OSADL) eG 6 | % Author: Caren Kresse 7 | % 8 | %########################################################################### 9 | 10 | Allow List 11 | 12 | This document lists FOSS licenses that may always be used in any of our projects 13 | without an individual approval request. 14 | -------------------------------------------------------------------------------- /Annexes/Approval-Process.txt: -------------------------------------------------------------------------------- 1 | %########################################################################### 2 | % 3 | % Annex to the OSADL Open Source Policy Template 4 | % 5 | % Copyright (c) 2019,2020 Open Source Automation Development Lab (OSADL) eG 6 | % Author: Caren Kresse 7 | % 8 | %########################################################################### 9 | 10 | Approval process 11 | 12 | 13 | This document details the process that third-party software needs to go through 14 | before being entered into our company's repository to make sure that it can be 15 | licensed correctly. The flowchart at the end of this document displays the 16 | sequence of steps that are described below. 17 | 18 | - Candidate for Use: A third-party software component that has been successfully 19 | tested in a first technical assessment and is now considered for inclusion into 20 | our company's repository. 21 | 22 | ======================================== 23 | - Intended use: In-house or product? The FOSS policy rules if and how software 24 | for in-house use is treated differently from software that is intended to be 25 | copied and distributed. The Flowchart must be adapted accordingly. 26 | ======================================== 27 | ######################################## 28 | Option 1: If all Open Source Software is treated as equal, this step is omitted 29 | and the approval process continues with Collect license information. 30 | ######################################## 31 | Option 2: Otherwise, the approval process continues with Collect license 32 | information for software that is to be distributed, but concludes positively for 33 | in-house software. 34 | ######################################## 35 | 36 | - Obtain complete corresponding source code: The complete corresponding source 37 | code (CCSC) is needed to extract license information, for potential bug fixes 38 | and other modifications and to be able to fulfill license obligations. It must 39 | be downloaded from the original project repository and stored along with the 40 | download link. 41 | ======================================== 42 | NOTE: Binary-only repositories (e.g. Maven) that do not contain any source code 43 | make it practically impossible to fulfill many license obligations. 44 | ======================================== 45 | 46 | - Collect license information: The license of the Candidate for Use has to be 47 | determined. Either there is a license notice included in the software, or a 48 | default license is given in the imprint of a website or the supplier provides a 49 | BOM containing license information. Our company maintains a -> "List of known 50 | licenses" that contains all licenses that have been evaluated previously (e.g. 51 | based on SPDX list, OSI list, OSADL OSLOC). When an unknown license has gone 52 | through an approval request it is added to this list. 53 | 54 | - Deny listed? If the license of the Candidate for Use is listed on the 55 | project-specific or on the company-wide -> "Deny List", the Candidate for Use 56 | must be discarded. 57 | ======================================== 58 | The company might maintain a Deny List of licenses (e.g. licenses with an 59 | advertising clause) that must not be used for a particular project 60 | (project-specific Deny List) or that must never be used at all (company-wide 61 | Deny List). 62 | ======================================== 63 | 64 | - Allow listed? If the license of the Candidate for Use is listed on the 65 | project specific or on the company-wide -> "Allow List", the Candidate for Use 66 | is automatically approved. 67 | ======================================== 68 | The company might maintain an Allow List of licenses (e.g. permissive licenses 69 | licenses without any particularities) that may always be used for a particular 70 | project (project-specific Allow List) or that may always be used in the company 71 | (company-wide Allow-List). 72 | ======================================== 73 | 74 | - Intended type of integration? Will the Candidate of Use form a derivative work 75 | with any other software in the project, i.e. will it be linked to anything, or 76 | will it be a stand-alone component within the project? In case of a derivative 77 | work, can the components be separated again? For further reading see Supplement 78 | -> "What is a derivative work?". 79 | 80 | - Derivative work with other FOSS? Derivative work with proprietary software? It 81 | is differentiated whether a derivative work is formed with other FOSS or with 82 | proprietary software as this might have different implications on license 83 | compatibility and obligations. 84 | 85 | - Check compatibility: When the Candidate for Use forms a derivative work with 86 | other FOSS, the involved licenses have to be checked for compatibility if 87 | necessary (i.e. the copyleft is triggered in the concrete use case). To do so, 88 | our company's instance of the -> "OSADL Compatibility Matrix" is to be 89 | consulted. The final license of the combined work denotes the row of the 90 | matrix. Compatibility between two licenses is indicated with green color, 91 | incompatibility with red color and cases that need to be decided individually 92 | with grey color. 93 | ======================================== 94 | When the respective authority (e.g. M, LD or PL) has decided on how to interpret 95 | an unclear compatibility, this may be displayed in the company's individual 96 | version of the compatibility matrix. 97 | ======================================== 98 | 99 | - Check compatibility with proprietary license: When the Candidate for Use forms 100 | a derivative work with third-party or in-house developed software under a 101 | proprietary license, the compatibility of the Candidate's license with the final 102 | proprietary license of the combined work must be checked. To do so, the 103 | appropriate row at the bottom of the company's instance of the -> "OSADL 104 | Compatibility Matrix" is to be consulted. 105 | ======================================== 106 | There are five additional rows at the bottom of the OSADL Compatibility Matrix 107 | that use the color code described above. These rows (license name, 108 | compatibilities) can be customized by the company according to their 109 | requirements. 110 | ======================================== 111 | 112 | - Other constraints: A particular license might contain other constraints e.g. 113 | setting the place of jurisdiction. Such additional constraints must be evaluated 114 | individually based on the license text. 115 | 116 | If the approval process concludes positively, the Candidate for Use may be 117 | entered into the company's software repository. The process of how to do so is 118 | outlined in our company's FOSS policy. If the approval process concludes 119 | negatively, the Candidate for Use must be discarded and this information must be 120 | archived. If the approval process concludes that an individual approval request 121 | must be made, the process as outlined in -> "Approval Request" must be 122 | followed. 123 | 124 | Image: Approval-Process-Flowchart.svg 125 | -------------------------------------------------------------------------------- /Annexes/Approval-Request.txt: -------------------------------------------------------------------------------- 1 | %########################################################################### 2 | % 3 | % Annex to the OSADL Open Source Policy Template 4 | % 5 | % Copyright (c) 2019,2020 Open Source Automation Development Lab (OSADL) eG 6 | % Author: Carsten Emde, Caren Kresse 7 | % 8 | %########################################################################### 9 | 10 | Approval request 11 | 12 | 13 | This document details the information and material that must be collected to 14 | submit an approval request for a third-party software component ("Candidate for 15 | Use"). A Candidate for Use is eligible for an approval request when it has gone 16 | through our company's -> "Approval process" and the outcome indicates so. The 17 | information must be entered into the form supplied at the end of this document 18 | and must be submitted to the LD. 19 | 20 | Information and material to submit 21 | 22 | - Intended use: Since third-party software that is merely used in-house may be 23 | treated differently from software that is intended to be copied and distributed 24 | to customers, it is important to specify the intended use of the Candidate for 25 | Use. 26 | 27 | - Software package name and version number: The correct name of the software 28 | package and the version number must be specified. If it is already predictable 29 | that in the foreseeable future other version numbers may apply, they must be 30 | given. 31 | ######################################## 32 | Option 1: A separate approval request must be submitted when the software is 33 | upgraded to a new version. 34 | ######################################## 35 | Option 2: All versions are approved as long as there is no license change. 36 | ######################################## 37 | 38 | - URL of the related software project: Some software projects maintain a home 39 | page that displays more general information of the software including background 40 | information and FAQ with respect to licensing. This is particularly important, 41 | since the authors or holders of rights of a software have an important say with 42 | respect to the license and interpretation of the same. 43 | 44 | - License name: Licenses have a distinguishable name, such as "Common 45 | Development and Distribution License 1.0" which must be given here. If 46 | available, the SPDX Identifier (https://spdx.org/licenses/) shall be used. 47 | 48 | - Type of license: The license type must be specified, if this is possible in 49 | advance: i.e. FOSS (listed in the catalog of Open Source licenses maintained by 50 | the Open Source Initiative (OSI, https://www.opensource.org)) or other. 51 | 52 | - Original license text: If the license is not listed by OSI, the original 53 | license text must be attached to the approval request. OSI listed licenses 54 | fulfill the requirements of the Open Source Definition (OSD, 55 | https://www.opensource.org/osd). Other licenses must be classified individually. 56 | 57 | - Type of integration: This item relates to the way the Candidate for Use will 58 | be integrated into a system, if any. This is important, since FOSS licenses 59 | differ with regard to obligations imposed on a derivative work (see Supplement 60 | -> "What is copyleft?"). Therefore, it should be specified here whether the 61 | software to be approved is stand-alone or whether it is combined with other 62 | third-party or in-house developed software. This has implications on whether the 63 | compatibility of involved licenses needs to be considered. There are various 64 | ways software components can interact, such as being statically or dynamically 65 | linked, as plugins, as kernel modules, through other interfaces, etc. For 66 | details see Supplement -> "What is a derivative work?" 67 | 68 | - Type of linkage: Not all copyleft licenses request that the same license must 69 | be used for any combined work, but may mitigate this obligation in such a way 70 | that another license may be used, if the software components are linked at 71 | compile or run time, can be separated at any time later on and the customer can 72 | individually replace components by another version of choice. Such licenses are 73 | called FOSS license with weak copyleft. It is therefore important to 74 | differentiate the way of how the components are linked to each other and whether 75 | they can be separated and relinked later on. 76 | ======================================== 77 | Copyleft licenses with and without restrictions are given as part of the -> 78 | "OSADL Open Source License Obligations Checklists" project. 79 | ======================================== 80 | 81 | - List of software components to which the Candidate for Use will be linked, if 82 | any: A complete list of all software components to which the Candidate for Use 83 | will be linked must be given here to allow a license compatibility check. In 84 | addition, for every such component the applicable license must be specified. If 85 | approval is granted and software components are listed here, the approval is 86 | limited to either stand-alone use or when linked to one of the listed 87 | components. 88 | 89 | - List of software components that the Candidate for Use requires at link or run 90 | time, if any: Some software packages are dependent on other software components 91 | such as language libraries. A complete list of all software components that the 92 | Candidate for Use requires at link or run time must be given here. In addition, 93 | for every such component the applicable license must be specified and a separate 94 | approval must have been obtained. 95 | 96 | - Attachments with respect to linkage and separability, if any: It sometimes 97 | may be difficult to decide which components are linked together and whether they 98 | can be separated later on - particularly, if a component recursively depends on 99 | other components. In this case, a callgraph and/or a list of unresolved symbols 100 | must be created and attached to this request (A tool to create such a call graph 101 | by analyzing ELF files is available in its original version at 102 | https://github.com/armijnhemel/compliance-scripts/tree/master/elfgraphs 103 | and as extended version made by OSADL at https://git.osadl.org/ckresse/callgraph). 104 | 105 | - Requester's contact data: Finally, the contact data of the requester must be 106 | given in case explanations of the provided information are needed. 107 | 108 | Approval request 109 | 110 | To be submitted to: 111 | Name 112 | Department 113 | Email 114 | 115 | Intended use: 116 | O In-house only 117 | O To be copied and distributed 118 | O As SaaS 119 | 120 | Software package name: 121 | 122 | Software version number: 123 | 124 | URL of the related software project: 125 | 126 | License name or SPDX Identifier: 127 | 128 | Type of license: 129 | O OSI approved 130 | O Other 131 | 132 | O Original license text attached (mandatory, if not listed by SPDX) 133 | 134 | Type of integration: 135 | O Stand-alone 136 | O Linked 137 | O Other 138 | 139 | Type of linkage, if any: 140 | O Static, unseparable 141 | O Static, separable 142 | O Dynamic 143 | 144 | List of software components to which the software package to be approved will be 145 | linked, if any: 146 | Software component #1: 147 | License: 148 | ... 149 | Software component #n: 150 | License: 151 | Additional software components, if any, are listed in an attachment. 152 | List of software components that the software package to be approved requires 153 | at link or run time, if any: 154 | Software component #1: 155 | License: 156 | ... 157 | Software component #n: 158 | License: 159 | Additional software components, if any, are listed in an attachment. 160 | 161 | Attachments with respect to linkage: 162 | O Callgraph 163 | O List of unresolved symbols 164 | 165 | Requester name, department: 166 | Requester email, phone: 167 | -------------------------------------------------------------------------------- /Annexes/BOM.txt: -------------------------------------------------------------------------------- 1 | %########################################################################### 2 | % 3 | % Annex to the OSADL Open Source Policy Template 4 | % 5 | % Copyright (c) 2019,2020 Open Source Automation Development Lab (OSADL) eG 6 | % Author: Carsten Emde, Caren Kresse 7 | % 8 | %########################################################################### 9 | 10 | Bill of Material (BOM) 11 | 12 | 13 | Traditionally, a Bill of Material (BOM) lists all parts that a product is made 14 | up of. More recently, this definition has been extended to also include software 15 | components. Traditionally, a Bill of Material (BOM) lists all parts that a 16 | product is made up of. More recently, this definition has been extended to also 17 | include software components. This document lists and explains the information 18 | required for a BOM for our products that contain software. Only software 19 | components that are actually distributed must be considered. The information 20 | must be entered into the form supplied at the end of this document. According 21 | to the number of distributed software components the provided Section 2: 22 | Distributed software material must be duplicated repeatedly. 23 | ######################################## 24 | Option 1: Only FOSS components are listed in the BOM. 25 | ######################################## 26 | Option 2: All software components, independent of how they are licensed, are 27 | listed in the BOM. 28 | ######################################## 29 | 30 | ======================================== 31 | The content of a BOM that is delivered along with the product depends on the 32 | customer's requirements and may be significantly shorter. At the very least, 33 | however, it must contain name and version of the component and its licenses. 34 | ======================================== 35 | 36 | 1 General information on the software product 37 | 38 | - Name: Unique name of the product that serves as reference throughout our 39 | company and the entire group of affiliates. 40 | 41 | - Company/department: Name of the leading department that is internally 42 | responsible for this software product. 43 | 44 | ######################################## 45 | - Optional: Brief description: A quick overview about the software product and 46 | its intended use cases. 47 | ######################################## 48 | - Optional: Third-party or in-house developed product: This entry notes whether 49 | this BOM describes an acquired product and the BOM is primarily needed for 50 | internal documentation, or whether the BOM describes a product developed in-house 51 | and the BOM is needed to compliantly fulfill license obligations when copying and 52 | distributing it. 53 | ######################################## 54 | - Optional: Asset ID: Unique ID to be referenced to our company's inventory list. 55 | ######################################## 56 | 57 | - Version number 58 | - Release date: The release date of the current version. 59 | ######################################## 60 | - Optional: Remarks: Additional information. 61 | ######################################## 62 | 63 | - In-house contacts: The persons responsible for the above information (e.g. 64 | SD, PL). 65 | 66 | 2 Distributed software material 67 | 68 | This is the actual bill of material, and since a software product may contain 69 | several separate components, this section may need to be repeated as often as 70 | necessary. Every section lists the following items: 71 | 72 | - Name: Unique name of the software component. 73 | 74 | ######################################## 75 | - Optional: Brief description: A quick overview about the software component 76 | and its intended use cases. 77 | ######################################## 78 | - Optional: Asset ID: Unique ID to be referenced to our company's inventory list. 79 | ######################################## 80 | 81 | - Version number 82 | 83 | - Release date: The release date of the current version. 84 | 85 | ######################################## 86 | - Optional if BOM is not internal: Provider: Name of the person or company that 87 | provides the software component. If the software has been developed in-house and 88 | the BOM is required for a compliant delivery of a product that contains this 89 | software, "in-house" should be specified here. 90 | ######################################## 91 | - Optional: if BOM is not internal: Provider contact: Full contact data of the 92 | provider, may be external or internal. 93 | ######################################## 94 | - Optional if BOM is not internal: Provider URL: URL of the provider, required 95 | if external, optional if internal. 96 | ######################################## 97 | - Optional: Source and/or object code: This specifies whether in its final state 98 | of the software component, i.e. when it is externally delivered or released for 99 | in-house use, the software component is available in source code or object code form 100 | or both. 101 | ######################################## 102 | - Optional: Programming languages: The programming languages employed, may be left 103 | undefined, if the software component is only available in object code form and 104 | the programming language is unknown. 105 | ######################################## 106 | - Optional: Acquisition mode: How was the software component acquired, multiple 107 | selections may be specified if applicable. 108 | - CD, DVD or similar 109 | - USB Stick 110 | - Download, this requires that the URL from where the software component was 111 | downloaded is additionally specified. 112 | - Integrated in hardware 113 | ######################################## 114 | 115 | - Licenses: This is the most important section of the BOM. All applicable 116 | licenses of this software component must be given. The preferred form is to use 117 | SPDX specifiers of the licenses. In case a selection may be made from several 118 | licenses (e.g. dual licensing) this must be noted. 119 | 120 | ######################################## 121 | - Optional: Remarks: Additional information. 122 | ######################################## 123 | 124 | - In-house contacts: The responsible person(s) at the PD and the SD must be 125 | given here. 126 | 127 | 3 Bill of Dependencies (BOD) 128 | 129 | A software product may be conveyed as a separate trade item but may require additional 130 | software components such as a standard library of the employed programming language 131 | at runtime. Such additional software components must be listed here. 132 | 133 | ######################################## 134 | - Optional: Source of information: The dependency information may have been 135 | obtained from the provider and/or immediately extracted from the code by our 136 | engineering department. 137 | ######################################## 138 | 139 | - In-house contacts: The responsible person(s) at the provider and/or in-house 140 | (SD or PL) must be given here. 141 | 142 | - Required software components: Finally and most importantly, the required 143 | software components must be listed. They shall be differentiated in two 144 | categories whether they form a derivative work with the software product 145 | described herein, or whether the two merely constitute an aggregate of 146 | independent pieces of software. 147 | 148 | 4 Approval 149 | 150 | The final section of the BOM contains the name of the responsible person at the 151 | LD who approved the BOM along with place, date and signature. 152 | 153 | Bill of Material 154 | 1 General information on the software product 155 | 156 | Name: 157 | 158 | Company/department: 159 | 160 | Optional: Brief description: 161 | 162 | Optional: Third-party or in-house developed product: 163 | O Third-party 164 | O In-house development 165 | 166 | Optional: Asset ID: 167 | 168 | Version number: 169 | 170 | Release date: 171 | 172 | Optional: Remarks: 173 | 174 | In-house contacts (SD or PL): 175 | 176 | 2 Distributed software material #1 177 | 178 | Name: 179 | 180 | Optional: Brief description: 181 | 182 | Optional: Asset ID: 183 | 184 | Version number: 185 | 186 | Release date: 187 | 188 | Optional if BOM is not internal: 189 | Provider: 190 | Provider contact: 191 | Provider URL: 192 | 193 | Optional: Source and/or object code: 194 | O Source 195 | O Object 196 | 197 | Optional: Programming language(s): 198 | 199 | Optional: Acquisition mode: 200 | O CD, DVD 201 | O USB stick 202 | O Download, Download URL if applicable 203 | O Integrated in hardware 204 | 205 | Licenses (in SPDX format): 206 | 207 | Optional: Remarks: 208 | 209 | In-house contacts: 210 | PD: 211 | SD: 212 | 213 | 3 Dependencies 214 | 215 | Optional: Source of information: 216 | O Obtained from provider 217 | O Extracted here from code 218 | 219 | In-house contact (SD or PL): 220 | 221 | Required software (derivative work): 222 | 223 | Required software (mere aggregate): 224 | 225 | 4 Approval 226 | 227 | In-house contact (LD): 228 | 229 | Approval: 230 | O Approved for in-house use 231 | O Approved for distribution 232 | 233 | Place and date: 234 | 235 | Signature: 236 | -------------------------------------------------------------------------------- /Annexes/Contribution-Permission.txt: -------------------------------------------------------------------------------- 1 | %########################################################################### 2 | % 3 | % Annex to the OSADL Open Source Policy Template 4 | % 5 | % Copyright (c) 2019,2020 Open Source Automation Development Lab (OSADL) eG 6 | % Author: Carsten Emde, Caren Kresse 7 | % 8 | %########################################################################### 9 | 10 | Contribution permission 11 | 12 | 13 | Before any of our employees can contribute to a FOSS project, they must request 14 | and obtain a contribution permission by completing one of the forms at the end 15 | of this document. The first form grants a one-time permission for a specific 16 | contribution while the second form grants a universal contribution permission 17 | for a specific project. To grant a contribution permission, a signatory of our 18 | company must sign this form. 19 | ======================================== 20 | Apart from the specified contribution permissions (one-time and general for a 21 | specific project) it might also be considered to grant a general permission to a 22 | specific contributor. 23 | ======================================== 24 | 25 | Below, some explanations are given on the required information. 26 | 27 | - Developer: Full name of the developer to whom the right is granted to 28 | contribute the specified software to the specified FOSS project under the 29 | specified license in the name of our company 30 | 31 | - Department: Full name and or abbreviation of the company department the 32 | developer belongs to 33 | 34 | - Software components to be contributed: Specific software components that are 35 | intended to be contributed; only required for a one-time contribution permission 36 | 37 | - Software project: The full name of the FOSS project 38 | 39 | - License(s): SPDX Identifier(s) of the license(s) under which the contributed 40 | code will be published 41 | 42 | - Repository: URL of the repository or the shared Internet folder where the 43 | software will be made available 44 | 45 | - Mailing list: URL and email address of the corresponding mailing list where 46 | code snippets, comments, ideas, proposals, reviews etc. are exchanged 47 | 48 | - Start of validity of the permission: Date; only required for a general 49 | contribution permission 50 | 51 | - End of validity of the permission: Date or "until further notice"; only 52 | required for a general contribution permission 53 | 54 | - Internal review: Must be specified whether required or not and, if so, by whom 55 | 56 | - Signed-off-by: Name : Name and email address to be used in the 57 | Signed-off-by: tag of a commit message. 58 | ======================================== 59 | This is particularly important, since many FOSS projects require this tag and 60 | understand that the person who signed it takes full responsibility that a 61 | contribution permission was granted and that the code does not contain 62 | procedures or works that are known to be protected by third-party rights. The 63 | given name must be the name of a natural person, however, it may be a good idea 64 | to provide an email address of the related department such as 65 | software@company.tld to ensure that a knowledgeable person can be contacted in 66 | the event that the developer has left the company. 67 | ======================================== 68 | 69 | - Signatures: Person(s) authorized to sign documents on behalf of our company 70 | must sign this contribution permission as we hold the exclusive rights of use of 71 | the specified software to be contributed. To accept the permission the developer 72 | must also sign. 73 | 74 | 75 | One-time contribution permission 76 | 77 | Hereby, permission is granted to the named developer to license the named 78 | software components developed in the course of his or her employment in the name 79 | of the company under the stated license and to share the same through the stated 80 | repository and/or mailing list. Individual files must carry a copyright notice 81 | and license notice according to the guidelines set by our FOSS policy. Existing 82 | or new license notices must correspond to the license(s) stated in this 83 | permission. 84 | 85 | Developer: 86 | 87 | Department: 88 | 89 | Software components to be contributed: 90 | 91 | FOSS project: 92 | 93 | License(s): 94 | 95 | Repository URL: 96 | 97 | Mailing list URL: 98 | 99 | Mailing list email address: 100 | 101 | Review required: 102 | 103 | Optional: Reviewer: 104 | 105 | Signed-off-by: Name: 106 | 107 | Signed-off-by: Email address: 108 | 109 | 110 | Signatures 111 | 112 | Place, date: 113 | Signatory: 114 | (Optional: Second signatory): 115 | 116 | Place, date: 117 | Developer: 118 | 119 | 120 | 3 General contribution permission 121 | 122 | Hereby, a universal permission is granted to the named developer to license 123 | software components developed in the course of his or her employment in the name 124 | of the company under the stated license and to share the same through the stated 125 | repository and/or mailing list. Individual files must carry a copyright notice 126 | and license notice according to the guidelines set by our FOSS policy. Existing 127 | or new license notices must correspond to the license(s) stated in this 128 | permission. 129 | 130 | Developer: 131 | 132 | Department: 133 | 134 | Software project: 135 | 136 | License(s): 137 | 138 | Repository URL: 139 | 140 | Mailing list URL: 141 | 142 | Mailing list email address: 143 | 144 | Start of validity of this permission: 145 | 146 | End of validity of this permission: 147 | O or until further notice 148 | 149 | Review required: 150 | 151 | Optional: Reviewer: 152 | 153 | Signed-off-by: Name: 154 | 155 | Signed-off-by: Email address: 156 | 157 | 158 | Signatures 159 | 160 | Place, date: 161 | Signatory: 162 | (Optional: Second signatory): 163 | 164 | Place, date: 165 | Developer: 166 | -------------------------------------------------------------------------------- /Annexes/Copyleft-Policy.txt: -------------------------------------------------------------------------------- 1 | %########################################################################### 2 | % 3 | % Annex to the OSADL Open Source Policy Template 4 | % 5 | % Copyright (c) 2019,2020 Open Source Automation Development Lab (OSADL) eG 6 | % Author: Carsten Emde, Caren Kresse 7 | % 8 | %########################################################################### 9 | 10 | Copyleft policy 11 | 12 | This document lists FOSS licenses that we consider to have a copyleft clause. 13 | The extend of the copyleft clause is categorized as "strong" (i.e. any 14 | derivative work is affected) or "weak" (i.e. separable linked components are not 15 | affected). Section 2 describes how we handle the use of copyleft licenses in our 16 | products. 17 | ======================================== 18 | After review, this list of copyleft licenses may instead be included in the -> 19 | "List of known licenses". 20 | ======================================== 21 | 22 | 1 Copyleft licenses 23 | 24 | The vast majority of licenses clearly state whether they contain a so-called 25 | copyleft clause (for explanations see -> "What is copyleft?"). It is generally 26 | agreed that this is the case for the licenses given in table Table 1. In 27 | addition to the name of the license, the SPDX Identifier and the extend of the 28 | copyleft is given. The latter may be "strong", requiring that the original 29 | license must always be used, or "weak", indicating that linked, but separable 30 | libraries may be licensed under a license of choice. 31 | 32 | ======================================== 33 | Interpretations of the extend of strong copyleft clauses are heterogeneous. This 34 | policy should therefore reflect the company's individual interpretation. The 35 | Supplement -> "What is a derivative work?" gives guidelines for such an 36 | interpretation. 37 | ======================================== 38 | 39 | License name (SPDX Identifier): Scope of copyleft 40 | 41 | GNU Affero General Public License v3.0 (AGPL-3.0): Strong 42 | Common Development and Distribution License 1.0 (CDDL-1.0): Weak 43 | Common Public License 1.0 (CPL-1.0): Strong 44 | Eclipse Public License 1.0 (EPL-1.0): Strong 45 | Eclipse Public License 2.0 (EPL-2.0): Weak 46 | European Union Public License 1.1 (EUPL-1.1): Strong 47 | GNU General Public Liense v2.0 (GPL-2.0): Strong 48 | GNU General Public Liense v3.0 (GPL-3.0): Strong 49 | IBM Public License Version 1.0 (IPL-1.0): Strong 50 | GNU Lesser General Public License v2.1 (LGPL-2.1): Weak 51 | GNU Lesser General Public License v3.0 (LGPL-3.0): Weak 52 | Mozilla Public License 1.1 (MPL-1.1): Weak 53 | Mozilla Public License 2.0 (MPL-2.0): Weak 54 | Microsoft Reciprocal License (MS-RL): Strong 55 | Open Software License 3.0 (OSL-3.0): Strong 56 | Reciprocal Public License 1.5 (RPL-1.5): Weak 57 | 58 | Table 1: Copyleft licenses 59 | 60 | Questionable copyleft 61 | ======================================== 62 | Unfortunately, some licenses are less clear with respect to their copyleft 63 | status, since there are good arguments for various views. If software that is 64 | licensed under such licenses, is going to be included in a product and 65 | distributed along with it, a decision must be made on how to handle these 66 | licenses. Table 2 lists the three most popular licenses with an unclear copyleft 67 | status. For possible interpretations see -> "OSADL Open Source License 68 | Obligations Checklists". 69 | ======================================== 70 | 71 | License name (SPDX Identifier): Scope of copyleft 72 | 73 | Boost Software License 1.0 (BSL-1.0): 74 | Option 1: Strong 75 | Option 2: Weak 76 | Option 3: None 77 | 78 | Microsoft Public License (MS-PL): 79 | Option 1: Strong 80 | Option 2: Weak 81 | Option 3: None 82 | 83 | OpenSSL License (OpenSSL-1.0): 84 | Option 1: Strong 85 | Option 2: Weak 86 | Option 3: None 87 | 88 | Table 2: Licenses with an unclear copyleft status 89 | 90 | ======================================== 91 | Table 1 may need to be extended if one or more of the licenses listed in Table 2 92 | are considered to be copyleft licenses. 93 | ======================================== 94 | 95 | 2 Using copyleft licenses in our products 96 | 97 | ======================================== 98 | Since many standard libraries are licensed under a copyleft license, it may 99 | appear impossible or at least very difficult to abandon copyleft licenses 100 | altogether. However, some management may decide to do so and, in consequence, 101 | this topic should be discussed and decided upon. 102 | ======================================== 103 | 104 | ######################################## 105 | Option 1: As a general rule, FOSS that is licensed under a copyleft license may 106 | not be used in our products. 107 | ######################################## 108 | Option 2: There is no general restriction on the use of FOSS that is licensed 109 | under a copyleft license. However, individual projects may define per-project 110 | rules on combining FOSS under copyleft licenses with proprietary software of our 111 | company. 112 | ######################################## 113 | 114 | This is appropriately noted in the lower part of the -> "Compatibility Matrix" 115 | that is an Annex to this FOSS policy. 116 | -------------------------------------------------------------------------------- /Annexes/Deny-List.txt: -------------------------------------------------------------------------------- 1 | %########################################################################### 2 | % 3 | % Annex to the OSADL Open Source Policy Template 4 | % 5 | % Copyright (c) 2019,2020 Open Source Automation Development Lab (OSADL) eG 6 | % Author: Caren Kresse 7 | % 8 | %########################################################################### 9 | 10 | Deny List 11 | 12 | Annex to Open Source Policy Template (Reference edition) 13 | 14 | This document lists FOSS licenses that we consider not suitable for use in any 15 | project. These licenses can never be approved for use in our company. 16 | 17 | 18 | -------------------------------------------------------------------------------- /Annexes/FOSS-in-ToU.txt: -------------------------------------------------------------------------------- 1 | %########################################################################### 2 | % OSADL Open Source Policy Template for License Compliance 3 | % 4 | % Annex with template texts for Terms of Use or EULA with regard to FOSS. 5 | % 6 | % Copyright (c) 2021 Open Source Automation Development Lab (OSADL) eG 7 | % 8 | %########################################################################### 9 | 10 | FOSS in Terms and Conditions 11 | 12 | Annex to Open Source Policy Template 13 | 14 | ============================================================================ 15 | If FOSS and proprietary development is jointly contained in a product and a 16 | company's own license terms shall be used for the proprietary development, care 17 | must be taken to ensure that these license terms are not in conflict with the 18 | FOSS license terms. If restrictions of use are applied to the whole software, a 19 | contradiction arises with regard to the freedoms of use granted by FOSS 20 | licenses. It is therefore strongly recommended to expressly limit the 21 | application of the proprietary license terms to the software components to which 22 | they apply. This may, for example, be done by using the following clause in a 23 | company's licenses, General Terms and Conditions, Terms of Use (ToU) or End User 24 | License Agreements (EULA): 25 | ============================================================================ 26 | 27 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 28 | English 29 | 1. Our products may contain Free and Open Source software (FOSS). According to 30 | the Open Source definition by the Open Source Initiative 31 | (https://opensource.org/osd) FOSS is software which is licensed by the 32 | respective holders of rights to everyone with extensive rights of use and 33 | without license fees and for which the source code is available. A list of the 34 | concerned software components and the respectively applicable license 35 | conditions as well as additional information on the availability of source 36 | code) are delivered along with the product. As long as the customer only uses 37 | the FOSS components internally, there are no license obligations for the 38 | customer towards the holders of rights of these FOSS components. However, the 39 | customer may additionally obtain a simple right of use for the contained FOSS 40 | from the respective holders of rights under the respective FOSS license 41 | conditions. Every use of FOSS on the basis of these FOSS licenses and outside 42 | of the intended use of our products is undertaken at the customer's own risk 43 | and is not subject to the contractual relationship with us. 44 | 45 | 2. Our General Terms and Conditions also apply to those products that contain 46 | FOSS, they do, however, not restrict the rights of use and freedoms of use 47 | granted by the FOSS licenses. Insofar, the FOSS licenses take precedence over 48 | these General Terms and Conditions. 49 | 50 | 3. The customer is permitted to modify our software components for the 51 | customer's own use and to perform reverse engineering of our software 52 | components for debugging of such modifications if these software components are 53 | linked with libraries licensed under the GNU Lesser General Public License 54 | (LGPL). However, forwarding the knowledge acquired during reverse engineering or 55 | forwarding modified software to third parties is prohibited. 56 | 57 | 4. Warranty for defects of our products that are due to a modification of FOSS 58 | is excluded. The customer bears the burden of proof that a defect of our 59 | product would also occur without the modification of the contained FOSS. 60 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 61 | 62 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 63 | Deutsch 64 | 1. Unsere Produkte können Free und Open Source Software (FOSS) enthalten. 65 | FOSS ist entsprechend der Open Source Definition der Open Source Initiative 66 | (https://opensource.org/osd) Software, die von den jeweiligen Rechteinhabern an 67 | jedermann zur umfassenden lizenzgebührenfreien Nutzung lizenziert wird und 68 | deren Sourcecode verfügbar ist. Eine Auflistung der davon betroffenen 69 | Software-Komponenten und der jeweils anwendbaren Lizenzbedingungen sowie 70 | weitergehende Informationen (z.B. zum Erhalt von Quellcode) werden dem Kunden 71 | zusammen mit dem Produkt übergeben. Solange der Kunde die FOSS-Komponenten 72 | ausschließlich intern benutzt, hat der Kunde keine Lizenzpflichten gegenüber 73 | den Rechteinhabern dieser FOSS-Komponenten. Der Kunde kann an der verwendeten 74 | FOSS von den jeweiligen Rechteinhabern jedoch zusätzlich ein einfaches Nutzungsrecht 75 | unter den Bedingungen erwerben, die die dafür jeweils anwendbaren FOSS-Lizenzen 76 | vorsehen. Jede Nutzung von FOSS auf der Basis dieser FOSS-Lizenzen und außerhalb 77 | der in unseren Produkten vorgesehenen Verwendung geschieht auf eigenes Risiko des 78 | Kunden und ist nicht Gegenstand des Vertragsverhältnisses mit uns. 79 | 80 | 2. Unsere Allgemeinen Geschäftsbedingungen gelten auch für die Produkte, die 81 | FOSS enthalten, beschränken jedoch nicht die in den FOSS-Lizenzen gewährt 82 | Nutzungsrechte und Nutzerfreiheiten. Die FOSS-Lizenzen gehen diesen Allgemeinen 83 | Geschäftsbedingungen insoweit vor. 84 | 85 | 3. Es ist dem Kunden gestattet, Software-Komponenten, die von uns stammen, 86 | für den eigenen Gebrauch des Kunden zu bearbeiten und zur Behebung von Fehlern 87 | solcher Bearbeitungen ein Reverse-Engineering vorzunehmen, sofern diese 88 | Software-Komponenten mit Programmbibliotheken unter der GNU Lesser General 89 | Public License (LGPL) verlinkt sind. Die Weitergabe der bei dem 90 | Reverse-Engineering gewonnen Informationen und der bearbeiteten Software ist 91 | hingegen nicht gestattet. 92 | 93 | 4. Die Gewährleistung für Mängel unserer Produkte, die auf einer Bearbeitung 94 | von FOSS beruhen, ist ausgeschlossen. Der Kunde trägt die Beweislast, dass 95 | ein Mangel unseres Produktes auch ohne die Bearbeitung der enthaltenen FOSS 96 | aufgetreten wäre. 97 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 98 | -------------------------------------------------------------------------------- /Annexes/FOSS-in-external-development.txt: -------------------------------------------------------------------------------- 1 | %########################################################################### 2 | % 3 | % OSADL Open Source Policy Template for License Compliance 4 | % 5 | % Annex on Outsourcing FOSS development. 6 | % 7 | % Copyright (c) 2021-2022 Open Source Automation Development Lab (OSADL) eG 8 | % 9 | %########################################################################### 10 | 11 | FOSS in external development 12 | 13 | When commissioning an external party (e.g. freelancer, supplier) to develop 14 | software that includes FOSS, it must be ensured that the external party adheres 15 | to the required standards of FOSS compliance. A template for the related 16 | sections of a contract with an external party is given below. 17 | 18 | ============================================================================ 19 | Please note that the proposed wording of the texts given in this document are 20 | general templates that must be reviewed by a company's legal counsel before 21 | they can be used. 22 | ============================================================================ 23 | 24 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 25 | This contract rules the handling of FOSS in the context of software developed 26 | by the external party and COMPANY. All software delivered to COMPANY under 27 | this contract by the external party is hereafter referred to as "Software 28 | Product". 29 | 30 | 1. Aim 31 | The provisions laid out in this contract aim to ensure that the Software 32 | Product delivered by the external party can be copied and distributed in 33 | compliance with the applicable licenses by COMPANY. 34 | 35 | 2. Scope 36 | The provisions laid out in this contract apply to the entire Software Product. 37 | The provisions of this contract shall prevail within their scope over our other 38 | contracting conditions and the General Terms and Conditions of the external 39 | party. 40 | 41 | 3. Definition 42 | 3.1 Free and Open Source Software ("FOSS") for the purpose of this contract 43 | is software the license of which meets the requirements of the "Open Source 44 | Definition" (https://opensource.org/osd) of the Open Source Initiative and/or 45 | is registered in the publicly accessible lists of Free Licenses and Open Source 46 | Licenses of the Free Software Foundation and/or the Open Source Initiative, 47 | respectively. 48 | 49 | 3.2 The provisions laid out in this contract apply accordingly to software that 50 | is dedicated to the Public Domain by the copyright holder. 51 | 52 | 4. Verification and information obligations of the external party 53 | The external party shall be aware that non-compliance with the license 54 | obligations for FOSS may result in aviolation of copyright law, and thus, in 55 | defects of title of the Software Product. The external party alone is 56 | responsible for meeting the license conditions of all FOSS that is included in 57 | the Software Product. This also applies to embedded systems as well as firmware 58 | updates and any other software distribution. 59 | 60 | The external party must check any pre-existing software that is included in the 61 | Software Product for FOSS. This applies accordingly for software that the 62 | external party received from their suppliers. The external party commits to 63 | comply with the standard for Open Source License Compliance, ISO 5230, i.e. the 64 | current OpenChain Standard Version (2.0 or later) (See 65 | https://wiki.linuxfoundation.org/_media/openchain/openchainspec-current.pdf). 66 | 67 | =============================================================================== 68 | If the contracting party wishes to offer assistance to the external party to 69 | implement the OpenChain standard, e.g. by offering access to the contracting 70 | party's own FOSS policy and/or by offering use of their compliance tooling 71 | infrastructure to the external party, the following text passages can be 72 | included. If so, please check that all requirements of the applicable data 73 | protection law are complied with. 74 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 75 | If desired, the external party has the right to get access to COMPANY'S FOSS 76 | policy and/or the tooling infrastructure implemented in our company to achieve 77 | compliance. 78 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 79 | =============================================================================== 80 | 81 | 5. FOSS documentation 82 | At the latest with delivery of the Software Product the external party must 83 | provide COMPANY with 84 | 85 | - a "Bill of Material" ("BOM"), a list of the used FOSS components, 86 | corresponding version number and respective FOSS licenses as SPDX identifier 87 | (https://spdx.org/licenses/) including all dependencies, and 88 | 89 | - a document for the compliance with the FOSS licenses ("Open Source Content 90 | Documentation") which contains all license texts and copyright notices with 91 | regard to the respective files in Debian DEP-5 format 92 | (http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/), or SPDX 93 | format (https://spdx.org/spdx-specification-21-web-version) or other 94 | standardized format and additionally all further information that must be 95 | provided when distributing the software according to the applying licenses, and 96 | 97 | - the complete and corresponding source code of FOSS contained in the Software 98 | Product. 99 | 100 | 6. Use of copyleft licenses 101 | 6.1 The external party must ensure that copyleft-licensed software is used in 102 | the Software Product only in a way that does not bear the risk that COMPANY 103 | must license own software and/or third party software components as FOSS when 104 | used in combination with the Software Product without having obtained a prior 105 | approval from COMPANY for this purpose. Copyleft licenses are FOSS licenses 106 | that contain the requirement to license all or defined modifications of the 107 | software or software combinations as FOSS when the modifications or software 108 | combinations are redistributed or used by third parties. 109 | 110 | 6.2 The external party ensures that the license conditions of all software 111 | components linked with FOSS licensed under the GNU Lesser General Public 112 | License allow any user of the software modification of these software 113 | components and reengineering for debugging such modifications. 114 | 115 | 6.3 The external party ensures that COMPANY will be provided with all 116 | necessary information required to enable the customer to perform compilation 117 | and reinstallation of FOSS licensed under the GNU Lesser General Public 118 | License, the GNU General Public License and the GNU Affero General Public 119 | License (if applicable), especially in case the product is an embedded system. 120 | 121 | 7. Guarantee 122 | The external party guarantees that the Software Product does not violate any 123 | third-party copyrights and that the license conditions of all FOSS and 124 | third-party software are complied with. 125 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 126 | 127 | 2. Contributing externally developed software to a FOSS project 128 | In case the software developed by the external party is intended to be licensed 129 | under a FOSS license and contributed to a FOSS project or published as a new 130 | FOSS project, there are different scenarios of how to handle the rights on the 131 | created software. The following templates can be added to the general contract 132 | on FOSS in outsourced development given above. 133 | 134 | - Rights remain with the external party 135 | Ownership in the copyrights of the developed software remain with the external 136 | party. The work contract stipulates that all software is licensed under the FOSS 137 | license agreed-upon by all parties in advance and either contributed to a 138 | public repository or delivered to the customer directly. 139 | 140 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 141 | The external party will retain the copyright ownership for all software 142 | developed as part of this contract. They will license all such software under 143 | the specified FOSS license(s). They will ensure that no third-party rights are 144 | violated by this licensing, in particular with respect to patents and 145 | compatibility of all involved FOSS licenses. 146 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 147 | 148 | - Credit 149 | Rights remain with the external party, but the company is credited in the file 150 | headers. In this case, the template wording of KeepRights will be extended by 151 | the following addition: 152 | 153 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 154 | The external party agrees to place the following acknowledgment within the file 155 | headers of all software developed as part of this contract. 156 | 157 | Support by COMPANY is gratefully acknowledged. 158 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 159 | ============================================================================ 160 | Please note that most FOSS licenses do not require such an acknowledgment to be 161 | delivered along with a binary distribution of the software. If this is desired, 162 | the acknowledgment should be included in the copyright notice. 163 | ============================================================================ 164 | 165 | - Repository 166 | Rights remain with the external party, but the software is licensed under a 167 | specified FOSS license and published on a specified repository. In case the 168 | software is contributed to an existing project, the external party additionally 169 | goes through the contribution process until the contribution is accepted. In 170 | this case, the template wording of KeepRights can be extended by the following 171 | addition: 172 | 173 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 174 | The external party agree to contribute the software developed as part of this 175 | contract to the specified repository or FOSS project. This includes following 176 | the project's contribution process and integrating any required changes until 177 | the contribution is accepted. 178 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 179 | 180 | In case the software is released as a new FOSS project, the external party is 181 | commissioned to maintain the repository and take care of contributions from 182 | third parties. In this case, the template wording of KeepRights can be extended 183 | by the following addition: 184 | 185 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 186 | The external party agree to publish the software developed as part of this 187 | contract on the specified repository. In addition, they will maintain the 188 | published software for number of years. This includes reviewing and integrating 189 | contributions from third parties, tracking security issues and updating the 190 | software accordingly. 191 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 192 | 193 | - All rights are transferred (software buyout) 194 | The work contract stipulates that the copyright ownership is transferred 195 | entirely to the customer on delivery of the software. 196 | 197 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 198 | (1) The external party shall grant COMPANY all economic rights in the software 199 | which the external party creates for the purpose of fulfilling the contractual 200 | relationship. With regard to the rights of use, COMPANY shall thus be provided 201 | with the same rights as if the software had been created in an employment 202 | relationship pursuant to Section 69b) (1) German Copyright Act. COMPANY is 203 | authorized to transfer the acquired rights of use and/or to grant non-exclusive 204 | rights of use thereto, in particular to publish the software under any open 205 | source license and to license it to all third parties. 206 | 207 | (2) At the request of the developers involved, these may be named as authors in 208 | the source code, with the external party using copyright and author notices 209 | according to the following syntax: 210 | 211 | Copyright (c) [year] COMPANY, authors: [name of author optional] 212 | 213 | The external party shall ensure that the source code contains the copyright 214 | notices of the developers who wish to be named, at the time the software is 215 | supplied to COMPANY. 216 | 217 | (3) If the external party uses pre-existing FOSS in the development of the 218 | software, a complete list of the used FOSS with the following information shall 219 | be provided upon delivery of the software: 220 | 221 | - Name and version of the FOSS, 222 | - FOSS license(s) as SPDX identifier (https://spdx.org/licenses/) and a 223 | - license information document for the distribution of the software to 224 | third parties. 225 | 226 | This license information document shall contain all FOSS license texts and 227 | copyright notices of the used FOSS. The external party shall ensure that the 228 | license compatibility of the FOSS used in the software is maintained. 229 | Alternative to the previous sentence: COMPANY wishes to offer the software 230 | under the following FOSS license: name of FOSS license (e.g. GNU General Public 231 | License, Version 3). The external party shall ensure that only such 232 | pre-existing FOSS is used which has licenses compatible with name of FOSS 233 | license (e.g. GNU General Public License, Version 3). 234 | 235 | (4) The software shall be delivered in source code form with documentation and 236 | the FOSS license information document. 237 | 238 | (5) Additional option: Notwithstanding paragraph, COMPANY shall not acquire 239 | any exclusive rights to the software components in Annex A, but shall rather be 240 | granted the perpetual, worldwide and unrestricted non-exclusive, irrevocable 241 | right to exploit the software in any known and unknown way and to reproduce, 242 | distribute, adapt and make the software available to the public and to 243 | sublicense it to this extent. The paragraphs shall apply accordingly; the 244 | external party shall be named as copyright owner in the copyright notice. 245 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 246 | 247 | =========================================================================== 248 | For software buyouts where contract law of a country from outside the EU 249 | applies - in particular in the US - the wording of a buyout clause will be 250 | different. The following text can give some reference points on what needs to be 251 | considered. Please note that the wording in particular of the text given below 252 | is a proposal that must be reviewed by a company's legal counsel before it can 253 | be used. 254 | =========================================================================== 255 | 256 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 257 | Subject to the terms and conditions of this Agreement, external party hereby 258 | grants to COMPANY a worldwide, royalty-free, exclusive, perpetual and 259 | irrevocable license, with the right to transfer an unlimited number of 260 | non-exclusive licenses or to grant sublicenses to third parties, under the 261 | Copyright covering the software to use the software by all means, including, 262 | but not limited to: 263 | 264 | - publish the software, 265 | - modify the software, 266 | - prepare derivative works based upon or containing the software and/or to 267 | combine the software with other programs, 268 | - reproduce the software in original or modified form, 269 | - distribute, to make the software available to the public, display and 270 | publicly perform the software in original or modified form. 271 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 272 | -------------------------------------------------------------------------------- /Annexes/GPL-Encryption.txt: -------------------------------------------------------------------------------- 1 | %########################################################################### 2 | % OSADL Open Source Policy Template for License Compliance 3 | % 4 | % Annex with template texts for distributing encrypted GPL software. 5 | % 6 | % Copyright (c) 2021 Open Source Automation Development Lab (OSADL) eG 7 | % 8 | %########################################################################### 9 | 10 | Encryption and GPL - Template texts 11 | 12 | Annex to Open Source Policy Template 13 | 14 | Send-in solution 15 | The following template text must be used to inform recipients of encrypted 16 | software licensed under a GNU General Public License how the send-in solution 17 | [unlocking variant / installation variant] for installing their own software 18 | versions works. 19 | 20 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 21 | English: 22 | The safety of this product is of great importance to us. Therefore, as a rule, 23 | modified versions of the deployed Open Source software can only be installed 24 | [if the security features in use are removed by us / if this is enabled by us]. 25 | Please note that the installation of modified software can entail that possible 26 | safety requirements on the product are no longer fulfilled and that 27 | consequently, it can no longer be used in the originally intended way. 28 | 29 | If you still wish to install modified versions of the software components 30 | licensed under the GNU General Public License (GPL) and/or the GNU Lesser 31 | General Public License (LGPL), please contact (open-source@company.tld) noting 32 | that you would like to install own versions of the software on your device. You 33 | will then receive all necessary information to return the device to us 34 | [including the software to be installed. The latter must contain adequate 35 | installation information]. 36 | 37 | In order to comply with our license obligations towards the GPL and/or LGPL 38 | licensors, we will remove the security features in use, [thereby enabling you 39 | to install GPL and/or LGPL software, / install your GPL and/or LGPL software,] 40 | remove our trademarks from the product, and return the product to you. However, 41 | redistribution of the product with modified software is not permitted as 42 | exhaustion of the distribution right cannot occur for the specific copy. Also 43 | the use of the product may be prohibited if it violates any legal provisions. 44 | It is your responsibility to check whether the use is permissible in the 45 | specific case or to obtain the required permits. The warranty is void for any 46 | defects related to the use of modified software. 47 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 48 | 49 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 50 | Deutsch: 51 | Die Sicherheit dieses Produktes ist für uns von großer Wichtigkeit. Daher 52 | können modifizierte Versionen der verwendeten Open Source-Software im Regelfall 53 | nur installiert werden, [wenn die verwendeten Sicherheitsfeatures durch uns 54 | entfernt werden / wenn dies durch uns ermöglicht wird]. Bitte beachten Sie, 55 | dass die Installation modifizierter Software dazu führen kann, dass eventuell 56 | geltende Sicherheitsanforderungen an das Produkt nicht mehr erfüllt werden und 57 | dieses dann nicht mehr in der ursprünglich vorgesehenen Form genutzt werden 58 | kann. 59 | 60 | Wenn Sie dennoch modifizierte Versionen der Softwarekomponenten installieren 61 | möchten, die unter der GNU General Public License (GPL) und/oder der GNU Lesser 62 | General Public License (LGPL) lizenziert sind, kontaktieren Sie bitte 63 | (open-source@company.tld) mit dem Hinweis, dass Sie eigene Versionen der 64 | Software auf Ihr Gerät installieren möchten. Sie erhalten sodann alle 65 | notwendigen Informationen für die Rücksendung des Gerätes an uns [und die 66 | Lieferung der zu installierenden Software. Letztere muss hinreichende 67 | Installationsinformationen enthalten]. 68 | 69 | Wir werden dann zur Erfüllung unserer Lizenzpflichten gegenüber den GPL- 70 | und/oder LGPL-Lizenzgebern die verwendeten Sicherheitsfeatures entfernen, 71 | [Ihnen dadurch die Installation von GPL- und/oder LGPL-Software ermöglichen, / 72 | Ihre GPL- und/oder LGPL-Software installieren,] unsere Marken vom Produkt 73 | entfernen und das Produkt wieder an Sie zurücksenden. Die Weiterverbreitung des 74 | Produkts mit modifizierter Software ist allerdings nicht gestattet, weil am 75 | konkreten Vervielfältigungsstück keine Erschöpfung des Verbreitungsrechtes 76 | eintreten kann. Auch die Verwendung des Produkts kann verboten sein, wenn es 77 | gegen gesetzliche Bestimmungen verstößt. Es obliegt Ihnen zu überprüfen, ob 78 | die Verwendung im konkreten Fall zulässig ist bzw. die dafür erforderlichen 79 | Genehmigungen einzuholen. Die Gewährleistung erlischt für alle Mängel, die 80 | auf der Verwendung modifizierter Software beruhen. 81 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 82 | 83 | 84 | Encryption together with differently licensed components 85 | 86 | The following template text must be used to inform recipients of software 87 | licensed under a GNU General Public License that is encrypted together with 88 | differently licensed components how they can decrypt the GPL-components and 89 | what consequences result from such actions. 90 | 91 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 92 | English: 93 | Dear Customer, 94 | the purchased device contains software that was encrypted for security and/or 95 | safety reasons. However, the license of some of the software components 96 | requires enabling installation of your own version of such software. Therefore, 97 | the key to decrypt the software is included in the delivery of the product. 98 | 99 | In the event that you exercise your right, i.e., decrypt the software and 100 | install your own software, we would like to point out the following 101 | consequences: 102 | 103 | - The principle of exhaustion does not apply with respect to the trademarks in 104 | case the software was modified. Redistribution of the product with our 105 | trademarks on it is therefore not permitted without our consent. 106 | 107 | - The warranty expires for all defects that are caused by the modification of 108 | the software. 109 | 110 | - You may be held liable for damages that may result from the use of the 111 | product with modified software, especially if you allow third parties to use 112 | it. 113 | 114 | - The use of the product may be prohibited if it violates legal regulations. It 115 | is your responsibility to check whether the use is permitted in the specific 116 | case or to subject the product to the required certification. 117 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 118 | 119 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 120 | Deutsch: 121 | Sehr geehrter Kunde, 122 | das von Ihnen erworbene Gerät enthält Software, die wir aus 123 | Sicherheitsgründen verschlüsselt haben. Allerdings verlangt die Lizenz der 124 | Software, dass wir Ihnen den Schlüssel verfügbar machen, so dass Sie eigene 125 | Versionen der so lizenzierten Softwarekomponenten selbständig aufspielen 126 | können. 127 | 128 | Für den Fall, dass Sie von diesem Recht Gebrauch machen, d.h. die Software 129 | entschlüsseln und eigene Software aufspielen, weisen wir auf folgende 130 | Konsequenzen hin: 131 | 132 | - Der markenrechtliche Erschöpfungsgrundsatz greift bei einer Modifikation der 133 | Software nicht ein. Eine Weiterverbreitung des Produktes mit unseren 134 | Markenhinweisen ist damit ohne unsere Zustimmung nicht zulässig. 135 | 136 | - Die Gewährleistung erlischt für alle Mängel, die auf der Verwendung 137 | modifizierter Software beruhen. 138 | 139 | - Sie können für Schäden haftbar gemacht werden, die sich aus der Benutzung 140 | des Produktes mit einer modifizierten Software ergeben können, insbesondere 141 | wenn Sie Dritten die Benutzung ermöglichen. 142 | 143 | - Die Verwendung des Produkts kann verboten sein, wenn dies gegen gesetzliche 144 | Bestimmungen verstößt. Es obliegt Ihnen zu überprüfen, ob die Verwendung im 145 | konkreten Fall zulässig ist, bzw. die dafür erforderlichen Genehmigungen 146 | einzuholen. 147 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 148 | -------------------------------------------------------------------------------- /Annexes/Identified-Licenses.txt: -------------------------------------------------------------------------------- 1 | %########################################################################### 2 | % 3 | % Annex to the OSADL Open Source Policy Template 4 | % 5 | % Copyright (c) 2019,2020 Open Source Automation Development Lab (OSADL) eG 6 | % Author: Caren Kresse, Carsten Emde 7 | % 8 | %########################################################################### 9 | 10 | List of known licenses 11 | 12 | 13 | This document lists all FOSS licenses that have been evaluated previously. When 14 | an unknown license has gone through our approval request it is added to this 15 | list. 16 | ======================================== 17 | It might make sense to categorize this list, e.g. by strong, weak, no copyleft, 18 | additional sales obligations (e.g. LGPL-2.1), acknowledgment requirements, 19 | licensing of patents, etc. 20 | 21 | The list below is merely a suggestion that is based on the OSADL Open Source 22 | License Obligation Checklists. It must be reviewed individually before employing 23 | it. A company's list of known licenses could also be based on e.g. the SPDX list 24 | or OSI list of licenses. 25 | ======================================== 26 | 27 | 1 Licensing categories 28 | 29 | 1.1 Copyleft licenses 30 | 31 | Strong copyleft licenses 32 | - GNU Affero General Public License v3.0 (AGPL-3.0) 33 | - Common Public License 1.0 (CPL-1.0) 34 | - Eclipse Public License 1.0 (EPL-1.0) 35 | - European Union Public License 1.1 (EUPL-1.1) 36 | - GNU General Public License v2.0 (GPL-2.0) 37 | - GNU General Public License v3.0 (GPL-3.0) 38 | - IBM Public License Version 1.0 (IPL-1.0) 39 | - Microsoft Reciprocal License (MS-RL) 40 | - Open Software License 3.0 (OSL-3.0) 41 | 42 | Weak copyleft licenses 43 | - Common Development and Distribution License 1.0 (CDDL-1.0) 44 | - Eclipse Public License 2.0 (EPL-2.0) 45 | - GNU General Public License v2.0 WITH Classpath exception 2.0 (GPL-2.0 WITH 46 | Classpath-exception) 47 | - GNU Lesser General Public License v2.0 (LGPL-2.0) 48 | - GNU Lesser General Public License v2.1 (LGPL-2.1) 49 | - GNU Lesser General Public License v3.0 (LGPL-3.0) 50 | - Mozilla Public License 1.1 (MPL-1.1) 51 | - Mozilla Public License 2.0 (MPL-2.0) 52 | - Mozilla Public License 2.0 no copyleft exception 53 | (MPL-2.0-no-copyleft-exception) 54 | - Reciprocal Public License 1.5 (RPL-1.5) 55 | 56 | Copyleft licenses with additional requirements 57 | - GNU Lesser General Public License v2.1 (LGPL-2.1) 58 | ======================================== 59 | The GNU Lesser General Public License v2.1 (LGPL-2.1), imposes additional sales 60 | obligations. These include that the recipient must be permitted modification of 61 | linked proprietary components and reverse engineering of the same to debug such 62 | modifications. This may conflict with other equally applicable sales conditions 63 | in such a way that the management may generally forbid to use software under 64 | such licenses in products. Alternatively, such licenses may, of course, simply 65 | be put on the -> "Deny List". 66 | ======================================== 67 | - GNU Lesser General Public License v3.0 (LGPL-3.0) 68 | ======================================== 69 | Version 3.0 of the GNU Lesser General Public License (LGPL-3.0) imposes the 70 | additional obligation to not restrict modification of those parts of a 71 | derivative work that are licensed thus, and to permit reverse engineering to 72 | debug such modifications. 73 | ======================================== 74 | 75 | ######################################## 76 | Option 1: Software that is licensed under the GNU Lesser General Public License 77 | v2.1 (LGPL-2.1) and/or the GNU Lesser General Public License v3.0 (LGPL-3.0) and 78 | that would be linked from our company's proprietarily licensed software may not 79 | be used in products. 80 | ######################################## 81 | Option 2: There is no general restriction on the use of software that is 82 | licensed under the GNU Lesser General Public License v2.1 (LGPL-2.1) or the GNU 83 | Lesser General Public License v3.0 (LGPL-3.0). However, individual projects may 84 | define per-project rules on combining software under GNU Lesser General Public 85 | License v2.1 (LGPL-2.1) and/or GNU Lesser General Public License v3.0 (LGPL-3.0) 86 | with proprietary software of our company. 87 | ######################################## 88 | 89 | This is then appropriately noted in the lower part of the -> "Compatibility 90 | Matrix" that is part of this FOSS policy. 91 | 92 | 1.2 Permissive licenses 93 | 94 | With acknowledgment requirements 95 | - Apache License 1.0 (Apache-1.0) 96 | - Apache License 1.1 (Apache-1.1) 97 | - BSD 4-Clause License (BSD-4-Clause) 98 | - BSD 4-Clause "Original" or "Old" License (BSD-4-Clause-UC) 99 | - Freetype Project License (FTL) 100 | - Independent JPEG Group License (IJG) 101 | - XFree86 License 1.1 (XFree86-1.1) 102 | - zlib/libpng License with Acknowledgement (zlib-acknowledgement) 103 | 104 | Without particular requirements 105 | - Academic Free License v2.0 (AFL-2.0) 106 | - Academic Free License v2.1 (AFL-2.1) 107 | - Apache License 2.0 (Apache-2.0) 108 | - Artistic License 1.0 (Perl) (Artistic-1.0-Perl) 109 | - BSD 2-Clause License (BSD-2-Clause) 110 | - BSD-2-Clause Plus Patent License (BSD-2-Clause-Patent) 111 | - BSD 3-Clause License (BSD-3-Clause) 112 | - bzip2 and libbzip2 License v1.0.5 (bzip2-1.0.5) 113 | - bzip2 and libbzip2 License v1.0.6 (bzip2-1.0.6) 114 | - Creative Commons Zero v1.0 Universal (CC0-1.0) 115 | - curl License (curl) 116 | - Eiffel Forum License v2.0 (EFL-2.0) 117 | - Historic Permission Notice and Disclaimer (HPND) 118 | - IBM PowerPC Initialization and Boot Software (IBM-pibs) 119 | - ICU License (ICU) 120 | - ISC License (ISC) 121 | - libpng License (Libpng) 122 | - libtiff License (libtiff) 123 | - MIT License (MIT) 124 | - CMU License (MIT-CMU) 125 | - Net Boolean Public License v1 (NBPL-1.0) 126 | - NTP License (NTP) 127 | - Python License 2.0 (Python-2.0) 128 | - Qhull License (Qhull) 129 | - SunPro License (SunPro) 130 | - Unicode License Agreement - Data Files and Software (2015) (Unicode-DFS-2015) 131 | - Unicode License Agreement - Data Files and Software (2016) (Unicode-DFS-2016) 132 | - Universal Permissive License v1.0 (UPL-1.0) 133 | - Do What The F*ck You Want To Public License (WTFPL) 134 | - X11 License (X11) 135 | - zlib License (Zlib) 136 | 137 | 2 Explicit licensing of patents 138 | 139 | ======================================== 140 | All FOSS licenses require licensing implemented patents. But while not all 141 | licenses rule this explicitly, the licenses listed here do so. 142 | ======================================== 143 | 144 | - Academic Free License v2.0 (AFL-2.0) 145 | - Academic Free License v2.1 (AFL-2.1) 146 | - GNU Affero General Public License v3.0 (AGPL-3.0) 147 | - Apache License 2.0 (Apache-2.0) 148 | - BSD-2-Clause Plus Patent License (BSD-2-Clause-Patent) 149 | - bzip2 and libbzip2 License v1.0.5 (bzip2-1.0.5) 150 | - Creative Commons Zero v1.0 Universal (CC0-1.0) 151 | - Common Development and Distribution License 1.0 (CDDL-1.0) 152 | - Common Public License 1.0 (CPL-1.0) 153 | - Eclipse Public License 1.0 (EPL-1.0) 154 | - Eclipse Public License 2.0 (EPL-2.0) 155 | - European Union Public License 1.1 (EUPL-1.1) 156 | - GNU General Public License v2.0 (GPL-2.0) 157 | ======================================== 158 | The patent license of the GPL-2.0 is not undisputed as sections 0 and 1 of the 159 | license are not explicit. 160 | ======================================== 161 | - GNU General Public License v2.0 WITH Classpath exception (GPL-2.0 WITH 162 | Classpath-exception) 163 | - GNU General Public License v3.0 (GPL-3.0) 164 | - IBM PowerPC Initialization and Boot Software (IBM-pibs) 165 | - Independent JPEG Group License (IJG) 166 | - IBM Public License Version 1.0 (IPL-1.0) 167 | - GNU Lesser General Public License v2.1 (LGPL-2.1) 168 | - GNU Lesser General Public License v3.0 (LGPL-3.0) 169 | - Mozilla Public License 1.1 (MPL-1.1) 170 | - Mozilla Public License 2.0 (MPL-2.0) 171 | - Mozilla Public License 2.0 no copyleft exception 172 | (MPL-2.0-no-copyleft-exception) 173 | - Microsoft Public License (MS-PL) 174 | - Microsoft Reciprocal License (MS-RL) 175 | - Open Software License 3.0 (OSL-3.0) 176 | - Reciprocal Public License 1.5 (RPL-1.5) 177 | -------------------------------------------------------------------------------- /Annexes/Purchase-Contract.txt: -------------------------------------------------------------------------------- 1 | %########################################################################### 2 | % 3 | % Annex to the OSADL Open Source Policy Template 4 | % 5 | % Copyright (c) 2019,2020 Open Source Automation Development Lab (OSADL) eG 6 | % Author: Till Jaeger, Astrid Spura, Caren Kresse 7 | % 8 | %########################################################################### 9 | 10 | Special purchase conditions for Free and Open Source Software (FOSS-SPC) 11 | 12 | 13 | 1 Scope 14 | 15 | These FOSS-SPC apply to the purchase of all products containing software by 16 | COMPANY and independent of the type of contract on which the purchase is based. 17 | The provisions of these FOSS-SPC shall prevail within their scope over our other 18 | conditions of purchase and the General Terms and Conditions of the supplier. 19 | 20 | 2 Definition 21 | 22 | 2.1 Free and Open Source Software ("FOSS") for the purpose of this FOSS-SPC 23 | is software the license of which meets the requirements of the "Open Source 24 | Definition" (https://opensource.org/osd) of the Open Source Initiative and/or 25 | is registered in the publicly accessible lists of Free Licenses and Open Source 26 | Licenses of the Free Software Foundation and/or the Open Source Initiative, 27 | respectively. 28 | 29 | 2.2 These FOSS-SPC apply to Public Domain Software accordingly. 30 | 31 | 3 Verification and information obligations of the supplier 32 | 33 | The supplier shall be aware that non-compliance with the license obligations for 34 | FOSS may result in a violation of copyright law, and thus, in defects of title 35 | of the supplied products. The supplier alone is responsible for meeting the 36 | license conditions of all FOSS that is included in the products supplied to 37 | COMPANY . This also applies to embedded systems as well as firmware updates and 38 | any other software distribution. 39 | 40 | The supplier must check the software included in his products for FOSS and must 41 | also gather the required information from sub-suppliers. It is the 42 | responsibility of the supplier to comply with ISO 5230, the current OpenChain 43 | Standard Version (2.0 or later) 44 | (https://wiki.linuxfoundation.org/\_media/openchain/openchainspec-current.pdf). 45 | 46 | 47 | 4 FOSS documentation 48 | 49 | At the latest with delivery of the product the supplier must provide COMPANY 50 | with 51 | 52 | a) a "Bill of Materials" ("BOM"), i.e. a list of the used FOSS 53 | components, corresponding version number and respective FOSS licenses as SPDX 54 | identifier (https://spdx.org/licenses/), and 55 | 56 | b) a document for the compliance with the FOSS licenses ("Open Source Content 57 | Documentation") which contains all license texts and copyright notices with 58 | regard to the respective files in Debian DEP-5 format 59 | (http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/) or SPDX 60 | format (https://spdx.org/spdx-specification-21-web-version) and additionally all 61 | further information that must be provided when distributing the software 62 | according to the applying licenses. 63 | 64 | c) the complete and corresponding source code of FOSS contained in the product. 65 | 66 | 5 Use of copyleft licenses 67 | 68 | 5.1 The supplier must ensure that copyleft-licensed software is used in products 69 | only in a way that does not bear the risk that COMPANY must license own 70 | software components or third-party software components as FOSS when used in 71 | combination with the product without having obtained a prior approval from 72 | COMPANY for this purpose. Copyleft licenses are here considered to be those 73 | FOSS licenses that require modifications of software licensed as such to also 74 | be licensed as FOSS when distributing it. 75 | 76 | 5.2 The supplier ensures that the license conditions of all software components 77 | linked with FOSS licensed under the GNU Lesser General Public License allow any 78 | user of the software modification and reengineering for debugging such 79 | modifications. 80 | 81 | 5.3 The supplier ensures that COMPANY will be provided with all necessary 82 | information required to enable compilation and reinstallation of FOSS licensed 83 | under the GNU Lesser General Public License, the GNU General Public License and 84 | the GNU Affero General Public License (if applicable), especially in case the 85 | product is an embedded system. 86 | 87 | 6 Assurance 88 | 89 | The supplier assures that the distributed products do not violate any 90 | third-party copyrights and that the license conditions of all FOSS and 91 | third-party software are fully met. 92 | 93 | 7 Violation of these FOSS-SPC 94 | 95 | 7.1 In case of violation of these FOSS-SPC the supplier agrees to either 96 | immediately remedy any defects and/or replace those FOSS components that are not 97 | compliant with their license by license-compliant components. 98 | 99 | 7.2 The supplier agrees to compensate COMPANY for all damages and costs arising 100 | from the failure to comply with the provisions given in this FOSS-SPC. 101 | 102 | 103 | ======================================== 104 | Deutsche Version: 105 | ======================================== 106 | 107 | Besondere Einkaufsbedingungen für Freie und Open Source-Software (FOSS-BEB) 108 | 109 | 1 Geltungsbereich 110 | 111 | Diese FOSS-BEB gelten für den Erwerb sämtlicher Produkte, die Software 112 | enthalten, durch UNTERNEHMEN und unabhängig von dem Vertragstypus des dem 113 | Erwerb zugrunde liegenden Vertrages. Die FOSS-BEB gelten in ihrem 114 | Anwendungsbereich vorrangig vor unseren übrigen Einkaufsbedingungen und den 115 | Allgemeinen Geschäftsbedingungen des Anbieters. 116 | 117 | 2 Definition 118 | 119 | 2.1 Freie Software und Open Source-Software ("FOSS") im Sinne dieser 120 | FOSS-BEB ist Software, deren Lizenz den Anforderungen der "Open Source 121 | Definition" (https://opensource.org/osd) der Open Source Initiative genügt 122 | und/oder von der Open Source Initiative und/oder der Free Software Foundation 123 | in deren öffentlich zugänglichen Listen Open Source-Lizenzen bzw. freier 124 | Lizenzen aufgenommen wurde. 125 | 126 | 2.2 Für Public Domain-Software gelten diese FOSS-BEB entsprechend. 127 | 128 | 3 Prüfungs- und Informationspflichten des Anbieters 129 | 130 | Dem Anbieter ist bekannt, dass die Nichteinhaltung der Lizenzbedingungen für 131 | FOSS zu einer Urheberrechtsverletzung und zu einem Rechtsmangel der an 132 | UNTERNEHMEN gelieferten Produkte führen kann. Der Anbieter ist alleine dafür 133 | verantwortlich, die Lizenzbedingungen sämtlicher FOSS einzuhalten, die in den 134 | an UNTERNEHMEN gelieferten Produkten enthalten ist. Dies betrifft sowohl 135 | Embbeded-Systeme als auch Firmware-Updates und jede andere Distribution von 136 | Software. 137 | 138 | Der Anbieter hat die in seinen Produkten enthaltene Software auf FOSS zu 139 | überprüfen und auch von Vorlieferanten die erforderlichen Informationen 140 | einzuholen. Die Einhaltung des OpenChain Standards in der Version 1.2 141 | (https://wiki.linuxfoundation.org/_media/openchain/openchainspec-1.2.pdf) oder 142 | späteren Versionen ist eine Obliegenheit des Anbieters. 143 | 144 | 4 FOSS Dokumentation 145 | 146 | Der Anbieter muss UNTERNEHMEN spätestens mit der Überlassung des Produktes 147 | 148 | a) eine "Bill of Materials" ("BOM"), d.h. eine Liste der verwendeten 149 | FOSS Komponenten, ihrer Versionsnummer und der anwendbaren FOSS Lizenzen als 150 | SPDX-Identifier (https://spdx.org/licenses/), und 151 | 152 | b) ein Dokument zur Einhaltung der FOSS Lizenzen ("Open Source Content 153 | Documentation"), das alle Lizenztexte und Copyright-Hinweise mit Bezug auf die 154 | jeweiligen Dateien im Debian DEP-5-Format 155 | (http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/) oder 156 | SPDX-Format (https://spdx.org/spdx-specification-21-web-version) enthält, sowie 157 | zusätzlich alle weiteren Informationen, die aufgrund der anwendbaren Lizenzen 158 | bei der Überlassung der Software übergeben werden müssen, und 159 | 160 | c) den vollständigen und korrespondierenden Quellcode der in dem Produkt 161 | enthaltenden FOSS zur Verfügung stellen. 162 | 163 | 5 Einsatz von Copyleft-Lizenzen 164 | 165 | 5.1 Der Anbieter hat sicherzustellen, dass Software unter Copyleft-Lizenzen in 166 | den Produkten nur in einer Weise verwendet wird, die nicht das Risiko enthält, 167 | dass UNTERNEHMEN bei der Verwendung des Produktes in Kombination mit eigenen 168 | Software-Komponenten oder Software-Komponenten Dritter als FOSS lizenzieren 169 | muss, ohne dass dafür die vorherige Zustimmung von UNTERNEHMEN eingeholt wurde. 170 | Als Copyleft-Lizenzen werden solche FOSS-Lizenzen verstanden, deren 171 | Lizenzbedingungen verlangen, dass Modifikationen der darunter lizenzierten 172 | Software bei der Weitergabe ebenfalls als FOSS lizenziert werden müssen. 173 | 174 | 5.2 Der Anbieter stellt sicher, dass die Lizenzbedingungen sämtlicher 175 | Software-Komponenten, die mit FOSS unter der GNU Lesser General Public License 176 | verlinkt ist, jedem Nutzer der Software die Bearbeitung zum eigenen Gebrauch und 177 | das Reengineering zur Behebung von Fehlern solcher Bearbeitungen gestatten. 178 | 179 | 5.3 Der Anbieter stellt sicher, dass UNTERNEHMEN die erforderlichen 180 | Informationen zur Verfügung gestellt werden, die das Kompilieren und 181 | Wiederaufspielen von FOSS unter der GNU Lesser General Public License, der GNU 182 | General Public License und der GNU Affero General Public License ermöglichen 183 | (sofern vorhanden), insbesondere wenn das Produkt ein Embedded System ist. 184 | 185 | 6 Zusicherung 186 | 187 | Der Anbieter sichert zu, dass die von ihm gelieferten Produkte keine 188 | Urheberrechte Dritter verletzen und die Lizenzbedingungen sämtlicher FOSS und 189 | anderer Third-Party-Software vollständig erfüllt werde 190 | 191 | 7 Verletzung dieser FOSS-BEB 192 | 193 | 7.1 Im Falle einer Verletzung dieser FOSS-BEB verpflichtet sich der Anbieter, 194 | den Mangel unverzüglich zu beheben und/oder nicht lizenzkonforme 195 | FOSS-Komponenten durch lizenzkonforme Komponenten zu ersetzen. 196 | 197 | 7.2 Der Anbieter verpflichtet sich UNTERNEHMEN sämtliche Kosten und Schäden zu 198 | ersetzen, die sich aus der Nichteinhaltung der Zusicherungen aus diesen FOSS-BEB 199 | ergeben. 200 | 201 | -------------------------------------------------------------------------------- /Annexes/SaaS-Licenses.txt: -------------------------------------------------------------------------------- 1 | %########################################################################### 2 | % 3 | % Supplement to the OSADL Open Source Policy Template 4 | % 5 | % Copyright (c) 2019,2020 Open Source Automation Development Lab (OSADL) eG 6 | % Author: Till Jaeger, Caren Kresse 7 | % 8 | %########################################################################### 9 | 10 | SaaS licenses 11 | 12 | This document lists FOSS licenses that explicitly rule how to handle using the 13 | respective software as a service in the so-called "cloud". 14 | 15 | 1 Licenses with an effective copyleft clause for the cloud 16 | - GNU Affero General Public License v2.0 (AGPL-2.0) 17 | - GNU Affero General Public License v3.0 (AGPL-3.0) 18 | - Server Side Public License, v 1 (SSPL-1.0) 19 | 20 | 2 Licenses that do not require any obligations in the cloud 21 | - GNU General Public License v3.0 (GPL-3.0) 22 | - GNU Lesser General Public License v3.0 (LGPL-3.0) 23 | - Apache License 2.0 (Apache-2.0) 24 | - Mozilla Public License 2.0 (MPL-2.0) 25 | - Eclipse Public License 2.0 (EPL-2.0) 26 | -------------------------------------------------------------------------------- /LICENSING: -------------------------------------------------------------------------------- 1 | Copyright 2019, 2020 Open Source Automation Development Lab (OSADL) eG and contributors, 2 | Licensed under Creative Commons Attribution 4.0 International (CC-BY-4.0), https://creativecommons.org/licenses/by/4.0/ 3 | Attribution: A project by the Open Source Automation Development Lab (OSADL) eG. For further information about authors and contributors see the contribution history at www.osadl.org/os-policy 4 | 5 | 6 | Creative Commons Attribution 4.0 International 7 | 8 | Creative Commons Corporation ("Creative Commons") is not a law firm and does not provide legal services or legal advice. Distribution of Creative Commons public licenses does not create a lawyer-client or other relationship. Creative Commons makes its licenses and related information available on an "as-is" basis. Creative Commons gives no warranties regarding its licenses, any material licensed under their terms and conditions, or any related information. Creative Commons disclaims all liability for damages resulting from their use to the fullest extent possible. 9 | 10 | Using Creative Commons Public Licenses 11 | 12 | Creative Commons public licenses provide a standard set of terms and conditions that creators and other rights holders may use to share original works of authorship and other material subject to copyright and certain other rights specified in the public license below. The following considerations are for informational purposes only, are not exhaustive, and do not form part of our licenses. 13 | 14 | Considerations for licensors: Our public licenses are intended for use by those authorized to give the public permission to use material in ways otherwise restricted by copyright and certain other rights. Our licenses are irrevocable. Licensors should read and understand the terms and conditions of the license they choose before applying it. Licensors should also secure all rights necessary before applying our licenses so that the public can reuse the material as expected. Licensors should clearly mark any material not subject to the license. This includes other CC-licensed material, or material used under an exception or limitation to copyright. More considerations for licensors : wiki.creativecommons.org/Considerations_for_licensors 15 | 16 | Considerations for the public: By using one of our public licenses, a licensor grants the public permission to use the licensed material under specified terms and conditions. If the licensor's permission is not necessary for any reason–for example, because of any applicable exception or limitation to copyright–then that use is not regulated by the license. Our licenses grant only permissions under copyright and certain other rights that a licensor has authority to grant. Use of the licensed material may still be restricted for other reasons, including because others have copyright or other rights in the material. A licensor may make special requests, such as asking that all changes be marked or described. Although not required by our licenses, you are encouraged to respect those requests where reasonable. More considerations for the public : wiki.creativecommons.org/Considerations_for_licensees 17 | 18 | Creative Commons Attribution 4.0 International Public License 19 | 20 | By exercising the Licensed Rights (defined below), You accept and agree to be bound by the terms and conditions of this Creative Commons Attribution 4.0 International Public License ("Public License"). To the extent this Public License may be interpreted as a contract, You are granted the Licensed Rights in consideration of Your acceptance of these terms and conditions, and the Licensor grants You such rights in consideration of benefits the Licensor receives from making the Licensed Material available under these terms and conditions. 21 | 22 | Section 1 – Definitions. 23 | 24 | a. Adapted Material means material subject to Copyright and Similar Rights that is derived from or based upon the Licensed Material and in which the Licensed Material is translated, altered, arranged, transformed, or otherwise modified in a manner requiring permission under the Copyright and Similar Rights held by the Licensor. For purposes of this Public License, where the Licensed Material is a musical work, performance, or sound recording, Adapted Material is always produced where the Licensed Material is synched in timed relation with a moving image. 25 | b. Adapter's License means the license You apply to Your Copyright and Similar Rights in Your contributions to Adapted Material in accordance with the terms and conditions of this Public License. 26 | c. Copyright and Similar Rights means copyright and/or similar rights closely related to copyright including, without limitation, performance, broadcast, sound recording, and Sui Generis Database Rights, without regard to how the rights are labeled or categorized. For purposes of this Public License, the rights specified in Section 2(b)(1)-(2) are not Copyright and Similar Rights. 27 | d. Effective Technological Measures means those measures that, in the absence of proper authority, may not be circumvented under laws fulfilling obligations under Article 11 of the WIPO Copyright Treaty adopted on December 20, 1996, and/or similar international agreements. 28 | e. Exceptions and Limitations means fair use, fair dealing, and/or any other exception or limitation to Copyright and Similar Rights that applies to Your use of the Licensed Material. 29 | f. Licensed Material means the artistic or literary work, database, or other material to which the Licensor applied this Public License. 30 | g. Licensed Rights means the rights granted to You subject to the terms and conditions of this Public License, which are limited to all Copyright and Similar Rights that apply to Your use of the Licensed Material and that the Licensor has authority to license. 31 | h. Licensor means the individual(s) or entity(ies) granting rights under this Public License. 32 | i. Share means to provide material to the public by any means or process that requires permission under the Licensed Rights, such as reproduction, public display, public performance, distribution, dissemination, communication, or importation, and to make material available to the public including in ways that members of the public may access the material from a place and at a time individually chosen by them. 33 | j. Sui Generis Database Rights means rights other than copyright resulting from Directive 96/9/EC of the European Parliament and of the Council of 11 March 1996 on the legal protection of databases, as amended and/or succeeded, as well as other essentially equivalent rights anywhere in the world. 34 | k. You means the individual or entity exercising the Licensed Rights under this Public License. Your has a corresponding meaning. 35 | 36 | Section 2 – Scope. 37 | 38 | a. License grant. 39 | 1. Subject to the terms and conditions of this Public License, the Licensor hereby grants You a worldwide, royalty-free, non-sublicensable, non-exclusive, irrevocable license to exercise the Licensed Rights in the Licensed Material to: 40 | A. reproduce and Share the Licensed Material, in whole or in part; and 41 | B. produce, reproduce, and Share Adapted Material. 42 | 2. Exceptions and Limitations. For the avoidance of doubt, where Exceptions and Limitations apply to Your use, this Public License does not apply, and You do not need to comply with its terms and conditions. 43 | 3. Term. The term of this Public License is specified in Section 6(a). 44 | 4. Media and formats; technical modifications allowed. The Licensor authorizes You to exercise the Licensed Rights in all media and formats whether now known or hereafter created, and to make technical modifications necessary to do so. The Licensor waives and/or agrees not to assert any right or authority to forbid You from making technical modifications necessary to exercise the Licensed Rights, including technical modifications necessary to circumvent Effective Technological Measures. For purposes of this Public License, simply making modifications authorized by this Section 2(a)(4) never produces Adapted Material. 45 | 5. Downstream recipients. 46 | A. Offer from the Licensor – Licensed Material. Every recipient of the Licensed Material automatically receives an offer from the Licensor to exercise the Licensed Rights under the terms and conditions of this Public License. 47 | B. No downstream restrictions. You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, the Licensed Material if doing so restricts exercise of the Licensed Rights by any recipient of the Licensed Material. 48 | 6. No endorsement. Nothing in this Public License constitutes or may be construed as permission to assert or imply that You are, or that Your use of the Licensed Material is, connected with, or sponsored, endorsed, or granted official status by, the Licensor or others designated to receive attribution as provided in Section 3(a)(1)(A)(i). 49 | b. Other rights. 50 | 1. Moral rights, such as the right of integrity, are not licensed under this Public License, nor are publicity, privacy, and/or other similar personality rights; however, to the extent possible, the Licensor waives and/or agrees not to assert any such rights held by the Licensor to the limited extent necessary to allow You to exercise the Licensed Rights, but not otherwise. 51 | 2. Patent and trademark rights are not licensed under this Public License. 52 | 3. To the extent possible, the Licensor waives any right to collect royalties from You for the exercise of the Licensed Rights, whether directly or through a collecting society under any voluntary or waivable statutory or compulsory licensing scheme. In all other cases the Licensor expressly reserves any right to collect such royalties. 53 | 54 | Section 3 – License Conditions. 55 | 56 | Your exercise of the Licensed Rights is expressly made subject to the following conditions. 57 | 58 | a. Attribution. 59 | 1. If You Share the Licensed Material (including in modified form), You must: 60 | A. retain the following if it is supplied by the Licensor with the Licensed Material: 61 | i. identification of the creator(s) of the Licensed Material and any others designated to receive attribution, in any reasonable manner requested by the Licensor (including by pseudonym if designated); 62 | ii. a copyright notice; 63 | iii. a notice that refers to this Public License; 64 | iv. a notice that refers to the disclaimer of warranties; 65 | v. a URI or hyperlink to the Licensed Material to the extent reasonably practicable; 66 | B. indicate if You modified the Licensed Material and retain an indication of any previous modifications; and 67 | C. indicate the Licensed Material is licensed under this Public License, and include the text of, or the URI or hyperlink to, this Public License. 68 | 2. You may satisfy the conditions in Section 3(a)(1) in any reasonable manner based on the medium, means, and context in which You Share the Licensed Material. For example, it may be reasonable to satisfy the conditions by providing a URI or hyperlink to a resource that includes the required information. 69 | 3. If requested by the Licensor, You must remove any of the information required by Section 3(a)(1)(A) to the extent reasonably practicable. 70 | 4. If You Share Adapted Material You produce, the Adapter's License You apply must not prevent recipients of the Adapted Material from complying with this Public License. 71 | 72 | Section 4 – Sui Generis Database Rights. 73 | 74 | Where the Licensed Rights include Sui Generis Database Rights that apply to Your use of the Licensed Material: 75 | 76 | a. for the avoidance of doubt, Section 2(a)(1) grants You the right to extract, reuse, reproduce, and Share all or a substantial portion of the contents of the database; 77 | b. if You include all or a substantial portion of the database contents in a database in which You have Sui Generis Database Rights, then the database in which You have Sui Generis Database Rights (but not its individual contents) is Adapted Material; and 78 | c. You must comply with the conditions in Section 3(a) if You Share all or a substantial portion of the contents of the database. 79 | 80 | For the avoidance of doubt, this Section 4 supplements and does not replace Your obligations under this Public License where the Licensed Rights include other Copyright and Similar Rights. 81 | 82 | Section 5 – Disclaimer of Warranties and Limitation of Liability. 83 | 84 | a. Unless otherwise separately undertaken by the Licensor, to the extent possible, the Licensor offers the Licensed Material as-is and as-available, and makes no representations or warranties of any kind concerning the Licensed Material, whether express, implied, statutory, or other. This includes, without limitation, warranties of title, merchantability, fitness for a particular purpose, non-infringement, absence of latent or other defects, accuracy, or the presence or absence of errors, whether or not known or discoverable. Where disclaimers of warranties are not allowed in full or in part, this disclaimer may not apply to You. 85 | b. To the extent possible, in no event will the Licensor be liable to You on any legal theory (including, without limitation, negligence) or otherwise for any direct, special, indirect, incidental, consequential, punitive, exemplary, or other losses, costs, expenses, or damages arising out of this Public License or use of the Licensed Material, even if the Licensor has been advised of the possibility of such losses, costs, expenses, or damages. Where a limitation of liability is not allowed in full or in part, this limitation may not apply to You. 86 | c. The disclaimer of warranties and limitation of liability provided above shall be interpreted in a manner that, to the extent possible, most closely approximates an absolute disclaimer and waiver of all liability. 87 | 88 | Section 6 – Term and Termination. 89 | 90 | a. This Public License applies for the term of the Copyright and Similar Rights licensed here. However, if You fail to comply with this Public License, then Your rights under this Public License terminate automatically. 91 | b. Where Your right to use the Licensed Material has terminated under Section 6(a), it reinstates: 92 | 1. automatically as of the date the violation is cured, provided it is cured within 30 days of Your discovery of the violation; or 93 | 2. upon express reinstatement by the Licensor. 94 | c. For the avoidance of doubt, this Section 6(b) does not affect any right the Licensor may have to seek remedies for Your violations of this Public License. 95 | d. For the avoidance of doubt, the Licensor may also offer the Licensed Material under separate terms or conditions or stop distributing the Licensed Material at any time; however, doing so will not terminate this Public License. 96 | e. Sections 1, 5, 6, 7, and 8 survive termination of this Public License. 97 | 98 | Section 7 – Other Terms and Conditions. 99 | 100 | a. The Licensor shall not be bound by any additional or different terms or conditions communicated by You unless expressly agreed. 101 | b. Any arrangements, understandings, or agreements regarding the Licensed Material not stated herein are separate from and independent of the terms and conditions of this Public License. 102 | 103 | Section 8 – Interpretation. 104 | 105 | a. For the avoidance of doubt, this Public License does not, and shall not be interpreted to, reduce, limit, restrict, or impose conditions on any use of the Licensed Material that could lawfully be made without permission under this Public License. 106 | b. To the extent possible, if any provision of this Public License is deemed unenforceable, it shall be automatically reformed to the minimum extent necessary to make it enforceable. If the provision cannot be reformed, it shall be severed from this Public License without affecting the enforceability of the remaining terms and conditions. 107 | c. No term or condition of this Public License will be waived and no failure to comply consented to unless expressly agreed to by the Licensor. 108 | d. Nothing in this Public License constitutes or may be interpreted as a limitation upon, or waiver of, any privileges and immunities that apply to the Licensor or You, including from the legal processes of any jurisdiction or authority. 109 | 110 | Creative Commons is not a party to its public licenses. Notwithstanding, Creative Commons may elect to apply one of its public licenses to material it publishes and in those instances will be considered the "Licensor." The text of the Creative Commons public licenses is dedicated to the public domain under the CC0 Public Domain Dedication. Except for the limited purpose of indicating that material is shared under a Creative Commons public license or as otherwise permitted by the Creative Commons policies published at creativecommons.org/policies, Creative Commons does not authorize the use of the trademark "Creative Commons" or any other trademark or logo of Creative Commons without its prior written consent including, without limitation, in connection with any unauthorized modifications to any of its public licenses or any other arrangements, understandings, or agreements concerning use of licensed material. For the avoidance of doubt, this paragraph does not form part of the public licenses. 111 | 112 | Creative Commons may be contacted at creativecommons.org. 113 | 114 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # OSADL Open Source Policy Template – Plain text version 2 | This repository contains the plain text version of the OSADL Open Source Policy Template: The Basis for License Compliance. This Open Source Policy is not meant to be used as is, but serves as a template from which an individual policy can be created. The original template consists of one main PDF document, that contains links to Annexes (additional PDF documents to accompany a FOSS policy with processes and forms for legal and other information on projects and products) and Supplements for further reading (separate PDF documents to provide technology background and explain relevant aspects of copyright law and license compliance in more detail). For more information on the project go to [www.osadl.org/os-policy](https://www.osadl.org/os-policy). 3 | 4 | The PDF documents of the original OS-Policy template can be filled out according to a company's requirements. However, some company's might prefer to customize the policy template more extensively. Therefore, the plain text version is provided and maintained here. 5 | 6 | ### Contributions 7 | Contributions and feedback on content and usability of the Policy Template are welcome. Please send your suggestions and comments as pull requests or issues. Contributions will be reviewed and, if approprate, included. Contributors agree to publish their contribution under the copyright notice and attribution as stated in section [Licensing](#licensing) below. Contributers may refuse to be named in the contribution history. 8 | 9 | ### Structure 10 | The original PDF documents rely on layout and linking for structuring. As this could not be transferred identically to the plain text version, an introduction to the structuring of the text files is given below and in the initial explanation of the main document. 11 | 12 | The main document is OS-Policy_Master.txt. It contains 13 | * Template texts for the various chapters of a FOSS policy that can be adapted according to a company’s requirements. These texts are made up of instructions with brief explanations for anyone who reads and implements the FOSS policy. 14 | 15 | * Additional explanations for whoever creates a company’s individual FOSS policy from this template. These may be removed from the final document. 16 | ======================================== 17 | Initiated and concluded by lines of equal signs 18 | ======================================== 19 | 20 | * When there are various possibilities of interpreting or handling a situation, possible options are given: 21 | ######################################## 22 | Preceeded by the word "Option" and initiated, separated and concluded by lines of hashtags 23 | ######################################## 24 | Option 2: 25 | ######################################## 26 | 27 | * Ready made text block templates that may be used to modify or extend existing company contracts and other documents, such as employment contracts. 28 | ++++++++++++++++++++++++++++++++++++++++ 29 | Initiated and concluded by lines of plus signs 30 | ++++++++++++++++++++++++++++++++++++++++ 31 | 32 | * Annexes and Supplements are given as separate .txt files in [Annexes/](Annexes) and [Supplements/](Supplements) Where they are referenced, the document title is preceded by an arrow -> 33 | 34 | ## Disclaimer 35 | This collection of explanations, templates and contract proposals was created in close collaboration with OSADL's General Counsel Dr. Till Jaeger and other legal professionals. However, the fact that legal professionals were involved in the preparation of the documents does not mean that any of the assessments or recommendations may be understood as individual legal advice that can only be given on a per-case basis by a lawyer. 36 | 37 | ## Licensing 38 | Copyright 2019, 2020 Open Source Automation Development Lab (OSADL) eG and contributors, 39 | Licensed under Creative Commons Attribution 4.0 International (CC-BY-4.0), [https://creativecommons.org/licenses/by/4.0/](https://creativecommons.org/licenses/by/4.0/) 40 | Attribution: A project by the Open Source Automation Development Lab (OSADL) eG. For further information about authors and contributors see the contribution history at [www.osadl.org/os-policy](https://www.osadl.org/os-policy) 41 | -------------------------------------------------------------------------------- /Supplements/Acknowledgments.txt: -------------------------------------------------------------------------------- 1 | %########################################################################### 2 | % 3 | % Supplement to the OSADL Open Source Policy Template 4 | % 5 | % Copyright (c) 2019,2020 Open Source Automation Development Lab (OSADL) eG 6 | % Author: Carsten Emde 7 | % 8 | %########################################################################### 9 | 10 | How To: Acknowledgments 11 | 12 | 13 | 1 Background 14 | 15 | A FOSS license may impose the obligation to forward or to provide an 16 | acknowledgment using a text which is usually stated in the license. The obvious 17 | intention of the original authors or the organization that owns the copyright of 18 | the software to request such acknowledgment is to be credited for the time and 19 | money of making the work available free of charge under an Open Source license. 20 | However, it also is intended to transparently inform the recipient of the 21 | software that the supplier may not be the author and may not merit the full 22 | credit. For the latter, some licenses request that the acknowledgment is 23 | provided at a conspicuous location and not in some hidden place where it can 24 | easily be overlooked. 25 | 26 | 27 | 2 Examples 28 | 29 | 2.1 BSD-4-Clause-UC 30 | A well-known example of an Open Source license that requires an acknowledgment 31 | is the (original) BSD-4-Clause-UC license that states in section 3: 32 | 33 | All advertising materials mentioning features or use of this software must 34 | display the following acknowledgement: This product includes software developed 35 | by the University of California, Berkeley and its contributors. 36 | 37 | Note that this acknowledgment contains a static string, i.e. it must always be 38 | cited verbatim. 39 | 40 | 2.2 IPL-1.0 41 | The (now outdated) IPL-1.0 license imposes a similar acknowledgment obligation 42 | and requests that it must be placed in a conspicuous location: 43 | 44 | Each Contributor must include the following in a conspicuous location in the 45 | Program: Copyright (C) 1996, 1999 International Business Machines Corporation 46 | and others. All Rights Reserved. 47 | 48 | This acknowledgment also contains a static string and must always be cited 49 | verbatim. 50 | 51 | 2.3 BSD-4-Clause 52 | The general form of the BSD-4-Clause license may be used by right holders other 53 | than the University of California, Berkeley and thus, each occurrence may name a 54 | different entity (the term "organization" is used as a placeholder by the SPDX 55 | Working Group): 56 | 57 | All advertising materials mentioning features or use of this software must 58 | display the following acknowledgement: 59 | This product includes software developed by the organization. 60 | 61 | All different texts of the various acknowledgments must be extracted 62 | individually from every software package and provided along with advertising 63 | material, if any. In some cases, the author or authors may have omitted to 64 | replace the term "organization" by an appropriate name or ignored it 65 | intentionally. In this case, the acknowledgment can be cited as is and needs 66 | only to occur once should several files or software packages use the same 67 | license. 68 | 69 | 3 Practical considerations 70 | 71 | 3.1 Required actions may differ 72 | Only if i) source code delivery is chosen, ii) the acknowledgment obligation of 73 | the license does not explicitly request a particularly enhanced visibility of it 74 | and iii) the source code delivery contains the acknowledgment in the source code 75 | files or in an accompanying obviously named file, no additional action is 76 | required to fulfill the acknowledgment obligation. However, if the 77 | acknowledgment must be placed at a well visible location or binary delivery is 78 | chosen in which case the acknowledgment normally is stripped off during 79 | compilation, the text of the acknowledgment must be carefully extracted and 80 | provided separately in an appropriate manner. Copying and distributing software 81 | without appropriately acknowledge the authors although it is requested by the 82 | license may breach the license and, thus, constitute copyright infringement. 83 | 84 | 3.2 Examples of relevant license obligation as obtained from the OSADL License 85 | Obligations Checklists 86 | An Open Source license checklist may contain the section 87 | 88 | USE CASE Source code delivery 89 | YOU MUST Credit Verbatim "Acknowledgment" 90 | ATTRIBUTE Highlighted 91 | 92 | or the section 93 | 94 | USE CASE Binary delivery 95 | YOU MUST Credit Verbatim "Acknowledgment" 96 | 97 | while the latter may or may not require the acknowledgment to be placed at a 98 | conspicuous location such as 99 | 100 | ATTRIBUTE Highlighted 101 | 102 | In all above cases, the appropriate acknowledgment string must be obtained and 103 | provided along with the product as specified in the license. 104 | 105 | 3.3 How to obtain the acknowledgment string 106 | The recommended way to obtain the acknowledgment string is to identify and 107 | extract it as explained in the Supplement -> "How To Scan 108 | -------------------------------------------------------------------------------- /Supplements/Container-Compliance.txt: -------------------------------------------------------------------------------- 1 | %########################################################################### 2 | % OSADL Open Source Policy Template for License Compliance 3 | % 4 | % Supplement on License compliance for containers and Containerfiles 5 | % 6 | % Copyright (c) 2021 Open Source Automation Development Lab (OSADL) eG 7 | % 8 | %########################################################################### 9 | 10 | License Compliance for containers and Containerfiles 11 | 12 | Supplement to open Source Policy Template 13 | 14 | In recent years, container virtualization has become increasingly popular also 15 | in industry. One of the reasons for this popularity, is certainly the 16 | possibility it offers to deploy and run an application with all its 17 | dependencies within a container. This avoids compatibility issues between 18 | various components on the target system. While this undoubtedly simplifies life 19 | from a technical point of view, it complicates it from a legal standpoint. This 20 | is because although a large majority of containers comprise Free and Open 21 | Source software (FOSS), their licensing requirements have so far not been 22 | considered either by the container technology itself nor by most suppliers of 23 | container software. 24 | 25 | The desire to run certain software separately form the rest of the system is 26 | not new, and the required technical means have already existed for some time. 27 | However, only in recent years this technology has experienced a remarkable 28 | growth. Besides security requirements this is also due to the increasing 29 | complexity of modern computer systems and the resulting compatibility issues 30 | between various software components. Containers address these challenges by 31 | offering the possibility to combine, deploy and run all dependencies, data and 32 | configurations of an application in an isolated environment. 33 | 34 | Terminology 35 | When speaking of "containers" one may refer to various different things: 36 | 37 | - The container engine together with a container runtime is the layer between 38 | the host's operating system and the individual containers. The engine organizes 39 | and manages the container instances and their allocated resources. There are 40 | various providers of container engines, among others Docker 41 | (https://www.docker.com/) , Podman (https://podman.io/) or LXD 42 | (https://linuxcontainers.org/). 43 | 44 | - Container image refers to a collection of software components o disk. 45 | 46 | - One or several container instances can be created from a container image. 47 | 48 | - In addition, it is possible to pass a script (a so-called Containerfile) to 49 | the container engine to create a container image by downloading, assembling and 50 | configuring software. 51 | 52 | In most cases it becomes clear from context what is meant when speaking of 53 | containers so that a specification is usually not necessary. 54 | 55 | What is a container image made up of? 56 | Similar to other build environments - like e.g. Yocto - container images 57 | consist of layers that build on top of each other and contain different 58 | components, functionalities and modifications as schematically shown in 59 | Figure 1. 60 | 61 | Figure 1: Structure of a Container image made up of stacked layers containing 62 | different Functionalities. (Container-Content.svg) 63 | 64 | The lowest layer is called "base layer" or "base image" and contains essential 65 | system requirements such as system libraries, a package management system and a 66 | shell. Figure 2 shows schematically how subsequent layers add individual 67 | applications and their libraries or updates to modify or replace software in 68 | lower layers. 69 | 70 | Figure 2: Schematic representation of components inside individual container 71 | layers. (Container-Layers.svg) 72 | 73 | When a container instance is created from such an image and started, the 74 | running container shows only the projection onto the topmost layer as shown in 75 | Figure 3. However, the distributed image and the running container still 76 | include all software components of every layer. 77 | 78 | Figure 3: Representation of the view from inside a running container instance: 79 | All layers are projected onto the top layer. Original versions of deleted and 80 | modified components (E and C) are not visible but still included. 81 | (Container-Top-View.svg) 82 | 83 | Where do container layers come from? 84 | A container base image is generally derived from a minimal version of a Linux 85 | distribution such as Debian, Ubuntu or Alpine. These base images are often 86 | provided directly by the distributions themselves. In addition, there is a 87 | large number of public repositories offering container images of various 88 | projects. These are in turn usually built on top of a distribution base layer. 89 | Individual customization, however, is obtained from private company 90 | repositories or created manually. 91 | 92 | FOSS in containers 93 | As already apparent from the base layers' description containers usually 94 | include also Free and Open Source software (FOSS). Thus, license obligations of 95 | the contained FOSS must be complied with when copying and distributing or 96 | publicly reproducing containers. Depending on the respective licenses this may 97 | include information obligations (delivery of license texts, copyright notices, 98 | warranty disclaimers, etc.), disclosure obligations (delivery or offer of the 99 | complete corresponding source code and build and installation instructions) and 100 | licensing obligations (considering FOSS in Terms of Use and EULA, correctly 101 | licensing own development in case a derivative work with copyleft licensed FOSS 102 | is created). Complying with these license obligations is particularly 103 | challenging for containerized software for two main reasons: 104 | 105 | 1. Due to the layered structure of containers it is not obvious which 106 | software is actually distributed. 107 | License obligations have to be fulfilled for all included software components, 108 | irrespective of whether they are ever used or not. Thus, also the license 109 | conditions of software in lower layers must be complied with. 110 | 111 | 2. A vast majority of public container repositories do not include sufficient 112 | or even any compliance material. 113 | However, the obligation to comply with license conditions remains largely with 114 | the distributor of a container and not with the owner of a repository. 115 | 116 | What about Containerfiles? 117 | In general, FOSS license obligations are only required to be fulfilled when 118 | distributing or publicly reproducing the software. In many cases however, 119 | containers are not distributed physically but specified in form of 120 | Containerfiles whereby software is downloaded and configured only at the 121 | recipient's end. Thus, the container engine creates a container image according 122 | to the instructions from the Containerfile. Who is responsible for license 123 | compliance of the downloaded software in this case? To answer this question the 124 | definition of "distribution" according to copyright law must be considered. For 125 | this purpose, it must be noted that several German and European court rulings 126 | interpret the concept of distribution insofar as the legal person who controls 127 | or holds the organizational responsibility over the act of distribution is also 128 | responsible for it. With respect to Containerfiles this means that the person 129 | who creates a Containerfile - and thereby controls what software is used in 130 | what way - must also fulfill the license obligations of any downloaded FOSS 131 | when the Containerfile is executed at the recipient's end. Therefore, 132 | distributing a Containerfile is equivalent to distributing the specified 133 | container image. 134 | 135 | Are there any exceptions? 136 | 137 | In light of the present situation, the question arises whether and how 138 | compliance efforts can be consolidated within the community. It should be noted 139 | that FOSS licenses do not impose any conditions on the availability of system 140 | requirements. For example, if a FOSS application is distributed as a 141 | stand-alone item, no license obligations have to be fulfilled for the operating 142 | system that must be present at the recipient's end for the application to run. 143 | When distributing containers it is respectively true that no license 144 | obligations must be fulfilled for the operating system or the container engine 145 | if these are installed by the recipient. Taking into account the definition of 146 | container base images as a collection of essential system components, it can be 147 | fathomable to extend the definition of "system requirements" to include 148 | container base images. Following this, referencing a base image in a 149 | Containerfile might be considered support in acquiring the system requirements 150 | instead of an individual act of distribution. The result of this interpretation 151 | is that license obligations for the base image do not have to be fulfilled by 152 | the creator of the Containerfile but by the owner of the repository that 153 | provides it. A condition for this to be permissible is that there are no 154 | modifications of the base image and especially that the base image is 155 | distributed in a license compliant way by the owner of the repository. However, 156 | this exception cannot be extended to include software components beyond the base 157 | image as the individual composition of various layers concern a particular 158 | container and can therefore no longer be considered system requirements. 159 | Manufacturers must still fulfill license obligations of individually selected 160 | software when distributing Containerfiles. In addition, it should be noted that 161 | so far there is no case law on this topic, and therefore, different 162 | interpretations with respect to the distribution of Containerfiles and the 163 | exception of base images are conceivable. However, there is a published article 164 | on the issue by a renowned specialist lawyer available that advocates and 165 | substantiates the interpretation presented here: "Distribution of 166 | Dockerfiles: Who is responsible for FOSS License Compliance?", Journal of 167 | Open Law, Technology, \& Society, 12(1), pp 1 20 DOI: 10.5033/jolts .v1 2 168 | i1.147, (https://jolts.world/index.php/jolts/article/download/147/267) 169 | 170 | A license compliant container base image! 171 | 172 | When taking the described interpretation as valid, a manufacturer does not have 173 | to fulfill license obligations for a base layer if the distributed Containerfile 174 | can obtain the base layer in a license compliant way from the referenced 175 | repository. As laid out above, this is currently not the case for most 176 | providers. However, it seems obvious for a solution to the issue to apply the 177 | Open Source principle of shared development of non-differentiating technologies 178 | and services to license compliance of container base images. Therefore, OSADL 179 | has initiated the OSADL Base Image project to create license compliant versions 180 | of frequently used Linux based container base images and provide these 181 | publicly. License compliant means in particular to provide the complete 182 | corresponding source code that can be rebuild and installed according to the 183 | provided build and installation instructions, the extracted license texts and 184 | copyright notices, a separate warranty disclaimer in favor of the original 185 | authors and conspicuous legal notices to point out where to find the 186 | above-mentioned material. The OSADL Base Images are also available in two 187 | versions: 188 | 189 | - Immediate source code delivery: All compliance material is contained 190 | within the base image itself. 191 | 192 | - Delayed source code delivery with written offer: Only the legal notices, the 193 | extracted license texts and copyright notices and the written offer for the 194 | source code are contained within the base image. The source code and build and 195 | installation instructions are provided separately. 196 | 197 | The currently available variants and architectures of the OSADL Base Image are 198 | listed on the project website (https://www.osadl.org/base-image). In addition, 199 | instructions on how the base image and the compliance material is created are 200 | also available an can be used to create individual container layers in a 201 | license compliant way. 202 | 203 | -------------------------------------------------------------------------------- /Supplements/Container-Content.svg: -------------------------------------------------------------------------------- 1 | 2 | 17 | 19 | 21 | 29 | 34 | 35 | 43 | 48 | 49 | 57 | 62 | 63 | 71 | 76 | 77 | 85 | 90 | 91 | 99 | 104 | 105 | 113 | 118 | 119 | 127 | 132 | 133 | 141 | 146 | 147 | 148 | 172 | 174 | 175 | 177 | image/svg+xml 178 | 180 | 181 | 182 | 183 | 184 | 189 | 197 | 205 | 213 | 224 | 228 | 232 | 236 | Base image 247 | Add B and D 258 | Modify C, delete E 269 | A 280 | C 291 | E 302 | 313 | F 324 | D 335 | B 346 | C' 357 | 361 | E 372 | 373 | 374 | -------------------------------------------------------------------------------- /Supplements/Container-Layers.svg: -------------------------------------------------------------------------------- 1 | 2 | 17 | 19 | 27 | 32 | 33 | 41 | 46 | 47 | 55 | 60 | 61 | 69 | 74 | 75 | 83 | 88 | 89 | 97 | 102 | 103 | 111 | 116 | 117 | 125 | 130 | 131 | 139 | 144 | 145 | 146 | 170 | 172 | 173 | 175 | image/svg+xml 176 | 178 | 179 | 180 | 181 | 182 | 187 | 194 | 201 | 208 | 219 | Layer 1: Base image 230 | Layer 2: Application 241 | Layer 3: Updates 252 | 256 | 260 | 264 | System requirements: system libraries, package management, shell, ... 282 | Application and required libraries 295 | Delete and modify 306 | 307 | 308 | -------------------------------------------------------------------------------- /Supplements/Container-Top-View.svg: -------------------------------------------------------------------------------- 1 | 2 | 18 | 20 | 22 | 25 | 29 | 33 | 34 | 42 | 47 | 48 | 56 | 61 | 62 | 70 | 75 | 76 | 84 | 89 | 90 | 98 | 103 | 104 | 112 | 117 | 118 | 126 | 131 | 132 | 140 | 145 | 146 | 154 | 159 | 160 | 169 | 179 | 180 | 204 | 206 | 207 | 209 | image/svg+xml 210 | 212 | 213 | 214 | 215 | 216 | 221 | 229 | 237 | 248 | A 259 | F 270 | D 281 | B 292 | C' 303 | 312 | E 323 | 332 | 343 | 352 | C 363 | 372 | 373 | 374 | -------------------------------------------------------------------------------- /Supplements/Copyleft.txt: -------------------------------------------------------------------------------- 1 | %########################################################################### 2 | % 3 | % Supplement to the OSADL Open Source Policy Template 4 | % 5 | % Copyright (c) 2019,2020 Open Source Automation Development Lab (OSADL) eG 6 | % Author: Carsten Emde, Caren Kresse 7 | % 8 | %########################################################################### 9 | 10 | What is copyleft? 11 | 12 | 13 | 1 Background 14 | The coinage copyleft was introduced by Richard Stallman in the 1980s. It is not, 15 | as may be suggested by the alleged dichotomy, the opposite of copyright, but 16 | rather is based on and enforced by copyright law. This supplement explains the 17 | various aspects of copyleft and the reasons why a company should define an 18 | individual policy on how to deal with it. 19 | 20 | 1.1 What is copyright in an adaption? 21 | Whenever an author adapts the work of another author with permission of the 22 | latter, he or she gains a copyright in the adaption, i.e. an own copyright in 23 | the adaptation that is dependent on the copyright in the original work. Thus, 24 | neither the original author nor the author of the derivative work has the legal 25 | power to decide independently how to license the adaptation. All license 26 | obligations must be fulfilled together whenever the derivative work is made 27 | publicly available or copied and distributed. The positive aspect of the 28 | copyright in an adaption is that the individual creative contribution of the 29 | adapter is honored and that the adapter has the right to be remunerated for his 30 | or her work. A potential difficulty however is that an adapter - as long as he 31 | or she stays within the permissions of the original license - may impose 32 | license obligations that contradict the existing ones. In that case, the two 33 | license obligations are incompatible, and the common work may never be copied 34 | and distributed throughout the entire legal protection period (The Berne 35 | Convention for the Protection of Literary and Artistic Works stipulates that 36 | national law of member countries must grant copyright protection during the 37 | entire life of the author plus at least 50 years, if the author is known. If 38 | the author is unknown, the date of the creation or the first publication is 39 | used as reference, but national law differs considerably how this is further 40 | ruled.) unless holders of rights reach an agreement later on. Nevertheless, it 41 | certainly is possible that the license obligations are different, but 42 | compatible. But there remains the fact that it may become difficult, if not 43 | impossible, to evaluate the various licenses of a work for compatibility, if a 44 | rather large number of adapters have modified or expanded the original work and 45 | are imposing individual and different obligations. 46 | 47 | 1.2 What is copyleft? 48 | The origin 49 | While Free and Open Source software (FOSS) existed before the concept of 50 | copyleft was nvented, and the freedoms that such licenses granted were 51 | appreciated by users and adapters of such software, there always remained the 52 | risk that adapters would not license their contributions as FOSS and thereby 53 | reproprietarize the work. The concept of copyleft aims to counteract this 54 | threat to FOSS: A copyright license may contain a clause that denies the right 55 | of adapters to add own license obligations or to modify existing ones, but 56 | forces the adapter to always use the original copyright license. Such a clause 57 | is called copyleft. 58 | 59 | Some might see this obligation to always use the original license as a 60 | restriction of their freedom ("I may not reproprietare") while others see it as 61 | an increase in their freedom ("my adaption is protected from being 62 | reproprietarized"). Either way, copyleft certainly has simplified licensing 63 | works with a large number of different adapters as only one license needs to be 64 | considered. 65 | 66 | The dilemma 67 | As outlined above, an advantage of copyleft is that the work will always be 68 | licensed under the same single license and questions never arise whether 69 | individual obligations of different licenses are compatible or not. But 70 | copyleft also has an important downside: An adapter may be forced to use 71 | unacceptable license conditions and, thus, cannot adapt the work, although 72 | these adaptations would improve the work or otherwise be welcome. The latter is 73 | particularly relevant in the case of software licenses, if the original license 74 | imposes strict obligations, for example, with respect to source code disclosure 75 | and implicit patent licensing. Since frequently used FOSS licenses such as the 76 | GNU General Public Licenses not only contain a copyleft clause, but also impose 77 | strict disclosure obligations and an explicit patent license, lawyers and legal 78 | departments tend to recommend avoiding copyleft licenses altogether. This 79 | recommendation is based on the fear that, due to a inadvertent lack of 80 | attention, proprietary and patented code may be combined with copyleft licensed 81 | software and, thus, the company's intellectual property would get lost. In 82 | the past, this fear has led to pejorative labeling of the copyleft effect as 83 | "viral", "infectious", or even as "cancerous". Such vocabulary is 84 | not only inappropriate, but simply wrong as far as the meaning is concerned and 85 | shall never be used in this context: Licensing a software under a particular 86 | license is always an active decision - mostly because of the compelling 87 | properties of a particular software, while a person may contract an infection 88 | or develop cancer completely unwillingly. Anyway, to generally avoid software 89 | under a copyleft license may be difficult, if not impossible, since important 90 | and indispensable software such as the Linux kernel or the GNU C library are 91 | exclusively distributed under a copyleft license. 92 | 93 | The potential 94 | From the adapter's vie- as opposed to the view of a user - the copyleft 95 | clause has an important advantage: It ensures that a work that once is free and 96 | open will stay so forever. Material that is licensed under a non-copyleft 97 | license, in contrast, may be improved and used in proprietary software by 98 | others, but the improvements may remain hidden, effectively leading to a 99 | re-proprietarization of the code. This may make it easier for a company's 100 | management to permit an employed engineer contributing to a project that is 101 | licensed under a copyleft license than if it were licensed differently. 102 | 103 | The policy 104 | Based on the above arguments pro and contra copyleft licenses, a company is well 105 | advised to introduce a general policy how and under what conditions to deal 106 | with copyleft - not only with respect to using and distributing FOSS, but 107 | also with respect to contributing to FOSS projects and to selecting a suitable 108 | license in case the company decides to establish own FOSS projects. Decisions 109 | on how unclear copyleft clauses in particular licenses are interpreted for a 110 | company should also be documented in such a policy. 111 | 112 | 1.3 Strong vs. weak copyleft 113 | The normal copyleft relates to any kind of derivative works (for an explanation 114 | of a derivative work refer to Supplement -> "What is a derivative work", 115 | irrespective of whether the various components of the derivative work can be 116 | individually separated and replaced or not. This normal copyleft is also called 117 | "strong copyleft". In contrast, a copyleft clause may contain an exception from 118 | the strict obligations that allows components that can be separated and replaced 119 | at a later date - for example because they consist of separate files - not to 120 | fall under the conditions of copyleft, and therefore may be licensed under a 121 | different license than the original work. For such a clause that considerably 122 | alleviates the license obligations of normal copyleft the term "weak copyleft" 123 | has prevailed. It must, however, be noted that the copyleft for adaptions of 124 | the original work is just as strong as normal copyleft and the restriction is 125 | only valid for separable components. Therefore, weak copyleft is also called 126 | "restricted copyleft". Furthermore, licenses that impose restricted copyleft 127 | conditions may impose other obligations on the components that are exempted 128 | from copyleft. The latter applies, for example, to the GNU C library that is 129 | licensed under the Lesser General Public License version 2.1. This license only 130 | imposes a weak copyleft and, thus, permits to use another license for a work to 131 | which it is linked, but requires that the terms of the other license "permit 132 | modification of the work for the customer's own use and reverse engineering 133 | for debugging such modifications". 134 | 135 | 2 Criteria for a copyleft policy 136 | 137 | 2.1 Using FOSS in-house 138 | The very generous licensing conditions of FOSS permit unrestricted use which 139 | even includes unrestricted copying within the organization of a legal person 140 | such as an incorporated or a limited liability company. This aspect remains 141 | unchanged the various FOSS license conditions and includes without exception 142 | even licenses with weak or strong copyleft. Insofar, a special policy is 143 | probably not needed that rules the in-house use of FOSS with respect to 144 | copyleft or not. Please consider that there might be a specific situation for 145 | SaaS which might be considered distribution in particular cases and which is not 146 | explicitly ruled in most older licenses. 147 | 148 | 2.2 Modifying in-house used FOSS 149 | If FOSS that is used in-house shall be modified, it is important to consider 150 | whether the particular software, the software department or even the entire 151 | company might be sold in the near or even far future, since this means that 152 | license obligations must be fulfilled at the time of the sale or other 153 | distribution. If this is the case, the copyleft policy should rule whether a 154 | copyleft license of in-house software is acceptable in case such software is 155 | adapted to the company's requirements. 156 | 157 | 2.3 Copying and distributing FOSS in products 158 | Copying and distributing FOSS in products requires that the related license 159 | conditions are fulfilled - including the obligations imposed by a copyleft 160 | clause, if any. Thus, the copyleft policy should first provide information which 161 | licenses are 162 | - considered not to have a copyleft clause 163 | - considered to have a weak copyleft clause 164 | - considered to have a strong copyleft clause 165 | - unclear with respect to copyleft 166 | 167 | and should give recommendations for what kind of software which type of copyleft 168 | is acceptable. The -> "OSADL Open Source License Obligations Checklists" may be 169 | consulted when writing this part of the copyleft policy. Declaring a particular 170 | copyleft license unacceptable is of course only relevant if the copyleft is 171 | triggered in a particular scenario. The approval process outlined in the FOSS 172 | policy takes the technical constellation into account. 173 | 174 | 2.4 Contributing to external FOSS projects 175 | Whenever an employed software engineer is creating a software work, he or she 176 | enjoys the exclusive exploitation rights granted by copyright law only for a 177 | non-measurable small amount of time, since these rights are automatically 178 | transferred to the employer according to, for example, § 69b UrhG (German 179 | copyright law). In addition, most companies' work contracts stipulate an 180 | equivalent rule including the work of freelancers and other non-employed 181 | contributors, since the transferal of exploitation rights from the latter is not 182 | part of the legal provision. A software engineer, therefore, needs the 183 | permission of the company's management,before he or she may contribute to an 184 | external FOSS project, and a policy is needed with respect to which licenses 185 | are acceptable for what kind of work. As already mentioned above, copyleft 186 | licenses may be preferable, since they protect the contributed code from being 187 | usurped by others, particularly by competitors. 188 | 189 | 2.5 Establishing own FOSS projects 190 | The above mentioned considerations for contributing to external FOSS projects 191 | apply just as much for own FOSS projects. In addition, the company has the 192 | choice which FOSS license to use. This requires that the copyleft policy must 193 | contain directions which licenses and particularly which copyleft conditions are 194 | mandatory, desirable, acceptable or unacceptable when own FOSS projects are 195 | established. 196 | 197 | As a general rule, for software that is mostly feature-complete, has little 198 | architecture and system dependencies, does not await further evolution and is 199 | hoped to be used by many in all kind of projects (such as, for example, a 200 | network protocol) a non-copyleft license probably is best suitable. In contrast, 201 | for a software that only is in its first stage, awaits a long evolution and can 202 | run stand-alone (such as, for example, the Linux kernel), a copyleft license is 203 | normally recommended. 204 | -------------------------------------------------------------------------------- /Supplements/How-To-Rebuild.txt: -------------------------------------------------------------------------------- 1 | %########################################################################### 2 | % 3 | % Supplement to the OSADL Open Source Policy Template 4 | % 5 | % Copyright (c) 2019,2020 Open Source Automation Development Lab (OSADL) eG 6 | % Author: Armijn Hemel, Carsten Emde, Caren Kresse 7 | % 8 | %########################################################################### 9 | 10 | How to archive and rebuild 11 | 12 | 13 | Archiving and storing source code for a rebuild is important: It is possible 14 | that years after a product has been released someone needs to be able to rebuild 15 | the source code for various reasons such as license compliance or security - or 16 | simply bug fixing. 17 | 18 | 1 Archiving 19 | 20 | When archiving source code the following information has to be stored in a repository: 21 | - product name and version 22 | - source code (the build tree of a source code release must be clean (e.g. make 23 | clean or equivalent), i.e. there must not be any binary artifacts) 24 | - (re)build instructions 25 | - description of the environment: 26 | - operating system and version 27 | - installed packages (dependencies) 28 | - environment variables, users, paths and permissions if changed from default 29 | - expected results 30 | 31 | If a company already has a corporate backup strategy, it is recommended to 32 | include this information in the backup for convenience and to ensure that it 33 | does not get lost over time. In any way, this information should be stored in a 34 | way that makes it easy to be located in the version control system of a company, 35 | for example as separate Git tag. It is advisable to store the build artifacts. 36 | In certain situations (such as very old software) it is recommended to even 37 | store all software including the entire tool chain and everything else that is 38 | needed for a rebuild (e.g. a disk snapshot to later load into a virtual 39 | machine, original installation media, etc.) 40 | 41 | After archiving source code a rebuild should be done to ensure that the archived 42 | information is complete and correct. 43 | 44 | 2 Rebuild 45 | 46 | Doing a test rebuild of archived source code is important, particularly with 47 | respect to the disclosure obligations imposed by some FOSS licenses. When the 48 | source code is made available either along with the delivery of a product or as 49 | required in accordance with a written offer, for example as stipulated in 50 | section 3 of the GNU General Public License version 2 (GPL-2.0), the source 51 | code must be complete and correspond to the binary version contained in the 52 | product. In addition, comprehensive build instructions must be provided to 53 | allow an average skilled software engineer with reasonable effort to 54 | successfully rebuild the software. If a rebuild is not possible or the 55 | resulting object code is not absolutely identical to the original one, the 56 | company is in breach of the license which may entail legal consequences. 57 | Therefore, the preparation of the software archive must be done with utmost 58 | diligence and must not be delivered to the requesting customer, unless a test 59 | rebuild could be performed successfully. 60 | 61 | I. Who should carry out the test rebuild? 62 | It is recommended that the test rebuild is carried out by a person who is not 63 | directly involved in the original software development of the product, i.e. by 64 | someone without intimate implicit knowledge of the build process in order to be 65 | able to catch any undocumented steps. 66 | 67 | II. How should the test rebuild be carried out? 68 | The following steps should be taken for a rebuild: 69 | 70 | 1. Install a (virtual) machine as specified in the archived instructions to 71 | make sure that the success of the rebuild does not depend on the system where 72 | the original software was built. 73 | 2. Follow the instructions and rebuild the source code 74 | 3. Compare the built binary with the original binary (see section below) 75 | 76 | If a rebuild cannot be successfully done, the build instructions are not 77 | complete and must be amended accordingly. 78 | 79 | III. How should the created object code be tested whether it is complete and 80 | corresponding? 81 | The silver bullet of checking for completeness and correspondence, obviously, is 82 | to obtain identicalness of the original and the newly created software. 83 | However, this is not always the case, since for example 84 | 85 | 1. the tool chain may have been updated, 86 | 2. the tool chain may generate and insert time stamps and/or random numbers, 87 | 3. the tool chain may include debug information such as absolute file names 88 | (that almost always differ when software is built at different locations), 89 | 4. the order of the software components may have changed. 90 | 91 | The easy case: Files are identical 92 | Whether files are identical can easily be tested using the cmp command line tool 93 | that only exits without error, if the compared files are the same. Similarly, 94 | cryptographic checksum generators such as md5sum or sha256sum can be run and 95 | identical files can be assumed, if the checksums are identical. 96 | 97 | The challenging case: Files are not identical 98 | If the files are not identical, the easiest way to establish functional 99 | equivalence is to run the original and the newly created software and to compare 100 | results. This is greatly facilitated, if an original conformance test suite is 101 | available that may be run by either software. If not, typical runtime scenarios 102 | may be selected and the two software versions tested on them. 103 | 104 | Alternatively and if the software may not easily be run and tested, string and 105 | string-like constants may be extracted using the strings command line tool and 106 | compared using a tool to search for text differences such as diff. Differences 107 | detected by the cmp tool or slight differences in size may then be explained by, 108 | for example, different build dates that are included in the binary program. 109 | 110 | Example 111 | A program may contain a similar puts instruction to print a message with time 112 | and date information as in the following example: 113 | 114 | #include 115 | 116 | int main(int argc, char *argv[]) 117 | { 118 | puts("This program was built on " __DATE__ ", at " __TIME__ "\n"); 119 | } 120 | 121 | The compiler will evaluate the terms __DATE__ and __TIME__ at compile time and 122 | insert the resulting texts as string constants into the program. When the 123 | program is compiled during creation of the original distribution and compiled 124 | again at the time of the rebuild test, two different program versions are 125 | created that do not pass the test for identicalness: 126 | 127 | # cmp example.orig example.rebuild 128 | example.orig example.rebuild differ: byte 757, line 1 129 | 130 | However, when strings are extracted from the two program versions and compared 131 | using the following commands 132 | 133 | # strings example.orig >example.orig.strings 134 | # strings example.rebuild >example.rebuild.strings 135 | # diff example.orig.strings example.rebuild.strings 136 | 9c9 137 | < This program was built on Jan 1 2020, at 12:34:56 138 | --> This program was built on Jan 31 2020, at 01:23:45 139 | 140 | it becomes evident that the two programs merely show a plausible difference in a 141 | string constant, but everything else is identical. 142 | 143 | Build instructions 144 | Some FOSS licenses, in particular the GNU (Lesser) General Public Licenses, 145 | require the distributor of binary software to also deliver "scripts to control 146 | compilation and installation" (GPL-2.0 sect. 3), build and installation 147 | instructions as part of the complete corresponding source code. Such 148 | instructions could read as follows 149 | (https://github.com/armijnhemel/compliance-scripts/blob/master/doc/build-instructions-template.txt): 150 | 151 | ======================================================================== 152 | SPDX-Identifier: CCO-1.0 153 | These are the build instructions to rebuild the FOSS components for 154 | [SOFTWARE NAME AND VERSION]. 155 | 156 | Please note: Rebuilding the source code and reinstalling the resulting programs 157 | onto the device are not supported by our technical support department! Warranty 158 | claims on the modified software will expire, as long as the customer cannot 159 | prove that the defect would also occur without the modification. 160 | 161 | The instructions below have been tested on [DISTRIBUTION]. Other operating 162 | systems or distributions have not been tested. 163 | 164 | To rebuild the software, the following steps must be performed: 165 | 166 | 1. Installing a (virtual) machine with [DISTRIBUTION], with at least 167 | [SPACE] GiB of free disk space available. 168 | 169 | 2. Installing the following packages: 170 | * [PACKAGE 1] 171 | * [PACKAGE 2] 172 | * [PACKAGE N] 173 | 174 | 3. Creating a directory [SOURCE DIRECTORY]: 175 | 176 | $ sudo mkdir -p [SOURCE DIRECTORY] 177 | 178 | 4. Optional: changing the owner and environment of the directory 179 | 180 | $ sudo chown [USR:GROUP] [SOURCE DIRECTORY] 181 | $ export [VARIABLE] 182 | 183 | 5. Unpacking the archive [SOURCE ARCHIVE] to this directory 184 | 185 | $ cd [SOURCE DIRECTORY] 186 | $ tar xf [SOURCE ARCHIVE] 187 | 188 | 6. Starting the build process 189 | 190 | [BUILD INSTRUCTIONS] 191 | 192 | 7. After the build process is complete, the built binaries are located in 193 | [BINARY DIRECTORY] and can be installed with 194 | 195 | [INSTALLATION INSTRUCTIONS] 196 | ======================================================================== 197 | -------------------------------------------------------------------------------- /Supplements/How-To-Scan.txt: -------------------------------------------------------------------------------- 1 | %########################################################################### 2 | % 3 | % Supplement to the OSADL Open Source Policy Template 4 | % 5 | % Copyright (c) 2019,2020 Open Source Automation Development Lab (OSADL) eG 6 | % Author: Carsten Emde, Caren Kresse 7 | % 8 | %########################################################################### 9 | 10 | How to scan 11 | 12 | 13 | 1 Introduction 14 | 15 | What is scanning? 16 | The term "scanning" in the context of software license compliance may refer to 17 | two completely different issues: 18 | 19 | 1. Informational software scanning 20 | Extract typical lines of text from program sources and other files possibly 21 | protected by copyright law. The main purpose is to collect obvious notices in 22 | plain text. 23 | 24 | 2. Forensic software scanning or code clone scanning 25 | Discover non-obvious, hidden or even obfuscated software snippets that were 26 | incorporated from third parties into a particular source code and may not be 27 | licensed correctly. For this purpose, certain criteria from suspicious software 28 | ("fingerprints") are matched against a usually large data base of the same 29 | criteria of known software components. 30 | 31 | Table 1: Characteristics of informational and forensic software scanning 32 | 33 | Informational Scanning 34 | Effort: Low 35 | Duration: Hours/days 36 | FOSS: Available 37 | Expensive: Not at all 38 | Examples: Monk, Nomos, Scancode, Fossology (Fossology is not a scanning 39 | program per se, but is an administration server that uses external scanners) 40 | 41 | Forensic Scanning 42 | Effort: High 43 | Duration: Days/weeks 44 | FOSS: Not available 45 | Expensive: Very 46 | Examples: Black Duck (Synopsys), Palamida (Flexera), FossID 47 | 48 | As can be seen, the two scanning variants, informational and forensic, have 49 | little in common; thus, they will be presented and discussed in the following in 50 | two different main sections. 51 | 52 | 2 Informational scanning 53 | 54 | 2.1 Motivation 55 | Most FOSS licenses require that copyright notices, warranty disclaimer and 56 | license texts are made available to a recipient of software that is conveyed 57 | under such license. If the software is delivered in source code form, this is 58 | usually easy to do and may not even require any additional action, since these 59 | notices and texts are normally available within or along with the source code. 60 | Some licenses, such as the various variants of the GNU General Public licenses, 61 | make it a little more difficult, since they require that copyright notices and 62 | warranty disclaimer are published in a conspicuous manner which usually 63 | requires some extra work even if source code is only forwarded. However, 64 | fulfilling the information obligations of FOSS licenses always requires 65 | additional actions if the distribution is done in binary form, since 66 | accompanying documentation and comments that may contain such information are 67 | stripped from the source code during creation of the binary. In consequence, 68 | legal texts and notices need to be extracted from the original source code in a 69 | separate action to provide them to a recipient as required by the license. 70 | 71 | The differences in information obligations of FOSS licenses between source code 72 | and binary delivery is also reflected in the OSADL Open Source License 73 | Obligations Checklists by using the actions Forward or Provide for source code 74 | or binary delivery, respectively. For example, license obligations of the 75 | BSD-2-Clause license with respect to the copyright notices read: 76 | 77 | USE CASE Source code delivery 78 | YOU MUST Forward Copyright notices 79 | USE CASE Binary delivery 80 | YOU MUST Provide Copyright notices In Documentation OR Distribution material 81 | 82 | Hence, in case of binary delivery a company process or at least an additional 83 | procedure during compilation must be established to create the information 84 | material that has to be provided and distributed along with the software in 85 | documentation or other material. 86 | 87 | 2.2 How does informational software scanning work? 88 | Informational software scanning uses an approach that is, at first glance, 89 | comparable to the Find function of a text processor: A case-insensitive search 90 | key such as "copyright (c)" followed by a number that indicates the year of 91 | writing the code, is defined and located in the text, and the subsequent part 92 | of the line is evaluated to retrieve, for example, the name and other data of 93 | the copyright holder. The most naive approach for this purpose can be realized 94 | by using the FOSS egrep function and specifying a so-called regular expression 95 | that matches usual forms of the copyright notice including any year number 96 | between 1900 and 2099 such as 97 | 98 | egrep -ir "Copyright \(c\) (19|20)[0-9][0-9]" . 99 | 100 | which may produce, for example in the init subdirectory of the Linux kernel 101 | source code, the output 102 | 103 | main.c: * Copyright (C) 1991, 1992 Linus Torvalds 104 | calibrate.c: * Copyright (C) 1991, 1992 Linus Torvalds 105 | noinitramfs.c: * Copyright (C) 2006, NXP Semiconductors, All Rights Reserved 106 | version.c: * Copyright (C) 1992 Theodore Ts'o 107 | 108 | The first word of the above output lines reproduces the name of the source code 109 | where the subsequently printed copyright notice was found. A similar procedure 110 | may then be undertaken to extract other required legal notices such as warranty 111 | disclaimer and type of license. It should be noted that licenses in source code 112 | come in two forms: 113 | 114 | - License text: The complete text of the license. Commonly used for shorter 115 | licenses such as BSD or MIT. 116 | - License reference: For source code released under licenses with a long license 117 | text (such as the (L)GPL or Apache licenses), an abbreviated reference that 118 | indicates the license (and possibly where to find the complete text) is used. 119 | This can sometimes be a single SPDX identifier. 120 | 121 | While the variations of license texts are limited, there may be spelling 122 | variants, line breaks or other deviations from the usual form of all other legal 123 | notices in source code, since there are no legal provisions how to compose 124 | them. In consequence, the form of the copyright notice is merely limited by the 125 | creativity of software engineers. Software scanning tools developed 126 | particularly for this purpose have already been mentioned in the introduction. 127 | They take, at least to a certain amount, into consideration the above 128 | limitations and should therefore be used instead. Nevertheless, their working 129 | mode is based on the same principle as the egrep example above, i.e. they 130 | search for occurrences of predefined match strings. Furthermore, they may 131 | implement a fuzzy algorithm to detect keywords even if they are inaccurately 132 | phrased. 133 | 134 | In most cases, the results of scan tools cannot be used without some manual 135 | modifications to account for inaccuracies within the source files. Of course, 136 | notices may not be changed without possessing the rights required to do so but 137 | for example licenses that are only listed in a root directory but are explicitly 138 | stated to be valid for all files below the respective root directory may be 139 | assigned to the concerned files. Therefore, in addition to scan tools, it is 140 | recommended to employ a company wide license management tool that stores the 141 | scanning results and manual completions in a database and allows to administer, 142 | adapt and retrieve them under various usage conditions. A suitable license 143 | management tool for this purpose is Fossology. It should, however, be noted that 144 | Fossology itself is not a scanning tool, but makes use of various default 145 | software scanners that are normally part of the standard installation. In 146 | addition, it offers the possibility to configure individual scanners at the 147 | user's choice. 148 | 149 | There is no definitive form in which to deliver the extracted materials. 150 | However, it is commonly accepted to organize them by software package. 151 | 152 | 2.3 Introducing informational software scanning in a company 153 | Although it certainly is possible to execute informational software scanning 154 | from time to time manually, it is recommended to introduce related standard 155 | processes as part of the overall software license compliance policy of a 156 | company. For this purpose, two process bottlenecks have to be established that 157 | must be passed by every piece of software that is used in a company, and 158 | informational software scanning is either performed or verified at the 159 | bottlenecks. The first bottleneck is reached when software is entering the 160 | company and is referred to as input gateway. The other bottleneck is reached 161 | when software is leaving the company and is referred to as output gateway: 162 | 163 | Input gateway 164 | Purpose: Ensure that all licenses of incoming software are registered and 165 | checked 166 | Occasion: Software evaluation/purchase 167 | 168 | Output gateway 169 | Purpose: Ensure that all license obligations of outgoing software are fulfilled 170 | Occasion: Intermediate/official software release 171 | 172 | Table 2: Purpose of software scanning at the input and output gateway 173 | 174 | 2.4 Scanning for additional requirements 175 | Almost all modern software requires additional components, i.e. software 176 | libraries, to be linked dynamically when running (see Supplement -> "What is a 177 | derivative work?" for details on dynamic linking). These libraries are often 178 | not supplied when software is entering a company but are expected to be already 179 | available or to be acquired separately. To be aware of all additional 180 | components an incoming software might require to run, the input gateway should 181 | include a scan for so-called "unresolved symbols". These unresolved symbols 182 | in a binary software indicate that additional components are required which 183 | might impose further license obligations. It is recommended to evaluate such 184 | possible additional licenses in accordance with a company's established FOSS 185 | policy. 186 | 187 | Scanning for unresolved symbols within a binary software is straightforward and 188 | only requires simple tools. One example is the command line tool objdump that 189 | displays information about binary objects including the symbol table storing 190 | each of the program's symbols along with, among other, information about its 191 | location. If a symbol cannot be located within the object - i.e. it cannot be 192 | resolved - it is marked as "UND" (undefined), for example 193 | 194 | objdump -T myprogram | grep UND 195 | 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 exit 196 | 197 | Unresolved symbols need to be supplied by the respective libraries when the 198 | program is running; in the above example the locally unavailable C function 199 | exit() can be resolved by version 2.2.5 of the GNU C library that needs to be 200 | supplied when the program myprogram is launched. 201 | 202 | 2.5 Training for informational software scanning 203 | The usage of the various tools of informational software scanning and, 204 | particularly, of the management tool Fossology is not obvious. A company's 205 | compliance process should, therefore, contain in-house training or 206 | participation at external training courses of the responsible personnel to 207 | ensure that the software is adequately installed and used and the results may 208 | be trusted. 209 | 210 | 3 Forensic scanning 211 | 212 | The above described method of informational scanning is based on trust: It is 213 | assumed that i) all legal notices in the source code are accurate and complete 214 | or inconsistencies can be resolved manually and ii) no software of unknown or 215 | doubtful origin was introduced. This, however, is not always possible; thus, 216 | methods had to be developed to discover negligent or fraudulent contamination of 217 | source code with unlicensed or even unlicensable material. Such methods are 218 | called "forensic scanning". For the time being, they are primarily available 219 | to search for undeclared FOSS in a given source code. Prior to searching, short 220 | unique characteristics (similar to fingerprints of humans) of appropriate code 221 | snippets of all known and publicly available released versions of FOSS are 222 | generated and stored along with project data in a database that may become 223 | rather huge, e.g. several tens or even hundreds of terabytes. When using 224 | forensic scanning for undeclared FOSS in a suspicious source code, 225 | characteristic fingerprints of appropriate code snippets of that source code are 226 | generated in the same way as when creating the database of known Open source 227 | software, and these characteristics are searched for in the database. If a match 228 | is found, the corresponding code snippet is compared manually to exclude a 229 | false-positive finding. In case of a confirmed match, appropriate steps have to 230 | be taken to either remove the faulted software snippet or to compliantly license 231 | it. 232 | 233 | 3.1 Criteria whether forensic scanning is needed or not 234 | Since forensic scanning is, for the time being, not available as a FOSS tool, 235 | and licensing such software can be very expensive, it is recommended to 236 | carefully evaluate whether forensic scanning is needed or not. The main 237 | criterion, as already mentioned above, is trust. Can a company trust another 238 | company or a person who is delivering a particular piece of software? This 239 | equally applies to employed software developers, to freelancers and software 240 | providers and, last but not least, even to software and hardware manufacturers, 241 | if the purchased products are intended to be integrated into own devices and 242 | brought to the market as a product. Alternatively, it may be negotiated that the 243 | provider undertakes forensic scanning and delivers the scan result along with 244 | the product. However, this again introduces the need for a certain trust that 245 | the external forensic scanning was executed thoroughly and no results were 246 | retained. 247 | 248 | Apart from the criteria mentioned above, it might make sense to conduct a 249 | forensic scan when acquiring companies or company shares if the main assets of 250 | that company are copyrights in their software. 251 | 252 | 3.2 Special case: Single-shot or double-shot forensic scanning 253 | A company may only recently have introduced appropriate processes to ensure that 254 | all software that is entered into the company's software pool is correctly 255 | registered and, thus, licensable. However, the existing software that was grown 256 | over many years may not have undergone comparably rigorous compliance processes 257 | in the past. In such a case, a "one-shot" forensic scanning may be executed 258 | to either ensure that the entire software pool is clean or, if this is not the 259 | case, to take appropriate measures that it becomes clean. Thereafter, one may 260 | either trust the newly introduced processes (single-shot forensic scanning) or 261 | repeat the scanning after a test period of, for example a year, to ensure that 262 | the new processes are reliably in place (double-shot forensic scanning). Such 263 | limited forensic scanning is certainly less expensive and resource intensive 264 | than continuous scanning, but may, if appropriately executed, provide a 265 | comparable amount of trust. 266 | -------------------------------------------------------------------------------- /Supplements/License-Choice.txt: -------------------------------------------------------------------------------- 1 | %########################################################################### 2 | % 3 | % Supplement to the OSADL Open Source Policy Template 4 | % 5 | % Copyright (c) 2019,2020 Open Source Automation Development Lab (OSADL) eG 6 | % Author: Till Jaeger, Caren Kresse 7 | % 8 | %########################################################################### 9 | 10 | Selecting a FOSS license 11 | 12 | 13 | This document gives some selection criteria and the outline of a selection 14 | process for choosing a Free and Open Source Software (FOSS) license for a 15 | software project. The flowchart at the end of this document displays the 16 | sequence of steps that are described herein. 17 | 18 | Selection Criteria 19 | 20 | 0. Eligible FOSS licenses 21 | It is generally recommended to use established and well-known FOSS licenses to 22 | further acceptance and facilitate subsequent use. While many popular choices 23 | have become outdated, the following licenses have proven to be widely accepted 24 | and known standard licenses and are therefore considered eligible. They are 25 | grouped in the following list according to the extent of copyleft (for details see 26 | -> "What is copyleft?"): 27 | 28 | a) Licenses with a strong copyleft 29 | - GNU General Public License v2.0 (GPL-2.0) 30 | - GNU General Public License v3.0 (GPL-3.0) 31 | - GNU Affero General Public License v3.0 (AGPL-3.0) 32 | 33 | b) Licenses with a weak ("restricted") copyleft 34 | - Mozilla Public License 2.0 (MPL-2.0) 35 | - Eclipse Public License 2.0 (EPL-2.0) 36 | - GNU Lesser General Public License v3.0 (LGPL-3.0) 37 | - GNU Lesser General Public License v2.1 (LGPL-2.1) 38 | 39 | c) Permissive licenses (licenses without a copyleft) 40 | - MIT License (MIT) 41 | - Apache License 2.0 (Apache-2.0) 42 | 43 | 1. Are there enough rights of use on the code that is to be licensed as FOSS? 44 | As a rule, the worlwide, perpetual and unrevocable unrestricted rights of use 45 | are required for copying, distribution, public reproduction and modification 46 | (e.g. acquired through Art. 69b UrhG (German Copyright Act) or through a license 47 | agreement). In some cases non-exclusive and sublicensable rights can be 48 | sufficient. 49 | 50 | 2. Does the code contain pre-existing proprietary third-party components? 51 | If the code contains proprietary third-party components (e.g. .NET libraries), 52 | licensing it under a strong copyleft license is generally not possible, unless 53 | all proprietary third-party components are removed. 54 | 55 | 3. Does the code contain pre-existing FOSS components? 56 | If the code contains third-party FOSS components, it must be checked 57 | a) whether these existing components are licensed under a copyleft license that 58 | determines the license for the entire code or that requires a compatibility 59 | check, or 60 | b) whether these existing components are licensed under a permissive license and 61 | the compatibility with the final project license must be checked. 62 | 63 | 4. Should users be required to license their modifications as FOSS by selecting 64 | a copyleft license? 65 | The essential question when selecting a license is the decision whether it 66 | should have a copyleft clause and thereby prevent modifications and continuous 67 | development to become proprietary, or whether it is acceptable that 68 | modifications and continuous development may be licensed proprietarily. This 69 | question is in close context with question 5. 70 | 71 | 5. Is the software meant to be used in close connection (static or dynamic 72 | linking or substantial integration) with other programs that may be proprietary 73 | as well as FOSS? 74 | The typical context in which the software is meant to be used is to be 75 | determined. If linking (or similar integration) with other programs under 76 | arbitrary licenses shall be allowed, the final license of choice may only have a 77 | weak copyleft clause or must be permissive; licenses with a strong copyleft 78 | clause are generally not possible in such cases. Is the software meant to be 79 | used exclusively in a FOSS context, the relevant selection criterion is license 80 | compatibility. 81 | 82 | 6. If a copyleft clause is desired, should it also be valid when the software is 83 | not copied and distributed but offered as Software as a Service (SaaS) or as a 84 | cloud service? 85 | - AGPL-3.0 requires modifications to be disclosed also when the software is used 86 | interactively via network (e.g. cloud service) 87 | - GPL-3.0, LGPL-3.0, MPL-2.0 and EPL-2.0 do not extend their copyleft clause to 88 | this type of use 89 | - GPL-2.0 and LGPL-2.1: unclear 90 | 91 | Additional considerations 92 | 93 | The following questions do not influence the selection of the final FOSS 94 | license but are nonetheless important to consider when planning to license a 95 | project under a FOSS license. 96 | 97 | a) Are there own patents and are these to be licensed royalty-free with the 98 | software? 99 | All FOSS licenses require licensing implemented patents. Some licenses rule this 100 | explicitly others do not. For the sake of clarity, it is recommended to select a 101 | license that explicitly rules the extent of the patent license for one's own 102 | patents. 103 | 104 | b) Do own patents that are not (yet) implemented in the software remain 105 | unaffected? 106 | All FOSS licenses restrict the patent license to the particular licensed software. 107 | 108 | c) Can own liability and warranty be excluded? 109 | With regard to liability and warranty exclusion there are no significant 110 | differences between the eligible FOSS licenses under German contract law. 111 | Liability and warranty depend on the form of distribution and not on the choice 112 | of license. 113 | 114 | d) Does subsequent use require to reference the software's origin? 115 | All eligible FOSS licenses require to deliver the respective license text and 116 | possible copyright notices and thereby implicitly create the obligation to 117 | disclose the software's origin to the user. 118 | 119 | e) Does the license allow third parties (companies or developers) to contribute 120 | to the continuous development of the software? 121 | All FOSS licenses grant sufficient rights of use to allow every interested party 122 | to contribute. 123 | 124 | f) Can the software quality be assured? 125 | Quality assurance does not depend on the choice of license but on the control of 126 | the FOSS development process. Controlling the "official" development process 127 | (e.g. on a development or version control platform such as Eclipse or GitHub) 128 | can also influence the software quality, e.g. by accepting or declining 129 | third-party contributions. Although a fork from the "official" project cannot be 130 | prevented, transferring a negative reputation can be constrained by controlling 131 | the project name (work title, trademark). 132 | 133 | g) Must the license be compatible with GPL-2.0 and/or GPL-3.0 or AGPL-3.0? 134 | - MPL-2.0 is by default compatible, but compatibility can be explicitly 135 | excluded as per Exhibit B of the MPL-2.0. 136 | - EPL-2.0 is by default not compatible, but compatibility can be created 137 | explicitly as per Exhibit A of the EPL-2.0. 138 | - MIT is compatible with all eligible FOSS licenses listed in section 0. 139 | - Apache-2.0 is compatible with GPL-3.0 and AGPL-3.0 but not with GPL-2.0. 140 | 141 | Image: License-Choice-Flowchart.svg 142 | -------------------------------------------------------------------------------- /Supplements/License-Compatibility.txt: -------------------------------------------------------------------------------- 1 | %########################################################################### 2 | % 3 | % Annex to the OSADL Open Source Policy Template 4 | % 5 | % Copyright (c) 2020 Open Source Automation Development Lab (OSADL) eG 6 | % Author: Caren Kresse, Till Jaeger 7 | % 8 | %########################################################################### 9 | 10 | License compatibility 11 | 12 | 13 | In the course of the adoption of FOSS and modern software development 14 | strategies, it has become indispensable to combine pre-existing software 15 | components (e.g. program libraries) that are licensed under different licenses 16 | and distribute them together. The same applies to code snippets which are 17 | transferred from one FOSS project to another. This raises the question whether 18 | or not such code integration or combination under more than one FOSS license is 19 | compliant with the applicable license conditions and in which cases FOSS 20 | licenses are incompatible. 21 | 22 | There are three possible outcomes when evaluating compatibility of FOSS licenses 23 | with each other: 24 | 25 | - Incompatibility: Two licenses are incompatible with each other when they 26 | contradict each other, i.e. one requires something that the other one does not 27 | allow to require. 28 | 29 | - Unilateral compatibility: Two licenses are unilaterally compatible when their 30 | requirements do not contradict each other but one license requires to be the 31 | valid ("leading") license for the combination of code under the involved 32 | licenses (typically based on a copyleft clause). 33 | 34 | - Multilateral compatibility: Two or more licenses are bi- or multilaterally 35 | compatible when their requirements do not contradict each other and none of them 36 | has any licensing requirements on differently licensed components of the 37 | combination of code. 38 | 39 | Whereas the use of code under several permissive licenses is always permitted 40 | since there are no conflicting license conditions known to this day, the use of 41 | code under a copyleft license may cause license incompatibilities. The reason is 42 | that copyleft licenses are self-referential, i.e. the license requires that 43 | modifications must be licensed under the original license and not under any 44 | other licensing conditions. For details, see -> Supplement "What is Copyleft?". 45 | To the extent the copyleft of the involved licenses is not triggered, license 46 | compatibility is not an issue. However, if the copyleft in a concrete technical 47 | constellation extends to code under a divergent license, a license compatibility 48 | check must be carried out. Therefore, in a first step it must be checked whether 49 | and to what extent the copyleft of the relevant licenses is triggered, and 50 | subsequently in a second step the license compatibility of the licenses involved 51 | must be assessed. 52 | 53 | Some general guidelines for determining compatibility of FOSS licenses have 54 | evolved empirically: 55 | 56 | - Copyleft licenses are not compatible with each other. 57 | Copyleft licenses each require that the modified code be subject only to the 58 | original license. This is not feasible with multiple involved licenses with a 59 | copyleft, since all licenses but one are necessarily violated. 60 | 61 | Figure 1: Copyleft licenses are not compatible with each other (example). 62 | GPL-2.0, MPL-1.1, EPL-1.0 -> No compatibility 63 | 64 | Exception: 65 | A copyleft license may explicitly provide a particular compatibility exception 66 | for another copyleft license, e.g. LGPL-2.1 and GPL: "You may opt to apply the 67 | terms of the ordinary GNU General Public License instead of this License to a 68 | given copy of the Library." 69 | 70 | Figure 2: Compatibility of copyleft licenses can be explicitly ruled by 71 | exception (example). 72 | GPL-2.0, LGPL-2.1, MPL-2.0 -> GPL-2.0 73 | 74 | - Permissive licenses are unilaterally compatible with copyleft licenses. 75 | A copyleft license and a permissive license are generally compatible, with the 76 | copyleft license being the "leading" license under which the derivative work is 77 | distributed. The reason is that there is a long term consensus in the FOSS 78 | community that copyleft licenses are compatible with permissive license which do 79 | not have additional requirements but only license conditions contained in the 80 | copyleft license as well. 81 | 82 | Exception: 83 | If the permissive license contains 84 | additional requirements that the copyleft license does not require, they are not 85 | compatible; e.g. the BSD-4-Clause is a permissive license that contains an 86 | advertising clause (see -> Supplement "How to: Acknowledgments") which in the 87 | sense of the GPL-2.0 constitutes a "further restriction", and thus makes the two 88 | licenses incompatible. 89 | 90 | Figure 3: Permissive licenses are unilaterally compatible with copyleft licenses 91 | unless the permissive license contains additional requirements (example). 92 | GPL-2.0, BSD-2-Clause -> GPL-2.0 93 | BSD-4-Clause -> Not compatible 94 | 95 | - Permissive licenses are multilaterally compatible. 96 | Permissive FOSS licenses are generally compatible with each other. A combination 97 | of components licensed only under permissive licenses can be compliantly 98 | distributed by fulfilling the license obligations of all involved licenses. 99 | 100 | Figure 4: Permissive licenses are multilaterally compatible (example). 101 | MIT, BSD-2-Clause, Apache-2.0 -> Optional license, i.e. MIT, BSD-2-Clause, 102 | Apache-2.0 or other (even proprietary) 103 | 104 | - If a license is unclear or the copyleft is questionable, compatibility cannot 105 | be determined universally. 106 | If a license requirement or the extend of a copyleft clause is unclear, 107 | compatibility with other licenses has to be decided on an individual basis. 108 | 109 | These guidelines have emerged from creating the -> "OSADL Compatibility Matrix". 110 | This matrix displays the state of compatibility of every license that is 111 | evaluated as part of the -> "OSADL Open Source License Obligations Checklists" 112 | with every other license (Please note that the Compatibility Matrix and the Open 113 | Source License Obligations Checklists are work in progress and as such require 114 | continuous review to give the information they provide more legal certainty.). 115 | Compatibility is displayed by a green field, incompatibility by a red field and 116 | unclear cases by a gray field. In case two licenses are unilaterally compatible, 117 | the leading license marks the row of the matrix. For a schematic of the matrix 118 | see Table 1. 119 | 120 | License A: Copyleft license that does not allow further restrictions (e.g. 121 | GPL-2.0) 122 | License B: Copyleft license with explicit compatibility with license A (e.g. 123 | LGPL-2.1) 124 | License C: License with an unclear copyleft clause (e.g. OpenSSL) 125 | License D: Permissive license without further requirements (e.g. MIT) 126 | License E: Permissive license with further requirements (e.g. BSD-4-Clause) 127 | 128 | Table 1: Schematics of the -> "OSADL Compatibility Matrix" 129 | 130 | Leading License: License A 131 | Compatibility with 132 | - License B: Yes 133 | - License C: Unknown 134 | - License D: Yes 135 | - License E: No 136 | 137 | Leading License: License B 138 | Compatibility with 139 | - License A: No 140 | - License C: Unknown 141 | - License D: Yes 142 | - License E: No 143 | 144 | Leading License: License C 145 | Compatibility with 146 | - License A: No 147 | - License B: No 148 | - License D: Unknown 149 | - License E: Unknown 150 | 151 | Leading License: License D 152 | Compatibility with 153 | - License A: No 154 | - License B: No 155 | - License C: Unknown 156 | - License E: Yes 157 | 158 | Leading License: License E 159 | Compatibility with 160 | - License A: No 161 | - License B: No 162 | - License C: Unknown 163 | - License D: Yes 164 | --------------------------------------------------------------------------------