Pariser Urteil zum Y2k38 Bug – Eine technische Einordnung

Wir haben bereits in einem früheren Blogbeitrag über das Pariser Urteil zum Y2k38 Bug berichtet, gestützt auf die Berichterstattung französischer Medien. Dabei stand insbesondere im Fokus, dass ein Gericht erstmals die Herstellerhaftung im Zusammenhang mit dem Jahr-2038-Problem bestätigt und Alstom verpflichtet hat, den Softwarefehler zu beheben.

Das Thema der Haftung ist aus unserer Sicht so brisant und weitreichend, dass wir es nicht bei der oberflächlichen Berichterstattung belassen wollten. Deshalb haben wir den Gerichtsentscheid anschliessend selbst gelesen und analysiert.

Dieser Beitrag stellt keine juristische Einschätzung dar und ersetzt keine Rechtsberatung. Die folgenden Ausführungen basieren ausschliesslich auf einer technischen Analyse des Urteilstextes im Hinblick auf das Jahr-2038-Problem (Y2K38) sowie auf der langjährigen Auseinandersetzung der BEOZ Association mit zeitbezogenen Softwarefehlern in langlebigen Systemen.

Wir führen Schritt für Schritt durch den Entscheid und ordnen die technischen Feststellungen und Annahmen so ein, dass sichtbar wird, welche Bedeutung sie auch für andere Systeme und vergleichbare Fälle haben könnten.

Daraus haben wir unser subjektives Urteil abgeleitet und die wichtigsten Punkte aus unserer Sicht zusammengefasst. Mit dem Button überspringst du die ausführliche Analyse.

Unsere Analyse bezieht sich auf das Urteil des Tribunal administratif de Paris, Nr. 1921668 (13. November 2025). Gerichtsentscheide französischer Verwaltungsgerichte sind öffentlich zugänglich und werden über staatliche Open-Data-Plattformen bereitgestellt. Der von uns analysierte Urteilstext stammt aus einer solchen offiziellen Veröffentlichung (Datum des Downloads: 10.01.2026).

Es handelt sich dabei um einen Entscheid eines französischen Verwaltungsgerichts, der nach französischem Recht grundsätzlich mit Rechtsmitteln angefochten werden kann. Unsere Betrachtung bezieht sich ausschliesslich auf den zum Zeitpunkt der Analyse vorliegenden Urteilstext und dessen Inhalt.

Gegenstand des Verfahrens ist ein Vertrag zwischen der Régie autonome des transports parisiens (RATP) und dem Zughersteller Alstom über die Lieferung und den Betrieb von Schienenfahrzeugen für den Pariser Nahverkehr. Im Rahmen dieses Vertrags stellte die RATP fest, dass bestimmte in den Fahrzeugen eingesetzte Softwaresysteme ein festes zeitliches Limit aufweisen und ab einem bestimmten Zeitpunkt nicht mehr korrekt funktionieren.

Konkret geht es um den sogenannten Y2K38 Bug (Jahr-2038-Problem). Dieser bekannte Zeitüberlauf führt dazu, dass Datums- und Zeitangaben nur bis zum 19. Januar 2038 verarbeitet werden können. Nach diesem Zeitpunkt kann es zu Fehlfunktionen oder Ausfällen kommen.

Bevor wir uns mit der Argumentation von Alstom oder den Feststellungen des Gerichts befassen, beginnen wir mit den Forderungen der RATP. Sie bilden den Ausgangspunkt des Verfahrens und zeigen, wie der Betreiber selbst die Tragweite des Y2K38 Bugs einschätzt.

«la garantie des vices cachés est engagée ; le bogue « A… » constitue une non-conformité eu égard à la durée de vie attendue du matériel roulant, qui le rend impropre à l’usage auquel la RATP le destine»

„Die Garantie für versteckte Mängel ist gegeben; der Fehler [Y2k38 Bug] stellt eine Nichtkonformität hinsichtlich der erwarteten Lebensdauer
des rollenden Materials dar, wodurch es für den von der RATP vorgesehenen Verwendungszweck ungeeignet ist.»

– Tribunal Administratif de Paris N° 1921668, 13. November 2025

Aus Sicht der RATP wird das Jahr-2038-Problem als versteckter Mangel eingeordnet. Entscheidend ist nicht der Eintritt der Funktionsstörung im Jahr 2038, sondern dass die Einschränkung der Nutzbarkeit bereits bei der Lieferung angelegt war. Damit verortet die RATP die Verantwortung klar beim Hersteller und nicht beim späteren Betrieb.

«si les vices cachés sont retenues, à titre principal, condamner la société Alstom transport SA (la « société Alstom Transport ») à la reprise des défauts affectant les logiciels de la totalité du parc de matériels roulants … à permettre à l’échéance de
2038 l’exploitation sans aucune dégradation fonctionnelle …»

„Wenn die versteckten Mängel anerkannt werden, soll die Firma Alstom Transport SA (die „Firma Alstom Transport”) dazu verurteilt werden, die Mängel der Software des gesamten Fahrzeugparks zu beheben … um bis zum Jahr
2038 den Betrieb ohne jegliche Funktionsbeeinträchtigung zu ermöglichen.»

– Tribunal Administratif de Paris N° 1921668, 13. November 2025

Zentral ist hier der Anspruch auf eine vollständige Behebung ohne funktionale Einschränkungen. Die RATP fordert keine Übergangslösung und keine Kompensation, sondern eine Korrektur, die den uneingeschränkten Betrieb des gesamten Fahrzeugparks sicherstellt.

Damit wird der Y2K38-Bug aus Sicht des Betreibers nicht als akzeptabler Kompromiss oder als planbares Betriebsrisiko behandelt. Die Verantwortung für eine uneingeschränkte Nutzbarkeit wird vollständig dem Hersteller zugewiesen.

«réaliser dans un délai de six mois un état des lieux de l’ensemble des matériels
roulants affectés par le bogue A… et le transmettre à la RATP et au tribunal»

„innerhalb von sechs Monaten eine Bestandsaufnahme aller vom Y2k38 Bug betroffenen Fahrzeuge durchzuführen und diese an die RATP und das Gericht weiterzuleiten»

– Tribunal Administratif de Paris N° 1921668, 13. November 2025

Die Forderung nach einer Bestandsaufnahme innerhalb von sechs Monaten setzt den Ausgangspunkt für alle weiteren Schritte. Bevor Lösungen entwickelt werden, soll zunächst Klarheit über den tatsächlichen Umfang des Y2K38-Bugs geschaffen werden. Das zeigt, dass zum Zeitpunkt des Verfahrens kein gesichertes Gesamtbild vorlag. Offenbar ist es schwierig, bei komplexen und über Jahre gewachsenen Systemen zuverlässig zu erfassen, welche Komponenten tatsächlich betroffen sind und wie weit sich ein solcher Fehler durch den Fahrzeugpark zieht.

«trouver dans les vingt-quatre mois suivants une solution sur un des matériels roulants et la tester puis en rendre compte à la RATP et au tribunal dans un rapport technique détaillé … d’adresser à la RATP avant le 31 décembre de chaque année un compte-rendu sur l’étendue des pistes de résolution explorées par la société Alstom Transport et l’état d’avancée de ses recherches et travaux»

„innerhalb der folgenden vierundzwanzig Monate eine Lösung für eines der Fahrzeuge zu finden und diese zu testen und anschließend der RATP und dem
Gericht in einem detaillierten technischen Report darüber zu berichten … der
RATP bis zum 31. Dezember jedes Jahres einen Bericht über den Umfang der von Alstom Transport untersuchten Lösungsansätze und den Stand der Forschungs- und Entwicklungsarbeiten zu übermitteln»

– Tribunal Administratif de Paris N° 1921668, 13. November 2025

Bemerkenswert ist, dass die RATP nicht nur ein Ergebnis fordert, sondern einen klar strukturierten und kontrollierten Ablauf vorgibt. Verlangt werden eine Lösung, deren Erprobung an einem konkreten Fahrzeug sowie eine detaillierte Berichterstattung, die sich ausdrücklich nicht nur an den Betreiber, sondern auch an das Gericht richtet.

Aus unserer Sicht spricht diese Ausgestaltung dafür, dass das Vertrauen in eine selbständige und reibungslose Problemlösung durch den Hersteller begrenzt ist. Die geforderten Zwischenschritte und Berichtspflichten wirken wie ein Instrument zur laufenden Kontrolle und Absicherung, nicht wie eine blosse Formalität. Das Jahr-2038-Problem wird damit als komplexes Vorhaben behandelt, dessen Lösung nicht einfach vorausgesetzt wird, sondern nachvollziehbar belegt werden soll.

Nachdem die Forderungen der RATP den Rahmen des Verfahrens abstecken, lohnt sich der Blick auf die Argumentation von Alstom. Sie zeigt, an welchen Punkten Hersteller und Betreiber grundlegend unterschiedlich auf das Jahr-2038-Problem blicken.

«La société Alstom Transport soutient que la RATP a eu connaissance du prétendu vice plus de deux ans avant la requête, l’échéance d’Horodatage 2038 … étant mentionnée dès 1999 dans des publications destinées au grand public.»

„Die Gesellschaft Alstom Transport trägt vor, dass die RATP mehr als zwei Jahre vor der Klage von dem behaupteten Mangel Kenntnis gehabt habe, da der Zeitstempel-Stichtag 2038 … bereits seit 1999 in Veröffentlichungen für die breite Öffentlichkeit erwähnt worden sei.»

– Tribunal Administratif de Paris N° 1921668, 13. November 2025

Mit diesem Argument stellt Alstom das Jahr-2038-Problem als allgemein bekanntes technisches Thema dar. Der Fokus liegt dabei nicht auf der konkreten Ausgestaltung der gelieferten Systeme, sondern auf der Behauptung, dass die Problematik seit Jahrzehnten öffentlich dokumentiert sei. Daraus leitet Alstom ab, dass der Betreiber dieses Risiko hätte erkennen und berücksichtigen müssen.

Tatsächlich ist das Jahr-2038-Problem in technischen Fachkreisen seit Langem bekannt. Bereits im Umfeld des Jahr-2000-Problems gab es einzelne Veröffentlichungen, die auf spätere zeitbezogene Grenzen hinwiesen. Von einer breiten Wahrnehmung ausserhalb spezialisierter Kreise kann jedoch kaum gesprochen werden.

Auffällig ist zudem, dass dieses Argument die konkrete Systemarchitektur ausblendet. Der Verweis auf allgemeine Veröffentlichungen ersetzt aus unserer Sicht nicht die Auseinandersetzung mit der tatsächlichen Implementierung in den gelieferten Fahrzeugen. Der Y2K38 Bug wird hier als abstraktes, bekanntes Phänomen behandelt, nicht als Eigenschaft eines spezifischen Produkts mit einer definierten Nutzungsdauer.

In diesem Zusammenhang zeigt sich ein innerer Widerspruch der Argumentation: Wenn das Jahr-2038-Problem tatsächlich als allgemein bekannt gelten soll, stellt sich die Frage, weshalb ein spezialisierter Hersteller wie Alstom dieses bekannte Risiko nicht bereits bei der Auslegung der Systeme berücksichtigt hat. Gerade bei langlebigen und sicherheitskritischen Systemen wäre zu erwarten, dass bekannte zeitliche Grenzen frühzeitig in der Architektur adressiert werden.

Aus unserer Sicht beantwortet die Berufung auf eine allgemeine Bekanntheit des Problems daher nicht die zentrale Frage: Wie konkret wurde das Risiko bei der Entwicklung und Lieferung der betroffenen Systeme behandelt? Genau diese Ebene bleibt in der Argumentation ausgeblendet.

«La société Alstom Transport fait valoir en deuxième lieu que la RATP, dans les documents contractuels préparatoires, préconisait l’usage de logiciels open source, que la plupart des logiciels open source sont encore à ce jour codés en 32 bits signé et sont donc concernés par l’Echéance d’Horodatage 2038.»

„Alstom Transport macht zweitens geltend, dass die RATP in den vorbereitenden Vertragsunterlagen den Einsatz von Open-Source-Software empfohlen habe, dass die meisten Open-Source-Programme bis heute noch in signierten 32-Bit codiert seien und daher vom Zeitstempel-Stichtag 2038 betroffen seien.»

– Tribunal Administratif de Paris N° 1921668, 13. November 2025

Dieses Argument halten wir für grundlegend verfehlt. Es suggeriert, dass der Einsatz von Open-Source-Software die Ursache des Jahr-2038-Problems sei und verlagert damit die Verantwortung von der konkreten Systemauslegung auf eine pauschale Technologieentscheidung.

Open Source ist jedoch weder ein technisches Zeitformat noch eine direkte Architekturentscheidung, sondern ein Lizenz- und Entwicklungsmodell. Ob ein System intern ein signiertes 32-Bit-Zeitformat verwendet, ist eine bewusste Implementierungsentscheidung. Sie liegt bei denjenigen, die Software auswählen, integrieren und für den vorgesehenen Einsatz auslegen – nicht bei der Lizenzform des Quellcodes.

Besonders problematisch ist, dass diese Argumentation implizit die Verantwortung auf offene Entwicklergemeinschaften abzuwälzen versucht, die häufig unentgeltlich grundlegende Softwarebausteine bereitstellen. Die Industrie nutzt diese Bausteine gezielt und profitiert davon. Treten langfristige Probleme auf, die aus der eigenen Systemarchitektur resultieren, Open Source dafür verantwortlich zu machen, verkennt die Rollenverteilung.

Aus unserer Sicht lenkt dieses Argument vom eigentlichen Kern ab: der Verantwortung des Herstellers für die langfristige Funktionsfähigkeit und Auslegung sicherheitskritischer Systeme. Wir hoffen, dass eine solche Argumentationslinie keine Schule macht.

«La société Alstom Transport soutient en troisième lieu que ce vice ne serait que de la maintenance, à la charge de la RATP.»

„Die Gesellschaft Alstom Transport trägt drittens vor, dass es sich bei diesem Mangel lediglich um eine Frage der Wartung handele, die in die Verantwortung der RATP falle.»

– Tribunal Administratif de Paris N° 1921668, 13. November 2025

Mit diesem Argument ordnet Alstom das Jahr-2038-Problem ausdrücklich dem laufenden Betrieb und der Wartung zu. Der Y2K38 Bug wird damit nicht als Eigenschaft der gelieferten Systeme verstanden, sondern als ein Thema, das im Verantwortungsbereich des Betreibers liegt und im Rahmen normaler Instandhaltung zu behandeln sei.

Aus unserer Sicht ist diese Einordnung bemerkenswert, weil sie den Y2K38 Bug von der Systemauslegung entkoppelt. Wartung setzt in der Regel voraus, dass ein System innerhalb seiner vorgesehenen Architektur betrieben und gepflegt wird. Ein fest verankertes zeitliches Limit, das unabhängig von Wartungsmassnahmen zu einem Funktionsverlust führt, lässt sich jedoch nicht ohne Eingriffe in die grundlegende Struktur beheben.

Die Argumentation verlagert die Verantwortung damit vollständig auf den Betreiber, ohne zu adressieren, ob und wie ein solches Zeitlimit im Rahmen regulärer Wartung überhaupt auflösbar ist. Genau diese Abgrenzung zwischen Wartung und grundlegender Systemanpassung bildet aus unserer Sicht einen zentralen Punkt der weiteren Betrachtung.

«Pour contester l’application de la garantie des vices cachés en l’espèce, la société Alstom Transport fait valoir en premier lieu qu’aucune clause du marché MI09 ne prévoit que le matériel doit pouvoir être exploité 30 ans.»

„Um die Anwendung der Garantie für versteckte Mängel in diesem Fall zu bestreiten, macht die Gesellschaft Alstom Transport zunächst geltend, dass keine Klausel des Vertrags MI09 vorsieht, dass das Material über einen Zeitraum von 30 Jahren betrieben werden können muss.»

– Tribunal Administratif de Paris N° 1921668, 13. November 2025

Aus unserer Sicht berührt dieses Argument einen sensiblen Punkt. Wird die Funktionsfähigkeit eines Systems faktisch an eine nicht ausdrücklich vereinbarte Lebensdauer gekoppelt, entsteht der Eindruck, dass eine bekannte technische Grenze bewusst hingenommen wird, solange sie ausserhalb des vertraglich zugesicherten Zeitraums liegt.

Diese Haltung bezeichnen wir als vorsätzliche Obsoleszenz. Gemeint ist damit keine offen erklärte Absicht, sondern die bewusste Inkaufnahme einer bekannten zeitlichen Begrenzung, obwohl eine deutlich längere Nutzung der Systeme absehbar und üblich ist. Gerade bei langlebigen und sicherheitskritischen Systemen bedeutet dies aus unserer Sicht keine zufällige Schwäche, sondern eine konzeptionell in Kauf genommene Einschränkung der Nutzbarkeit.

Nachdem die Forderungen der RATP und die Argumente von Alstom dargestellt wurden, richtet sich der Blick nun auf das Urteil des Gerichts. Im Mittelpunkt steht dabei nicht eine pauschale Schlussfolgerung, sondern die schrittweise Bewertung und Gewichtung der einzelnen vorgebrachten Argumente. Das Urteil zeigt, welche Überlegungen das Gericht aufgreift, wie es diese einordnet und an welchen Stellen es den Positionen der Parteien folgt oder sie zurückweist.

In den folgenden Abschnitten gehen wir die zentralen Punkte des gerichtlichen Urteils der Reihe nach durch. Wir greifen die relevanten Passagen aus dem Urteilstext auf, übersetzen sie und ordnen ein, welche Argumente für das Gericht ausschlaggebend waren und wie sie im Entscheid gewichtet wurden.

«Le bogue A… est donc susceptible de constituer un vice caché au sens de l’article 1641 du code civil … Il résulte de ce qui précède que la RATP établit que le bogue A… dont sont affectés les logiciels des matériels roulants du marché MI09 en litige constituent un vice qui empêchera leur utilisation à partir du 19 janvier 2038, les rend impropres à leur destination normale quand bien le vice ne prendrait effet qu’à compter de cette date.

Il a été volontairement masqué par la société Alstom Transport au moyen de lignes de codes. Il doit, dès lors, être regardé comme un vice rédhibitoire au sens de l’article 1641 du code civil. Ce vice était inconnu de la RATP,
acheteur certes professionnel mais d’une spécialité différente de la société Alstom Transport, lors de la conclusion du marché, et ne pouvait pas être décelé par elle.

Par suite, la responsabilité de la société Alstom Transport doit être engagée au titre des vices cachés affectant la chose vendue.»

„Der Fehler [Y2k38 Bug] ist daher geeignet, einen versteckten Mangel im Sinne von Artikel 1641 des Zivilgesetzbuches darzustellen … Aus dem Vorstehenden ergibt sich, dass die RATP nachweist, dass der [Y2k38 Bug] , von dem die Software der Schienenfahrzeuge des streitgegenständlichen Vertrags MI09 betroffen ist, einen Mangel darstellt, der ihre Nutzung ab dem 19. Januar 2038 verhindern wird und sie für ihren normalen Verwendungszweck ungeeignet macht, auch wenn der Mangel erst ab diesem Zeitpunkt wirksam wird.

Er wurde von der Gesellschaft Alstom Transport durch Programmzeilen bewusst verborgen. Er ist daher als wesentlicher Mangel im Sinne von Artikel 1641 des Zivilgesetzbuches anzusehen. Dieser Mangel war der RATP, obwohl sie eine professionelle Käuferin ist, jedoch mit einer anderen fachlichen Spezialisierung als die Gesellschaft Alstom Transport, bei Vertragsschluss unbekannt und konnte von ihr nicht erkannt werden.

Folglich ist die Verantwortung der Gesellschaft Alstom Transport aufgrund der versteckten Mängel der verkauften Sache gegeben.“

– Tribunal Administratif de Paris N° 1921668, 13. November 2025

Diese Passage markiert den Kern der gerichtlichen Entscheidung. Das Gericht stellt klar fest, dass der Y2K38 Bug einen Mangel darstellt, der die Nutzung der Fahrzeuge ab einem konkret benannten Datum verhindert und sie damit für ihren vorgesehenen Zweck ungeeignet macht. Entscheidend ist dabei ausdrücklich, dass der Mangel bereits existiert, auch wenn seine Wirkung erst später eintritt.

Besonders deutlich ist die Feststellung, dass der Fehler bewusst im Code verborgen wurde. Damit weist das Gericht die Argumentation zurück, es handle sich lediglich um ein allgemein bekanntes technisches Limit oder um ein Wartungsthema. Der Y2K38 Bug wird als strukturelle Eigenschaft der gelieferten Software eingeordnet, nicht als betriebliche Frage.

Zentral ist zudem die Differenzierung zwischen professionellem Käufer und fachlicher Spezialisierung. Das Gericht anerkennt, dass die RATP zwar ein professioneller Akteur ist, jedoch nicht über dieselbe technische Expertise verfügt wie der Hersteller. Daraus folgt, dass der Mangel für den Käufer weder bekannt noch erkennbar war.

In der Gesamtschau führt das Gericht diese Punkte konsequent zusammen und leitet daraus die Herstellerhaftung ab. Der Y2K38-Bug wird nicht als fernes Zukunftsproblem betrachtet, sondern als ein bei Vertragsschluss angelegter, versteckter und wesentlicher Mangel, für den der Hersteller einzustehen hat.

«Il résulte de l’instruction d’une part que la spécification de soutien logistique MI09 évoque une durée de vie minimale de 30 ans pour les matériels roulants et d’autre part que le document “spécification pour la réalisation des logiciels embarqués” rédigé par la RATP indique une durée de vie du matériel ferroviaire estimée à 40 ans.
Ainsi, les trains MI09 ayant été livrés entre décembre 2011 et avril 2017, la date butoir du bogue A… soit le 19 janvier 2038 est comprise dans la durée de vie contractuelle du matériel. Dès lors, ce moyen de défense de la société Alstom Transport ne peut qu’être écarté.»

„Aus den Akten ergibt sich einerseits, dass die logistische Spezifikation MI09 eine minimale Lebensdauer von 30 Jahren für die Schienenfahrzeuge vorsieht, und andererseits, dass das von der RATP erstellte Dokument ‚Spezifikation für die Entwicklung der eingebetteten Software‘ eine geschätzte Lebensdauer des Eisenbahnmaterials von 40 Jahren angibt. Da die Züge des Typs MI09 zwischen Dezember 2011 und April 2017 geliefert wurden, liegt das Stichtagsdatum des Fehlers [Y2k38 Bug], nämlich der 19. Januar 2038, innerhalb der vertraglichen Lebensdauer des Materials. Folglich kann dieses Verteidigungsargument der Gesellschaft Alstom Transport nur zurückgewiesen werden.»

– Tribunal Administratif de Paris N° 1921668, 13. November 2025

Mit dieser Begründung setzt das Gericht einen deutlichen Massstab: Der Y2K38 Bug darf den natürlichen und vorgesehenen Lebenszyklus eines Produkts nicht verkürzen. Entscheidend ist nicht, ob ein technisches Limit existiert, sondern ob dieses Limit innerhalb der geplanten und dokumentierten Lebensdauer wirksam wird. Ist dies der Fall, kann es nicht als hinzunehmende Randbedingung behandelt werden.

Das Gericht macht damit klar, dass bekannte technische Grenzen nicht dazu führen dürfen, die Nutzbarkeit eines Produkts faktisch vorzeitig zu beenden. Ein System, das über Jahrzehnte eingesetzt werden soll, muss auch über diesen Zeitraum hinweg funktionsfähig bleiben. Eine Architektur, die genau innerhalb dieses Zeitraums versagt, schränkt den Lebenszyklus unzulässig ein.

Aus unserer Sicht ist dies eine klare Absage an jede Form impliziter oder vorsätzlich in Kauf genommener Obsoleszenz. Der Y2K38 Bug wird nicht als akzeptabler Endpunkt eines Produkts betrachtet, sondern als ein Mangel, der den vorgesehenen Einsatz unterbricht.

«Toutefois, cette recommandation de la RATP de nature à éviter justement une obsolescence et visant une maintenabilité des logiciels ne pouvait valablement être interprétée par la société Alstom Transport comme demandant exclusivement l’utilisation de logiciels codés en 32 bits signé, alors que cette échéance du bogue A… pouvait être contournée notamment par des logiciels codés en 64 bits ou en 32 bits non signé. En tout état de cause … ne peut pas s’appuyer seulement sur l’état de l’art pour justifier ne pas avoir conseillé à la RATP de recourir à d’autres logiciels non codés en 32 bits signés.»

„Diese Empfehlung der RATP, die gerade darauf abzielte, eine Obsoleszenz zu vermeiden und die Wartbarkeit der Software sicherzustellen, konnte von der Gesellschaft Alstom Transport nicht zulässigerweise so ausgelegt werden, als verlange sie ausschliesslich den Einsatz von in signiertem 32-Bit-Code geschriebenen Programmen, zumal diese Frist des Bugs [Y2k38 Bug] insbesondere durch in 64 Bit oder in nicht signiertem 32 Bit codierte Software hätte umgangen werden können. Jedenfalls kann … nicht allein auf den Stand der Technik berufen, um zu rechtfertigen, dass sie der RATP nicht geraten hat, andere, nicht in signiertem 32-Bit-Code geschriebene Software einzusetzen.»

– Tribunal Administratif de Paris N° 1921668, 13. November 2025

Das Gericht wertet die Forderung der RATP nach dem Einsatz von Open-Source-Software ausdrücklich als Bestreben, Obsoleszenz zu vermeiden und die Wartbarkeit über die Lebensdauer der Fahrzeuge sicherzustellen. Diese Einordnung ist aus unserer Sicht nachvollziehbar. Open Source erscheint hier nicht als Selbstzweck, sondern als Mittel, um langfristige Abhängigkeiten zu reduzieren und die Wartbarkeit komplexer Systeme über Jahrzehnte hinweg zu ermöglichen.

Kritischer sehen wir jedoch die im Urteil enthaltene Feststellung, dass der Y2K38-Stichtag „insbesondere“ durch den Einsatz von 64-Bit-Software oder von nicht signiertem 32-Bit-Code hätte umgangen werden können. Diese Aussage ist zwar grundsätzlich korrekt, blendet aus unserer Sicht jedoch den zeitlichen Kontext der Systementwicklung aus. 64-Bit-Architekturen sind zwar seit den frühen 2000er-Jahren verfügbar, fanden jedoch in langlebigen, sicherheitskritischen Systemen mit langen Entwicklungs- und Zertifizierungszyklen oft erst deutlich später breite Anwendung. Auch als 64-Bit-Systeme technisch verfügbar waren, bedeutete dies nicht automatisch, dass sie in allen relevanten Umgebungen einsetzbar oder zugelassen waren.

Y2K38-fähige 32-Bit-Systeme, etwa im Linux-Umfeld ab 2020, sind erst vergleichsweise spät entstanden und standen zum Zeitpunkt vieler Architekturentscheidungen noch nicht in stabiler, breit eingesetzter Form zur Verfügung.

Vor diesem Hintergrund erscheint es aus unserer Sicht zumindest prüfenswert, in welchem Umfang praktikable Alternativen tatsächlich existierten, als die betroffenen Systeme konzipiert und umgesetzt wurden. Genau dieser Aspekt deutet darauf hin, dass heute sehr viele Systeme in unterschiedlichen Bereichen vom Jahr-2038-Problem betroffen sind. Die Herausforderung liegt dabei nicht allein im mangelnden Wissen über das Problem, sondern in der begrenzten Verfügbarkeit und Einsetzbarkeit geeigneter Lösungen zum jeweiligen Zeitpunkt – ein Umstand, der in vielen Bereichen bis heute fortwirkt.

«A cet égard, la mise à jour de l’horodatage des logiciels est d’une telle complexité qu’elle n’a pas encore fait l’objet d’une solution technique à ce jour. En outre, cette non-conformité est apparue ab initio, alors que la maintenance doit s’accomplir après le déploiement des logiciels.»

„In diesem Zusammenhang ist die Aktualisierung der Zeitstempelung der Software von einer solchen Komplexität, dass sie bis heute noch nicht Gegenstand einer technischen Lösung war. Zudem ist diese Nichtkonformität von Anfang an entstanden, während Wartung erst nach der Inbetriebnahme der Software erfolgt.»

– Tribunal Administratif de Paris N° 1921668, 13. November 2025

Mit dieser Passage trifft das Gericht eine aus unserer Sicht zentrale Klarstellung: Der Y2K38 Bug ist kein gewöhnlicher Softwarefehler, der sich im Rahmen der laufenden Wartung durch ein einfaches Update beheben lässt. Das Gericht erkennt ausdrücklich an, dass es sich um ein hochkomplexes Problem handelt, für das bislang keine etablierte technische Lösung existiert.

Besonders wichtig ist die zeitliche Einordnung. Die Nichtkonformität bestand von Anfang an und ist damit Teil der ursprünglichen Systemarchitektur. Wartung setzt hingegen voraus, dass ein System zunächst konform ausgeliefert wird und erst später Anpassungen benötigt. Diese klare Trennung weist den Versuch zurück, den Y2K38 Bug nachträglich als Wartungsaufgabe umzudeuten.

Aus Sicht der BEOZ Association ist diese Feststellung von grosser Bedeutung. Seit Jahren weisen wir darauf hin, dass das Jahr-2038-Problem kein klassischer Bug ist, sondern eine strukturelle Begrenzung, die tief in Betriebssysteme, Laufzeitumgebungen und abhängige Software eingebettet ist. Dass ein Gericht diese Komplexität ausdrücklich anerkennt, markiert einen wichtigen Schritt weg von der Vorstellung, man könne das Problem „bei Gelegenheit“ im Rahmen normaler Wartungsfenster lösen.

Damit macht das Urteil deutlich: Der Y2K38 Bug ist kein Thema für ein spätes Patch, sondern eine grundlegende architektonische Herausforderung, die langfristige Planung, substanzielle Eingriffe und klare Verantwortlichkeiten erfordert.

«Les 140 trains au titre de ce contrat ont été mis en service entre décembre 2011 et avril 2017.
223 logiciels embarqués sur les 261 ont été analysés par la société Alstom Transport à la suite d’une réclamation de la RATP et parmi eux 38 ont été reconnus comme porteurs du bogue dit A…»

„Die 140 Züge, die unter diesen Vertrag fallen, wurden zwischen Dezember 2011 und April 2017 in Betrieb genommen.
Von den insgesamt 261 eingebetteten Softwarekomponenten wurden nach einer Beanstandung der RATP 223 durch die Gesellschaft Alstom Transport analysiert, wobei 38 von ihnen als Träger des sogenannten Fehlers [Y2k38 Bug] anerkannt wurden.»

– Tribunal Administratif de Paris N° 1921668, 13. November 2025

Die im Urteil genannten Zahlen verdeutlichen, dass es sich um ein grosses und technisch vielschichtiges Problem handelt. 140 Züge, ausgeliefert über mehrere Jahre, nutzen eine Vielzahl eingebetteter Softwarekomponenten. Von insgesamt 261 Komponenten wurden bislang 223 analysiert, wobei 38 eindeutig als vom Y2K38-Bug betroffen identifiziert wurden. Diese Zahl darf jedoch nicht als Entwarnung verstanden werden.

Zum einen ist die Analyse unvollständig, da nicht alle Softwarekomponenten untersucht wurden. Zum anderen bedeutet die Identifikation von 38 betroffenen Komponenten nicht, dass die übrigen als uneingeschränkt fehlerfrei gelten können. Vielmehr zeigt sich, dass der tatsächliche Zustand der Systeme nur teilweise bekannt ist und dass der Y2K38-Bug kein klar abgegrenzter Einzelfehler ist.

Hinzu kommt die wirtschaftliche Dimension. Die betroffenen Fahrzeuge stellen Investitionen in der Grössenordnung von mehreren Millionen Euro pro Zug dar. Die notwendigen Analysen, Anpassungen, Tests und erneuten Zulassungen betreffen nicht nur einzelne Softwaremodule, sondern potenziell ganze Systemketten. Selbst ohne zusätzliche Beschaffungen entstehen dadurch erhebliche Kosten, die weit über den Aufwand eines klassischen Softwarefehlers hinausgehen.

Aus unserer Sicht zeigt dies, dass der Fall Paris kaum isoliert betrachtet werden kann. Wenn vergleichbare Systeme auch in anderen Netzen, bei anderen Betreibern oder von anderen Herstellern im Einsatz sind, spricht vieles dafür, dass der hier sichtbare Aufwand nur einen Ausschnitt eines deutlich grösseren Problems darstellt. In der Gesamtschau bewegt sich diese Fragestellung sehr wahrscheinlich in einer Grössenordnung von Milliardeninvestitionen.

Zentral ist dabei die Frage der Kostentragung. Das Urteil des Pariser Verwaltungsgerichts gibt hierzu eine klare Richtung vor: Die Verantwortung für die Behebung eines solchen strukturellen Mangels liegt beim Hersteller. Aber können Hersteller diese Last überhaupt tragen?

Aus dem Urteilstext lässt sich ein klarer zeitlicher Ablauf rekonstruieren, der für das Verständnis des Falls zentral ist:

• 1999: Alstom verweist darauf, dass das Jahr-2038-Problem seit diesem Zeitpunkt öffentlich bekannt sei.
• Oktober 2017: Tests der RATP machen erstmals konkret sichtbar, dass die eingesetzten Systeme im Pariser Nahverkehr keine Datumsangaben über das Jahr 2037 hinaus verarbeiten können.
• November 2018: Alstom räumt ein, dass sich der Y2K38-Bug nicht auf einzelne Komponenten beschränkt, sondern potenziell alle gelieferten Fahrzeuge betrifft.
• Oktober 2019: Die RATP reicht Klage gegen Alstom ein.
• November 2025: Das Verwaltungsgericht Paris entscheidet zugunsten der RATP.
• Januar 2038: Der bekannte Überlaufzeitpunkt der Unix-Zeit, an dem der Y2K38 Bug wirksam wird. Die Epochalypse!

Dieser Zeitstrahl macht mehrere Aspekte deutlich. Einerseits wird das Jahr-2038-Problem von Alstom als seit mehr als einem Vierteljahrhundert bekannt dargestellt. Andererseits liegen zwischen der konkreten Feststellung des Problems im Betrieb (2017) und dem erstinstanzlichen Gerichtsurteil (2025) bereits acht Jahre. In diesem Zeitraum wurde das Problem juristisch aufgearbeitet, ohne dass bis heute eine vollständig umgesetzte Lösung vorliegt.

Unabhängig von der weiteren rechtlichen Entwicklung zeigt der Fall, dass ein Problem mit einem scheinbar weit entfernten Stichtag bereits lange vor 2038 operative, organisatorische und rechtliche Relevanz entfaltet. Die verbleibende Zeit bis 2038 ist aus Sicht langlebiger Systeme nicht gross. Entwicklung, Tests, Zertifizierung und Rollout geeigneter Lösungen benötigen Jahre, nicht Monate.

Vor diesem Hintergrund stellt sich aus unserer Sicht eine weitergehende Frage: Was bedeutet dieser Zeitrahmen für Betreiber, die ihre Systeme bislang noch nicht systematisch auf Y2K38-Kompatibilität geprüft haben? Der Pariser Fall legt nahe, dass das Jahr-2038-Problem nicht erst kurz vor dem Stichtag relevant wird. Vielmehr beginnt der eigentliche Handlungsdruck deutlich früher – und genau dieser Zeitfaktor dürfte für viele Betreiber die eigentliche Herausforderung darstellen.