18.05.2021

5 rechtliche Fehler, die Startups beim Programmieren vermeiden sollten

Von Lizenzbedingung bis Urheberrecht: Startups treten immer wieder in dieselben rechtlichen Fallen, wenn es um den Code ihres Produkts geht.
/artikel/5-rechtliche-fehler-die-startups-beim-programmieren-vermeiden-sollten
Programmieren, Code, Coding, Startup, Team
© Unsplash

GASTBEITRAG

„Das ist ein wirklich genialer Code, aber das Risiko, das wir uns damit einkaufen ist uns leider zu hoch. Wir haben uns daher für ein anderes Investment entschieden.“ Damit du bei der Verwertung deines Produktes oder einem Exit diesen oder einen ähnlichen Satz nicht hören musst, solltest du aus Legal-Sicht unter anderem die folgenden fünf Fehler beim Coding vermeiden. 

1. Vorsicht beim Einsatz von Open Source. 

Der Quellcode von Open Source Software wird kostenfrei zur Verfügung gestellt. Insbesondere für junge Programmier*innen ist diese daher interessant und wird häufig im eigenen Code integriert, doch hier ist Vorsicht geboten. 

Lizenzen für Open Source Software enthalten oft sogenannte „Copyleft“ Klauseln. Durch solche Klauseln werden Lizenznehmer*innen verpflichtet Bearbeitungen des Quellcodes ebenfalls kostenlos zur Verfügung zu stellen. Die bekannteste Copyleft-Lizenz ist GNU General Public License (GPL)

Wenn du deinen Code also auf Open Source, die zB unter GPL steht, aufbaust, ist der Copyleft Effekt auf deinen Code anwendbar. Du müsstest deinen Quellcode daher kostenfrei zur Verfügung stellen und könntest Schwierigkeiten bei der Verwertung des Codes (zB beim Verlangen von Lizenzgebühren) bekommen.

Key Takeaway: Drum prüfe, wer (Open Source) Code in die eigene Software integriert.  

Don’t forget: Selbstverständlich musst du auch bei bezahlter Software, die Lizenzbedingungen prüfen, um herauszufinden, ob eine Verwertung möglich ist.  

2. Code documentation – mehr als nur „comments“ 

Ja, die Hauptsache ist, dass dein Code funktioniert, aber für Investor*innen oft genauso relevant ist eine exakte Dokumentation des Codes. 

Um potentielle Investor*innen zu beeindrucken, empfiehlt es sich nicht nur comments zum Code hinzuzufügen, sondern die einzelnen Coding-Schritte ausführlicher zu dokumentieren, etwa in einem README file. Abhängig davon, was das Einsatzgebiet deines Codes ist, kann auch eine API Dokumentation angebracht sein. 

Key Takeaway: Documentation is key – auch aus Legal-Sicht.

3. Coding together – ein smarter Move? 

Gemeinsam Programmieren, ob in einem Angestelltenverhältnis oder als Business Partner – was so nett klingt, ist aus Legal-Sicht ohne „Sicherheitsvorkehrungen“ nicht immer ein smarter Move. 

Das Urhebergesetz sorgt zwar grundsätzlich für Programmierer*innen vor, indem es (i) einen urheberrechtlichen Schutz für Computercode vorsieht und (ii) festlegt, dass, wenn Arbeitnehmer*innen für den Dienstgeber codieren, die Nutzungsrechte an dem Programmierten auf den Dienstgeber übergehen… Also alles easy? Leider nicht! 

Das UrhG – und somit auch diese, für den Dienstgeber günstige Stellung gilt nämlich nur, wenn der Dienstnehmer ein Computerprogramm iSd UrhG programmiert. Wird nur ein Teil davon oder nur einzelne Algorithmen programmiert, könnte diese Bestimmung nicht anwendbar sein. In diesem Fall ist es notwendig eine ergänzende Vereinbarung mit dem Mitarbeiter oder der Mitarbeiterin zu treffen (das kann bspw. im Dienstvertrag passieren).  

Wenn du mit deiner Business-Partnerin oder deinem Business Partner gemeinsam codierst, kann es möglich sein, dass ihr beide sogenannte „Miturheber“ des Codes seid. Den Code könntet ihr dann nur gemeinsam verwerten – das solltet ihr jedenfalls bedenken. Bei deiner Geschäftspartnerin oder deinem Geschäftspartner wird das häufig ohnehin so gewollt sein. Rechtlich tricky könnte es werden, wenn dir eine Freundin oder ein Freund beim Codieren maßgeblich hilft und ihr euch bis dahin keine Gedanken über die Zusammenarbeit/Rechte/Verwertung gemacht habt. 

Key Takeaway: Mache dir bereits frühzeitig Gedanken, wer welche Rechte an dem Code haben soll und sichere diese Rechtsposition vertraglich ab. 

4. Achtung im Zusammenhang mit Input-Daten

Für die Entwicklung und das Training von Algorithmen sind Daten erforderlich – nur durch Beispiele kann ein Algorithmus lernen, Muster in Daten zu erkennen.

Abhängig davon, welche Daten du deinem Code fütterst, musst du weitere Bestimmungen beachten. Sobald du zum Training personenbezogene Daten verarbeiten musst, sind die Bestimmungen der DSGVO anwendbar. 

Personenbezogene Daten sind alle Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person beziehen, wie zB Name, Alter, persönliche Vorlieben, E-Mailadresse oder Foto. Häufig ist nicht ganz klar, was alles ein personenbezogenes Datum darstellen kann (etwa hat der Europäische Gerichtshof vertreten, dass in bestimmten Fällen IP-Adressen auch personenbezogene Daten sind). Bevor ihr Daten verarbeitet ist es daher wichtig zu klären, ob diese Personenbezug aufweisen. 

Eine Datenverarbeitung ist nur unter bestimmten Voraussetzungen rechtmäßig, insbesondere bei Einwilligung der betroffenen Person oder zur notwendigen Erfüllung eines Vertrags. Zudem treffen den Verarbeiter umfassende Pflichten (Datenlöschung, Berichtigung, organisatorische Vorkehrungen, etc). Die Nichteinhaltung der DSGVO ist mit hohen Geldstrafen bedroht.

Bereits im Vorfeld der Entwicklung sollte daher berücksichtigt werden, welche Daten durch einen Algorithmus verarbeitet werden und wie die Vorgaben der DSGVO ohne zusätzlichen Aufwand eingehalten werden können (Vertragliche Grundlage, Einholung von Einwilligung, etc). Ansonsten drohen später zusätzliche Kosten durch die nachträgliche Anpassung oder sogar Strafzahlungen.

Key Takeaway: Checke bereits bei der Entwicklung welche Daten du deinem Algorithmus fütterst, um später böse Überraschungen und aufwändiges Umprogrammieren zu vermeiden. 

5. Vertragliche Geheimhaltung

Wie bereits zuvor gesagt, kann es sein, dass dein Code bzw Teile davon (etwa bloße Algorithmen) keinen urheberrechtlichen Schutz genießen; doch auch für solche Fälle gibt’s eine Lösung. 

Programmcodes können nämlich ein „Betriebsgeheimnis“ darstellen und dadurch wettbewerbsrechtlich vor Mitbewerber*innen geschützt sein – doch aufgepasst, auch hier ist es wichtig bereits frühzeitig an den Schutz zu denken. Damit Code ein Betriebsgeheimnis iSd UWG sein kann, muss er folgende Voraussetzungen erfüllen: mangelnde Offenkundigkeit, Geheimhaltungswille und Geheimhaltungsinteresse.

Mangelnde Offenkundigkeit bedeutet, dass Informationen nicht allgemein bekannt sind und auch tatsächlich geheim gehalten werden. Sie dürfen nur einem beschränkten Personenkreis bekannt gemacht werden (zB Arbeitnehmer*innen, Tester*innen). Daher sollten Geheimhaltungsvereinbarungen mit Personen getroffen werden, die Zugriff auf den Code haben, um eine weitere Verbreitung zu verhindern. Häufig reicht eine bloße Geheimhaltungsvereinbarung im Dienstvertrag dazu nicht aus; das ist aber im Einzelfall zu klären. 

Der Geheimhaltungswille muss aus den äußeren Umständen zum Ausdruck kommen. Geheimhaltungsvereinbarungen oder technische Schutzvorkehrungen (Zugangsbeschränkungen, etc) lassen den Geheimhaltungswillen erkennen. 

Vertragliche oder technische Schutzvorkehrungen lassen auch das Geheimhaltungsinteresse erkennen.

Was bringt der Schutz als Betriebsgeheimnis? Die unlautere Verwertung von Betriebsgeheimnissen zu Wettbewerbszwecken ist strafbar. Zusätzlich können gegen Mitbewerber Schadenersatz- und Unterlassungsansprüche geltend gemacht werden. Gerade wenn Codes nicht die Voraussetzungen für urheberrechtlichen Schutz oder ein Patent erfüllen, ist das Wettbewerbsrecht von besonderer Bedeutung. Dafür sollten neben technischen Vorkehrungen auch vertragliche Geheimhaltungspflichten vorgesehen werden. 

Key Takeaway: Insoweit du deinen Code (auch) als Betriebsgeheimnis schützen möchtest, überlege dir bereits frühzeitig, welche vertraglichen und nicht vertraglichen (zB technischen) Maßnahmen du setzen wirst, um einen solchen Schutz zu erreichen. 

Um deinen Code bestmöglich schützen und anschließend verwerten zu können, gilt es also einiges zu beachten, wobei das wichtigste natürlich weiterhin die Funktionalität deines Codes und der Spaß am Programmieren bleibt.

Über den Autor

Martin Hanzl © EY Law
Martin Hanzl © EY Law

Martin Hanzl ist Senior Associate bei EY Law Pelzmann Gall Größ Rechtsanwälte und betreut dort Mandant*innen unter anderem zu Fragen rund um neue Technologien. Zudem ist er in der Projektleitung des Blockchain and Smart Contracts Projektes des European Law Institute tätig und publiziert regelmäßig zu rechtlichen Themen rund um neue Technologien, Blockchain, Smart Contracts und Digitalisierung.

Deine ungelesenen Artikel:
17.07.2026

„Wir bauen das FedEx fürs All“ – Ex-Iron-Dome-Projektleiterin Hilla Haddad Chmelnik im Interview

Auf der Restart Innovation Vienna erzählte Ex-Iron Dome Projektleiterin Hilla Haddad Chmelnik über ihr Space-Startup mit einem klaren Ziel: Lieferungen ins All.
/artikel/wir-bauen-das-fedex-fuers-all-ex-iron-dome-projektleiterin-hilla-haddad-chmelnik-im-interview
17.07.2026

„Wir bauen das FedEx fürs All“ – Ex-Iron-Dome-Projektleiterin Hilla Haddad Chmelnik im Interview

Auf der Restart Innovation Vienna erzählte Ex-Iron Dome Projektleiterin Hilla Haddad Chmelnik über ihr Space-Startup mit einem klaren Ziel: Lieferungen ins All.
/artikel/wir-bauen-das-fedex-fuers-all-ex-iron-dome-projektleiterin-hilla-haddad-chmelnik-im-interview
Hilla Haddad Chmelnik, Co-Founderin & CEO von Moonshot

Hilla Haddad Chmelnik, Mitgründerin von Moonshot, will die Weltraum-Logistik mit ihrem 25-köpfigen Team vorantreiben. Statt auf teure chemische Raketen setzt das israelische DeepTech-Startup auf elektromagnetische Beschleunigung. Im brutkasten-Interview spricht die ehemalige „Iron Dome“-Projektleiterin über das enorme Potenzial im All, das Scheitern in Simulatoren und was Europa von Israels Innovationskraft lernen kann.

Sie sind Luft- und Raumfahrttechnikerin, waren Projektleiterin beim Iron Dome und Generaldirektorin im israelischen Ministerium für Innovation, Wissenschaft und Technologie. Jetzt haben Sie Moonshot gegründet, ein Unternehmen, das Transporte im All per elektromagnetischer Beschleunigung statt mit klassischen Raketen anpackt. Sie sitzen da ja wirklich genau an der Schnittstelle von SpaceTech, DeepTech, Verteidigung und Politik. Wenn wir mal aufs große Ganze schauen: Wo steht SpaceTech gerade allgemein?

Für mich sind das gar keine getrennten Dinge. SpaceTech oder eigentlich der Weltraum an sich ist einfach die nächste Stufe für die Menschheit. Um Quantentechnologie, Energie oder KI wirklich weiterzuentwickeln, müssen wir ins All. Der Weltraum ist eine ganz eigene Domäne. Das ist im Grunde wie beim Internet: Wir sagen heute ja auch nicht „Internet-Tech“, das Internet ist einfach die Basis für alles andere.

Die Erde wird langsam ziemlich voll, und uns gehen hier die Ressourcen aus. Selbst wenn wir über Quantencomputing oder Smartphones reden: Dafür brauchen wir Seltene Erden. Und davon haben wir auf der Erde schlicht nicht genug.

Und Sie glauben fest daran, dass wir diese Stoffe im All finden?

Naja, sie kamen ja ursprünglich von dort, also werden wir sie auch dort finden. Wir wissen, dass es sie auf dem Mond gibt und auf Meteoriten. Und das Thema Energie ist im All ein Selbstläufer, es gibt dort keine Atmosphäre, die Sonne scheint also ununterbrochen. Deshalb reden wir ja auch über Rechenzentren im Weltraum. Warum sollte man das tun? Weil uns auf der Erde der Strom ausgeht, selbst wenn wir über Atomkraft nachdenken.

Bei erneuerbaren Energien auf der Erde hat man immer Probleme mit der Atmosphäre und dem Tag-Nacht-Wechsel. Im All hat man diese Sorgen nicht, dafür eben andere. Aber da der Zugang zum All in den letzten zehn Jahren so viel billiger geworden ist, und die Preise fallen weiter, sind die Wege jetzt frei. Wenn wir erst mal dort sind, entsteht da eine völlig neue Industrie. Alles, was Sie genannt haben, Quanten, Cyber, Mobile, Verteidigung, wird eine Anwendung im All brauchen. Deswegen ist das Ding so riesig. Und deshalb ist der SpaceX-Börsengang auch so eine Riesensache: Es ist das Fundament, die nackte Infrastruktur.

Und wo hakt sich Moonshot da ein? Welches Problem löst ihr genau?

Bei uns dreht sich alles um die Lieferkette. Es ist reine Logistik. Die Straße ins All steht ja jetzt. Und weil es diese Straßen gibt, wird es dort oben immer mehr Infrastruktur geben. Ganz egal, ob das eine private Raumstation als Fabrik ist, ein Rechenzentrum oder ein Satellit: Sie alle brauchen eine funktionierende Lieferkette. Irgendwer muss die Rohstoffe, das Wasser oder die Ersatzteile ja hochbringen. Genau das macht Moonshot.

Sie bauen also sozusagen den Lastwagen für den Weltraum? Über welchen Zeithorizont reden wir da eigentlich?

Wir bauen eher das FedEx fürs All. Wir peilen den Anfang der 30er-Jahre an, also so 2030, 2032 wollen wir ins All. Wenn man heute Fracht hochschicken will, muss man bei den aktuellen Preisen immer den ganzen Truck buchen, also eine komplette Falcon-Rakete oder ein ganzes Starship. Jedes Mal, wenn man ins All will, muss man 21 Tonnen bei einer Falcon oder 100 Tonnen bei einem Starship mitnehmen.

Wenn Sie da oben aber schon metaphorisch gesagt Ihren Kaffeeladen haben und eigentlich nur jede Woche frische Bohnen brauchen, mieten Sie ja nicht jedes Mal den ganzen Sattelschlepper. Sie brauchen einen Paketdienst, eben wie FedEx. Moonshot nutzt dafür eine ganz andere Physik: Wir arbeiten mit elektromagnetischen Beschleunigern, nicht mit chemischen Raketen. Dadurch schaffen wir dieselben Preise, aber eben für kleine Pakete. Wir schicken 200 oder 300 Kilo zum gleichen Kilopreis hoch wie das Starship. Man bestellt einfach eine Lieferung.

Sind Sie damit nicht ein Konkurrent für SpaceX?

Nein, überhaupt nicht. Wir ergänzen uns perfekt. Wir brauchen SpaceX ja, damit sie immer mehr Masse ins All schießen. Und je mehr Masse die hochbringen, desto mehr Kunden haben wir am Ende. Das ist eigentlich genau das Gegenteil von Konkurrenz. Wir wollen, dass die chemischen Raketen so oft wie möglich fliegen.

Denken Sie an einen Umzug von Europa in die USA: Es ist völlig klar, dass Sie selbst in der Business Class nach New York fliegen. Aber es macht überhaupt keinen Sinn, Ihr Sofa im Flugzeug neben sich zu setzen. Das schicken Sie im Frachtcontainer. Im Moment sind die chemischen Raketen im All die Business Class. Sie sind teuer. Und obwohl es billiger ist als vor 20 Jahren, zahlt man für jedes Kilo exakt dasselbe. Das heißt, das Kilo Astronaut, das Teuerste, was man hochschicken kann, kostet im Transport genauso viel wie das Kilo Wasser, das er trinkt. Wenn wir also einen guten Preis für das Kilo Astronaut haben, zahlen wir für das Wasser schlicht viel zu viel.

Mit unserer Technologie bei Moonshot werden wir niemals Astronauten transportieren können. In einem Frachtcontainer reist man ja auch nicht nach New York, es ist zu heiß, dauert zu lange, das hält kein Mensch aus. Unsere Anlage arbeitet mit extremen Kräften von bis zu 800 G. Das überlebt kein Mensch und auch keine empfindliche Elektronik. Aber Wasser, Treibstoff, mechanische Bauteile oder Ersatzteile wie Solarpaneele stecken das locker weg.

Wir trennen diese Fracht also von den teuren Raketen. Die Raketen bleiben für die Menschen und die feine Sensorik. So baut man eine echte Industrie auf. Eine hochentwickelte Wirtschaft braucht Häfen, Schienen, Lkw und Flugverkehr. Wenn eine Insel nur ein einziges Transportmittel hat, wird die Wirtschaft dort nie richtig laufen. Und genau das machen wir im All: Wir bauen die nächste Logistikebene neben den klassischen Raketen auf.

Entwickeln Sie diese elektromagnetische Beschleunigung eigentlich komplett neu oder nutzen Sie bestehende Technologien?

Wir bauen natürlich unsere eigene Technologie, aber wir machen keine Grundlagenforschung. Bei uns ist das reines Engineering. Die Wissenschaft dahinter hat sich im letzten Jahrzehnt quasi von selbst entwickelt, durch die erneuerbaren Energien, durch die Medizintechnik. Die Basiskomponenten wie Kondensatoren, Schalter oder spezielle Materialien, die extreme Kräfte und Hitze aushalten, gibt es alle schon auf dem Markt, und sie sind viel billiger geworden. Vor zehn Jahren hätten wir uns an diese Sache gar nicht herangewagt, weil die Technik noch nicht so weit war.

Jetzt nehmen wir diese Komponenten, die gar nicht primär für uns entwickelt wurden, und fügen sie in unserer Maschine zusammen. Wir erfinden also keine neuen Kondensatoren, sondern kaufen sie von der Stange und passen sie so an, dass sie genau unsere Spezifikationen erfüllen und bezahlbar bleiben. Es ist also kein neues wissenschaftliches Rätsel, sondern clevere Ingenieursarbeit und Integration.

Wie viel von diesem Ingenieur-Know-how bringen Sie aus Ihrer Zeit beim Iron Dome mit? Hilft Ihnen diese militärische Erfahrung bei Ihrem heutigen Projekt?

Der entscheidende Punkt ist eigentlich die ganze Philosophie der israelischen Verteidigungsindustrie. Mein Chefingenieur hat das David’s Sling-Programm geleitet, eine andere Kollegin kommt aus dem Arrow-Raketenprogramm. Die wahre Kunst in Israels Verteidigungssektor ist es, hochkomplexe Hardware und Luftfahrtsysteme extrem billig, wahnsinnig schnell und fast ohne reale Systemtests zu bauen. Und das liegt schlicht daran, dass Israel klein ist, wir haben gar keinen Platz für riesige Testgelände. Deshalb haben wir über die Jahrzehnte hinweg ganz andere Methoden entwickelt als die Amerikaner oder Europäer: Wir setzen massiv auf Simulatoren.

Sie setzen also voll auf digitale Zwillinge?

Genau. Wir bauen hochkomplexe digitale Zwillinge des gesamten Systems. Die testen wir dann im Labor im ganz kleinen Maßstab. Weil wir das so akribisch machen, können wir uns blind auf unsere Simulatoren verlassen. Wenn wir das finale, echte System bauen, wissen wir fast schon, dass es funktioniert. Reale Systemtests heben wir uns wirklich nur für den allerletzten Schritt auf. Denn wenn wir in Israel ein echtes System testen, ist das kein Experiment mehr, da muss es klappen. Wir haben weder das Geld noch den Platz für Fehler, und uns schaut ständig jeder auf die Finger. Als ich beim Iron Dome war, war praktisch jeder reale Test ein Volltreffer.

Elon Musk hat völlig recht, wenn er sagt: Wenn ein realer Test klappt, war es eigentlich kein richtiger Test, weil man nur durch Fehler lernt. Also machen wir unsere Fehler in den Simulatoren. Und genau das ist auch das Fundament von Moonshot. Wir arbeiten mit Ingenieuren zusammen, die genau diese Schule durchlaufen haben. Wir bauen ein kleines Labormodell mit gerade mal sechs Zentimetern Durchmesser und eineinhalb Metern Länge. Damit schießen wir 300 Gramm mit 100 Metern pro Sekunde ab. Aber damit beweisen wir exakt die Präzision im Mikrosekundenbereich, die Latenz und die Kontrollierbarkeit, die wir später im Großen brauchen. Wir machen das so, weil wir in Israel wegen unserer Größe gar keine andere Wahl hatten.

Schauen wir mal auf die nackten Zahlen: Wie zieht man so ein DeepTech-Startup für Weltraum-Logistik strategisch hoch? Wie viel Geld braucht man für die R&D-Phasen, wie sieht Ihr Team aus und wie lief die erste Finanzierung?

Wir sind zu dritt im Gründerteam. Am Anfang brauchten wir gar nicht so viel Geld. Unsere These war einfach: Wenn wir ein bisschen Startkapital kriegen, können wir in Israel ein großartiges Team aufbauen. Solche Leute sind schwer zu kriegen, man braucht ganz spezielle Talente. Aber wir wussten, dass Israel ein riesiges Reservoir für genau diese Talente ist. Wenn das Geld da ist, können wir sie anheuern.

Und was heißt „ein bisschen Startkapital“ im SpaceTech-Bereich?

In unserer Pre-Seed-Runde waren das 2,5 Millionen Dollar. Für Weltraumverhältnisse ist das tatsächlich wenig. Dazu kamen noch 1,5 Millionen von der israelischen Innovationsbehörde, das war unser Fundament fürs erste Jahr. Gerade haben wir unsere Seed-Runde mit rund 14 Millionen Dollar abgeschlossen. Damit finanzieren wir die Fertigstellung unseres ersten echten Produkts: die EMA (Electromagnetic Mass Accelerator). Das ist ein Beschleuniger mit 30 Zentimetern Durchmesser. Damit testen wir nicht nur unsere Simulatoren, sondern bringen auch direkt ein Produkt auf den Markt, das für den Verteidigungssektor extrem spannend ist, weil es als Testumgebung für Hyperschall-Technologie dient.

Das Verteidigungsministerium hat zu uns gesagt: „Dass ihr irgendwann ins All wollt, ist super. Aber im Moment brennen wir darauf, mit eurem Beschleuniger Hyperschall-Tests superschnell und billig durchzuführen.“ Wir feilen gerade am Vertrag, um dieses Labor gemeinsam mit ihnen aufzubauen. Für das Weltraumprojekt reicht uns eine EMA-Geschwindigkeit von 1.000 Metern pro Sekunde, aber das Ministerium braucht 2.000 Metern pro Sekunde. Die Anlage wird deshalb 25 Meter lang sein statt der geplanten 7 Meter. Mit den 14 Millionen Dollar kommen wir erst mal ein Jahr aus. Danach gehen wir in die nächste Runde.

Welches Volumen peilt ihr für die nächste Runde an und was wollt ihr damit machen?

Wir planen eine Runde von etwa 20 bis 30 Millionen Dollar. Damit wollen wir die finalen Bausteine für unseren großen Beschleuniger im All entwickeln, den Magnetar. Wichtig ist: Das Geld fließt nicht in die riesigen Baukosten der Anlage, sondern in die reine Technologie. Die massiven Errichtungskosten für das finale System, das wir übrigens in Alaska aufbauen wollen, kommen später direkt von den Kunden und Partnern, sobald die Technik steht.

Ihre ersten Kunden sind also vor allem Regierungen?

Es geht vor allem um Gelder aus Verteidigungsbudgets. In den USA unterschreibt man heute oft gar nicht direkt bei der Regierung, sondern bei privaten Firmen, die wiederum über staatliche Programme bezahlt werden. Es läuft also im Rahmen von Regierungsprojekten. In Israel arbeiten wir direkt mit dem Verteidigungsministerium zusammen, weil das Projekt dort als strategisches, nationales Gut gilt. Das Ministerium sichert den Zugang, damit die großen Player wie IAI (Israel Aerospace Industries) oder Rafael das System uneingeschränkt nutzen können.

Zum Schluss noch ein Blick auf Europa: Wir diskutieren hier ja ständig über mangelnde Wettbewerbsfähigkeit und das Problem, dass geniale Forschung viel zu selten den Weg in den Markt findet. Israel gilt da weltweit als das absolute Vorbild beim Technologietransfer. Was kann Europa von Israel lernen, wenn es darum geht, Forschung in Produkte zu verwandeln und Richtlinien zu schaffen, die Startups wie Ihres überhaupt erst ermöglichen?

Niemand wünscht sich Krieg, das ist klar. Aber der fundamentale Unterschied ist schlicht: Wir müssen innovativ sein, um zu überleben. In Europa gibt es diesen existenziellen Druck zum Glück nicht. Ihr müsst also andere Wege und Motive finden, um diesen Zug zu entwickeln und Länder wie Österreich oder Deutschland haben dafür ja durchaus gute, eigene Strukturen.

Aber der wahre Kern unseres Erfolgs und unserer Resilienz ist einfach, dass wir keine andere Wahl haben. Wir müssen abliefern, und zwar extrem schnell. Und es muss auf Anhieb funktionieren. Beim Iron Dome haben uns damals fast alle Experten weltweit gesagt, das sei technisch unmöglich. Aber wenn du in Israel lebst und ständig Raketen aus dem Gazastreifen angeflogen kommen, akzeptierst du die Aussage „das geht nicht“ einfach nicht. Es muss gehen. Und genau dieser Druck zwingt dich dazu, einen Weg zu finden, wie es klappt. Das ist es, was uns voranbringt.

Toll dass du so interessiert bist!
Hinterlasse uns bitte ein Feedback über den Button am linken Bildschirmrand.
Und klicke hier um die ganze Welt von der brutkasten zu entdecken.

brutkasten Newsletter

Aktuelle Nachrichten zu Startups, den neuesten Innovationen und politischen Entscheidungen zur Digitalisierung direkt in dein Postfach. Wähle aus unserer breiten Palette an Newslettern den passenden für dich.

Montag, Mittwoch und Freitag

AI Summaries

5 rechtliche Fehler, die Startups beim Programmieren vermeiden sollten

AI Kontextualisierung

Welche gesellschaftspolitischen Auswirkungen hat der Inhalt dieses Artikels?

Leider hat die AI für diese Frage in diesem Artikel keine Antwort …

5 rechtliche Fehler, die Startups beim Programmieren vermeiden sollten

AI Kontextualisierung

Welche wirtschaftlichen Auswirkungen hat der Inhalt dieses Artikels?

Leider hat die AI für diese Frage in diesem Artikel keine Antwort …

5 rechtliche Fehler, die Startups beim Programmieren vermeiden sollten

AI Kontextualisierung

Welche Relevanz hat der Inhalt dieses Artikels für mich als Innovationsmanager:in?

Leider hat die AI für diese Frage in diesem Artikel keine Antwort …

5 rechtliche Fehler, die Startups beim Programmieren vermeiden sollten

AI Kontextualisierung

Welche Relevanz hat der Inhalt dieses Artikels für mich als Investor:in?

Leider hat die AI für diese Frage in diesem Artikel keine Antwort …

5 rechtliche Fehler, die Startups beim Programmieren vermeiden sollten

AI Kontextualisierung

Welche Relevanz hat der Inhalt dieses Artikels für mich als Politiker:in?

Leider hat die AI für diese Frage in diesem Artikel keine Antwort …

5 rechtliche Fehler, die Startups beim Programmieren vermeiden sollten

AI Kontextualisierung

Was könnte das Bigger Picture von den Inhalten dieses Artikels sein?

Leider hat die AI für diese Frage in diesem Artikel keine Antwort …

5 rechtliche Fehler, die Startups beim Programmieren vermeiden sollten

AI Kontextualisierung

Wer sind die relevantesten Personen in diesem Artikel?

Leider hat die AI für diese Frage in diesem Artikel keine Antwort …

5 rechtliche Fehler, die Startups beim Programmieren vermeiden sollten

AI Kontextualisierung

Wer sind die relevantesten Organisationen in diesem Artikel?

Leider hat die AI für diese Frage in diesem Artikel keine Antwort …

5 rechtliche Fehler, die Startups beim Programmieren vermeiden sollten