Open Source Software Lizenzen erklärt

Der Rechtsstreit zwischen Palantir und dem Onlinemagazin Republik zeigt die strategische Bedeutung von Datenhoheit. Trotz technischer Stärken verzichtet die Schweizer Armee auf die Software. Risiken wie Kontrollverlust und möglicher Zugriff ausländischer Behörden wiegen schwerer als Effizienzgewinne. Compliance wird damit zum wirtschaftlichen Faktor.

Im Zentrum steht strategische Souveränität durch Open Source und das neue EMBAG-Gesetz. Künftig gilt für die Bundesverwaltung: Public Money, Public Code. Open Source ermöglicht Kontrolle über Code und Daten, fördert Zusammenarbeit und spart Kosten durch Mehrfachnutzung. Gleichzeitig braucht es klare Governance, Lizenzmanagement und Audits.

1. Digitale Souveränität ist kein politisches Schlagwort, sondern aktives Risikomanagement gegen Vendor-Lock-in und Kontrollverlust.

2. Open Source bietet strategische Vorteile, erfordert jedoch professionelles Lizenzmanagement und klare Prozesse.

3. Unternehmen und Behörden sollten Abhängigkeiten prüfen, E-ID-Potenziale nutzen und eine saubere Open-Source-Governance etablieren.

Dani: Herzlich willkommen zur 21. Ausgabe von unserem Zweiblog-Format und immer daran denken: teilen, liken und kommentieren.

Erich: Das hilft uns. Wie jemand anderes immer sagt: Der Algorithmus ist unser Freund.

Dani: Starten wir mit der ersten News von heute. Nämlich die Strategie «Digitale Schweiz 2026», die vom Bundesrat verabschiedet worden ist. Hand aufs Herz, lieber Erich. Ist das jetzt nur Papier für die Schublade oder steckt da auch echter Business Value dahinter für einen Mittelstand?

Erich: Es ist mehr wie ein Papier. Der Fokus liegt ganz klar auf der digitalen Souveränität und auf der E-ID. Das ist ein direkter Auftrag an die Wirtschaft, kritische Abhängigkeiten zu reduzieren.

Dani: Souveränität, das klingt doch echt teuer. Warum sollen jetzt CEOs Geld für Unabhängige Software investieren oder in die Unabhängigkeit investieren, wenn die Standardlösungen und die Hyperscaler bequemer sind? Es ist doch viel einfacher. Wo liegt hier eigentlich der Benefit?

Erich: Der Mehrwert darauf liegt in der Risikominimierung und in der Kostenkontrolle. Der Bund will explizit einen Vendor-Lock-in vermeiden, also die Bindung an einen bestimmten Anbieter. Wer auf proprietäre Blackboxen setzt, n die man nicht einsehen kann, verliert am Ende die Preishoheit und Handlungsfähigkeit, insbesondere wenn eine Krise eintritt.

Dani: Du sprichst ganz klar auf Open Source an, aber die Individualsoftware hat doch einen Ruf, pflegeintensiv zu sein. Wie rechtfertigen wir hier die Eigenentwicklungskosten oder die Entwicklungskosten gegenüber Lizenzmieten?

Erich: Durch Effizienzgewinn im Prozess. Der Beirat des Bundesrates fordert explizit mehr Förderung von Open Source Software. Mit offener Individualsoftware unterstützt du direkt deinen Kernprozess dort wo du dich abhebst, differenzierst, statt deine Firma in eine Standardsoftware umzubiegen. Deine Prozesse an die Software anzupassen, nicht umgekehrt. Das haben wir auch schon in der letzten Episode 20 diskutiert und behandelt. Wann macht Individualsoftware Sinn? Und dort haben wir auch eine Checkliste dabei, die ein bisschen aufzeigt, wie man herausfinden kann, ob Individualsoftware etwas für mich ist.

Dani: Auch ein valider Punkt, den du hier ansprichst. Schauen wir doch ganz kurz noch auf die E-ID, von der haben wir es auch schon gehabt, ein weiteres Kernthema 2026. Ist das jetzt nur ein Bürgerservice vom Bund oder ist das wirklich auch ein Umsatztreiber für die Unternehmen?

Erich: Für Unternehmen, die Umsätze mit Identifikationsleistungen erzielen, stellt dies einen Umsatztreiber dar. Die E-ID schafft für sie eine staatlich garantierte Vertrauensinfrastruktur. Das bedeutet, dass Unternehmen ihre Onboarding-Prozesse oder gesetzlich vorgeschriebenen Identifikationspflichten effizienter gestalten können.

Wenn ich heute mit einer Person eindeutig identifiziert kommunizieren möchte, muss ich häufig mein Geburtsdatum, meine Adresse oder weitere persönliche Angaben machen, damit mein Gegenüber sicher sein kann, dass ich tatsächlich die Person bin, für die ich mich ausgebe. Gleiches gilt beim Kauf von Produkten in Online-Shops, die eine Altersprüfung erfordern, etwa bei Alkohol, Spielen, Filmen oder ähnlichen Angeboten.

In solchen Fällen ergeben sich klare Vorteile, da diese Prozesse vollständig automatisiert werden können. Dadurch sinken auch die Prozesskosten. Diesen Aspekt haben wir bereits in Episode 13 diskutiert.

Dani: Wir sind immer etwas in der Zeit voraus. Konkret aber jetzt für morgen, wenn man noch nicht in der Zeit voraus ist: Was muss der CEO jetzt machen, um aus dieser Strategie oder dieser Idee einen Wettbewerbsvorteil zu schaffen?

Erich: Erstens: ein Audit der Abhängigkeiten durchführen. Prüfen, wo hohe Lizenzkosten anfallen und wo Datenhoheit oder die Hoheit über den Code ein zentraler Faktor des Geschäftsmodells sind. Das sind potenzielle Kandidaten für Open-Source-Lösungen oder für Individuallösungen auf Basis von Open-Source-Software.

Zweitens: im Hinblick auf die E-ID die entsprechenden Voraussetzungen schaffen. Für Kunden mit einer E-ID: Das Identifizieren, und zwar sicher und ohne Medienbruch, hat gerade in Onlineshops einen massiven Vorteil gegenüber der Konkurrenz, wenn ich Produkte habe, die das benötigen. Und vielleicht noch ein Hinweis: Aktuell sieht so aus, wie die E-ID im Verlauf des zweiten Halbjahres eingeführt wird.

Dani: Da sind wir gespannt. Gehen wir gleich zur zweiten News über. Was haben wir bereit?

Erich: Bei der zweiten News geht es um Palantir und das Schweizer Onlinemagazin Republik.

Dani: Ihr habt es vielleicht gesehen, Palantir verklagt die Republik wegen einer Recherche über die gescheiterten Regierungsgeschäfte oder besser gesagt die Beschaffungen. Ein Mediastreit, Erich, oder ist dort viel mehr hinter dem ganzen Thema?

Erich: Ja, da ist viel mehr dahinter. Der Kern dahinter ist ein Bericht des Armeestaabs, der die Republik aufgearbeitet hat. Markiert eine strategische Zäsur im Umgang mit US-Datenplattformen. Und das in der sensitiven Schweizer IT-Landschaft.

Dani: Die Armee verzichtet auf die Software, obwohl sie diese Technik als beeindruckend klassifiziert haben. Lassen wir dort nicht ein massives Effizienzpotenzial auf der Strecke liegen?

Erich: Kurzfristig ist das vielleicht so, aber die Analyse zeigt, die Risiken sind viel grösser oder wiegen schwerer auf. Es geht um den Verlust der Datenhoheit und theoretisch Zugriff durch US-Dienste auf diese Informationen.

Dani: Palantir übrigens bestreitet das vehement und verweist auf technische Audits. Trotzdem, was lernen wir daraus für Business Case im Mittelstand?

Erich: Dass Compliance heute ein harter ökonomischer Faktor ist. Wenn die Armee Vendor-Lock-in- und Souveränitätsrisiken höher gewichtet als die Features einer Applikation, dann ist das ein Signal für jeden Verwaltungsrat in einem Unternehmen oder für verantwortliche Behörden.

Dani: Heisst das jetzt, Finger weg von US-Lösungen? Das ist doch in dieser globalisierten Wirtschaft unvorstellbar.

Erich: Das kann man nicht so pauschal sagen. Aber für Kernprozesse in meinem Unternehmen und dort, wo sensible Daten gespeichert oder verarbeitet werden, ist es sicher wichtig, zum Beispiel mit einer Individualsoftware auf Open-Source-Basis zu arbeiten, bei der ich weiss, wie die Daten verarbeitet werden und wo sie liegen, um die Abhängigkeiten zu reduzieren und daraus eine Absicherung zu haben.

Dani: Individualsoftware ist nicht nur eine teure Eigenentwicklung oder ein endloses Projekt, hoffe ich doch. Rechnet sich das dann gegen so einenSuite auf?

Erich: Die Lizenzsoftware kostet immer mehr und wird immer teurer. Je nachdem muss ich Anpassungen machen, die individuell auf mich zugeschnitten sind. Der Unterschied ist aber bei offenen Standards oder bei einer Individualsoftware auf offenen Standards gehört der Code und die Daten mir. Das heisst, du kaufst nicht eine Blackbox, sondern du investierst in deine eigene Lösung, die dir als Unternehmen gehört.

Dani: Das heisst, die Kontrollen über Code und Daten liegen bei mir und das ist auch dementsprechend der Asset Value vom Ganzen und ich kann alles anpassen, was ich brauche.

Erich: Wer proprietäre Silos baut, riskiert längerfristig seine Handlungsfähigkeit. Der Fall zeigt: Digitale Souveränität ist kein politisches Schlagwort, sondern Risikomanagement.

Dani: Wie sieht das für Behörden und NPOs aus?

Erich: Wenn selbst der Bund Cloud-Lösungen zögerlich anschaut oder einführt, dann müssten auch öffentliche Stellen oder die öffentliche Hand auf auditiablere und transparente Systeme setzen, um das Vertrauen bei der Bevölkerung oder den Bürgern nicht zu verspielen.

Dani: Es dreht sich wieder einmal um Daten, Erich. Schon letztes Jahr hat sich alles um Daten, Code und die ganze Infrastruktur gedreht. Und kommen wir doch gleich zum nächsten Elefanten, unser heutiges Hauptthema: Strategische Souveränität. Strategische Souveränität durch Open-Source-Lizenzen und Business Case.

Wir starten mit dem Elefanten, der hier im Raum steht, nämlich dem neuen Bundesgesetz der EMBAG (Bundesgesetz über den Einsatz elektronischer Mittel zur Erfüllung von Behördenaufgaben). Die Bundesverwaltung muss Software nun als Open Source veröffentlichen, wenn sie etwas umsetzt.

Erich, ist das jetzt Bürokratie oder ein echter Marktöffner, eine Chance? Was ist es?

Erich: Das EMBAG ist ein massiver Game-Change. Mit Artikel 9 des EMBAG gilt: Public Money, Public Code. Was die Öffentlichkeit zahlt, soll sie auch nutzen können in Form von Code. Der Staat wird somit vom reinen Käufer zum Mitgestalter eines offenen Ökosystems.

Dani: Aber der Begriff Open Source ist ja recht schwammig. Viele denken an Gratis-Software wie Google und Co. Was ist denn der harte Kern, der meine IT-Strategie wirklich verbessert?

Erich: Es geht um das Schlagwort, oder fast schon Passwort könnte man sagen in der Schweiz, digitale Souveränität. Du besitzt die Kontrolle über Code und Daten, wie wir das vorhin schon diskutiert haben. Keine Blackboxen, keine Abhängigkeit von einzelnen Anbietern, kein Vendor-Lock-in.

Und du kannst den Code selbst anschauen und anpassen, wie du es benötigst. Unabhängig von den Lösungen grosser Anbieter.

Dani: Aber wenn der Code veröffentlicht wird, stellt sich immer wieder die gleiche Frage: Man sagt, dann kann ja jeder sehen, wie es gemacht ist, und das sei gefährlich, weil andere hineinschauen können.

Erich: Auf der einen Seite sieht man rein, auf der anderen Seite gibt es aber ganz viele Leute, die etwas Positives daraus nehmen und helfen, dass der Code besser wird oder um schneller Sicherheitslücken zu finden.

Dani: Das hatten wir ja bei den Browsern immer so. Die sind immer Open Source gewesen.

Erich: Und Open Source haben wir auch in Episode 6 als Thema diskutiert, was Vor- und Nachteile der Open Source Software sind.

Dani: Unabhängigkeit zieht in diesem Fall immer. Schauen wir doch kurz in die Praxis.

Wenn ich Software freigebe - oder eben nicht - laufe ich dann nicht in eine ganze Welt von Lizenzen? Wo fangen wir hier an?

Erich: Das ist ein heikles Thema. Da muss man wissen, was man macht. Man kann hier drei Modelle unterscheiden.

Wenn man recherchiert, findet man im Wesentlichen zwei Modelle: das permissive Lizenzmodell und das Copyleft-Modell bei Open-Source-Software.

Daneben gibt es noch ein drittes Modell, häufig als Open-Core-Lizenzmodell bezeichnet. Dabei wird die Software meist von einem Anbieter entwickelt, der eine Open-Source-Version bereitstellt, diese jedoch zusätzlich in einer erweiterten, kommerziellen Variante vertreibt.

Die gewählte Lizenz bestimmt im Kern, wie mit dem Code umgegangen werden darf: ob und unter welchen Bedingungen Dritte ihn proprietär nutzen können, ob sie ihn weitergeben oder verändern dürfen, wie Änderungen geteilt werden müssen und ob kommerzielle Einschränkungen bestehen.

Dani: Lassen wir uns das mal exemplarisch beleuchten. Ich will maximale Verbreitung für meine Schnittstellen. Damit sie zum Industriestandard wird, welche Lizenz nehme ich, wenn ich so etwas veröffentliche?

Erich: Du nimmst die permissive Lizenz – also eine Bewilligungslizenz wie MIT oder Apache 2.0. Diese erlauben grundsätzlich eine sehr freie Nutzung, auch den Einbau in proprietäre, geschlossene Produkte.

Das senkt die Hürde für die Adoption massiv, weil Unternehmen die Software ohne weitgehende Verpflichtungen in eigene Lösungen integrieren können.

Dani: Wenn ich verhindern will, dass ein Cloud-Gigant meine Arbeit nimmt, sie als Service verkauft und mir nichts zurückgibt. Wovor habe ich denn dort eigentlich Angst?

Erich: Dafür nimmst du die Copy-Left-Lizenz, wie GPL oder besser AGPL. Das heisst, wer den Code modifiziert, muss die Verbesserungen auch wieder zurückspielen und unter der gleichen Lizenz veröffentlichen. Dass diese auch wieder verwendet und weiterverbreitet wird, und nicht kommerziell genutzt wird.

Dani: Gibt es dann einen viralen Effekt, wenn ich einen GPL-Code in meiner eigenen Software einsetze? Muss ich dann mein ganzes Produkt offenlegen? Das wäre dann wieder ein Risiko für den Teil, den ich jetzt gemacht habe?

Erich: Ja, das ist dann die sogenannte starke Copy-Left-Lizenz. Zwingt die Offenheit, aber dort muss man aufpassen, es gibt Abstufungen. Der LGPL erlaubt das Verlinken der Bibliotheken ohne aber das Hauptprogramm zu infizieren.

Dani: Dann gibt es ja auch noch Open Code, wie z.B. bei Shopware. Eine Firma entwickelt eine Software und bietet sie als Open Source Version an. Shopware, Magento verbieten aber anderen Firmen die Software kommerziell zu nutzen. Jetzt komme ich gar nicht mehr draus.

Erich: Es gibt immer mehr Firmen, die eigene Lizenzmodelle definieren und zusätzliche Bestimmungen festlegen. Bei Shopware wurde beispielsweise geregelt, dass ab einem Online-Shop-Umsatz von über 1 Mio. die Open-Source-Version nicht mehr verwendet werden darf.

Hier ist es entscheidend, die konkreten Bedingungen hinter solchen Lizenzmodellen genau zu prüfen. Für mich sind das nicht zwingend klassische Open-Source-Modelle. Man kann die Software zwar nutzen, doch häufig handelt es sich eher um ein Marketinginstrument, um Verbreitung und Marktdurchdringung zu fördern.

Sobald bestimmte Schwellenwerte überschritten werden, ist eine kommerzielle Lizenz erforderlich und es fallen entsprechende Kosten an. Deshalb muss man sehr genau hinschauen, welche Rechte und Pflichten tatsächlich gelten.

Dani: Gut, aber wir sind ja hier in der Schweiz und in Europa und gibt es da nicht rechtliche Stolpersteine mit den US-Lizenzen wie der GPL? Die kommt ja nicht von uns. Wie ist das mit Haftung und Urheberrecht?

Erich: Behörden sollten in diesem Zusammenhang die EUPL, also die European Union Public License, prüfen. Sie ist mit dem Schweizer Recht kompatibel, mehrsprachig ausgestaltet und berücksichtigt auch Software-as-a-Service-Modelle.

Das kann im Gesamtbild einen strategischen Vorteil darstellen.

Dani: Lass mich mal kurz über die Risiken sprechen, wenn ich von diesem Urwald oder diesem grossen Elefanten jetzt vielleicht ein wenig mehr sehe, nachdem was du erklärst, aber immer noch nicht durchsehe. Wie ist das jetzt, wenn ich Open Source nutze und ich habe das Gefühl, es ist alles gut. Wer garantiert mir dann, dass ich hier nicht irgendeine Lizenzverletzung begehe? Und ein Audit, das ich dann machen lasse, ist vielleicht sehr teuer.

Erich: Die Compliance ist hier Chefsache und du brauchst diese Lizenz-Audits. Hier gibt es aber Tools, die dabei helfen. Entwickler, die ich nutzen kann, die den Code durchforsten und schauen, ob dort Lizenzverletzungen vorliegen. Hier wird der Code so entsprechend gescannt und ein Report darüber generiert.

Aber auch damit hat man natürlich keine 100%ige Sicherheit. Das Ganze muss zusätzlich durch die Offenlegung des Codes getragen werden, was bei Open Source grundsätzlich kein Problem ist.

Man muss die Einhaltung unterstützen können, etwa durch Audits und entsprechende Prüfmechanismen. Und der Softwareentwickler, der die Software programmiert, muss den gesamten Prozess transparent gestalten und im Entwicklungsprozess geeignete Kontrollen einbauen.

So kann verhindert werden, dass während der Entwicklung unbemerkt Lizenzverletzungen entstehen, die erst im Nachhinein festgestellt werden.

Dani: Das heisst für mich auch: Es braucht klare Prozesse, und vor allem einen Partner wie CS2, die für euch etwas entwickeln und bereits in der Umsetzung darauf achten, dass alles sauber, transparent und lizenzkonform abläuft.

Aber gehen wir zurück zur zentralen Frage: Wo liegt der Effizienzhebel? Warum soll ich Code teilen? Du hast eingangs gesagt, das sei ein echter Game-Changer, wenn Code geteilt wird, insbesondere dort, wo die Öffentlichkeit bezahlt hat.

Und ja, ich habe in meinem Fall vielleicht dafür bezahlt, es war teuer, und nun soll ich diesen Code freigeben. Warum sollte ich das tun? Wo liegt der Nutzen?

Erich: Weil du dort natürlich Synergien nutzen kannst. Wie du bei den Daten immer gesagt hast: Einmal entwickeln, mehrfach nutzen. Ich teile eine Basiskomponente und die Weiterentwicklung von dem Ganzen, das ist dann noch das, was oben drauf kommt. Und das kann ich nur machen, wenn der Code frei ist und zur Verfügung steht. Das spart natürlich auch massive Entwicklungskosten durch Community Feedback oder Weiterentwicklung von anderen, die das machen.

Dani: Ich will nicht sagen, dass das neu ist. Seit Jahren kennen wir das bei TYPO3, dort spielt man Erweiterungen und Verbesserungen an die Community zurück. Als CS2 kennen wir dieses Prinzip von Haus aus.

Aber das Prinzip „Teilen statt neu entwickeln“ erhält mit dieser EMBAG-Geschichte nun ein neues Gewicht. Wenn ein Kanton eine Lösung für ein bestimmtes Anliegen entwickelt, diese finanziert und sie anschliessend kostenlos anderen öffentlichen Stellen zur Verfügung stellt, wird das in manchen Fällen sicher noch Diskussionen auslösen.

Erich: Ja, davon gehe ich ebenfalls aus. Es wird sicher Kantone und Departemente geben, die offensiver unterwegs sind, digital weiterentwickelt oder organisatorisch reifer als andere. Es gibt Bereiche, die bereits stark digitalisiert sind, andere weniger.

Was ich im EMBAG oder im weiteren Kontext bislang nicht klar geregelt sehe, ist die Frage der Kostensituation. Konkret: Wenn ein Kanton viel Geld in die Entwicklung einer Lösung investiert und andere Kantone oder Stellen später davon profitieren, ohne sich an den Entwicklungskosten zu beteiligen, entsteht ein Spannungsfeld. Der eine zahlt, die anderen nutzen.

Hier sehe ich durchaus ein gewisses Risiko für das gesamte EMBAG-Vorhaben. Diese Verteilungs- und Finanzierungsfrage wird vermutlich noch diskutiert und geklärt werden müssen.

Vielleicht hat ja jemand aus der Zuhörerschaft bereits Einblick in entsprechende Modelle oder Lösungsansätze, die wir nicht kennen. Wenn es dazu Erfahrungen oder Ideen gibt, dürfen diese gerne einfliessen, wir sind dankbar für entsprechende Hinweise in den Kommentaren.

Dani: Es ist wieder die Liberalität der Schweiz, die gefragt ist, dass jeder Kanton etwas entwickelt. Und wenn sie noch miteinander sprechen und kooperieren, dann kann jeder eine andere Ecke verbessern.

Erich: Langfristig, ich sage jetzt in 20 Jahren, wird sich das ungefähr ausgleichen. Die Frage ist, wie schnell jene, die noch nicht so digitalisiert sind oder das Thema noch nicht so verstehen, vorankommen und ob die anderen nicht irgendwann plötzlich ein Problem haben.

Das kann man allenfalls mit einem Zahlungsausgleich zwischen den Kantonen regeln oder mit einem ähnlichen Mechanismus. Aber da gibt es sicher andere Spezialisten, die dazu eine fundierte Meinung haben und weiterhelfen können.

Dani:  Schauen wir uns noch einmal die ganze Geschichte an. Für die Schweizerbehörden ist es Pflicht, für Firmen ist es eine Chance. Wie setz ich das morgen konkret um?

Erich: Es braucht als Unternehmen oder Behörde eine saubere Open-Source-Governance. Das kann beispielsweise auf Basis des Status erarbeitet werden. Dort ist man recht zügig unterwegs, und es gibt zahlreiche Unterlagen, allerdings sind diese eher verteilt verfügbar.

Vielleicht wäre es sinnvoll, dazu eine Zusammenfassung im Blog zu erstellen, in der man die relevanten Inhalte verlinkt und bündelt.

Zentral ist jedoch, dass klar definiert wird: Was nutzen wir? Was geben wir als Open Source frei und unter welcher Lizenz oder in welcher Form? Wer pflegt das weiter? Wer betreut die Community? Wer übernimmt den Betrieb? Denn Code ohne Pflege ist letztlich totes Kapital.

Dani: Was sind jetzt die Massnahmen aus Sicht der IT-Chefs, die sich um dieses Thema kümmern, um eben nicht in eine grosse Abhängigkeit zu kommen?

Erich: Das Erste ist professionelles Lizenzmanagement. Du musst wissen, welche Lizenzierungsmodelle die Marktstandards sind, etwa permissive Lizenzen, sowie Copyleft-Lizenzen wie AGPL oder EUPL für Kernprodukte, die du vor Vereinnahmung schützen willst. Und prüfe natürlich auch Open-Core-Lizenzmodelle, sofern das für dich relevant ist.

Dani: Involviert Partner, die sich mit diesem Thema auskennen. Diese Partner positionieren sich meistens sehr digital unabhängig. Sie bieten Wartungen an, Integrationen und Haftungsübernahmen für Open-Source-Lösungen. Das machen wir seit über 25 Jahren für unsere CS2-Kunden und kümmern uns um den Teil. Darum an dieser Stelle ein kleines Werbefenster: Ruft uns an und wir sprechen über euer Projekt. Werbefenster geschlossen. Gehen wir zum Tooltip.

Erich: Eines der ältesten Tools, die ich kenne, und eines, das sehr weit verbreitet ist und eine tolle Funktionalität bietet: das Bildverarbeitungsprogramm GIMP: eine kostenlose Open-Source-Alternative zu Adobe.

Im Marketing sind visuelle Assets entscheidend, aber die Lizenzkosten für Software belasten das Budget der Marketingabteilung immer stärker. Von der Creative Suite können wir da ein Lied singen, sie wird von Jahr zu Jahr teurer und verursacht immer höhere Kosten.

Welches Tool kommt also als Alternative für die Bildbearbeitung in Frage?

Dani: Du hast es schon gesagt: GIMP ist hier natürlich ein Thema. Eine leistungsstarke Open-Source-Alternative zum Marktführer, der gerade wieder einen Preisaufschlag vorgenommen hat.

GIMP ist ein pixelbasiertes, extrem vielseitiges Tool und deckt im Grunde alles ab – von Retuschen bis hin zu komplexen Kompositionen. Also genau jene typischen Anwendungsbereiche, für die Photoshop so stark ist.

Und wie du gesagt hast: Dieser „Dinosaurier“ ist eigentlich schon sehr alt, hat sich aber immer gehalten und sich kontinuierlich weiterentwickelt.

Erich: Das klingt nach sinnvoll Kosten zu sparen und je nachdem auch strategisch sinnvoll. Aber wo liegt jetzt der konkrete operative Nutzen den Arbeitsprozess mit GIMP zu beschleunigen?

Dani: Du hast hier auch ein Profi-Werkzeug an der Hand, mit einem entscheidenden Unterschied: Es gibt kein Abo-Modell.

Du kannst, wie gewohnt, mit Ebenen, Masken und Pfaden arbeiten. Wenn sich jemand ernsthaft mit Bildbearbeitung beschäftigen will, ist das genau das richtige Tool. Zudem kannst du mit Plugins arbeiten, etwa mit BIMP, um automatisierte Batch-Prozesse durchzuführen.

Ich erinnere mich noch daran, wie wir ganze Verzeichnisse bearbeiten mussten, weil die Bilder alle korrekt durchnummeriert sein sollten. Mit GIMP kannst du hunderte von Produktbildern automatisiert durchlaufen lassen. In diesem Bereich ist es definitiv eine starke Alternative.

Erich: Ja, das skaliert wunderbar und super gut. Aber welches spezifische Problem löst es denn, das andere Standardtools zum Beispiel nicht abdecken?

Dani: Du kannst hier definitiv komplexe Retuschen durchführen, bei denen du nicht einfach schnell einer KI sagst, sie solle jemanden aus dem Bild schneiden.

Du kannst störende Objekte nahtlos entfernen, Perspektiven korrigieren oder Hintergründe professionell freistellen, gerade auch bei grossen Bildern, die du weiterverarbeiten willst, etwa für neue Layoutlinien oder grosse Plakate.

Es ermöglicht dir tiefgreifende Eingriffe in die gesamte Bildstruktur und nicht nur das schnelle Anwenden eines Filters.

Erich: Aber das sind jetzt alles super Vorteile. Gibt es auch Grenzen? Für was ist das Tool weniger geeignet? Wo ist es limitiert?

Dani: Die grösste Limitierung bei GIMP ist eindeutig der Farbraum, konkret RGB im Gegensatz zu CMYK. GIMP arbeitet primär im RGB-Modus, ähnlich wie andere Programme, die standardmässig auf RGB basieren.

Gerade CMYK ist hier ein Thema und bringt Einschränkungen mit sich. Auch native RAW-Formate sind nicht durchgehend direkt unterstützt, sodass man teilweise zusätzliche Plugins oder externe Tools benötigt.

Erich: Wie gesagt, da geht es um den Return on Investment. Was kostet das Ganze?

Dani: Ja, hier muss man wieder abwägen. Wenn du für bestimmte Aufgaben ohnehin Photoshop brauchst, bringt es nichts, komplett zu wechseln.

Wenn du aber weisst, dass du ein Tool wirklich nur für einen bestimmten Teilbereich benötigst und dir dafür die Lizenz über das Jahr sparen kannst, dann reduzierst du mit dem Einsatz von GIMP eindeutig Lizenzkosten, vorausgesetzt, du setzt es konsequent nur dafür ein.

Dann hast du hier gespart, musst aber gleichzeitig prüfen: Können meine Leute das bedienen? Können sie damit arbeiten? Die Oberfläche ist sicher etwas gewöhnungsbedürftig.

Ich würde sagen, wir haben heute bewusst ein Retro-Tool aufgegriffen. Es lohnt sich vielleicht, wieder einmal hineinzuschauen und zu sehen, wie sich dieser digitale Dinosaurier GIMP weiterentwickelt hat.

Erich: Quasi ein digitaler Dinosaurier. Kommen wir zum Abschluss der heutigen Episode. Vielen Dank fürs Zuhören. Und nicht vergessen: immer schön kommentieren. Ihr könnt uns auf YouTube abonnieren, den Podcast bei Apple oder Spotify abonnieren und uns natürlich auf LinkedIn folgen. Dann verpasst ihr keine Episode. Oder informiert euch über unsere Newsletter-Einträge.

Dani: Darum sagen wir: Bis zum nächsten Mal. Bleibt gesund. Tschüss.