TDOSCA & OSCake: FOSS Compliance automatisieren

Mit dem Open Source Licen­se Com­pen­di­um und dem Open Source Com­pli­ance Advi­sor hat die Deut­sche Tele­kom das The­ma ‘Open-Source-Com­pli­ance’ bereits vor­an­ge­bracht. Am BOSL‑3.0 durf­te ich in ihrem Namen mit­schrei­ben. Aller­dings bie­tet die DT mitt­ler­wei­le so vie­le kom­ple­xe Pro­duk­te mit Open-Source-Anteil an, dass es zu teu­er wird, die not­wen­di­gen Com­pli­ance-Arte­fak­te manu­ell zu erzeu­gen. Not­wen­dig ist eine prak­tisch nutz­ba­re auto­ma­ti­sier­te ‘Tool­chain’. Die­ser Arti­kel disuk­tiert eine neue Metho­dik (TDOSCA) und einen neu­es Tool (OSCa­ke), die die DT unter dem Dach des Open Chain Pro­jekts öffent­lich umsetzt.

3 einfache Fragen an Open Source Compliance Tools

Es gibt ohne Zwei­fel bereits eine Rei­he von Open-Source-Com­pli­ance tools. Die Open-Chain-Refe­rence-Too­ling-Work-Group hat eine ent­spre­chen­de Lis­te zusam­men­ge­stellt. Die kann noch wei­ter grup­piert wer­den:

• Eini­ge der Tools wer­den von Orga­ni­sa­tio­nen wie die Apa­che-Foun­da­ti­on, SPDX, Eclip­se der der About-Code-Initia­ti­ve ange­bo­ten.
• Ande­re ste­hen inso­fern etwas abseits, als sie einen spe­zi­el­len Fokus haben oder gar kei­ne rich­ti­ge Tools sind.
• Und wie­der ande­re bil­den eine Grup­pe, weil sie eher Ser­vices sind, als Tools.

Die Deut­sche Tele­kom hat dabei einen recht ein­fa­chen Blick­win­kel. Wann immer ihr ein FOSS-Com­pli­ance-Tool begeg­net, fragt sie deren Ent­wick­le­rin­nen und Ver­tre­te­rin­nen:

• Lie­fert die­ses Tool der Fir­ma die FOSS-Com­pli­ance-Arte­fak­te, die sie wirk­lich benö­tigt? Und wenn nicht,
  • Wel­chen Teil davon könn­te es ihr lie­fern?
  • Wie­viel Hand­ar­beit fällt dann noch auf Sei­ten der Tele­kom an?

Die Deut­sche Tele­kom hat viel Erfah­rung dar­in, ange­bo­te­ne FOSS-Com­pli­ance-Tools zu sich­ten. Ihren Mit­ar­bei­te­rin­nen sind exzel­len­te Tools und bril­li­an­te Exper­tin­nen begeg­net, die oft völ­lig davon über­zeugt waren, dass sie der Fir­ma umfas­send hel­fen könn­ten. Am Ende der Gesprä­che fühl­te es sich aber oft so an, dass die Anbie­te­rin­nen nicht wirk­lich ver­stan­den hat­ten, was die DT benö­tig­te (und noch immer benö­tigt). Um den Punkt zu ver­deut­li­chen: Wer lan­ge Lis­ten gefun­de­ner FOSS-Kom­po­nen­ten anbie­tet und dann sagt, dass die Fir­ma nun jeden Ein­trag mit ihren Juris­tin­nen durch­ge­hen müs­se, hilft ihr nicht wirk­lich.

Und den­noch, auch die Deut­sche Tele­kom AG muss mit sol­chen lan­gen Lis­ten umge­hen. Die Open Source Com­pli­ance ist kei­ne Fra­ge der Lust oder Unlust: Ent­we­der wir nut­zen die Open-Source-Kom­po­nen­ten und erfül­len die Lizenz­be­din­gun­gen, oder wir nut­zen die Kom­po­nen­ten nicht. Des­halb kann Tele­kom auch nicht län­ger war­ten. Die Kom­ple­xi­tät ihrer Pro­duk­te zwingt sie, die Auto­ma­ti­on von Open-Source-Com­pli­ance selbst vor­an­zu­trei­ben. Aller­dings wird sie dazu nicht den nächs­ten Green­field-Ansatz ver­fol­gen, son­dern sich im Geis­te von Open-Source-Ent­wick­lun­gen in bestehen­de Pro­jek­te ein­brin­gen.

Eine Test-Driven Entwicklung von Tools zur Erzeugung von Open Source Compliance Artefakten

DTs ers­ter Schritt ziel­te auf die Ver­bes­se­rung ihrer eige­nen Kom­mu­ni­ka­ti­on. Sie woll­te — aus­ge­hend vom Stand­punkt einer gro­ßen Fir­ma mit vie­len kom­ple­xen Soft­ware­stacks — ein­fa­cher klar­stel­len, was sie wirk­lich benö­tigt und von Tools erwar­tet. Zu die­sem Zweck hat die Tele­kom den Ansatz einer ‘Test Dri­ven Soft­ware Ent­wick­lung’ auf die Pro­gram­mie­rung der Com­pli­ance-Tools über­tra­gen:

• Einer­seits sol­len die Test­ca­ses wirk­lich nutz­ba­re Soft­ware ent­hal­ten, und zwar zusam­men mit den Anga­ben über Lizen­sie­run­gen und Abhän­gig­kei­ten und ein­ge­bet­tet in Paket­ma­na­ger, wie sie auch in ‘rich­ti­gen’ Open-Source-Pro­jek­ten ver­wen­det wer­den.
• Ande­rer­seits sol­len die­se Test­ca­ses als Refeenz­da­ten auch schon alle Com­pli­ance-Arte­fak­te ent­hal­ten, die es — wären sie dem Soft­ware­pa­ket bei­gelegt — erlau­ben wür­den, die pake­tier­te Soft­ware lizenz­kon­form zu ver­tei­len.

Außer­dem meint die DT,

• dass exis­tie­ren­de Open-Source-Pro­jek­te in der Regel zu kom­plex sei­en, um um sie zu Test­ca­ses zu machen.
• dass ‘künst­lich’ erzeug­te Soft­ware sich bes­ser auf ein­zel­nen Com­pli­ance-Aspek­te fokus­sie­ren las­se.
• dass die Refe­renz-Soft­ware auf der einen Sei­te funk­tio­nal ein­fa­che Hel­lo- World Pro­gram­me sein soll­ten,
• die auf der ande­ren Sei­te auch sol­che aus­ge­feil­ten Com­pli­ance-Fal­len ent­hal­ten müs­se, wie frau sie in rich­ti­gen Open-Source-Pro­jek­ten fin­det..

Anhand sol­cher Test-Cases soll­ten die Com­mu­ni­ty, die Tools und betei­lig­te Fir­men veri­fi­zie­ren und kom­mu­ni­zie­ren kön­nen,

• wel­che Com­pli­ance-Fal­len ein Tool schon erfolg­reich bewäl­tigt,
• wel­che Arte­fak­te ein Tool schon lie­fert (und wel­che nicht),
• wo es noch offe­nen Her­aus­for­de­run­gen gibt
• und wo abwei­chend Ergeb­nis­se nur eine Fra­ge der Inter­pre­ta­ti­on sind.

Die ‘Hello World’ Open-Source-Compliance-Testcases

Alle TDOS­CA-Test­ca­ses wer­den unter dem Dach der Git­Hub-Orga­niza­ti­on Open-Source-Com­pli­ance gehos­tet und anhand des Pre­fi­xes tdos­ca grup­piert. Die READ­ME-Datei des Haupt­re­po­si­to­ries tdos­ca beschreibt die all­ge­mei­ne Sys­te­ma­tik: Frau darf erwar­ten, dass jeder Test­ca­se die­sel­be Struk­tur mit­bringt. Die kann gut anhand des Test­ca­ses tdos­ca-tc06-plainhw erläu­tert wer­den:

• Auf der obers­ten Ebe­ne beschreibt eine spe­zi­fi­sche README-Datei die Inten­tio­nen des Test­ca­ses.
• Im Ord­ner input-sources befin­det sich die Soft­ware
  • samt der Lizenz und Lizen­sie­rungs­in­for­ma­ti­on, die ana­log zu ‘ech­ten’ Pro­jek­ten arran­giert sind
  • in einer Form, dass sie mit den Stan­dard­tech­ni­ken kom­pi­liert und instal­liert wer­den könn­te (hier also mit java + maven).
• Auf der obers­ten Ebe­ne beschreibt außer­dem eine ‘Com­pli­ance-Trap Datei’ die Her­aus­for­de­run­gen, die in und mit die­sem Test­ca­ses imple­men­tiert wor­den sind und mit denen ein Tool umge­hen soll­te.
• In dem Ord­ner refe­rence-com­pli­ance-arti­facts befin­den sich dann die Com­pli­ance-Arti­fak­te, die ein Tool idea­ler­wei­se lie­fern soll­te:
  • eine BOM-Datei, die die ent­hal­te­nen Kom­po­nen­ten auf­lis­tet
  • eine Lis­te der Pake­te, die auf dem Ziel­sys­tem vor­in­stal­liert sein müs­sen
  • die eine Open-Source-Com­pli­ance-Datei, die — sofern frau sie dem Paket als Gan­zes hin­zu­fügt — dar­aus ein lizenz­kon­form dis­tri­bu­ier­ba­res Soft­ware­pa­ket macht.

Die ein­zel­nen Test­ca­ses sind in den spe­zi­el­len Repo­si­to­ries tdos­ca-tc01 … tdos­ca-tc0n abge­legt.

Zen­tra­les Ele­ment der Refe­renz­ar­te­fak­te ist die Datei Open Sour­ce Compli­ance File: Zu ihrem For­mat hat sich die Deut­sche Tele­kom von einer Datei inspie­ren las­sen, die Cis­co OSCF dem Jab­ber-Cli­ent bei­legt: https://www.cisco.com/c/dam/en_us/about/doing_business/open_source/ docs/CiscoJabberforWindows-128–1578365187.pdf. Die­se Datei ist nicht per­fekt. Aber zeigt gut, wie frau mit dem The­ma umge­hen könn­te. Im Rah­men von TDOSCA bie­tet die OSCF-Datei des 6. Test­ca­ses einen guten Ein­blick.

Ein Zwischenfazit und ein Zusatz:

Im all­ge­mei­nen nut­zen die TDOS­CA-Test­ca­ses also die fol­gen­de Struk­tur:

Die TDOS­CA-Intia­ti­ve — gehos­ted unter dem Schutz des Open-Chain-Pro­jek­tes der Linux-Foun­da­ti­on und betreut unter dem Dach der Open­Chain Refe­rence Too­ling Work Group — soll­te der Com­mu­ni­ty eine gute Mög­lich­keit bie­ten, ihre Arbeit sys­te­ma­tisch zu eva­lu­ie­ren.

Trotz­dem blie­be eine ‘Geschmäck­le’, wenn die Deut­sche Tele­kom nur die­sem Ansatz folg­te. Sie wür­de leicht in die Rol­le einer Poli­zis­tin oder Rich­te­rin rut­schen. Das ist nicht das, was die Tele­kom sein möch­te. Sie möch­te Com­mu­ni­ty auch prak­tisch vor­an­brin­gen. Dar­um hat sie bereits exis­tie­ren­de Tools anhand von TDOS­CA-Test­ca­ses eva­lu­iert, hat Erfah­run­gen gemacht und Kon­se­quen­zen gezo­gen:

TDOSCA und ORT …

Als ers­tes hat sich die DT dem Open Source Review Tool­kit zuge­wen­det, um eine Durch­stichs­ver­si­on zu erzeu­gen, die den Test­ca­se-Input nimmt und auto­ma­ti­siert die Com­pli­ance-Datei­en erzeugt:

Hier die

• die 5 Kom­po­nen­ten, die ORT in sei­nem README als sei­ne Bestand­tei­le erähnt,
• die Art der Datenj, die sie gene­rie­ren und
• die Wei­se, wie sie den Inhalt ihrer Vor­gän­ger wei­ter­ver­ar­bei­ten.

Aus­ge­hend von die­ser Skiz­ze kann frau nun erläu­tern, …

… welche Erfahrung mit ORT

auf­ge­lau­fen sind:

• Zunächst muss­te die DT akzep­tie­ren, dass der ORT den ers­ten und ein­fachs­ten Test-Case nicht hat ver­wer­ten kön­nen, weil der ‘Paket­ma­na­ger’ GNU auto­tools noch nicht in das ORT inte­griert war.
• Dann muss­te die DT ler­nen, dass ORT bei der Aus­wer­tung der Daten des Paket­ma­na­gers grad­le, ORT — momen­tan- noch nicht ent­schei­den kann, wel­ches die Default-Lizenz ist.
• Und schließ­lich muss­te die DT kon­sta­tie­ren, das die im ORT-Rea­der ein­ge­bau­ten Stan­dard-Tem­pla­tes dem Prin­zip der Über­erfül­lung der Lizenz­be­din­gun­gen fol­gen.

Was heißt das? Gibt frau ein kom­plett unter der MIT lizen­zi­sier­tes Paket wei­ter, muss sie nur die­sen einen Lizenz­text ein­schließ­lich des einen mit ihr ver­bun­de­nen Copy­rights­tate­ments bei­le­gen, um es lizenz­kon­form zu dis­tri­bu­ie­ren. Tools, die dem Prin­zip der Über­fül­lung fol­gen, fügen dem aber z.B. auch noch die Copy­right­li­nes hin­zu, die sie mit der GPL ori­en­tier­ten Such­tech­nik in den Quel­len gefun­den haben.

Das ist ein viel­fach ver­wen­de­ter Ansatz. Dem Prin­zip der Lizenz-Über­fül­lung zu fol­gen, ist jedoch eine pro­ble­ma­ti­sche Stra­te­gie:

• Zum einen wer­den Feh­ler, die in den bei­geleg­ten Com­pli­ance-Arte­fak­ten gemacht wer­den, den Dis­tri­bu­to­ren auch dann zuge­rech­net, wenn die­se Tei­le gar nicht hät­ten mit­ge­lie­fert wer­den müs­sen.
• Zum ande­ren kön­nen die zusätz­lich mit­ge­lie­fer­ten Com­pli­ance-Arte­fak­te die­je­ni­gen über­schrei­ben oder aus­he­beln, die der Lizenz nach mit­ge­lie­fert wer­den müs­sen.

Glück­li­cher­wei­se ist ORT modu­lar auf­ge­baut und macht ihre Bestand­tei­le kon­fi­gu­rier­bar, was der DT erlaubt, das Tool ent­spre­chend anzu­pas­sen:

Konsequenz 1: das ORT erweitern

• Die Deut­sche Tele­kom plant eine Eva­lu­ie­rung der GNU auto­tools zu imple­men­tie­ren und an das ORT Team zurück­zu­ge­ben.
• Außer­dem wird sie eine Heu­ris­tik ent­wi­ckeln und upstream geben, die immer die Default­li­zenz aus­weist.

Konsequenz 2: die Testcases komplettieren

Die DT wird fer­ner zusätz­li­che Test­ca­se imple­men­tie­ren, sodass der mul­ti-dimen­sio­na­le Raum aus Com­ple­xi­ty x Pro­gram­mier­spra­che x Paket­ma­na­ger bes­ser abge­deckt wird..

Konsequenz 3: eine intelligente Open Source Compliance artifact knowledge engine entwickeln

• Die Deut­sche Tele­kom AG wird schließ­lich eine intel­li­gen­te Kom­po­nen­te ent­wi­ckeln, in die das Wis­sen um Open Source Lizenz­be­din­gun­gen dekla­ra­tiv ein­ge­bet­tet ist, so dass sie es auto­ma­ti­siert anwen­den kann. Dazu wird sie
  • ihren eige­nen ‘Wri­ter’ ins ORT ein­bet­ten
  • mit­tels Eclip­se und XText eine Domainen-spe­zi­schen Spra­che in Sachen Open-Source-Lizen­zen ent­wi­ckeln
  • und mit­tels Eclip­se und XTend eine ent­spre­chen­den Arti­fact-Com­po­ser imple­men­tie­ren

Die­se neue Kom­po­nen­te, die auch für ande­ren Open Source Com­pli­ance Chains nutz­bar sein soll, wird OSCa­ke genannt und unter der Eclip­se Public Licen­se 2.0 ent­wi­ckelt. Die Abkür­zung steht für Open Sour­ce Compli­ance arti­fact know­ledge engi­ne.

OSCa­ke soll die Lücke schlie­ßend, die Open Source Scan­ner haben, die nach dem Prin­zip der Lizenz­über­fül­lung arbei­ten. Es wird Open-Source-Com­pli­ance-Coll­ec­tions neh­men und Open-Source-Com­pli­ance-Files lie­fern, die die For­de­run­gen der Lizen­zen genau erfül­len. OSCa­ke wird eine agnos­ti­sche Wis­sens­ma­schi­ne wer­den, und nicht von einem spe­zi­fi­schen Scan­ning-Tool abhän­gen, son­dern nur von einem feh­ler­to­le­ran­ten Input­for­mat. Um das zu errei­chen, wird OSCa­ke mit einer bipo­la­ren inne­ren Struk­tur arbei­ten:

Fazit

TDOSCA und OSCa­ke sind inter­es­san­te Arbeits­zie­le, für die Deut­sche Tele­kom AG selbst, für die Com­mu­ni­ty und für ande­re kom­mer­zi­el­le Ansät­ze:

• DT will in der Tat eine prak­tisch ver­wend­ba­re FOSS-Com­pli­ance-Tool-Chain auf­set­zen, die auto­ma­ti­siert pas­sen­de Com­pli­ance-Arte­fak­te ablei­tet.
• DT will den manu­el­len Auf­wand so weit als mög­lich redu­zie­ren.
• Und DT wird sei­ne Kom­po­nen­ten unter der Kon­trol­le TDOSCA ver­wirk­li­chen: der Initia­ti­ve zur Ent­wick­lung von Test Dri­ven Open Source Com­pli­ance Arti­fact Gathe­rers und Com­pi­lers

Und es ist ein beson­ders guter Aspekt die­ser Arbeit, dass sie öffent­lich pas­siert, unter dem Dach von Open-Chain und des­sen Open Chain Refe­rence­Too­ling Work­group.

---

Und in welchem Zusammenhang …

… steht das mit einer sys­te­ma­ti­schen Erfül­lung von FOSS-Lizen­zen? Nun, dazu müs­sen wir halt auch poli­ti­sche Kon­no­ta­tio­nen beden­ken, kon­zep­tio­nel­le und kon­tex­tu­el­le Aspek­te ana­ly­sie­ren — ein­zeln oder gemein­sam auf Kon­fe­ren­zen. Wir müs­sen kon­kre­te Fäl­le und all­ge­mei­ne Neben­wir­kun­gen durch­den­ken, für Soft­ware, Bil­der oder Doku­men­te. Wir müs­sen Trends benen­nen und Leit­fä­den erstel­len. Vor­nehm­lich aber müs­sen wir die Auto­ma­ti­sie­rung der Lizenz­er­fül­lung vor­an­trei­ben, unser Lizenz­wis­sen frei zur Ver­fü­gung stel­len, es in klei­ne­re Tools gie­ßen und in grö­ße­re Sys­te­me ein­brin­gen: Denn FOSS lebt von der Frei­heit durch Lizenz­er­fül­lung, im Gro­ßen und im Klei­nen.

---

Im Übri­gen: Män­ner sind mit­ge­meint.

• OSLiC sources: https://github.com/telekom/oslic
• OSLiC home­page: http://telekom.github.io/oslic/
• OSLiC ver­si­on 1.0.2: https://telekom.github.io/oslic/releases/oslic.pdf
• OSCAd sources: https://github.com/telekom/oscad
• OSCAd home­page: https://telekom.github.io/oscad/
• OSCAd ins­tance: http://oscad.fodina.de/
• Open­Chain home­page: https://www.openchainproject.org/
• Respec­ti­ve Linux Foun­da­ti­on pro­ject page: https://www.linuxfoundation.org/projects/security-compliance/
• Intro­duc­tion into the Open Chain Refe­rence Too­ling Work Group: https://www.openchainproject.org/news/2020/03/15/openchain-reference-tooling-work-group-in-2020
• Open Chain Refe­rence Too­ling Work Group home­page: http://oss-compliance-tooling.org/
• Exis­ting Open Source licen­se com­pli­ance tools: http://oss-compliance-tooling.org/Tooling-Landscape/OSS-Based-License-Compliance-Tools/
• Open-source Review Tool­kit: https://github.com/oss-review-toolkit/ort
• Test Driven Open Sour­ce Compli­ance Initia­ti­ve: https://github.com/Open-Source-Compliance/tdosca
• Open Sour­ce Compli­ance arti­fact know­ledge engi­ne: https://github.com/Open-Source-Compliance/OSCake
• Open Com­pli­ance Sum­mit 2020: https://events.linuxfoundation.org/open-compliance-summit/program/schedule/