{"id":3106,"date":"2020-11-28T11:14:48","date_gmt":"2020-11-28T10:14:48","guid":{"rendered":"https:\/\/fodina.de\/?p=3106"},"modified":"2023-01-03T21:45:41","modified_gmt":"2023-01-03T20:45:41","slug":"oscake-and-tdosca","status":"publish","type":"post","link":"https:\/\/2022.fodina.de\/en\/oscake-and-tdosca\/","title":{"rendered":"TDOSCA &#038; OSCake: Automating FOSS Compliance"},"content":{"rendered":"\n<div class=\"wp-block-image\"><figure class=\"alignleft size-large is-resized\"><a href=\"https:\/\/2022.fodina.de\/wp-content\/uploads\/2020\/11\/oscake-logo-400x482-1.png\" data-fancybox=\"\"><img decoding=\"async\" loading=\"lazy\" src=\"https:\/\/2022.fodina.de\/wp-content\/uploads\/2020\/11\/oscake-logo-400x482-1.png\" alt=\"\" width=\"100\" height=\"120\"><\/a><\/figure><\/div>\n\n\n\n<p>By releasing the <a href=\"https:\/\/2022.fodina.deen\/oslic\/\"><em>Open Source License Compendium<\/em><\/a> and the <a href=\"https:\/\/2022.fodina.deen\/oscad\/\"><em>Open Source Compliance Advisor<\/em><\/a>, <span style=\"color: #e20074;\">Deutsche Telekom<\/span> has already supported the task to deal with Open Source Compliance. But <span style=\"color: #e20074;\">DT<\/span> offers so many and complex Open Source based products that it is too expensive to create the necessary Open Source compliance artifacts manually. Thus, <span style=\"color: #e20074;\">DT<\/span> needs a practically usable automated toolchain.<!--more--> This article discusses a new method (<a href=\"https:\/\/github.com\/Open-Source-Compliance\/tdosca\">TDOSCA<\/a>) and a new tool (OSCake) that DT develops and contributes under the umbrella of the Open Chain Project.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">3 simple questions for an Open Source Compliance tool<\/h2>\n\n\n\n<p>Without any doubt, there exist already many Open Source compliance tools. The <a href=\"http:\/\/oss-compliance-tooling.org\/Tooling-Landscape\/OSS-Based-License-Compliance-Tools\/.\">Open-Chain-Reference-Tooling-Work-Group<\/a> has compiled a list of relevant information that can be clustered according to various criteria:<\/p>\n\n\n\n<div class=\"wp-block-image\"><figure class=\"alignleft size-large is-resized\"><a href=\"https:\/\/2022.fodina.de\/wp-content\/uploads\/2020\/11\/a-3questions.png\" data-fancybox=\"\"><img decoding=\"async\" loading=\"lazy\" src=\"https:\/\/2022.fodina.de\/wp-content\/uploads\/2020\/11\/a-3questions.png\" alt=\"\" width=\"200\" height=\"139\"><\/a><\/figure><\/div>\n\n\n\n<ul><li>Some of the tools can be grouped by the offering organizations like the Apache Foundation, SPDX, Eclipse, or the About Code Initiative.<\/li><li>Some of the tools are on the sidelines because they have a specific focus or are not really tools or anything else.<\/li><li>Some of the &#8216;tools&#8217; can be grouped by the fact that they are services, not tools.<\/li><\/ul>\n\n\n\n<p><span style=\"color: #e20074;\"><strong>Deutsche Telekom<\/strong><\/span> has a simple point of view on FOSS compliance tools. Whenever <span style=\"color: #e20074;\"><strong>DT<\/strong><\/span> comes across such a tool, it asks:<\/p>\n\n\n\n<ul><li>Does this tool deliver the FOSS compliance artifacts <span style=\"color: #e20074;\"><strong>DT<\/strong><\/span> really needs? If not<ul><li>What part of them can it deliver?<\/li><li>How much work does <span style=\"color: #e20074;\"><strong>DT<\/strong><\/span> still have to do manually if it used the tool?<\/li><\/ul><\/li><\/ul>\n\n\n\n<p><span style=\"color: #e20074;\"><strong>DT<\/strong><\/span> has a long tradition of evaluating FOSS compliance tools. Its employees met excellent tools and brilliant experts who often were completely convinced that they could essentially support <span style=\"color: #e20074;\"><strong>DT<\/strong><\/span>. But in the end, <span style=\"color: #e20074;\"><strong>DT<\/strong><\/span> mostly felt like that they didn&#8217;t really understand what DT needed (and still needs). To clarify this point: Whoever delivers large lists of (found) FOSS items and says that a company now has to discuss each entry of the list with its legal department does not really help the company.<\/p>\n\n\n\n<p>Nevertheless, <span style=\"color: #e20074;\"><strong>DT<\/strong><\/span> has to deal with such large lists. Open-Source-Compliance is not a question of pleasure or displeasure: either one uses Open-Source software and fulfills the respective requirements, or one does not use the software. Therefore <span style=\"color: #e20074;\"><strong>DT<\/strong><\/span> can&#8217;t wait anymore. The complexity of its products enforces <span style=\"color: #e20074;\"><strong>DT<\/strong><\/span> to advance the automation of open source compliance actively. For solving that issue, it doesn&#8217;t want to start the next greenfield approach but to participate in existing projects &#8211; entirely in the spirit of the open-source idea.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Setting up the <span style=\"color: #e20074;\">T<\/span>est-<span style=\"color: #e20074;\">D<\/span>riven environment to develop tools generating <span style=\"color: #e20074;\">O<\/span>pen <span style=\"color: #e20074;\">S<\/span>ource <span style=\"color: #e20074;\">C<\/span>ompliance <span style=\"color: #e20074;\">A<\/span>rtifacts<\/h2>\n\n\n\n<div class=\"wp-block-image\"><figure class=\"alignright size-large is-resized\"><a href=\"https:\/\/2022.fodina.de\/wp-content\/uploads\/2020\/11\/b-tdosca.png\" data-fancybox=\"\"><img decoding=\"async\" loading=\"lazy\" src=\"https:\/\/2022.fodina.de\/wp-content\/uploads\/2020\/11\/b-tdosca.png\" alt=\"\" width=\"200\" height=\"139\"><\/a><\/figure><\/div>\n\n\n\n<p><span style=\"color: #e20074;\"><strong>DT<\/strong><\/span>&#8216;s first step was to improve its own communication: it wants to clarify in a better way what it really needs &#8211; from the point of view of a large company dealing with many complex software stacks. Thus, <span style=\"color: #e20074;\"><strong>DT<\/strong><\/span> tried to apply the idea of &#8216;Test-Driven Software Development&#8217; to the development of compliance tools:<\/p>\n\n\n\n<ul><li>On the one side, these test cases should contain really usable software and the licensing and dependency information as they are usually put together in real projects.<\/li><li>On the other side, these test cases should contain those compliance artifacts that would allow distributing the software compliantly if added to the respective software package. <\/li><\/ul>\n\n\n\n<p>Additionally, <span style=\"color: #e20074;\"><strong>DT<\/strong><\/span> thinks,<\/p>\n\n\n\n<ul><li>that <em>existing open source projects are mostly too complex for being used as reference material<\/em><\/li><li><em>that artificially generated software could better focus on essential compliance issues<\/em><\/li><li><em>that the reference software on the one side should functionally be a simple hello world program<\/em>,<\/li><li><em>on the other side, should &#8216;implement&#8217; sophisticated compliance issues as they are found in real open-source<\/em> projects.<\/li><\/ul>\n\n\n\n<p>By using such test cases, the community, the tools, and the companies are enabled to verify,<\/p>\n\n\n\n<ul><li>with which compliance traps a tool can already successfully deal,<\/li><li>which artifacts a tool already deliver (and which not),<\/li><li>where there are still some open issues, and<\/li><li>where deviating results are only a matter of interpretation.<\/li><\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">The &#8216;Hello World&#8217; Open Source Compliance Test Cases<\/h2>\n\n\n\n<p>All TDOSCA-test-cases are offered under the umbrella of the GitHub organization <a href=\"https:\/\/github.com\/Open-Source-Compliance\/\"><em>Open-Source-Compliance<\/em><\/a> and clustered by the prefix <a href=\"https:\/\/github.com\/Open-Source-Compliance\/tdosca\"><em>tdosca<\/em><\/a>. The README of main repository <a href=\"https:\/\/github.com\/Open-Source-Compliance\/tdosca\/blob\/master\/README.md\"><em>tdosca<\/em><\/a> describes the general approach: one may expect that each test case offers the same structure. For example, take a look at <a title=\"https:\/\/github.com\/Open-Source-Compliance\/tdosca-tc06-plainhw\" href=\"https:\/\/github.com\/Open-Source-Compliance\/tdosca-tc06-plainhw\">tdosca-tc06-plainhw<\/a>:<\/p>\n\n\n\n<ul><li> On the top level, a test case-specific README describes its intention. <\/li><li> In the directory <em>input-sources<\/em>, you find a compilable software package <ul><li>that contains the licensing information just as real open source projects do <\/li><li>and can be installed by a standard technique (in this case: java + maven). <\/li><\/ul><\/li><li> On the top level, a compliance-trap file describes the challenges that are implemented in the source and should be managed by the tools. <\/li><li> And in the directory <em>reference-compliance-artifacts, <\/em>one can find the compliance artifacts that a tool should deliver: <ul><li>a BOM file listing the (sub) components of the package <\/li><li>a list of the packages that must be preinstalled on the target host <\/li><li>the Open Source Compliance File, which &#8211; added to the package &#8211; establishes a compliantly distributable open-source software package. <\/li><\/ul><\/li><\/ul>\n\n\n\n<p>The test cases themselves are stored in the respective repositories<strong><em> tdosca-tc01<\/em><\/strong> &#8230; <em><strong>tdosca-tc0n<\/strong><\/em><\/p>\n\n\n\n<p>The core reference entity of a test case is its <em>Open Source Compliance File<\/em>: Such a file shall contain all compliance artifacts so that a package is compliantly distributed if it is bundled with the respective OSCF. This idea was inspired by the file that CISCO adds to its jabber client: https:\/\/www.cisco.com\/c\/dam\/en_us\/about\/doing_business\/open_source\/ docs\/CiscoJabberforWindows-128-1578365187.pdf. This file is not completely sufficient. But it gives a good idea, how to deal with this issue. In the TDOSCA context, the meaning of such an Open Source Compliance File can be explained by looking at the <a href=\"https:\/\/github.com\/Open-Source-Compliance\/tdosca-tc06-plainhw\/blob\/master\/reference-compliance-artifacts\/oscf.pdf\">OSCF of the 6th test case<\/a>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">A summary and an addendum:<\/h2>\n\n\n\n<div class=\"wp-block-image\"><figure class=\"alignleft size-large is-resized\"><a href=\"https:\/\/2022.fodina.de\/wp-content\/uploads\/2020\/11\/c-tc-structure.png\" data-fancybox=\"\"><img decoding=\"async\" loading=\"lazy\" src=\"https:\/\/2022.fodina.de\/wp-content\/uploads\/2020\/11\/c-tc-structure.png\" alt=\"\" width=\"200\" height=\"139\"><\/a><\/figure><\/div>\n\n\n\n<p>In general each TDOSCA test-case implements the following structure:<\/p>\n\n\n\n<p>The TDOSCA initiative &#8211; hosted under the umbrella of OpenChain and the OpenChain Reference Tooling Work Group &#8211; could be a good method for the community to evaluate its tools by such test cases.<\/p>\n\n\n\n<p>But if <span style=\"color: #e20074;\"><strong>DT<\/strong><\/span> followed this approach purely, <span style=\"color: #e20074;\"><strong>DT<\/strong><\/span> would easily slip into the role of a police officer or a judge. That&#8217;s not what <span style=\"color: #e20074;\"><strong>DT<\/strong><\/span> wants to be; it wants to be a supportive part of the community. For that purpose, <span style=\"color: #e20074;\"><strong>DT<\/strong><\/span> has already evaluated existing tools on the base of the TDOSCA test cases, has made some experiences, and decided on some consequences:<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Applying the approach to ORT<\/h2>\n\n\n\n<div class=\"wp-block-image\"><figure class=\"alignright size-large is-resized\"><a href=\"https:\/\/2022.fodina.de\/wp-content\/uploads\/2020\/11\/d-ort.png\" data-fancybox=\"\"><img decoding=\"async\" loading=\"lazy\" src=\"https:\/\/2022.fodina.de\/wp-content\/uploads\/2020\/11\/d-ort.png\" alt=\"\" width=\"200\" height=\"139\"><\/a><\/figure><\/div>\n\n\n\n<p>First <span style=\"color: #e20074;\"><strong>DT<\/strong><\/span> decided to use ORT &#8211; the <a href=\"https:\/\/github.com\/oss-review-toolkit\/ort\">Open Source Review Toolkit<\/a> &#8211; for creating a break-through tool-chain-version which takes the test-case input and derives the compliance output:<\/p>\n\n\n\n<p>In the picture you see<\/p>\n\n\n\n<ul><li>the five components, ORT mentions in its README,<\/li><li>the data they generate, and<\/li><li>how they use the output of their predecessors.<\/li><\/ul>\n\n\n\n<p>Using this outline, we can now exemplify some of &#8230;<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">&#8230; and gaining experiences with ORT<\/h2>\n\n\n\n<div class=\"wp-block-image\"><figure class=\"alignleft size-large is-resized\"><a href=\"https:\/\/2022.fodina.de\/wp-content\/uploads\/2020\/11\/e-ort-experiences.png\" data-fancybox=\"\"><img decoding=\"async\" loading=\"lazy\" src=\"https:\/\/2022.fodina.de\/wp-content\/uploads\/2020\/11\/e-ort-experiences.png\" alt=\"\" width=\"200\" height=\"139\"><\/a><\/figure><\/div>\n\n\n\n<ul><li> First, <span style=\"color: #e20074;\"><strong>DT<\/strong><\/span> noticed that even the first and most simple test case that uses the GNU Autotools could not be evaluated yet. <\/li><li> Second, DT had to learn that in cooperation with gradle, ORT &#8211; for the moment &#8211; can not decide which of the found licenses is the default license.<\/li><li> Third, DT noticed that the standard templates included in ORT reader follow the principle of over fulfillment, the principle of over-fulfilling the license requirements. <\/li><\/ul>\n\n\n\n<p>What does the last point mean? If you have a software project completely and exclusively licensed under the MIT license, then it is sufficient to bundle the license text and its embedded copyright line with the package for making it compliantly distributable. Tools that follow the <em>principle of over fulfillment<\/em> would also add the artifacts created based on the GPL requirements, as &#8216;all copyright headers of all files&#8217; and so on.<\/p>\n\n\n\n<p>This is an often applied approach. But following the <em>principle of over fulfillment<\/em> is a problematic strategy:<\/p>\n\n\n\n<ul><li>On the one hand, the distributors are also responsible for incorrectly created compliance artifacts even if they are not required by the really relevant license and should not have supplied it.<\/li><li>On the other hand, the surplus compliance artifacts could overwrite or lever out the essential artifacts.<\/li><\/ul>\n\n\n\n<p>Fortunately, ORT follows the design principle to make everything configurable and extendable, which allows <span style=\"color: #e20074;\"><strong>DT<\/strong><\/span> to adapt its needs in three ways:<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Consequence 1: Improving ORT<\/h2>\n\n\n\n<ul><li><span style=\"color: #e20074;\"><strong>Deutsche Telekom<\/strong><\/span> plans to implement and to give back to ORT an evaluation technique of the <em>Autotools<\/em> scripts. <\/li><li>It will define, implement, and give upstream to ORT a generally usable strategy to determine the default license of a package. <\/li><\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">Consequence 2: Extending the case structure<\/h2>\n\n\n\n<div class=\"wp-block-image\"><figure class=\"alignright size-large is-resized\"><a href=\"https:\/\/2022.fodina.de\/wp-content\/uploads\/2020\/11\/f-multi-dim-tc.png\" data-fancybox=\"\"><img decoding=\"async\" loading=\"lazy\" src=\"https:\/\/2022.fodina.de\/wp-content\/uploads\/2020\/11\/f-multi-dim-tc.png\" alt=\"\" width=\"200\" height=\"139\"><\/a><\/figure><\/div>\n\n\n\n<ul><li><span style=\"color: #e20074;\"><strong>DT<\/strong><\/span> will define more test-cases according to the multi-dimensional room: complexity, programming language, and dependency manager.<\/li><\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">Consequence 3: Defining an intelligent <span style=\"color: #e20074;\"><strong>O<\/strong><\/span>pen <span style=\"color: #e20074;\"><strong>S<\/strong><\/span>ource <span style=\"color: #e20074;\"><strong>C<\/strong><\/span>ompliance <span style=\"color: #e20074;\"><strong>a<\/strong><\/span>rtifact <span style=\"color: #e20074;\"><strong>k<\/strong><\/span>nowledge <span style=\"color: #e20074;\"><strong>e<\/strong><\/span>ngine<\/h2>\n\n\n\n<ul><li><span style=\"color: #e20074;\"><strong>DT<\/strong><\/span> develops an intelligent component into which it embeds the Open Source License Compliance knowledge in a declarative manner by <ul><li>adding respective writers into ORT<\/li><li>adding a FOSS compliance domain-specific language realized on the base of Eclipse, XText<\/li><li>adding a respective compliance artifact composer based on XTend.<\/li><\/ul><\/li><\/ul>\n\n\n\n<div class=\"wp-block-image\"><figure class=\"alignleft size-large is-resized\"><a href=\"https:\/\/2022.fodina.de\/wp-content\/uploads\/2020\/11\/g-oscake.png\" data-fancybox=\"\"><img decoding=\"async\" loading=\"lazy\" src=\"https:\/\/2022.fodina.de\/wp-content\/uploads\/2020\/11\/g-oscake.png\" alt=\"\" width=\"200\" height=\"139\"><\/a><\/figure><\/div>\n\n\n\n<p>This new component of and for <em>Open Source Compliance Chains<\/em> is called  <span style=\"color: #e20074;\"><strong>OSCake<\/strong><\/span> &#8211; the <em><span style=\"color: #e20074;\"><strong>O<\/strong><\/span>pen <span style=\"color: #e20074;\"><strong>S<\/strong><\/span>ource <span style=\"color: #e20074;\"><strong>C<\/strong><\/span>ompliance <span style=\"color: #e20074;\"><strong>a<\/strong><\/span>rtifact <span style=\"color: #e20074;\"><strong>k<\/strong><\/span>nowledge <span style=\"color: #e20074;\"><strong>e<\/strong><\/span>ngine<\/em> -, that is developed under the terms of the Eclipse Public License 2.0<\/p>\n\n\n\n<div class=\"wp-block-image\"><figure class=\"alignright size-large is-resized\"><a href=\"https:\/\/2022.fodina.de\/wp-content\/uploads\/2020\/11\/h-oscake-structure.png\" data-fancybox=\"\"><img decoding=\"async\" loading=\"lazy\" src=\"https:\/\/2022.fodina.de\/wp-content\/uploads\/2020\/11\/h-oscake-structure.png\" alt=\"\" width=\"200\" height=\"139\"><\/a><\/figure><\/div>\n\n\n\n<p><span style=\"color: #e20074;\"><strong>OSCake<\/strong><\/span> shall close the gaps evoked by Open Source scanning tools that follow the principle of compliance over-fulfillment. It will take Open Source Compliance collections and deliver Open Source Compliance Files that really fit the requirements of the involved Open Source Licenses and their contexts. OSCake will become an agnostic compliance knowledge engine; it will not depend on a specific scanning tool but only on an error-tolerant input format. For being able to offer these features, OSCake will have an internal structure:<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Fazit<\/h2>\n\n\n\n<p>TDOSCA and OSCake establish a promising goal set for the company itself as well as for the community and other commercial approaches:<\/p>\n\n\n\n<ul><li><span style=\"color: #e20074;\"><strong>DT<\/strong><\/span> indeed wants to set up a practically usable FOSS compliance toolchain that automatically generates the compliance artifacts we need.<\/li><li><span style=\"color: #e20074;\"><strong>DT<\/strong><\/span> wants to reduce the manual work as far as possible.<\/li><li>And <span style=\"color: #e20074;\"><strong>DT<\/strong><\/span> develops this chain (and its components) under the control of TDOSCA: the project to develop Test-Driven Open Source Compliance Artifact Gatherers and Compilers &#8211; including our own tool &#8216;OSCake&#8217;.<\/li><\/ul>\n\n\n\n<p>And it is an outstanding aspect that both parts are developed under the umbrella of <a href=\"https:\/\/www.openchainproject.org\/\">OpenChain<\/a> and its <a href=\"http:\/\/oss-compliance-tooling.org\/\">Open Chain ReferenceTooling Workgroup<\/a>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><\/h2>\n\n\n\n<h2 class=\"wp-block-heading\"><span>Releated Links:<\/span><\/h2>\n\n\n\n<ul><li><span><span style=\"color: #e20074;\"><strong>OSLiC<\/strong><\/span> sources: <a href=\"https:\/\/github.com\/telekom\/oslic\">https:\/\/github.com\/telekom\/oslic<\/a><\/span><\/li><li><span><span style=\"color: #e20074;\"><strong>OSLiC<\/strong><\/span> homepage: <a href=\"http:\/\/telekom.github.io\/oslic\/\" title=\"http:\/\/telekom.github.io\/oslic\/\">http:\/\/telekom.github.io\/oslic\/<\/a><\/span><\/li><li><span><span style=\"color: #e20074;\"><strong>OSLiC<\/strong><\/span> version 1.0.2: <a href=\"https:\/\/telekom.github.io\/oslic\/releases\/oslic.pdf\" title=\"https:\/\/telekom.github.io\/oslic\/releases\/oslic.pdf\">https:\/\/telekom.github.io\/oslic\/releases\/oslic.pdf<\/a><\/span><\/li><li><span><span style=\"color: #e20074;\"><strong>OSCAd<\/strong><\/span> sources: <a href=\"https:\/\/github.com\/telekom\/oscad\" title=\"https:\/\/github.com\/telekom\/oscad\">https:\/\/github.com\/telekom\/oscad<\/a><\/span><\/li><li><span><span style=\"color: #e20074;\"><strong>OSCAd<\/strong><\/span> homepage: <a href=\"https:\/\/telekom.github.io\/oscad\/\" title=\"https:\/\/telekom.github.io\/oscad\/\">https:\/\/telekom.github.io\/oscad\/<\/a><\/span><\/li><li><span><span style=\"color: #e20074;\"><strong>OSCAd<\/strong><\/span> instance: <a href=\"http:\/\/oscad.fodina.de\/\" title=\"http:\/\/oscad.fodina.de\/\">http:\/\/oscad.fodina.de\/<\/a><\/span><\/li><li>OpenChain homepage: <a href=\"https:\/\/www.openchainproject.org\/\" title=\"https:\/\/www.openchainproject.org\/\">https:\/\/www.openchainproject.org\/<\/a><\/li><li>Respective Linux Foundation project page: <a href=\"https:\/\/www.linuxfoundation.org\/projects\/security-compliance\/\" title=\"https:\/\/www.linuxfoundation.org\/projects\/security-compliance\/\">https:\/\/www.linuxfoundation.org\/projects\/security-compliance\/<\/a><\/li><li>Introduction into the Open Chain Reference Tooling Work Group: <a href=\"https:\/\/www.openchainproject.org\/news\/2020\/03\/15\/openchain-reference-tooling-work-group-in-2020\" title=\"https:\/\/www.openchainproject.org\/news\/2020\/03\/15\/openchain-reference-tooling-work-group-in-2020\">https:\/\/www.openchainproject.org\/news\/2020\/03\/15\/openchain-reference-tooling-work-group-in-2020<\/a><\/li><li>Open Chain Reference Tooling Work Group homepage: <a href=\"http:\/\/oss-compliance-tooling.org\/\" title=\"http:\/\/oss-compliance-tooling.org\/\">http:\/\/oss-compliance-tooling.org\/<\/a><\/li><li>Existing Open Source license compliance tools: <a href=\"http:\/\/oss-compliance-tooling.org\/Tooling-Landscape\/OSS-Based-License-Compliance-Tools\/\" title=\"http:\/\/oss-compliance-tooling.org\/Tooling-Landscape\/OSS-Based-License-Compliance-Tools\/\">http:\/\/oss-compliance-tooling.org\/Tooling-Landscape\/OSS-Based-License-Compliance-Tools\/<\/a><\/li><li><span style=\"color: #1bada2;\"><strong>O<\/strong><\/span>pen-source <span style=\"color: #1bada2;\"><strong>R<\/strong><\/span>eview <span style=\"color: #1bada2;\"><strong>T<\/strong><\/span>oolkit: <a href=\"https:\/\/github.com\/oss-review-toolkit\/ort\" title=\"https:\/\/github.com\/oss-review-toolkit\/ort\">https:\/\/github.com\/oss-review-toolkit\/ort<\/a><\/li><li><span style=\"color: #e20074;\"><strong>T<\/strong><\/span>est <span style=\"color: #e20074;\"><strong>D<\/strong><\/span>riven <span style=\"color: #e20074;\"><strong>O<\/strong><\/span>pen <span style=\"color: #e20074;\"><strong>S<\/strong><\/span>ource <span style=\"color: #e20074;\"><strong>C<\/strong><\/span>ompliance <span style=\"color: #e20074;\"><strong>I<\/strong><\/span>nitiative: <a href=\"https:\/\/github.com\/Open-Source-Compliance\/tdosca\" title=\"https:\/\/github.com\/Open-Source-Compliance\/tdosca\">https:\/\/github.com\/Open-Source-Compliance\/tdosca<\/a><\/li><li><span style=\"color: #e20074;\"><strong>O<\/strong><\/span>pen <span style=\"color: #e20074;\"><strong>S<\/strong><\/span>ource <span style=\"color: #e20074;\"><strong>C<\/strong><\/span>ompliance <span style=\"color: #e20074;\"><strong>a<\/strong><\/span>rtifact <span style=\"color: #e20074;\"><strong>k<\/strong><\/span>nowledge <span style=\"color: #e20074;\"><strong><span>e<\/span><\/strong><\/span>ngine: <a href=\"https:\/\/github.com\/Open-Source-Compliance\/OSCake\" title=\"https:\/\/github.com\/Open-Source-Compliance\/OSCake\">https:\/\/github.com\/Open-Source-Compliance\/OSCake<\/a><\/li><li>Open Compliance Summit 2020: <a href=\"https:\/\/events.linuxfoundation.org\/open-compliance-summit\/program\/schedule\/\" title=\"https:\/\/events.linuxfoundation.org\/open-compliance-summit\/program\/schedule\/\">https:\/\/events.linuxfoundation.org\/open-compliance-summit\/program\/schedule\/<\/a><\/li><\/ul>\n","protected":false},"excerpt":{"rendered":"<p>Mit dem Open Source License Compendium und dem Open Source Compliance Advisor hat die Deutsche Telekom das Thema &#8216;Open-Source-Compliance&#8217; bereits vorangebracht. Allerdings bietet die DT mittlerweile so viele komplexe Produkte mit Open-Source-Anteil an, dass es zu teuer wird, die notwendigen Compliance-Artefakte manuell zu erzeugen. Notwendig ist eine praktisch nutzbare automatisierte &#8216;Toolchain&#8217;.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[21],"tags":[29,30,40],"translation":{"provider":"WPGlobus","version":"2.12.2","language":"en","enabled_languages":["de","en"],"languages":{"de":{"title":true,"content":true,"excerpt":false},"en":{"title":true,"content":true,"excerpt":false}}},"_links":{"self":[{"href":"https:\/\/2022.fodina.de\/en\/wp-json\/wp\/v2\/posts\/3106"}],"collection":[{"href":"https:\/\/2022.fodina.de\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/2022.fodina.de\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/2022.fodina.de\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/2022.fodina.de\/en\/wp-json\/wp\/v2\/comments?post=3106"}],"version-history":[{"count":93,"href":"https:\/\/2022.fodina.de\/en\/wp-json\/wp\/v2\/posts\/3106\/revisions"}],"predecessor-version":[{"id":4367,"href":"https:\/\/2022.fodina.de\/en\/wp-json\/wp\/v2\/posts\/3106\/revisions\/4367"}],"wp:attachment":[{"href":"https:\/\/2022.fodina.de\/en\/wp-json\/wp\/v2\/media?parent=3106"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/2022.fodina.de\/en\/wp-json\/wp\/v2\/categories?post=3106"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/2022.fodina.de\/en\/wp-json\/wp\/v2\/tags?post=3106"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}