Open Source: Wie die Anerkennung der Gemeinnützigkeit helfen könnte

Erst kürzlich haben verschiedene Vereine in einem offenen Brief von der Politik gefordert, mehr in Open-Source-Projekte zu investieren. "Eine moderne Verwaltung und die Förderung von Open Source [...] ist ein entscheidender Faktor, um die digitale Transformation der öffentlichen Hand nachhaltig voranzutreiben – unabhängig von politischen Wechseln oder Koalitionsdynamiken", heißt es von dem unter anderem aus der AG Kritis, ein aus der AG Nachhaltige Digitalisierung und Wikimedia bestehendes Bündnis. Eine Unterstützung für Open-Source-Projekte stellt jedoch auch die Anerkennung der Gemeinnützigkeit dar – in Deutschland ein kompliziertes Unterfangen. 2021 hatte das für Mastodon zunächst geklappt, doch das hat sich inzwischen wieder geändert. Warum konkrete Vorgaben bezüglich der Gemeinnützigkeit Open-Source-Unternehmen helfen würden und über eine nachhaltige Open-Source-Entwicklung haben wir mit Mirko Böhm, Senior Director für Community Entwicklung bei der Linux Foundation Europe, gesprochen. Aufgrund seiner jahrzehntelangen Erfahrung wurde er bereits als Dinosaurier im Bereich Open Source vorgestellt.

heise online: Welche Unterschiede gibt es im Open-Source-Bereich weltweit?

Mirko Böhm: Die Länder in Europa unterscheiden sich in dem Punkt nicht groß voneinander. Es gibt immer die beiden Lager, die die Open Source einfach als pragmatisches Mittel zur Zusammenarbeit betrachten und die, die es eher als gesellschaftliche Strömung sehen – als ein politisches Mittel. Diese Strömungen finden sich überall auf der Welt. Nur China ist anders. China spielt eine besondere Rolle, denn es ist ein sehr großes Land mit vielen Tech-Unternehmen, die sonst wenig mit uns zusammenarbeiten. Wir haben wenig Einblick, was dort vor sich geht. Die Linux Foundation ist die Heimat von vielen global aufgestellten Projekten wie der Linux Kernel, Yocto oder Kubernetes. Bei uns sammeln sich eher Menschen, die Open Source als pragmatisches Mittel für Zusammenarbeit sehen. Auch in den EU-Staaten haben wir ein weit verteiltes Netzwerk an Mitwirkenden. Dafür gibt es in den USA die Linux Foundation, in Europa die Linux Foundation Europe.

Es gibt manchmal Diskussionen um die Begriffe Freie Software und Open Source. Wie ist Ihre Sicht darauf?

Die Begriffe sind historisch gewachsen. Man könnte sich stundenlang darüber unterhalten, wie sie sich im Detail unterscheiden. Wir nutzen da die Anforderungen "use, study, modify, and distribute", also Verwenden, Verstehen, Anpassen, Verteilen. Und es gibt auf der anderen Seite die Open-Source-Definition, die aber im Prinzip auf das Gleiche hinausläuft. Die Software wird jedem zu jedem Zweck zur Verfügung gestellt und hat damit keine Diskriminierung in Richtung des Users. Der Zugang zu Technologie kann eine Art Menschenrecht sein.

Inwiefern können Änderungen bei der Gemeinnützigkeit von Bedeutung sein?

Der Begriff Gemeinnützigkeit gibt an, dass eine Tätigkeit der Allgemeinheit selbstlos hilft, das funktioniert gerade auch bei Technologien, genauer gesagt der Entwicklung von Technologien, die der Gemeinschaft unter einer Lizenz zur Verfügung stellt, die die Anforderungen der Open-Source-Definition erfüllen. Diese haben alle Mindestanforderungen. Und es gibt die Frage, was hat das für einen Einfluss auf unsere Gesellschaft? Beiträge zur Entwicklung von Linux zum Beispiel sollten immer als dem Gemeinwohl dienend betrachtet werden. Bezüglich der Software-Pflege gibt es verschiedene Sichtweisen. Es gibt Unternehmen, die sehr liberal Beiträge zu Linux-Projekten machen, ohne zu monetarisieren, die die Software zum Beispiel selbst verwenden wollen. Interessanterweise ist Microsoft da ein gutes Beispiel. Andere wie Amazon monetarisieren sehr stark. Für die Entwicklung gibt es eine offene Lizenz, das ist erst mal immer ein Beitrag zum Gemeinwohl, der positiv ist. Beiträge zu freier und offener Software tragen grundsätzlich positiv zum Gemeinwohl bei, weil sie gemeinsam den Stand an frei zugänglichen Technologien definieren. Aber ein Beitrag zum Gemeinwohl macht noch keine Gemeinnützigkeit, dafür muss die Technologie auch allen zur Weiterentwicklung offenstehen.

Gibt es auch Lizenzen, bei denen Sie sagen, die würden wir jetzt nicht mit hineinnehmen?

Grundsätzlich ist die Open-Source-Definition auch hier ein guter Maßstab. Es gibt die, die die Verpflichtung mit sich bringen, dass man seinen eigenen Source Code auch unter die gleiche Lizenz stellen muss. Aber die vier Grundrechte, die quasi allen gegeben werden, gelten für alle akzeptierten Open-Source-Lizenzen. Jede Open-Source-Lizenz macht aus der lizenzierten Software ein öffentliches Gut. Schwierigkeiten hätte ich zum Beispiel eher mit Lizenzen, die Patentrechte ausschließen. Diese sind auch zu Recht nicht als Open-Source-Lizenzen anerkannt, weil sie das Ergebnis nicht jedem zu jedem Zweck zur Verfügung stellen. Viele neueren Lizenz-Erfindungen versuchen genau das auszuhebeln. Sie sind nicht ausreichend, um aus Software ein öffentliches Gut zu machen.

Für mich ist eines der Grundprinzipien von Open Source, dass die Mitwirkung freiwillig und jedem offen ist. Dass jeder, der etwas beiträgt, das aus eigenen Stücken tut. Und ja, es gibt diese fast schon klassische Diskussion um vertikale Integration, wo die Integratoren (oft Cloud Provider) wenig in die Entwicklung zurückgeben. Aber es hat auch Gründe, die ganz praktisch sind. Zum Beispiel, dass sie manchmal gar nicht wollen, dass sich die Software schnell weiterentwickelt, weil sie diese in ihrem Produkt integrieren. Sie wollen die Software weitestgehend stabil und fehlerfrei haben, aber nicht unbedingt ständig neue Funktionen oder neue Versionen entwickeln.

Es gibt auch Bedenken, dass die Gemeinnützigkeit ausgenutzt wird. Wie lässt sich dem vorbeugen?

Es besteht die Gefahr, dass eine Art von Openwashing stattfindet. Erst durch eine offene Kollaboration steht die Mitwirkung wirklich jedem offen. Ein offener, kollaborativer Prozess erfordert eine neutrale Governance, bei der jeder freiwillig mitwirken kann. Diese freiwillige Beteiligung ist ein Schlüsselelement dessen, was wir als "offene Governance" (Open Governance) bezeichnen. Dieses Prinzip wird von großen Open Source Foundations verfolgt, da es ihr Grundprinzip ist. Im Gegensatz dazu ist bei einem Unternehmen, das eine Software veröffentlicht, aber keine weiteren Änderungen von Dritten zulässt, weil es sich um ein kommerzielles Produkt handelt, keine offene Governance gegeben. Solch ein Projekt ist zwar von der Lizenz her Open Source, aber der Entwicklungsprozess steht nicht allen Interessierten offen. Open-Source-Lizenzierung und ein offener Entwicklungsprozess, also eine offene Zusammenarbeit basierend auf Freiwilligkeit, müssen Hand in Hand gehen, wie z. B. bei der Linux Foundation, um ein Open-Source-Projekt als gemeinnützig zu betrachten.

Wir haben in den letzten Monaten einige Unternehmensentscheidungen gesehen, bei denen Open-Source-Produkte zu proprietären umgewandelt wurden, das ist ein Beispiel dafür. Wenn ein Unternehmen alle Rechte an der Software hat, dann können sie zum Beispiel die Kunden anfüttern. Und wenn die Software dann in die Infrastruktur integriert ist, können sie umschalten und sagen, wir stellen das unter eine proprietäre Lizenz. Und das ist für mich eine Schwierigkeit, die mit offener Kollaboration nicht auftritt. Ich würde die Gemeinnützigkeit tatsächlich an eine offene Kollaboration knüpfen.

Gibt es Gründe, warum Open Source hier nicht als gemeinnützig anerkannt ist?

Reine Softwareentwicklung ist in fast keinem Land ein Grund für Gemeinnützigkeit. Es muss immer mit einem Zweck verbunden sein, so ist es in Deutschland auch. Es soll ein gemeinnütziger Zweck verwirklicht werden, Volksbildung wird oft als Aufhänger verwendet. In den USA ist es ähnlich, das kann man eigentlich vergleichen. Es gibt auch dort die gemeinnützigen Organisationen, aber da legt es auch die Steuerbehörde fest. Die Linux Foundation hat eine Tochtergesellschaft, die heißt Linux Foundation Charities und dort sind alle gemeinnützigen Projekte aufgehängt.

Ein Problem ist immer, dass mit der Gemeinnützigkeit Einschränkungen bei der Geschäftstätigkeit einhergehen, etwa Dokumentationspflichten oder Einschränkungen bei erlaubten Tätigkeiten (wie etwa das allseits beliebte Verkaufen von Merchandise). Und deswegen setzen wir nicht die gesamte Dienstleistung als gemeinnützig auf, sondern nur einen Teil. Eine der größten Schwierigkeiten in Deutschland ist die Angabe eines gemeinnützigen Zwecks, der einen festgelegten Katalog entnommen werden muss.

Ein Beispiel dafür ist die Mastodon GmbH, der die Gemeinnützigkeit entzogen wurde, weil sie auch nicht-gemeinnützige Aktivitäten durchgeführt hat. Das Finanzamt hat Mastodon ohne Angabe von Gründen die Gemeinnützigkeit entzogen. Das heißt, notwendig wäre an der Stelle, Vorgaben zu machen, welche Geschäftstätigkeit dann als gemeinnützig gesehen werden kann. Im KDE-Verein, der in Deutschland sitzt, habe ich damals an der Gemeinnützigkeit gearbeitet. Da mussten wir uns mit Dingen wie Event-Organisationen, Merchandise-Shops oder ähnlichem teilweise getrennt aufstellen, weil die nicht mehr als gemeinnützig gelten. Es wäre hilfreich, wenn der Gesetzgeber klarer Vorgaben machen könnte.

Und wie wird sich die Arbeitsweise bei der Linux Foundation ändern, wenn es für den Verein die Gemeinnützigkeit auch in Deutschland gibt?

Wir haben zwei Standbeine, eines in Kalifornien und eines in Brüssel. Das heißt, wenn sich in Deutschland das Gemeinnützigkeitsrecht ändert, betrifft das dann Unternehmen, die an uns Mitgliedsbeiträge leisten. Und das ist dann auch eine steuerliche Frage. Und für Unternehmen, die an uns Mitgliedsbeiträge leisten, sind diese Beiträge auch jetzt schon Betriebsausgaben. Das heißt, die sind auch so abzugsfähig. Wir haben eine sehr diverse, internationale Mitgliedschaft, viele auch aus Deutschland. Das heißt eben, wenn die Gemeinnützigkeit in Deutschland anerkannt wird, betrifft das bei uns nur einen Bruchteil.

Deswegen denke ich, das Thema ist interessanter, ist wichtiger für Community-getriebene Vereine gerade in Deutschland. Ich würde mir wünschen, dass es für die Community das Leben leichter macht. Und dass wir denen auf diese Weise auch Anerkennung geben. Auch wenn sich damit für die Linux Foundation nicht wahnsinnig viel ändert, freuen wir uns, wenn die Open-Source-Community hier vom Gesetzgeber unterstützt wird und Anerkennung findet.

Wie sieht Ihrer Ansicht nach eine nachhaltige Open-Source-Entwicklung aus?

Zuallererst muss man verstehen, was die Natur eines Open-Source-Projekts und was die Natur eines Unternehmens ist. Ein Open-Source-Projekt ist definitionsgemäß nicht differenzierend. Wir geben es frei heraus, sodass es für jeden Zweck genutzt werden kann. Was die Software kann, ist für niemanden ein Alleinstellungsmerkmal für die Benutzererfahrung. Jedem anderen, der die Software nutzt, steht die gleiche Funktionalität zur Verfügung. Es spielt auch nicht unbedingt eine besondere Rolle, wer die Software geschrieben hat. Beiträge müssen also aus freien Stücken geleistet werden, und ohne die Erwartung einer konkreten Gegenleistung.

Als Nutzer bin ich den Kernentwicklern dankbar, aber ich muss keine Beziehung zu den Personen haben. Es gibt keine Verpflichtung, etwas zurückzugeben. Das geht in zwei Richtungen. Man kann als Anwender dann nicht sagen, der Bug muss bitte bis Montag gefixt werden. Wenn der Maintainer sagt, er hat jetzt keine Zeit, dann passiert es nicht. Er wird aber auch nicht verhindern, dass jemand anders am Code arbeitet. Das ist offene Kollaboration. Der Maintainer darf sich dann aber auch nicht über die Änderungen beschweren. Das ist die Natur von Open Source – die Mitwirkenden und die Anwender müssen nicht miteinander verhandeln.

Als Argument gegen Open Source wird oft gesagt, dass diese aus solchen Gründen nicht sicher ist. Was sagen Sie dazu?

Dieses Maintainer-Problem haben wir natürlich. Das ist eine komplexe Sache. Wenn sich die Natur des Projektes ändert, wenn aus einem Hobbyprojekt etwas Größeres wird und sich die Governance aber nicht ändert, dann ist das nicht lange tragbar. Dann ist es wichtig, dass auch anderen Raum gegeben wird, um am Code zu arbeiten und eine Community aufzubauen. Dafür müssen sich die ursprünglichen Entwickler manchmal zurückziehen, zum Beispiel, wenn sie das etwa zeitlich nicht mehr schaffen. Vielen fällt es aber schwer, ihr "Baby" abzugeben. Eine Foundation ist dann besser geeignet, um das Projekt fortzuführen.

Sicherheit ist für mich ein Supply-Chain-Thema. Kommerzielle Anbieter integrieren Open-Source-Komponenten in ihre Produkte, dadurch kommen sie beim Nutzer an. Beim Thema Security muss geprüft werden, an welcher Stelle die Verantwortung dafür eigentlich aufgehängt wird. Und das funktioniert auch nicht bei der Community, weil die Community fast nie kein End-User-Produkt-Anbieter ist, sondern Bausteine entwickelt. Wenn die Bausteine in kommerziellen Produkten verwendet werden, dann muss man darauf achten, dass diese konkreten Produkte sicher sind. Deswegen halte ich das Thema Sicherheit für essenziell. Software-Sicherheit ist ein wichtiges Thema, und es ist auch notwendig, dass das regulatorisch und ökonomisch sinnvoll abgebildet wird (siehe den Cyber Resilience Act und die Product Liability Directive).

(mack)