Herzlich willkommen zum zweiten Vortrag am zweiten Tag der Froscon 12. Andreas Schreiber vom Deutschen Zentrum für Luft- und Raumfahrt Technik e.V. und ja, Open Source Advokat, Quantified Self, Python, noch ganz viel mehr.

Und über das Verhältnis halt eben von Open Source und Wissenschaft. Ja, schönen Dank und auf geht's. Ja, danke. Mein Name hast du ja schon gesagt. Ich habe das Material, was ich jetzt präsentiere,

habe ich zusammengestellt mit Carina Haupt, die hat auch den Vortrag eigentlich eingereicht. Hatte aber doch keine, sagen wir mal, Zeit zu kommen. Deswegen präsentiere ich das hier. Genau, ich arbeite beim DLR. Das ist nicht so sperrig wie das Deutschen Zentrum für Luft- und Raumfahrt. Meistens in Köln-Ports, manchmal in Köln. Also wir sind hier weniger als zehn Kilometer entfernt.

Das ist unser Büro. Ich bin Abteilungsleiter, leite eine Abteilung für verteilte und intelligente Systeme. Wir machen Softwaretechnik im Wesentlichen. Und bin gleichzeitig auch noch Gruppenleiter in einer Gruppe für Secure Software Engineering im Institute for Data Science in Jena. Genau, und dann nebenbei mache ich noch so Sachen wie habe eine Firma gegründet,

wo wir medizinische Apps entwickeln, wo ich hauptsächlich das Data Science mache und auch der Tester bin und das alles ausprobiere. Das DLR, das Deutsche Zentrum für Luft- und Raumfahrt, nur ganz kurz, wer das nicht kennt, wir sind eine Einrichtung, die zum Wirtschaftsministerium gehört,

also von Steuergeldern finanziert wird im Wesentlichen zu mehr als 50 Prozent. Eine Forschungseinrichtung mit Forschung in Luftfahrt, Raumfahrt, Energie, Verkehr und Sicherheit und auch Raumfahrtagentur und Projektträger, das so ganz kurz. Schön verteilt auf Deutschland mit inzwischen 20 Standorten. Der größte ist Oberpfaffenhofen bei München mit über 2000 Mitarbeitern

und der zweitgrößte ist hier ganz in der Nähe Köln-Portz mit 1500, 1600 Mitarbeitern. Und das Ganze organisiert in 39 wissenschaftliche Einrichtungen und Institute. Darum geht es aber gar nicht so stark, es geht jetzt eher um solche Themen

wie Free- und Open Source Software und warum das in DLR eine Rolle spielt und was unsere Probleme sind oder waren. Darüber will ich reden. Software im DLR an sich ist wichtig, wie eigentlich überall heutzutage. Wir haben ganz viele Wissenschaftler, die Köpfe jetzt so eierköpfförmig sind,

das ist Zufall, das liegt an Powerpoint, da kann man beruhigt die oder kann ich die Schulter an Microsoft schieben, ich weiß nicht genau, wieso die eierförmig sind. Aber diese Fachspezialisten, also quasi meine Kollegen im DLR, die denken über alle möglichen Sachen nach, aus der Luft und Raumfahrt usw.,

Sachen wie Aerodynamik und Flugzeugflügel oder die Konstruktion von Flügeln, die Strömung in Turbinen und viele andere Themen und beschäftigen sich damit und haben da im Wesentlichen, das ist schon mal pauschal vorneweg, Software für die ganzen Teile, über die sie da nachdenken für die ganzen Fachdisziplinen.

Es gibt eine ganze Reihe von Software, deswegen ist Softwareentwicklung im DLR auch wichtig. Etwa 1500 Leute im DLR entwickeln Software jeden Tag. Wir geben etwa 150 Millionen Euro pro Jahr in Softwareentwicklung aus, in Personalkosten, das ist eine ganze Menge in Deutschland. Wir sind quasi eines der größten Softwarehäuser in Deutschland,

auch wenn man unsere Softwareprodukte ja so am Markt nicht unbedingt kaufen kann. Vieles ist so für interne Forschungsaufgaben usw. Deswegen die Software, die wir entwickeln, in der Regel ist das nicht Standard-Software, also Individual-Software, in der Theorie ist es ja so, wenn es das schon gäbe am Markt,

würde man es einfach kaufen, das geht, machen zwar auch nicht alle, manche entwickeln Sachen doppelt und so, das ist ein anderes Problem, aber bei uns gibt es tatsächlich gerade in der Forschung, in der Raumfahrt, das sind teilweise echte Nischenaufgaben, also es macht ja jetzt nicht jeder Raumfahrt in der Welt und da muss man tatsächlich relativ viel auch selber neu entwickeln,

weil man das eben nicht einfach so kaufen kann. Das gibt ganz spezielle, spezifische Anforderungen, je nach Art der Software, also typische Sachen, die wir haben, sind ja Simulation aller Art von allen möglichen technischen Systemen und die entsprechende Data Science dazu, Datenauswertung und Datenverarbeitung,

Visualisierung, bis hin zu Prozesssteuerungssachen oder auch bis hin dann ganz am Ende des Spektrums sind dann auch die eher langweiligen Sachen, Intranet-Anwendungen, die so Richtung unserer Verwaltung gehen, wo ich nichts mit zu tun habe, also meine Einrichtung, wir machen nur Software für den wissenschaftlichen Bereich im Deal,

das ist das Coole, die langweilige Software für unsere Verwaltung, also Anwendungen, SAP und so ein Quatsch, das machen wir uns dann eher externe Firmen. Ja, da kommen ganz komische Anfragen, wir sollten schon Zeugnisgeneratoren für die Personalabteilung entwickeln und Datenbanken fürs Doktorandenprogramm und so ein Quatsch. Spannender war schon eine Anfrage, den Zeitplan für die PR-Termine der Astronauten zu machen,

aber auch das war Software-technisch jetzt nicht spannend genug. Egal, ein Problem bei uns ist allerdings im Deal eher, dass von den ganz vielen Leuten, die Software entwickeln, die aller, allerwenigsten haben eine Ausbildung in Softwareentwicklung. Meistens sind das Ingenieure und Naturwissenschaftler, also Physiker,

wir haben viele Physiker, viele Luft- und Raumfahrtingenieure, Maschinenbauer, Verfahrenstechniker, Chemiker, Biologen, Mediziner, alle möglichen Leute, die maximal Programmierkurse an der Uni gehabt haben. Damit kann man vielleicht programmieren, aber damit kann man leider keine Software entwickeln.

Das große Drama in unserer Welt ist jetzt, dass Leute immer mehr Software entwickeln müssen. Also Software-Systeme, die ursprünglich mal kleine Programme waren, so Skripte und so was, aber dann immer mehr wachsen und immer mehr Leute eingesetzt werden. Der Härtefall ist dann, die werden dann eben von Leuten eingesetzt, die nicht mehr im DLR sind, also die wird dann nach außen gegeben und

womöglich sogar lizenziert. Also viel Software oder auch große Software-Pakete von uns, die werden zum Beispiel bei Airbus eingesetzt, in der Flugphysik und den ähnlichen Einrichtungen bei Airbus und neue Flugzeuggenerationen zu entwickeln. Und da gibt es halt ganz andere Anwendungen oder Anforderungen an die Qualität der Software, als dass sie nur irgendwie mal kurz laufen muss und

wenn es abstürzt, ist das auch egal. Also das ist ein Problem, also das ist ein Teil, was wir auch behandeln als unsere Einrichtung, dass wir uns darum kümmern, wie man an sich Software entwickelt, aber ein ganz spezielles Problem sind die Fragen, die die Lizenz

betreffen. Die Technologien, die bei uns verwendet werden für Softwareentwicklung sind super vielfältig. Nur mal als Beispiel, Programmiersprachen, da gibt es mindestens 30, das haben wir mal gezählt, da haben wir gefunden, die im Einsatz sind, aktiv und womit entwickelt wird, angefangen von Java über C, natürlich Fortran ist super verbreitet und dann halt bis zum Matlab oder LabView oder Anwendungen, Ada und solche Geschichten, das ist alles

gängig. Und entsprechend auch was Bibliotheken und ähnliches betrifft. Und auch bei den Lizenzen gibt es alles, sowohl im Einsatz von externer Software, als auch wie wir die Software selber lizenzieren und

weitergeben. Kommerzielle Lizenzen, gar keine Lizenzen, Open Source Lizenzen, freie Lizenzen, das ist alles vorhanden. Es gibt einen Riesenberg an Softwareprojekten, die wir haben, die zu zählen, geht jetzt schon mal gar nicht, das ist sehr unübersichtlich, in so einem Heterogenladen mit dem DLR. Es gibt Ansätze,

das zu katalogisieren, bei so einem Softwarekatalog, software.dlr.de, den bauen wir jetzt gerade neu, aber grundsätzlich versuchen wir auch sozusagen einen Katalog der Software im DLR zu erstellen, aber auch das ist schon ein schwieriges Thema, spare ich mir jetzt hier. Beispiele für Open Source Software, die wir entwickeln, ich habe mal drei

rausgegriffen, weil die auch so typisch sind. Gemeinsam ist den und vielen anderen Projekten, und das ist auch der Anlass, warum viele Software von uns als Open Source veröffentlicht wird, ist, dass die entwickelt werden, erst mal mit anderen Leuten zusammen, das heißt nicht nur innerhalb des DLR mit verschiedenen, vielleicht Abteilungen

oder Instituten, sondern auch mit externen Projektpartnern, Universitäten insbesondere oder anderen Forschungsreinrichtungen, und die werden dann auch genutzt von anderen. Das ist ja oft so ein klassischer Antrieb, auch was als Open Source zu veröffentlichen.

Beispiele sind so was wie das ESM-Wall-Tool heißt das, da geht es um Erdsystemmodellierung und die Vergleich von so Modellen zur Erdsystemmodellierung, ein Python-Tool, was in dieser Community entwickelt wird, als Open Source bereitgestellt wird, und da können Leute ihre Klimamodelle integrieren und mit anderen Klimamodellen vergleichen

oder Erdsystemmodellen vergleichen. Das ist eine Gemeinschaft, die stark wächst gerade. Oder ein anderes, was schon sehr lange, was schon sehr lange gibt, von Kollegen aus der Verkehrsforschung aus Berlin, Sumo, Simulation of Urban Mobility, da kann man halt Verkehrsströme in Städten insbesondere oder urbanen Räumen simulieren. Wann die

Entwicklung angefangen hat, weiß ich gar nicht, war schon lange Open Source und ist zum Beispiel jetzt dieses Jahr Teil der Eclipse Foundation geworden, also ist dem Eclipse-Universum beigetreten. Oder RCE, das ist was, was wir bei unseren Abteilungen entwickeln, Remote Component Environment, eine Umgebung, wo man verteilt im Netzwerk

das DLR Simulation und Bewertungen, Entwurf von Systemen durchführen kann. Und das Bildchen von vorhin, da geht es zum Beispiel darum, was ich vorhin gesagt habe, dass wir diese ganzen Eierköpfe, die ganzen Kollegen im DLR haben, die ihre ganzen Fachdomänen haben und darüber nachdenken mit ganz viel Wissen, wie das bei

Wissenschaftlern so ist, altes und hoffentlich sehr viel neues Wissen. Und dieses Wissen ist heutzutage eigentlich in der Regel in Software hinterlegt. Das ist so ein typischer Fall. Also man denkt sich irgendwas aus, ein Verfahren und programmiert das dann runter und dann kann der nächste das nutzen, wenn es gewisse

Qualitätsmaßstäbe einhält. Genau, und das ist eine Sache, und wenn die Leute dann zusammenarbeiten wollen, dann kann man eben die Daten austauschen und gemeinsam an irgendwelchen Projekten arbeiten, wo verschiedene Fachdisziplinen gebraucht werden. Was unsere Software zum Beispiel macht, ist dann das Software technisch zu verbinden, dass die Leute ihre

Daten austauschen können über verteilte Systeme hinweg und das Wissen auch so ein System, was dann von entsprechenden Partnern wie Universitäten genutzt wird und alleine schon deswegen Open Source geworden ist oder Open Source werden sollte, damit externe Partner in Projekten oder auch direkte Kooperationspartner das einfach runterladen und benutzen können. Und das gilt eben für viele Beispiele im DLR, die

wir haben. Und das wird dann hier eingesetzt, zum Beispiel das ist ein Bild, was irgendwie Hamburg in der TU Hamburg-Karburg entwickelt wird. Dort ist ein DLR-Institut ansässig und wir arbeiten da mit den Kollegen der TU zusammen am Entwurf von neuen Flugzeugen zum Beispiel. Genau, was hatten wir

eigentlich für Probleme in der Vergangenheit? Wir haben ja einiges als Open Source zur Verfügung gestellt und nutzen Open Source, wie viele Einrichtungen und Organisationen, da ist das DLR nicht anders als andere. Und wir haben wahrscheinlich auch Probleme gehabt, die viele andere auch haben oder hatten, dass Software mit Lizenzproblemen nach

außen gegeben wurden. Gab da so Vorfälle, die durchaus kritisch waren, wo wir eine Software weitergegeben haben oder sagen wir, die Bundesregierung hat Software von uns an einen anderen Staat gegeben, hat gesagt, das nimmt das mal, das ist Open Source, könnte einfach benutzen. Der andere Staat hat sich gefreut. Ich nenne jetzt keine Namen. Ich

habe ein Szenario gegen so Typhoons und so Wetter-Sachen und war aber gar nicht Open Source, weil die auf der Lizenzrechtszeit einen Fehler gemacht haben. Solche Sachen können sehr unangenehm werden, auch gerade wenn irgendwelche Politiker das aufgreifen und thematisieren bei so staatlichen

Einrichtungen und das hat viel Aufwand gekostet, diese Lizenzprobleme wieder zu fixen, also zu erkennen, wie ist eigentlich die Lizenzlage der verwendeten Bibliotheken und wie passen die zueinander und wie kann man da vielleicht kritische Lizenzen austauschen, sodass es insgesamt passt. Also die Lizenz-Kompatibilität der

verwendeten Software war da nicht erfüllt und da gab es relativ viele Beispiele, wo das gar nicht der Fall war. Der Grund ist, dass die Kollegen, die es entwickelt haben, also die Wissenschaftler, die eigentlich keine Ahnung haben von Softwareentwicklung, erst recht keine Ahnung hatten von Lizenzrecht. Kann man den auch

nicht vorhalten, sage ich gleich noch. Also die wussten nicht, welche Open-Source-Lizenz sinnvoll ist oder welche Bedingungen erfüllt werden müssen, um die Bedingungen der Open-Source-Lizenz einfach zu erfüllen, damit man rechtlich auf der richtigen Seite ist. Das ist jetzt keine Sache, die speziell ist für das DLR. Es gibt das in der

ganz aktuelle Studie, wo raus kam, dass es von einer International Conference on Program Comprehension von diesem Jahr in Bonn und Sairos stattgefunden hat. Da hat eine Gruppe von Leuten daneben erklärt und ihre Studienergebnisse vorgestellt und die Kernaussage ist im Grunde genommen, wenn

mehr als eine Lizenz involviert ist, dann versteht das keiner mehr. Dann versteht Softwareentwickler nicht mehr die Lizenzlage. Das ist jetzt alles so in dieser Studie von 375 befragten Leuten und bei irgendwie 20% oder so was war das halt so und das ist aber auch das spiegelt auch unsere Erfahrung im DLR wieder.

Also wenn das ein bisschen komplizierter wird und man nicht nur alles mit einer Lizenz hat, dann wird es halt kompliziert und das ist schwer zu verstehen. Wie gesagt, das ist jetzt das erste Mal so eine wissenschaftliche Studie, das ist auch einigermaßen belegt, dass das echt für Softwareentwickler an sich ein Problem ist. Softwarelizenzen und insbesondere mit mehr als einer Lizenz gemischt zu verstehen.

Bei uns im DLR sind ja, habe ich ja gesagt, so in den Jahren, sagen wir mal, in den frühen Jahren, gab dann auch hier so, ich habe dann auch schon draus kopiert aus einem internen Memo, was rumgegangen ist von unserem CIO, der hat dann so

Warnungen ausgesprochen. Muss man ein bisschen aufpassen mit Open Source, die Lizenzbedingungen haben grundsätzlich Rechtsgültigkeit, das war vielen Kollegen auch gar nicht bewusst. Also das ist ja nicht irgendwie ein Wort, das man einfach so benutzt, das ist ja was dahintersteckt, was wirklich ernst sein kann. Also Urheberrechtsversetzung

im Raum stehen, dass man da im Bereich der Haftung und Haftungsvergehen kommen kann, wenn man da irgendwas falsch macht, wenn man Software mit der falschen Lizenz so weitergibt und dass es Open Source Lizenzen gibt, die so infizierend wirken. Das sagt man ja für

die GPL und so, da will ich jetzt gar nicht diskutieren, ob das so stimmt oder nicht, aber das war die Warnung, die ausgesprochen wurde und dass da eben Lizenzen untereinander nicht kompatibel sein können und das dann einfach nicht zueinander passt und man die nicht einfach so kombinieren kann. Das sind halt so Warnungen, die rumgeschickt wurden im DLR an alle Institute, sollte dann so

verteilt werden. Das ist so die negative Seite, man kann ja so warnen und sagen, ja macht das alles böse und so. Wir haben das dann aber aufgegriffen und haben daraus verschiedene Aktionen abgeleitet, Maßnahmen im DLR, damit so Probleme mit Open Source

Lizenzrecht nicht mehr vorkommen. Und wir sind direkt drei Punkte, Information und Schulungen. Zu jedem sage ich gleich noch ein bisschen was. Wissensaustausch ist ein wichtiges Thema und individuelle Beratung und Unterstützung. An sich möglicherweise, je nachdem wo man so herkommt, nichts besonderes. Ich kenne auch Firmen, die das auch so probieren.

Im wissenschaftlichen Forschungseinrichtungen ist das aber relativ neu. Also da gibt es das nicht, dass man das so gezielt angeht und so massiv Hilfestellungen bietet mit hohem Ressourcenaufwand, Personal und auch Materialressourcen. Nur für Open Source Lizenzrecht. Im Bereich der Information und Schulungen,

das erste, was wir gemacht haben, ist ins Bildungsprogramm des DLR eine Schulung aufzunehmen zu Open Source Lizenzrecht, die jeder Mitarbeiter im normalen Bildungsprogramm sich anklicken kann und dann teilnehmen. Heißt rechtliche Aspekte der Open Source Nutzung. Findet mindestens einmal pro Jahr statt an irgendeinem DLR Standort. Da kann wie gesagt jeder teilnehmen

und die sind nicht besonders lang. Die dauern vier Stunden netto, also ohne Pausen. Oder so ein bisschen die wichtigsten Aspekte genannt werden, sage ich gleich noch. Und durchgeführt von zwei Leuten in der Regel, einem Juristen. Meistens ist das ein Mitarbeiter des Technologiemarktings, der sich mit Lizenzen und Patenten auskennt. Und einem jemand, der sich mit

Softwaretechnik auskennt, also jemand aus meiner Abteilung. Entweder mache ich das selber oder Mitarbeiter von mir. Und wir machen das dann gemeinsam und erzählen den Kollegen, was sie als notwendigste Basisinformation wissen müssen. Und das ist zum Beispiel, so die Agenda sieht zur Zeit etwa so aus. Erstmal eine

Einführung. Was ist überhaupt Open Source? Also ein bisschen der Unterschied zwischen Open Source, auch in Free Software und auch ein bisschen zur Philosophie von Open Source und wie das bedeutet, Open Source im DLR zu haben und zu nutzen. Und natürlich ein wesentlicher Block sind die rechtlichen Grundlagen, die man braucht. Was bedeuten diese Begriffe Copyright und Urheberrecht, Vertragsrecht.

Da ist dann auch auf den Folien da ganz viele Paragraphen zu sehen und so. Und was hat das auf der Folgen, wenn man da falsch handelt als Mitarbeiter aus Mitarbeitersicht, also Rechtsfolgen. Dann gibt es das halt, dann geht es halt um Open Source Software selber. Also welche Lizenzen gibt es

für Software überhaupt? Was bedeutet Open Source? Die Definition der OSI zeigen wir da und dann noch verschiedene Open Source Lizenzmodelle und erklären intensiv, was CopyLeft bedeutet. Und dann nächsten Abschnitt erklären wir da das etwas konkreter für einige Lizenzen, die relativ verbreitet sind im DLR, aber auch

sonst wo, wie GPL und die ganzen Apparten oder Eclipse Public License und BSD Licenses. Und das ist natürlich nicht alles, was so vorkommt, aber das sind erstmal die wichtigsten und viele Konzepte und viele Regelungen und Bedingungen wiederholen sich ja dann bei allen Lizenzen auch. Und am Ende geht es

nochmal ein bisschen Richtung Praxis. Und zu sagen, wie kann man Software nutzen, Bibliotheken und ähnliches aus Sicht der Software Technik. Wie kann man Open Source in eigene Projekte, also bestehende Bibliotheken in eigene Projekte einbinden? Wie sieht das aus mit dieser Lizenzkompatibilität? Also wie kann

man die prüfen? Und was muss man da beachten? Und wie verteilt man Open Source und wie entwickelt man eigentlich eigene Open Source Software? Das habe ich gar nicht in den Folien drin. Das Hosting von Open Source Software im DLR ist noch sehr heterogen. Es geht jetzt immer mehr Richtung GitHub. Jedes Institut kann sich da so einen GitHub-Bereich

einrichten, oder viele haben das schon gemacht und da landet die Open Source Software. Früher war das mehr verteilt bei Bitbucket und früher bei SourceForge, ganz früher bei Google Code, dass das noch gab und ähnliche Sachen. Und einige haben das auch bei sonstigen anderen Forschungseinrichtungen bei Google Hosted. Das kommt alles Mögliche vor. Die Anzahl der Schulungsteilnehmer,

die wir hatten in den letzten Jahren, ist nicht besonders hoch, aber man sieht, das ist einigermaßen verteilt von den Standorten. Bei München, Oberpfaffenhofen, Berlin und Köln, Stuttgart, Berlin, nochmal Köln. Das sind so, also wir tingeln durch die DLR-Standorte im Lauf der Zeit, so dass jeder mal auch einen kurzen Anreiseweg hat, um da teilzunehmen.

Und wir machen vorher auch immer Abfragen, um die Erwartungshaltung der Schulungsteilnehmer, das Vorwissen abzufragen. Die meisten haben, sagen halt, dass sie für das Thema, also Open Source Lizenzrecht, relativ wenig Vorwissen haben, also ungefähr die Hälfte. Und einige haben gar kein Vorwissen, andere ein bisschen

Vorwissen und keiner sagt, dass er jetzt schon Experte ist, aber sonst würden die sich auch wahrscheinlich nicht für so eine Schulung anmelden. In der Praxis treffen wir immer wieder Leute, die denken doch, dass sie ganz viel Ahnung haben und die hätten sich doch anmelden sollen. Das ist noch so ein Problem, die jetzt zu erreichen, aber da sage ich gleich noch was zu. Da haben wir nämlich andere Mittel gefunden. Aber

das ist jetzt erstmal für diese Reinschulung, so. Und die Erwartungen, dann können die noch konkrete Erwartungen oder Ziele formulieren, was sie denn lernen wollen, welche Aspekte in Projekten zu berücksichtigen sind, zum Beispiel oder Überblick über Open Source Lizenzmodelle oder wie man Open Source Software mit Closed Source Software kommuniert und so weiter. Klar, das ist jetzt schon

diese Agenda, die ich präsentiert habe, hat sich da schon niedergeschlagen. Die passen wir auch immer an, an die Erwartungen und an die Bedürfnisse der Teilnehmer. Deswegen sind die Begriffe mit Absicht auch ziemlich ähnlich. Die Ergebnisse hinterher gibt es dann immer noch natürlich, wie das

Feedback, was wir einholen, wo die Leute einen Fragebogen ausfüllen dürfen, wo es dann Ergebnisse gibt. Das zeigt eigentlich auch ein relativ gutes Bild, dass die grünen, was ist das Grün, ja, die grünlichen Balken sozusagen inwieweit sind die Erwartungen erfüllt worden.

Das ist ja das Große im Bereich der Schulnoten, ist das im Bereich 2, also bei über 50 Prozent, das ist schon ganz gut. Relativ wenig sagen, das ist ganz schlecht, das ist auch für uns schon mal gut. Und die roten Balken sind übrigens, was ist der erwartete

Nutzen für die tägliche Arbeit, das fragen wir auch ab. Also was denken die direkt nach der Schulung, wie weit denn das in der täglichen Arbeit hilft. Da sind die Bewertungen auch relativ gut. Da haben wir jetzt leider noch keine Bewertungen, wie das jetzt zum Beispiel ein paar Jahre nach der Schulung wirklich ist. Das bereiten wir gerade vor, da mal so eine Umfrage zu machen unter den ehemaligen,

allen ehemaligen Schulungsteilnehmern, aber das wird der nächste Schritt sein, das mal zu fragen, ob sich das bewahrheitet hat. Genau, diese Schulungen funktionieren so weit ganz gut und das Feedback ist ganz positiv. Was wir da noch gemacht haben ist, um wieder andere Leute zu erreichen, ist das Wissen über Open Source Lizenzrecht als Dokument

zur Verfügung zu stellen. Open Source Broschüre, Nutzung von Open Source Software im DLR heißt die. Die hatten wir tatsächlich auch in den Vorjahren auf der Frostconn verteilt. Ist leider im Moment vergriffen und wir planen die Neuauflage dieser Broschüre. Die nächste Broschüre würde dann auch unter einer Creative Common Lizenz frei verfügbar sein für alle und auch auf Englisch erscheinen, weil

wir inzwischen deutlich mehr Anfragen von außerhalb des DLRs kriegen als von internen Kollegen. Also aus der ganzen Helmholtz-Gemeinschaft und der ganzen Forschungslandschaft in Deutschland, die haben uns die letzten Exemplare aus der Hand gerissen, deswegen sind die halt jetzt weg. Aber wir planen gerade die Konsequenzen. Und den

Ausbruch natürlich. Der inhalt ist von einer Anwaltkanzlei aus Berlin entwickelt, die sich ganz gut mit Lizenzrecht und Open Source Lizenzrecht auskennt. Und der Inhalt ist im Wesentlichen unterteilte in zwei große Kapitel. How do software spread? Also, bei Lizenzrecht

geht es darum, dass man Software nach außen gibt, dann dritte. Wenn das nur intern wird, ist das erst mal eine andere Geschichte. Aber es geht dann zum einen um die Verteilung von unmodifizierten Code und zum zweiten Kapitel um modifizierten Code, also Code, den man geändert hat. Entschuldigung. In jedem dieser Kapitel listen wir ein paar Lizenzen auf mit den

entsprechenden Verpflichtungen, die man da erfüllen muss. Und auch wieder hier die Lizenzen, die im DLR halt am weitesten verbreitet waren. Darum ging es erstmal. Und dann jeweils gruppiert in Lizenzen mit starkem Copy left, schwachen Copy left, ohne Copy left oder mit speziellen Rechten. Das sind so die grobe Unterteilung. Und für

jede Lizenz sieht das ungefähr ähnlich aus, um das zu sehen kann. Es gibt da so Checklisten mit den Bedingungen der Lizenz. Da kann man dann abhaken, ob man das für sein eigenes Projekt, für sein eigenes Vorhaben da erfüllt. Man muss sich das nicht so aus den Lizenztexten irgendwie raus extra hier mit Text-Mining oder so, also mit Lesen. Und dann gibt es auch so Merkboxen oder Infoboxen, je nach Kontext, die irgendwelche

Begriffe erklären oder irgendwelche interessanten Formulierungen erklären oder sowas oder irgendwas klarer machen. So ist das Ganze aufgebaut. Kommt auch ganz gut an. Teilweise auch so Entscheidungsbäume für die Lizenzauswahl oder so. Ganz

wichtig ist, dass wir in diesem Bereich Informationen bereitstellen und was wir dann gemerkt haben, ist, dass das nicht reicht. Also dass wir damit schon viele Leute erreichen und die viele Leute uns Feedback geben, dass sie sich schon besser informiert fühlen. Aber es gibt noch ganz viele andere, die haben dann so Sachen wie Fragen und so und Diskussionsbedarf.

Und dafür haben wir das etabliert für direkten Wissenstaustausch. Zum einen natürlich, da kommt man bei Wissenstaustausch und Wissensdokumentation ganz schnell darauf, logischerweise, auf so Wikis und so ein Quatsch. Also hatten wir im DLR auch immer schon Wikis. Viele hatten das in Instituten installiert. Seit 2013 haben wir so eine zentrale

Wiki-Installation, das Atlassian Confidence Wiki. Und da gibt es dann verschiedene Bereiche, zum Beispiel für Software Engineering oder für Veranstaltungen oder jedes Institut hat da seinen eigenen Bereich und so. Und da kann man Sachen dokumentieren, das funktioniert so weit ganz gut. Und da haben wir auch eben einen gezielten Bereich für Open Source und alle

Open Source Themen, wo Hinweise zu Tools sind, zu Literaturhinweise. Da gibt es eine Frage- und Antwort-Section da drin, also für Diskussionen oder auch Hinweise auf Veranstaltungen. Also nicht nur die Schulung, sondern auch andere Veranstaltungen. Das sind alles Informationen, die wir uns jetzt nicht ausgedacht haben, sondern die man auch mit suchen beliebiger Art

im Internet findet, aber eben ein bisschen nett zusammengestellt und aufbereitet für das DLR. Also damit die Kollegen einfach erstmal nur einen Einsprung haben, wo sie hingehen können und dann finden sie im Grunde alles, was irgendjemand dachte, das ist relevant im Kontext DLR und können dann da Fragen stellen und so weiter. Genau, funktioniert so ganz gut,

wird mit der Zeit immer besser angenommen, wie überhaupt das ganze Wiki. Das ist alles relativ zäh eigentlich. Was allerdings noch viel besser funktioniert, ist was wir Wissensaustauschworkshops nennen. Das sind Veranstaltungen, so echte Live-Veranstaltungen, wo Leute zusammenkommen müssen an einem Ort, um sich auszutauschen, also echt peer-to-peer

mäßig miteinander unterhalten. Die gibt es im DLR zu verschiedenen Themen, wurden vor einigen Jahren eingeführt. Der erste war zum Thema Software Engineering. Da gibt es dann so einmal so einen Initialen Wissensaustauschworkshop und dann werden diese Reihen so, gibt es jedes Jahr ein Folgeworkshop zu den einzelnen Themen, auch zur Visualisierung oder autonom fliegen und so

weiter und auch ein zu den DLR Open, wo es allgemein so Sachen, Themen gibt wie Open Source, Open Science, Open Access, Open Data und so weiter. Letztes Jahr, der Initiale Wissensaustauschworkshop war dann zu Open Source in dem Fall. Funktioniert auch ganz gut, wie auch die

anderen Wissensaustauschworkshops mit anderen Themen. Die sind auch alle offen für alle DLR-Mitarbeiter grundsätzlich. Gibt allerdings da auch eine Teilnehmerbeschränkung, also ein bisschen gewollt, ungefähr 60 Teilnehmer. Sonst wird es auch unübersichtlich und vielleicht

zu groß, dann geht es schon in Richtung Konferenz teilweise. Also ist dann in Köln oder in anderen Standorten. Und die sind sehr viel interaktiver als so eine klassische Schulung. Also gibt dann kurze Impulsvorträge normalerweise. Dann vielleicht so Vorstellungsrunden,

die man irgendwie interessant gestaltet. Lightning Talks gibt es teilweise von Instituten, wo Leute auch, wo Kollegen auch dann vorstellen, was sie konkret für Probleme oder Lösungen haben. Und dann halt sehr beliebte Arbeiter und Diskussionen in kleinen Gruppen mit verschiedenen Arten von Modellen. Da gibt es so Sachen wie italienisches Kaffee und

Das ganze Ziel ist aber, dass das hochgradig interaktiv ist. Und klar, hier sieht man Karina, die heute ja eigentlich auch hätte präsentieren sollen, wie sie sich auf dem Boden kniet und sich selber vorstellt. Wir haben das letztes Jahr so gemacht, dass jeder so ein Poster über sich malen musste und das dann anderen Kollegen erklären,

was man so an Wissen bietet und hat. Oder funktioniert dann teilweise so ganz gut. Und hier Kollege Michael rechts hier mal erklärt, was er alles kann. Manchmal funktioniert es auch nicht so gut. Hier hat einer versucht zu erklären, wie seine Denkwelt aussieht. Das geht auch manchmal nach hinten los. Der macht irgendwas mit

Satelliten, so viel kann man sagen. Und naja, den Rest, das geht da mehr Richtung Kunst und nicht Richtung Forschung und Open Source, aber egal. Diese Wissensaustauschworkshop da machen wir die ganzen Sachen mit Erwartungsabfrage und Feedbacks. Die Erwartung und die Hoffnung

der Mitarbeiter ist auch hier so. Das Wichtige, was sie sich erhoffen, ist halt Informationsaustausch untereinander. Und das funktioniert auch ziemlich gut. Also 38% ist der rote Bereich oben, ist halt der Informationsaustausch, den erhoffen sich die Leute. Und das zweitgrößte ist halt Netzwerken, der früchtig satte, gelbe unten,

also mit anderen Kollegen auch in Kontakt kommen. Und das ist auch ein wichtiger Aspekt, dass man da mal so andere Kollegen sieht, die man normalerweise im Alltag nicht sieht. Das ist ja wie in vielen Firmen, das DDR ist halt sehr verteilt auf viele Standorte und das ist ja nicht ein Campus, wo man sich jeden Tag über den Weg läuft oder

schweigend miteinander redet. Deswegen ist das eine gute Gelegenheit auch insbesondere von anderen Standorten sein Informationsnetzwerk auszubauen und dann bei Fragen vielleicht direkt andere Leute zu fragen und nicht nur die, die immer die gleichen Köpfe, die immer die gleichen langweiligen Antworten geben. Das funktioniert in der

Praxis auch ziemlich gut. Und eine Erkenntnis aus diesem Wissensaustausch-Workshop sind teilweise die generelle Art, die wir vielleicht vorher auch schon ein bisschen wussten, die dann aber da nochmal direkt von Kollegen auch direkt geäußert wurden, dass Open Source relativ verbreitet schon ist im DLR und wie das verwendet wird in Form von Tools aus der Open Source Welt, die man benutzt einfach oder Libraries. Und

dass immer noch viele Forschungssoftware Closed Source ist, aber immer mehr Interesse daran besteht, eigene Forschungssoftware auch zu veröffentlichen. Also relativ high-level Erkenntnisse. Dann gibt es auch immer diese viele Kritik, das kommt oft auch von Führungskräften, dass man dann eben, wenn man was als Open Source veröffentlicht,

die Möglichkeit verliert, Gelder zu erwirtschaften. Das haben wir auch dann viel diskutiert, auch Strategien oder Erklärungen, warum das vielleicht nicht immer so ist. Dann auch so ein Kritikpunkt, dass ein Aufbau in der Open Source Community aufwendig ist. Neben der normalen Arbeit vielleicht noch so eine Gemeinschaft von

Externen irgendwie, naja, irgendwie mit denen zu kommunizieren und ein bisschen gemeinsam die Entwicklung zu planen und so weiter. Das kostet Zeit und ist für viele Leute auch irgendwie anscheinend nicht realisierbar. Denken die, ja, das wird ja in der Open Source-Strategie in das zu ändern und überhaupt das zusätzliche Zeitaufwand,

irgendwas aufzubereiten, dass es dann als Open Source veröffentlicht wird, fängt schon an mit der Frage, welche Lizenzen, wie müssen die da auswählen, darüber zu diskutieren, ist ja schon Zeitaufwand. Und dann so Sachen wie Klären, ob das Exportkontroll rechtlich überhaupt erlaubt ist und solche Geschichten. Da ist der Zeitaufwand hoch und das demotiviert auch viele Leute,

irgendwas als Open Source zu veröffentlichen. Deswegen werden wir auch da ansetzen und versuchen da, diese Sachen wegzudiskutieren. Klingt zu negativ, sagt man das denn. Also positive Beispiele zu liefern, wie man das hinkriegt im Alltag. Das ist zu Teil unserer nächsten Schritte, die wir beim DLR angehen. Auch so gibt es auch ganz konkrete

Resultate, die wir da haben. Was wir halt nicht hatten im DLR, ist so ein formal aufgeschriebenen Prozess. Wie geht man denn um, wenn man Open Source veröffentlichen will? Viele wollen das ja haben. Die gucken dann, gehen dann zu dem Qualitätsmanager im Institut und sagen, hier zeigt man mal die Prozessbeschreibung Veröffentlichung von Open Source Software. Und das haben wir

nicht gemacht mit Absicht. Weil das ist jetzt kein großes internes Geheimnis. Diese Qualitätsmanage-Geschichten, die lesen viele Leute nicht. Gucken da gar nicht rein. Würden das eh nicht finden. Und wir sind auch, haben das so gewählt, dass wir, dass wir Informationen und Veranstaltungen

bieten. Sozusagen erst mal direkt für alle Mitarbeiter anbieten und nicht von oben durch eine Prozessbeschreibung aufdrücken wollen. Das war unser Ansatz. Trotzdem gibt es jetzt immer mehr den Bedarf, doch da auch mal rechtlich bindende Prozessbeschreibung zu haben. Und das erstellen wir jetzt gerade dieses Jahr. Und es gibt halt allgemein dann immer bei den

Veranstaltungen relativ viel Feedback für weitere Aktivitäten. Genau, dann haben wir noch bereit, was wir auch viel machen, ist so direkte 1 zu 1 Beratung und Unterstützung. Da gibt es dann verschiedene Entrepreneur im DLR, die auch da bereitstellen. Je nach Fragestellung, so für Lizenzfragen gibt es das Technologie-Marketing, das DLR, die auch

für Vermarktung von Produkten hat und Software aller Arte zuständig sind. Und dann gibt es natürlich rechtliche Unterstützung für Körperleitgeschichten oder sonstige Rechtsfragen. Das ist natürlich wie so oft die Rechtsabteilung. Und für erst software-technische Fragen,

Lizenzkompatibilität Prüfung, Lizenzauswahl oder auch alle Sachen, die die Entwicklung betreffen, das machen dann erst Software-Techniker aus der Einrichtung, wo ich arbeite. Und genau, dann gibt es was ganz wichtiges, was ich auch als positiv herausgestellt habe, das ist in jedem Fall eine zentrale E-Mail-Adresse Open Source in DLR. Und da kann man erstmal alles hinschicken. Intern und da extern. Also wenn ihr irgendwas habt, könnt ihr auch alles da hinschicken.

Freuen sich die Kollegen. Genau, und eine Sache, die zum Beispiel da auch so entstanden ist, dass wir, wenn jemand kommt, so sagen, es gibt einige Lizenzen, die könnt ihr einfach so nehmen, die hat die Rechtsabteilung überprüft. Da müsst ihr nicht groß nochmal nachfragen. Das ist jetzt Simplified

BSC-License, Apache-License und Eclipse Public License. Bei allen anderen kann man oder sollte man vielleicht auch mal nachfragen, ob das das Richtige ist, aber die sind jetzt aus DLR-Rechtsabteilungssicht erstmal okay und kritisch für das DLR. Deswegen sagen wir, das sind so unsere Default-Lizenzen. Das wird sich vielleicht auch demnächst noch ändern, aber das ist

erstmal die Liste. Genau, und andere Themen, die so einmal auftauchen, sind halt Kriterien für die Auswahl von Open Source Software, also was man jetzt nutzen kann im Außenbereich, ob es ja auch existierende Open Source Software,

Best Practices für Open Source, wenn man jetzt selber mit Open Source entwickeln will oder eine eigene Open Source Software entwickeln will, oder ein Thema auch, was sehr relativ groß ist im DLR, was eigentlich fast ein eigener Vortrag wert wäre, ist das Thema Migration nach Open Source. Das DLR arbeitet ja gerade quasi, ja alles, was von Microsoft kommt, zu ersetzen durch

Open Source. Das ist ein relativ lang laufendes Projekt, das kann man sich vielleicht denken. Oder wir versuchen überhaupt viele kommerzielle Produkte, wie zum Beispiel, also sehr beliebt ist bei uns sowas wie Matlab für Simulation und Datenauswertung, hochkommerzielles Produkt. Ich glaube, dieizenzen kostet so um 10.000 Euro pro Jahr. Sowas auch zu ersetzen durch freie Versionen,

z.B. Python mit entsprechenden Bibliotheken. Und auch da hatten wir gezielt eigene Workshops nur zu diesem Thema, wo wir für verschiedene Produkte aus der kommerziellen Welt darüber diskutiert haben, wie man das durch freie Software ersetzen kann. Und wo da noch Lücken sind, wo wir

selber auch noch Entwicklungsarbeit reinstecken müssen. Genau. Und für Fragen und Antworten sozusagen gibt es im Wiki natürlich auch noch eine Seite. Das war mal so gedacht wie so eine Art Stack Overview intern. Wir haben das jetzt erstmal als Wiki probiert. Wenn das jetzt nicht skaliert, dann werden wir da vielleicht noch eine andere Lösung für aufsetzen. Aber

erstmal haben wir so für allgemeine Fragen und Antworten und Diskussionen auch eine Wiki-Seite. Genau. Damit bin ich durch. Ich hatte ja auch noch ein paar Minuten glaube ich. Als Worte am Ende sozusagen. Unser Vorgehen im DLR. Worauf passiert das? Zum Erden, wir haben damit angefangen

Informationsangebote für Mitarbeiter bereitzustellen und Raum und Gelegenheit gegeben, um zu diskutieren. Damit die Leute unternah diskutieren und ihr Wissen austauschen können. Und erst danach kommen jetzt bei uns langsam so formale Prozessbeschreibungen und vielleicht Vorgaben von oben, wenn sie notwendig sind. Und meiner Meinung nach ist es

oft so, dass viele andere auch Forschungseinrichtungen das anders rumversuchen. Einen Brief vom Vorstand rumschicken und sagen, ihr müsst das so und so machen. Und das ist oft auch, funktioniert das nicht besonders gut. Und das feedback der Kollegen ist ziemlich positiv. Und wir merken das auch. Und diese Support-E-Mail-Adresse, da kommt immer weniger an,

obwohl immer mehr als Open Source genutzt wird und immer mehr Open Source entwickelt wird. Die Carina hat damit mit einem von den Kollegen auch noch das ein bisschen genauer ausgewertet. Die Daten habe ich jetzt nicht hier, aber wir sehen auch an den E-Mail-Verläufen, dass immer

weniger Anfragen kommen und schließen daraus jetzt erst mal ganz mutig, dass es auch immer weniger Probleme gibt. Das werden wir in Zukunft auch noch ein bisschen genauer analysieren. Und genau, was sehr positiv ist, was ich auch ganz nett finde, ist, dass unser Vorgehen auch von anderen übernommen wird. Es fließt jetzt ein in so Dokumente, Handlungsempfehlungen

für die Helmholtz-Gemeinschaft, also alle Helmholtz-Forschungszentren in Deutschland und auch Max Planck und ähnliche Forschungseinrichtungen haben Interesse daran, unser Vorgehen so zu übernehmen. Genau, damit bin ich fertig. Vielen Dank. Du meinst jetzt von den Politikern,

wie aus dem Ministerium oder so, also da ist nicht explizit hoch, aber die Frage war, wie der politische Druck ist von den Geldgebern und der Politik, ist das richtig? Also der politische Druck ist bisher in Deutschland zumindest bei uns fast ankommend, nicht besonders hoch. Es gibt immer so Forderungen, dass das DLR, also von der Politik

eher weniger, aber auch eher von der Öffentlichkeit, dass das DLR natürlich auch seine Sachen öffentlich zur Verfügung stellen soll. Das ist ein Grund, warum wir das auch machen. Aber indirekt kommt ein Druck deutlich durch Projektausschreibung, wo zum Beispiel gefordert wird, dass bei Projektanträgen oder die Projektechemisse in öffentlich geförderten Projekten jetzt auf Bundesebene oder EU-Ebene, dass

diese eben open source sein müssen. Oder dass man sogar, wenn man eigene Software dort einbringt in das Projekt und die weiter entwickelt werden soll, dass die schon open source sein muss und so würde im Zweifelsfall das Projekt gar nicht erst genehmigt werden. Von daher ist der Druck ist deutlich höher noch zurzeit. Aber kann man natürlich halt eine Art indirekten politischen Druck betrachten.

Das gilt für alle Forschungseinrichtungen und Universitäten. Es gibt noch weitere Fragen. Wie war der Anfang? Ich würde erwarten,

ja. Ja, also war jetzt keine Frage, war eine Aussage. Also Steuerzahler würde erwarten, dass alles öffentlich gemacht wird. Ja, das würde ich auch. Also es gibt bisher keinen Drang und keine

Pflicht, das zu machen. Wir machen das meiste freiwillig. Wie gesagt, das wird hier eben gesagt, mit der Projektförderung, das ist eine Art Pflicht. Man kann natürlich dann sagen, man beantragt keine Projekte mehr. Also auch das ist ja freiwillig. Aber man kriegt natürlich auch keine Gelder oder weniger Gelder und kann seine eigenen Arbeiten nicht mehr durchführen. Also es ist

nicht ganz freiwillig am Ende des Tages. Aber es gibt keinen harten Drang, dass jemand sagt zu uns, ihr müsst jetzt unbedingt alles als open source veröffentlichen. Der Druck ist noch stärker im Bereich open data, für Datensätze. Da ist ja hier die Frage, was ist wichtiger und spannender, auch

für die Gesellschaft, Daten oder Source Code. Im Bereich der Daten oder auch im Bereich der Publikation als open access, da ist der Druck sehr viel höher als im Softwarebereich zum Beispiel. Also da gibt es auch klarere Vorgaben. Und auch da arbeiten wir dran. Das sind dann andere Leute im DLR vor allem, die dann eben versuchen, entsprechend zur open source

parallel zu einer open data Strategie aufzusetzen und Software oder Repositories bereitzustellen, über die wir dann eigene Datensätze zum Beispiel veröffentlichen können. Da ist ja diese Infrastruktur im Datenbereich noch viel weniger entwickelt jetzt und weniger harmonisiert. Also bei Source Code billig ausgedrückt, lädt das ja jeder bei

GitHub hoch und dann ist das veröffentlicht. Bei Daten ist das ja noch nicht so harmonisch, leider. Aber auch da arbeiten wir dran. Genau, eigentlich von den Mitarbeitern, genau. Die müssen eigentlich noch ihren Vorgesetzten fragen, wie bei allen wichtigen Entscheidungen,

wenn irgendwas nach außen gehen soll. Also alles, was irgendwie nach außen gehen soll, da muss ein Vorgesetzter zustimmen. Das gilt auch bei normalen textlichen Veröffentlichungen genauso bei Software. Und bei der Lizenzfrage ist es so, dass man eigentlich auch noch mal nachfragen sollte beim Technologie-Marketing oder bei der Rechtsabteilung, ob das so in Ordnung ist, wenn man

sich schon weiß. Also spezielle Lizenzen ist auch noch. Aber die meisten Entscheidungen oder der meiste Druck und die meisten Wünsche, was wir als Open Source veröffentlichen, kommen tatsächlich auch von Mitarbeitern. Viele sehen das ja in ihrem Kontext, wenn sie mit anderen Leuten zusammenarbeiten. Das ist deswegen diese Beispiele, die ich ganz am Anfang hatte.

Das sind alles Software-Projekte, wo meine Kollegen mit anderen Leuten zusammenarbeiten, die dann sozusagen auf der Mitarbeiter- und Wissenschaftler-Ebene Druck aufbauen. Ja, was ihr da macht als Algorithmen, das ist ja eigentlich ganz cool. Wir würden das bei uns im Forschungszentrum Y auch benutzen, aber nur wenn es Open Source ist. Da hat man erstmal schon mal die

Diskussion an der Backe und auch ganz schnell die Entscheidung, das als Open Source wirklich zu veröffentlichen. Ja, da. Wenn der was sagt. Meinst du

Geschäftsführer auf dem DLR? Ja gut, sowas haben wir nicht, weil wir ja kein Geschäft sind, aber wir haben einen Vorstand und das Entscheidende, die wichtigen Personen sind bei uns die Institutsleiter. Ach so, ja, das CIO quasi, der koordiniert im ganzen

Bereich IT und die IT-Governance. Also der unterstützt soweit er das kann. Der sieht auch natürlich, dass der Trend in diese Richtung geht. Also auf keinen Fall blockiert er das. Das ist ja erstmal schon eine Sache, die in einigen anderen Einrichtungen anders war. Und der finanziert uns teilweise. Der finanziert bei uns eine Person, die daran

arbeiten kann. Und mit dem stimmen wir das auch ab, was wir vorhaben. Also nicht, dass dann irgendwann es heißt, ne, das hätte er gar nicht machen dürfen oder so, so eine Aktion. Ja, das war, wie gesagt, das war so ein Warnbrief,

der als Warnung gedacht war. Aber auch nicht so, dass man da jetzt irgendwas nicht mehr machen darf. Es war als Warnung, die Leute aufzurütteln. Und direkt sozusagen schon vorher abgestimmt. Also ich habe auch mitgearbeitet bei der Formulierung dieser Warnung damals vor einigen Jahren. Würde ich vielleicht heute andere Formulierungen vorschlagen, aber wie auch

falls direkt im Anschluss haben wir sozusagen halt die Maßnahmen angeboten, um da zu helfen. Aber das war zum ersten Mal überhaupt um klar zu machen, dass es da möglicherweise irgendwo auch Probleme geben könnte mit Open Source. Lizenzrechtliche Art. Das hat auch funktioniert, ja. Ja, bitte. Nicht

mehr speziell, aber es ist halt, also bei GPL ist ja grundsätzlich, ja die Frage war, was hat gegen die GPL angesprochen? Das ist ja allgemein Sachen, allgemein geht es ja darum, die

Copy-Left-Klausel in der GPL. Das dann heißt, wenn du ein eigenes Software reinkopierst, zum Beispiel Ausschnitt, dann gilt diese Lizenz für die gesamte Software. Und das, das war halt, sagen wir mal, störend für einige Software-Projekte. Es gab dann etliche Sachen, da sollte halt die gesamte Software unter einer anderen Lizenz bleiben. Und dann haben aber Kollegen

sozusagen da vielleicht eine einzelne Datei ausgetauscht oder Code rauskopiert aus einer unter GPL-Lizenzierten Software reinkopiert und hätte ja die ganze Software unter GPL veröffentlicht werden müssen. Ja, das ist ja so eine Eigenheit davon. Und das wurde dann nur noch mal als Warnung aufgegriffen.

Diese Fälle sind auch aufgetreten bei uns und wahrscheinlich auch bei vielen anderen und hat dann im Einzelfall auch Arbeit verursacht, das dann durch entsprechende andere Lösungen, anderen Code zu ersetzen. Die Gefahren steigen ja auch, das, was gar nicht, ob es da nicht einen Vortrag zu gab, aber es ist natürlich auch überhaupt die Frage sozusagen, erkennt man das überhaupt? Ob man so einen Code-Ausschnitt

hat, gerade wenn man sich jetzt was von Stack Overflow kopiert oder so, wo man ja auch nicht genau weiß, wo das herkommt im Zweifelsfall und das reinkopiert. Und es gibt ja heute Möglichkeiten, das automatisch zu prüfen, also durch so Data Mining im Source Code Repository, sondern vor zehn Jahren hätte das im Leben niemand rausgefunden vielleicht, außer durch Zufallsfunde. Und heutzutage

gibt es ja so ganze Projekte, die durch Forsten regelmäßig getappt und dann listen die das auf, weil da alles Lizenzvergehende geht. Und da möchten wir nicht beistehen, ungern jedenfalls, ja. Ja, genau, das ist richtig, deswegen

machen wir das so. Richtig, genau. Ja, ganz viel. Ja, ja,

genau. Ach so, Entschuldigung, ja, haben wir schon mal Geld verdient mit nach der Veröffentlichung und Open- Source Software durch Beratung oder

Support? Ja, genau, haben wir, indem wir jetzt zum Beispiel Backfix gemacht oder Erweiterungswünsche bearbeitet haben oder allgemein Schulungen angeboten haben. Ja, ganz viele. Ja, gibt es.

In Zweifelsfall auf GitHub oder wir haben selber auch eine Seite software.dlr.de da sind auch ein paar Sachen aufgelistet. Ja, in den USA. Ja,

das weiß ich gar nicht. Ja, genau, also die Frage, um das zu wiederholen, es gibt in den USA das, wie heißt das, Expect-Programm. Ja, genau, so viel

weiß ich auch so und genau weiß ich auch nicht, wie es anders ist, aber da gelten teilweise andere Regeln. In Deutschland geht ja auch nicht so was wie ich glaube Public Domain oder so, das geht dann wieder. Das ist genau der Fall, das geht ja in Deutschland zum Beispiel auch nicht, dass man einfach auch die Rechte komplett abgibt. Also

weiß ich nicht. Sag du es, weiß ich nicht. Gut, wenn sonst noch Gesprächs- oder Diskussionsbedarf ist, wir haben da draußen so eine Art Stand, könnt gerne vorbeikommen, dann können wir weiter

diskutieren. Ja, vielen Dank.