Was Ihnen gehört, wenn das System fertig ist: Code, Daten und Abhängigkeit vom Entwickler

Das System ist übergeben, die Rechnung ist bezahlt, und nach einem halben Jahr beschließt das Unternehmen, den Entwickler zu wechseln, und genau in diesem Moment wird die Frage gestellt, die bis dahin niemandem dringend schien: Wem gehört das, wofür gezahlt wurde. Die Antwort in Deutschland überrascht fast alle, die sie zum ersten Mal hören, denn die Zahlung für die Entwicklung gibt dem Besteller für sich genommen kein Urheberrecht am geschaffenen Computerprogramm, und das ist keine juristische Spitzfindigkeit, sondern der gesetzliche Normalfall, der greift, sobald der Vertrag nichts anderes festhält.

Dieser Artikel handelt davon, was nach der Übergabe in Ihrer Hand bleibt, und das ist nicht dieselbe Frage, die wir schon betrachtet haben, als wir ein Standardprodukt mit Individualsoftware verglichen haben. Dort ging es um die Wahl; hier geht es darum, was Sie in der Hand halten, wenn die Wahl schon getroffen ist und das System läuft. Die Antwort zerfällt in drei Teile: den Code und die Rechte daran, die Daten zusammen mit dem Ort, an dem sie liegen, und die Abhängigkeit von den Menschen, die das System kennen.

Der Urheber ist immer ein Mensch, nie ein Unternehmen

Im Sinne des Urheberrechtsgesetzes ist Urheber der Schöpfer des Werkes, und das bedeutet, dass ein Unternehmen nie Urheber ist: Urheber sind die Programmierer, Designer und Texter, die am System gearbeitet haben. Computerprogramme werden als Sprachwerke geschützt, wie in der Richtlinie 2009/24/EG, und das Urheberrecht entsteht in dem Moment, in dem das Werk geschaffen ist, ohne Registrierung, ohne Kennzeichen und unabhängig davon, ob das Werk fertig ist.

Das Urheberrecht teilt sich in zwei Hälften, die das deutsche Gesetz als Urheberpersönlichkeitsrecht und Verwertungsrechte führt (in der Richtlinie 2009/24/EG Artikel 2 Absatz 3 wirtschaftliche Rechte genannt), und in der Praxis ist das die wichtigste Trennung in diesem ganzen Thema, weil nur Nutzungsrechte überhaupt zum Unternehmen gelangen können. Das Urheberrecht selbst ist nach § 29 Absatz 1 nicht übertragbar; zulässig ist die Einräumung von Nutzungsrechten nach § 31. Bei einem Computerprogramm umfassen die Verwertungsrechte nach § 69c unter anderem die Vervielfältigung, die Bearbeitung und andere Umarbeitungen, die Verbreitung einschließlich der Vermietung und die öffentliche Zugänglichmachung. Das Urheberpersönlichkeitsrecht bleibt beim Urheber auf Lebenszeit und ist niemandem übertragbar, und genau deshalb kann kein Vertrag schreiben, dass das Unternehmen zum Urheber wird.

Es gibt noch eine weitere Grenze, die selten auffällt und teuer werden kann. § 69b Absatz 1, der dem Arbeitgeber die Ausübung aller vermögensrechtlichen Befugnisse zuweist, spricht nur vom Computerprogramm, während für alles andere, was das Projekt hervorbringt, nämlich Design, Dokumentation, Texte und Anleitungen, § 43 gilt: die allgemeinen Regeln, soweit sich aus dem Inhalt oder dem Wesen des Arbeits- oder Dienstverhältnisses nichts anderes ergibt. Der gesetzliche Normalfall ist dann die Zweckübertragung nach § 31 Absatz 5, nicht ein automatischer Übergang der Rechte auf den Arbeitgeber. Praktisch heißt das, dass zwei in einem Projekt geschaffene Dinge zwei verschiedene Rechtsinhaber haben können, und ein Vertrag, der nur von der Software spricht, das Design draußen lassen kann.

Daraus folgen die ersten praktischen Konsequenzen, die man verstehen sollte, bevor alles andere kommt: wenn ein Unternehmen ein System bei einer Agentur in Auftrag gibt, ist die Rechtekette mindestens zwei Schritte lang, denn zuerst sind die Programmierer die Urheber, dann hat die Agentur die Nutzungsrechte von ihnen erworben oder nicht, und erst dann kann die Agentur Ihnen etwas einräumen. Fehlt ein Schritt, verspricht die Agentur mehr, als ihr gehört, und das fällt erst auf, wenn jemand nachprüft.

Arbeitnehmer und Auftrag sind zwei verschiedene gesetzliche Normalfälle

Hier liegt der Kern des Artikels, und hier führt die Intuition in die falsche Richtung. § 69b Absatz 1 bestimmt, dass dann, wenn ein Arbeitnehmer ein Computerprogramm in Wahrnehmung seiner Aufgaben oder nach den Anweisungen seines Arbeitgebers schafft, ausschließlich der Arbeitgeber zur Ausübung aller vermögensrechtlichen Befugnisse berechtigt ist, sofern nichts anderes vereinbart ist. Das ist die deutsche Antwort auf Artikel 2 Absatz 3 der Richtlinie 2009/24/EG, und sie gilt nur für Arbeitsverhältnisse und nur für Computerprogramme.

Beim Auftrag ist der gesetzliche Normalfall der umgekehrte, und genau deshalb darf man die beiden Fälle nicht vermischen: Das Urheberrechtsgesetz kennt keine Vorschrift, die dem Besteller die Verwertungsrechte allein durch die Bestellung zuweist. Der Werkvertrag nach § 631 BGB verpflichtet den Unternehmer zur Herstellung des versprochenen Werkes und den Besteller zur Zahlung der vereinbarten Vergütung, und über das Urheberrecht sagt er nichts, weil er die Herstellung und die Ablieferung regelt, nicht den Übergang von Nutzungsrechten.

Setzt man beides zusammen, ergibt sich die Lage, in die ein typisches Unternehmen gerät, ohne es zu wissen: der Kunde beauftragt ein System bei einer Agentur; die Programmierer sind Arbeitnehmer der Agentur, deshalb weist § 69b Absatz 1 die vermögensrechtlichen Befugnisse der Agentur zu; der Vertrag zwischen Kunde und Agentur ist ein Werkvertrag, der sie nicht weiterträgt. Im Ergebnis hat der Kunde für das Ergebnis gezahlt und das Ergebnis erhalten, aber die Verwertungsrechte sind bei der Agentur geblieben, und das Einzige, was der Kunde hat, ist eine unklare stillschweigende urheberrechtliche Lizenz, das System zu dem Zweck zu nutzen, zu dem es beauftragt wurde.

Es ist ein verbreiteter Irrtum, dass die Rechte an einem Computerprogramm demjenigen gehören, der die Entwicklung beauftragt und bezahlt hat, und das Urheberrechtsgesetz sieht keinen automatischen Übergang der Verwertungsrechte auf den Besteller vor. Der Inhalt einer bloß stillschweigenden Lizenz bleibt unklar, und weil das der gesetzliche Text ist, lohnt es sich, ihn so zu lesen, wie er dasteht, und in diesem Fall bestätigt er genau diese Lesart.

Dateien zu erhalten heißt nicht, Rechte zu erhalten

Die zweite Annahme, die einer Prüfung nicht standhält, ist, dass der Empfang des Codes irgendetwas entscheidet, aber § 44 Absatz 1 bestimmt, dass der Urheber mit der Veräußerung des Originals im Zweifel kein Nutzungsrecht einräumt. Praktisch heißt das, dass ein Archiv mit dem gesamten Quellcode, der Zugang zum Repository und selbst die vollständige Dokumentation immer noch nicht dasselbe sind wie das Recht, diesen Code zu nutzen, umzuarbeiten und einem anderen Entwickler zu übergeben.

Das gilt auch in die andere Richtung, und diese Seite ist weniger bekannt, denn ein Unternehmen kann die Nutzungsrechte mit einem gut geschriebenen Vertrag erworben und den Quellcode trotzdem nicht erhalten haben, wenn im Vertrag keine gesonderte Pflicht zur Übergabe stand. Eine Erlaubnis ohne die Datei ist ebenso unbrauchbar wie eine Datei ohne Erlaubnis, deshalb braucht der Vertrag beides, und das sind zwei selbständige Punkte, nicht ein Punkt, der den anderen von selbst enthält.

Wenn Nutzungsrechte richtig eingeräumt werden, verlangt das Gesetz eine gewisse Genauigkeit, und das ist keine Formalie, denn Nutzungsrechte können räumlich, zeitlich oder inhaltlich beschränkt eingeräumt werden. Sind die Nutzungsarten nicht ausdrücklich einzeln bezeichnet, bestimmt sich nach § 31 Absatz 5 nach dem von beiden Partnern zugrunde gelegten Vertragszweck, worauf sich das Recht erstreckt — nicht nach dem Land, in dem der Vertrag geschlossen wurde. Ein Unternehmen, das in mehreren Ländern tätig ist oder es werden will, hat deshalb einen unmittelbaren Grund, das Gebiet festzuschreiben, und eine Formulierung über eine Nutzungsart öffnet die übrigen nicht von selbst.

Es gibt noch eine weitere Überraschung für ein Unternehmen, das mit einer stillschweigenden Lizenz lebt und sie nie schriftlich gefasst hat. Eine Regel, nach der eine unbefristete Lizenz mit sechs Monaten Frist gekündigt werden kann und ein Verzicht auf dieses Recht unwirksam wäre, kennt das Urheberrechtsgesetz nicht. Der nächstliegende Rückruf wegen Nichtausübung nach § 41 gilt für Computerprogramme ausdrücklich nicht (§ 69a Absatz 5); der Rückruf wegen gewandelter Überzeugung nach § 42 bleibt, ist aber ein anderes Instrument und keine Kündigungsfrist von sechs Monaten. Ein Unternehmen, dessen einzige Grundlage für die Nutzung eine ungeschriebene Abrede ist, lebt deshalb nicht mit einer gesetzlichen Sechsmonatsfrist, sondern mit der Unklarheit, welche Nutzungsrechte ihm überhaupt zustehen.

Urheberpersönlichkeitsrecht, und was es nicht immer verbietet

Zum Urheberpersönlichkeitsrecht gehören namentlich die Anerkennung der Urheberschaft, der Schutz des Namens und der Schutz gegen Entstellung, und dazu tritt das Rückrufsrecht wegen gewandelter Überzeugung; das alles bleibt beim Urheber, weil diese Rechte nicht wie Nutzungsrechte auf einen anderen übertragen werden. Für ein Unternehmen, das ein System beauftragt hat, klingt das zunächst bedrohlich, weil der Eindruck entsteht, ein früherer Entwickler könne irgendwann verlangen, das System stillzulegen.

In der Praxis ist das kein verlässlicher Weg, ein System stillzulegen. Die Umarbeitung eines Computerprogramms ist ein Nutzungsrecht nach § 69c Nummer 2. Der Schutz gegen Entstellung nach § 14 bleibt: Der Urheber kann eine Entstellung oder eine andere Beeinträchtigung verbieten, die geeignet ist, seine berechtigten geistigen oder persönlichen Interessen am Werk zu gefährden. Ein früherer Programmierer kann die gewöhnliche Wartung oder eine Überarbeitung über das Urheberpersönlichkeitsrecht in der Regel nicht stoppen; er könnte § 14 noch aufrufen, wenn die Änderung jene Interessen gefährdet, und der Rückruf wegen gewandelter Überzeugung nach § 42 bleibt für Computerprogramme verfügbar. Genau dieser Teil des Bündels wäre für das Unternehmen gefährlich, und in der Praxis trägt er über das Urheberpersönlichkeitsrecht in der Regel nicht so weit.

Für das Unternehmen günstig und wissenswert, weil man sie sonst von der falschen Seite erwarten kann, ist eine weitere Norm: Die Vorschriften über die angemessene Vergütung und die weitere Beteiligung, die §§ 32 bis 32g, sind auf Computerprogramme nach § 69a Absatz 5 nicht anzuwenden, und das heißt, ein Programmierer, der meint, das System sei wertvoller geworden, als beide Seiten erwartet hatten, kann auf dieser Grundlage keine zusätzliche Vergütung verlangen.

Was bleibt, ist die Möglichkeit, als Urheber genannt zu werden, der Schutz gegen Entstellung, wenn berechtigte geistige oder persönliche Interessen gefährdet sind, und das Rückrufsrecht wegen gewandelter Überzeugung, und das ist ein erheblich kleineres Risiko als ein allgemeines Stilllegungsrecht, mit dem sich leben lässt. Wichtig ist nur, zwei Dinge nicht zu verwechseln: die Umarbeitung als Frage des Urheberpersönlichkeitsrechts ist in der Regel kein Hindernis, die Umarbeitung als Verwertungsrecht verlangt aber nach wie vor die Erlaubnis des Rechtsinhabers, deshalb braucht die Überarbeitung des Systems nach wie vor die Zustimmung der Agentur, wenn die Nutzungsrechte bei ihr geblieben sind.

Was das Gesetz auch ohne einen guten Vertrag gibt

Selbst einem Unternehmen, das nichts schriftlich gefasst hat, gibt das Gesetz einige Möglichkeiten, und es lohnt zu wissen, welche davon der Vertrag nehmen kann und welche nicht. § 69d Absatz 1 erlaubt dem zur Verwendung eines Vervielfältigungsstücks Berechtigten die in § 69c Nummer 1 und 2 genannten Handlungen, wenn sie für eine bestimmungsgemäße Benutzung einschließlich der Fehlerberichtigung notwendig sind, aber nur, soweit keine besonderen vertraglichen Bestimmungen vorliegen, deshalb kann der Vertrag dieses Recht nehmen, und viele Verträge tun das auch.

Die Erstellung einer Sicherungskopie ist ein anderer Fall, denn der Vertrag kann sie nicht nehmen: § 69d Absatz 2 bestimmt, dass die Erstellung einer Sicherungskopie durch eine zur Benutzung berechtigte Person nicht vertraglich untersagt werden darf, wenn sie für die Sicherung künftiger Benutzung erforderlich ist, und das entspricht Artikel 5 Absatz 2 der Richtlinie 2009/24/EG. Artikel 8 der Richtlinie bestimmt außerdem, dass vertragliche Bestimmungen, die im Widerspruch zu Artikel 6 oder zu den in Artikel 5 Absatz 2 und 3 vorgesehenen Ausnahmen stehen, nichtig sind.

Hier lohnt Genauigkeit, weil der Unterschied fein ist und leicht übertrieben wird: Für die Sicherungskopie sagt § 69d Absatz 2, dass sie nicht vertraglich untersagt werden darf, und § 69g Absatz 2 erklärt vertragliche Bestimmungen für nichtig, die zu § 69d Absatz 2, 3, 5 oder 7 oder zu § 69e in Widerspruch stehen. Deutschland hat Artikel 8 der Richtlinie also auch für die Dekompilierung übernommen. Richtig ist deshalb zu sagen, dass die Sicherungskopie im Vertrag nicht genommen werden kann und dass eine Klausel, die der Ausnahme für die Dekompilierung entgegensteht, nichtig ist.

Die Dekompilierung ist ihrerseits eng und unter Bedingungen erlaubt: sie darf vorgenommen werden, um die Interoperabilität eines unabhängig geschaffenen Programms herzustellen, wenn die Informationen nicht ohne weiteres zugänglich sind, sie von einer zur Verwendung eines Vervielfältigungsstücks berechtigten Person vorgenommen wird, und die Handlung sich auf die Teile beschränkt, die für die Interoperabilität nötig sind. Die gewonnenen Informationen dürfen nicht für andere Zwecke oder zur Herstellung eines im Wesentlichen ähnlichen Produkts verwendet werden, und dieser Ausweg ist nützlich, aber eng, und kein Unternehmen will, dass er der einzige ist.

Im System steckt viel Code, der nie Ihrer sein wird

Ein individuelles System ist fast nie nur der Code, den der Entwickler geschrieben hat, denn der größte Teil des Umfangs kommt aus Bibliotheken und einem Framework, die schon existierten. Dieser Code wird niemals Ihr Eigentum, in keinem Vertrag, weil Sie eine Lizenz von dessen Urhebern erhalten, und dieser Unterschied zählt genau dann, wenn jemand verspricht, alle Nutzungsrechte am System einzuräumen.

Permissive Lizenzen schaffen kein Problem, weil sie wenig verlangen und nicht beschränken, wie das fertige System in einem Geschäftsbetrieb genutzt werden darf. Die MIT-Lizenz erlaubt das Nutzen, Kopieren, Ändern, Zusammenführen, Veröffentlichen, Verbreiten und Verkaufen, sofern der Urheberrechtshinweis und die Lizenz selbst erhalten bleiben, und die Software wird übergeben, wie sie ist, ohne Gewähr, während die Apache-Lizenz 2.0 eine ausdrückliche Patentlizenz hinzufügt und verlangt, vorgenommene Änderungen zu kennzeichnen. Beide sind mit einem geschlossenen kommerziellen System vereinbar, die meisten heutigen Frameworks sind die eine oder die andere, und genau deshalb verlangt dieser Teil des Systems gewöhnlich gar keine Verhandlung.

Copyleft-Lizenzen verlangen Aufmerksamkeit, aber keine Panik, und genau hier werden am häufigsten Halbwahrheiten erzählt, obwohl die Free Software Foundation auf ihrer FAQ-Seite zur GPL klar schreibt, dass ein Unternehmen, das ein verändertes GPL-Programm auf der eigenen Website betreibt, den veränderten Quellcode nicht veröffentlichen muss, weil die Copyleft-Pflicht mit der Weitergabe von Kopien an andere entsteht, nicht mit der Nutzung im eigenen Haus. Mehrere Kopien innerhalb einer Organisation herzustellen und zu nutzen ist keine Verbreitung, obwohl die Weitergabe von Kopien an andere Organisationen, einschließlich Auftragnehmern zur Nutzung außerhalb des Unternehmens, das schon ist.

Die Ausnahme ist die GNU Affero GPL, und genau deren Netzinteraktionsklausel (AGPL §13) ist es, die die Menschen überrascht, denn wenn Sie das Programm verändern und die veränderte Fassung Nutzern erlaubt, darüber aus der Ferne über ein Rechnernetz zu kommunizieren, dann muss diesen Nutzern die Möglichkeit angeboten werden, den entsprechenden Quellcode zu erhalten. Die Bedingungen sind zwei und beide sind nötig: die Veränderung und die entfernte Nutzerinteraktion, deshalb ist es nicht richtig zu sagen, jede Nutzung einer Affero-Lizenz verlange die Veröffentlichung des Quellcodes, und es ist nicht richtig zu sagen, eine einzige solche Bibliothek unterwerfe automatisch das ganze System, weil das davon abhängt, wie die Komponenten verbunden sind.

Source-Code-Escrow bei einem Dritten, und was es wirklich gibt

Source-Code-Escrow (Quellcodehinterlegung) ist eine dreiseitige Lösung, in der der Entwickler den Quellcode einem neutralen Verwahrer übergibt und der Verwahrer ihn dem Besteller nur dann herausgibt, wenn der im Vertrag beschriebene Fall eintritt, und typische Fälle sind Insolvenz, Geschäftsaufgabe oder eine wesentliche Nichterfüllung der Wartungspflichten nach Abmahnung. Ein Gesetz, das diese Fälle festlegen oder auch nur aufzählen würde, gibt es in Deutschland nicht, deshalb gilt hier nur, was die Parteien selbst geschrieben haben, und deshalb ist der Escrow-Vertrag ebenso sorgfältig zu lesen wie der Entwicklungsvertrag selbst.

Escrow gibt genau das, was hinterlegt wurde, und nur dann, wenn eintritt, was beschrieben ist, überträgt aber für sich genommen keine Rechte, denn dafür ist wieder § 44 Absatz 1 zu erinnern, und es lehrt niemanden, das System zu betreiben. Das Unternehmen NCC Group, das diesen Dienst seit Jahrzehnten verkauft, räumt in den eigenen Unterlagen selbst ein: dass der Quellcode im Depot liegt, ist das eine, ihn kompilieren zu können das andere, und genau deshalb verkauft dasselbe Unternehmen auch die Prüfung des hinterlegten Inhalts. Das ist die Einschätzung einer interessierten Partei, aber es ist ein Eingeständnis über die Schwachstelle des eigenen Kerndienstes, und deshalb ist es brauchbar.

Bei heutigen Systemen gibt es noch eine zweite Lücke, die mit der rechtlichen Seite gar nichts zu tun hat: läuft das System als Dienst auf der Infrastruktur des Entwicklers, dann löst Quellcode ohne Laufzeitumgebung, Konfiguration und Daten den kleineren Teil des Problems, weil der Empfänger ein Archiv behält, nicht ein arbeitendes System. Praktiker schließen diese Lücke, indem sie das Escrow um eine Vereinbarung ergänzen, wer die Umgebung übernimmt und was geschieht, wenn die Rechnungen für das Hosting unbezahlt bleiben, und genau diese Punkte tauchen auf den Standardformularen für Escrow gewöhnlich nicht auf.

Es gibt auch ein rechtliches Hindernis, das nicht im Urheberrecht steht, sondern in der Insolvenz: Im Insolvenzverfahren können hinterlegtes Material und seine Herausgabe mit dem Regime der Insolvenzmasse in Konflikt geraten, also genau in dem Fall, für den Source-Code-Escrow am häufigsten gekauft wird. Die praktische Folgerung ist nicht, auf Escrow zu verzichten, sondern es nicht als Ersatz für eine schriftliche Einräumung der Nutzungsrechte und für die regelmäßige Übergabe des Quellcodes zu behandeln.

Wo das Repository liegt und wo die Daten liegen

Die Frage, wo Code und Daten liegen, entscheidet mehr als die Frage, wem sie gehören, denn Rechte ohne Zugang sind ein langsames Problem. Die GitHub-Dokumentation beschreibt klar, dass eine Organisation ein gemeinsames Konto ist, dem die Repositorys gehören, dass man sich nicht als Organisation anmeldet, weil sich jeder mit einem persönlichen Konto anmeldet, und dass die Organisationsbesitzer stets Zugriff auf alle Repositorys haben; ein Repository kann einem persönlichen Konto oder einer Organisation gehören, und diese Wahl ist wichtiger, als sie aussieht.

Gehört das Repository dem persönlichen Konto des Entwicklers, dann ist der Zugang des Kunden nur ein Zugang als Collaborator, den der Kontoinhaber jederzeit entziehen kann, und wenn er das Projekt verlässt, nimmt er die Adresse selbst mit. Gehört das Repository der Organisation des Kunden, in die der Entwickler als Mitglied eingeladen ist, dann bedeutet das Verlassen nur die Entfernung eines Zugangs und sonst nichts, und das ist eine der wenigen Dinge in diesem Artikel, die sich an einem einzigen Tag und ohne Anwalt in Ordnung bringen lassen.

Daten sind eine gesonderte Frage, und dort geht es nicht mehr um Urheberrecht: wenn der Entwickler personenbezogene Daten in Ihrem Auftrag verarbeitet, also die Produktionsumgebung betreibt, Kundendaten oder Beschäftigtendaten sieht oder Sicherungskopien anlegt, dann sind Sie Verantwortlicher und der Entwickler Auftragsverarbeiter im Sinne der Datenschutz-Grundverordnung. Artikel 28 verlangt einen schriftlichen Vertrag mit bestimmten Punkten: Gegenstand und Dauer der Verarbeitung, Art und Zweck, die Arten der Daten und die Kategorien betroffener Personen sowie die Rechte und Pflichten des Verantwortlichen.

Reine Programmierarbeit ohne Zugang zu personenbezogenen Daten löst Artikel 28 nicht aus, deshalb braucht nicht jeder Entwicklungsvertrag einen Auftragsverarbeitungsvertrag. Die Grenze ist einfach und prüfbar: wenn der Entwickler echte Kundendaten sehen kann, dann braucht es ihn, wenn der Entwickler nur mit Testdaten arbeitet und die Produktionsumgebung nicht sieht, dann nicht, und das allein ist ein Argument dafür, die Testumgebung getrennt zu halten.

Was Sie gewinnen und was Sie gleichzeitig übernehmen

Die Logik dieses Artikels war bisher einseitig, deshalb ist es nur fair, auch die andere Seite zu nennen: die volle Kontrolle über ein individuelles System ist nicht nur ein Gewinn, sondern auch ein Bündel von Pflichten, die nicht verschwinden. Bei einem Standardprodukt stellt der Hersteller Wartung, Sicherheitspatches und die Kompatibilität mit neuen Umgebungen bereit, und das steckt in der Abonnementgebühr, bei Individualsoftware stellt das alles der Eigentümer bereit, nämlich Sie, und das ist eine direkte Ausgabe, die jedes Jahr erscheint, unabhängig davon, ob sich im System etwas ändert.

Das Zweite, was Sie übernehmen, ist das Altern des Systems, das sich still ansammelt und sich auf keine Weise zeigt, solange niemand danach sucht. Das System stützt sich auf Sprach- und Framework-Versionen, für die die Hersteller Supportfristen setzen, und nach dem Ende dieser Fristen werden neue Sicherheitslücken nicht mehr geschlossen, obwohl das System genau so weiterläuft wie zuvor und kein Bildschirm davor warnt. Das ist kein Verbot, ein alterndes System zu betreiben, aber es ist der Moment, in dem der Eigentümer das Risiko übernimmt, und die konkreten Termine für PHP und Laravel haben wir in dem Artikel darüber gesammelt, was die Wahl von PHP und Laravel bedeutet, deshalb wiederholen wir sie hier nicht.

Das Dritte ist der Markt, und für eine fertige Plattform ist ein Spezialist vergleichsweise leicht zu finden, weil sie ausgebildet werden und es mehrere gibt, während ein individuelles System nur die kennen, die es gebaut haben, und einem neuen Entwickler Zeit zur Einarbeitung gegeben werden muss, bevor er etwas sicher ändern kann. Das heißt nicht, dass eine Übernahme unmöglich ist, aber es heißt, dass sie kostet, und diese Kosten erscheinen genau in dem Moment, in dem die Beziehung zum bisherigen Entwickler schon beendet ist.

Genau deshalb ist die Frage, was Ihnen gehört, keine juristische Formalie, sondern die Frage, wie teuer die nächste Wahl wird. Ein Unternehmen mit schriftlicher Einräumung, dem Quellcode im eigenen Repository und einer Liste der verwendeten Komponenten kann innerhalb einer Woche einen neuen Entwickler suchen, während ein Unternehmen ohne all das zuerst klärt, was es überhaupt darf, und erst dann zu suchen beginnt, und das ist der Unterschied zwischen einem Gespräch aus einer Position und einem Gespräch aus der Not.

Was in den Vertrag gehört, solange es noch geht

Alle vorangehenden Abschnitte führen auf eine kleine Menge von Punkten, die sich vor Arbeitsbeginn in den Vertrag zu schreiben lohnen, weil die Verhandlungsposition nach der Übergabe viel schwächer ist. Das Erste ist die schriftliche Einräumung der Nutzungsrechte, mit der Angabe, welche Rechte übergehen, in welchem Gebiet und für welche Dauer, denn sind die Nutzungsarten nicht bezeichnet, füllt § 31 Absatz 5 die Lücke nach dem Vertragszweck, und das ist nicht dasselbe wie eine gesetzliche Zuweisung an das Land des Vertragsschlusses. Das Zweite ist die Zusicherung, dass die Agentur sie von den eigenen Arbeitnehmern und Subunternehmern erworben hat, denn ohne diesen Schritt kann die Einräumung selbst leer sein.

Das Dritte ist die regelmäßige Übergabe des Quellcodes und dessen, was zu seiner Kompilierung nötig ist, nicht eine einmalige Übergabe am Projektende, und das Vierte ist, dass das Repository vom ersten Tag an in Ihrem Organisationskonto liegt. Das Fünfte ist eine Liste der Open-Source-Komponenten mit ihren Lizenzen, weil ohne diese Liste später niemand weiß, was im System ist und unter welchen Bedingungen; das Sechste ist ein Auftragsverarbeitungsvertrag, wenn der Entwickler echte Daten sehen wird, und das Siebte ist eine Vereinbarung darüber, was mit Umgebungen, Schlüsseln und Zugängen am Ende der Zusammenarbeit geschieht.

Keiner dieser Punkte verlangt einen langen Text, keiner von ihnen steht im Widerspruch zu einer guten Zusammenarbeit, und kein ehrlicher Entwickler widerspricht ihnen, weil sie genau das festhalten, was beide Seiten ohnehin meinen. Das Einzige, was sie ändern, ist, dass die Vereinbarung nicht mehr davon abhängt, ob die konkreten Menschen nach drei Jahren noch in demselben Unternehmen arbeiten und ob jemand sich erinnert, was damals mündlich gesagt wurde. Diese Punkte lohnt es, von jedem Entwickler zu verlangen, auch von uns, und sie vor Arbeitsbeginn in den Vertrag zu schreiben. Unsere Seite zur Individualsoftware-Entwicklung verspricht derzeit, Quellcode, Dokumentation und Infrastruktur-Konfiguration am Ende der Arbeit zu übergeben, und genau deshalb lohnt der dritte Punkt in dieser Liste, nämlich die regelmäßige Übergabe im Lauf der Arbeit, gesondert zu besprechen, statt anzunehmen, dass er selbstverständlich sei. Wenn Sie möchten, dass wir einen schon bestehenden Vertrag ansehen, schreiben Sie uns.