Softwareentwicklungsvertrag: Vollständiger Leitfaden + Kostenlose Vorlage

Die meisten Softwareprojekte scheitern nicht, weil die Entwickler schlecht im Programmieren waren. Sie scheitern, weil niemand niedergeschrieben hat, was "fertig" bedeutet. Der CHAOS-Report der Standish Group beziffert die Erfolgsquote von Softwareprojekten auf nur 31 %. Und Meinungsverschiedenheiten über den Umfang, unklare IP-Eigentumsverhältnisse und strittige Zahlungsbedingungen sind die häufigsten Ursachen.

Tatsächlich behebt ein Softwareentwicklungsvertrag all dies, bevor die Arbeit beginnt. Es handelt sich um den Vertrag zwischen einem Kunden und einem Entwickler (oder einer Agentur), der definiert, was gebaut wird, wem es gehört, was es kostet und was passiert, wenn etwas schiefgeht. Ohne einen solchen Vertrag verlassen Sie sich auf Treu und Glauben sowie auf Erinnerungen. Und Gerichte akzeptieren keines von beidem. In der Praxis geht es bei den meisten Streitigkeiten nicht um böse Absichten, sondern um unterschiedliche Erinnerungen an dasselbe Gespräch.

Dieser Leitfaden behandelt alles: wann Sie einen Softwareentwicklungsvertrag benötigen, die vier Vertragsarten und wann welche zu verwenden ist, jede Klausel, die wirklich wichtig ist, und eine kostenlose herunterladbare Vorlage, die Sie für Ihr Projekt anpassen können. Wenn Sie die Grundlagen bereits kennen und direkt zur Vorlage gelangen möchten, springen Sie zum Vorlagenabschnitt. Andernfalls ist der Kontext wichtig, insbesondere der IP-Abschnitt, in dem die meisten Verträge stillschweigend versagen. Hier ist die Sache: Die Behebung einer in der Produktion entdeckten Sicherheitslücke ist laut Untersuchungen von NIST etwa 30 Mal teurer, als sie während der Entwicklung zu erkennen. Allein diese Statistik sollte jede Zeile in Ihrer Abnahmetest-Klausel rechtfertigen. Für einen umfassenderen Blick darauf, wie sich Vereinbarungen von Verträgen unterscheiden, behandelt unser Leitfaden zu Verträgen vs. Vereinbarungen die rechtlichen Unterschiede, die es zu kennen lohnt. Wenn Sie bereit sind zu entwerfen, bietet unser Leitfaden So schreiben Sie einen Vertrag ein schrittweises Rahmenwerk.

Ein Softwareentwicklungsvertrag (SDA) ist ein rechtlich verbindlicher Vertrag zwischen einem Kunden und einem Softwareentwickler oder Entwicklungsunternehmen. Er definiert den Arbeitsumfang, die Zahlungsstruktur, den Lieferzeitplan, das Eigentum an geistigem Eigentum, die Vertraulichkeitsbedingungen und was passiert, wenn eine der Parteien aus der Vereinbarung aussteigen muss.

Der SDA ist kein Angebot, kein Projekt-Briefing und kein Slack-Thread, der die Arbeit bestätigt. Ehrlich gesagt, ich habe alle drei als 'Verträge' versucht gesehen, und keiner endete gut. Es ist die formelle rechtliche Aufzeichnung dessen, worauf sich beide Seiten geeinigt haben, bevor die Entwicklung begann. Einmal unterzeichnet, ist es das Dokument, auf das Sie sich bei einem Streit beziehen werden. Und das Dokument, das ein Gericht lesen wird, wenn es so weit kommt.

Was ein SDA abdeckt

Ein ordnungsgemäß ausgearbeiteter Softwareentwicklungsvertrag wird Folgendes adressieren:

• Arbeitsumfang. Was der Entwickler bauen wird, mit ausreichender Spezifität, dass ein Dritter den Abschluss bewerten könnte
• Liefergegenstände und Meilensteine. Was geliefert wird, in welcher Form und bis wann
• Zahlungsbedingungen. Gesamtgebühr, Zahlungsplan und was jede Zahlung auslöst
• IP-Eigentum. Wem der Code gehört, nachdem er geschrieben wurde
• Vertraulichkeit. Welche geschützten Informationen jede Partei privat halten muss
• Abnahmetest. Wie der Kunde bewertet, ob die gelieferte Software die Anforderungen erfüllt
• Garantien. Was der Entwickler hinsichtlich der Funktionalität der Software garantiert
• Kündigungsbedingungen. Wie eine der Parteien die Vereinbarung beenden kann und was mit bereits abgeschlossener Arbeit geschieht

Einige Kunden verwechseln den SDA mit einem Statement of Work. Es gibt Überschneidungen, aber sie sind nicht dasselbe. Allerdings ist die Unterscheidung wichtiger, als die meisten Menschen denken. Die Beziehung zwischen einem MSA und einem SOW erklärt, wie diese Dokumente in längerfristigen Engagements zusammenwirken.

Kurze Antwort: Immer wenn Sie jemanden für die Erstellung von Software bezahlen oder dafür bezahlt werden, sie zu erstellen.

Der Vertrag ist wichtig, egal ob Sie einen einzelnen Freelancer für ein zweiwöchiges Projekt engagieren oder eine 20-köpfige Agentur für ein 12-monatiges Produktprojekt beauftragen. Der Umfang ändert sich; die Notwendigkeit schriftlicher Bedingungen nicht.

Sie sollten einen Softwareentwicklungsvertrag haben, wenn:

• Sie Softwareentwicklung auslagern. Insbesondere an Offshore- oder Remote-Teams, bei denen Unterschiede in der Gerichtsbarkeit informelle Vereinbarungen erschweren
• Massgeschneiderte Software erstellt wird. Je individueller die Arbeit, desto mehr muss das IP-Eigentum ausdrücklich dokumentiert werden
• Mehrere Entwicklungsphasen existieren. Meilensteinbasierte Zahlungen erfordern schriftliche Abnahmekriterien, um jede Phase auszulösen
• Sensible Daten oder Systeme involviert sind. Jedes Projekt, das Kundendaten berührt, benötigt Vertraulichkeits- und Sicherheitsklauseln
• Sie auf proprietären Frameworks aufbauen. Bereits vorhandener Code, der in massgeschneiderte Liefergegenstände integriert wird, schafft ohne klare Vereinbarung unangenehme Eigentumsfragen
• Sie über Ländergrenzen hinweg arbeiten. Geltendes Recht und Gerichtsstand müssen genannt werden, wenn Entwickler und Kunde in verschiedenen Ländern sitzen

Die kurze Antwort, wann Sie auf einen vollständigen SDA verzichten können: fast nie. Selbst sehr kurze, geringwertige Arbeiten, die durch eine umfassende Master Service Agreement geregelt werden, sollten ein schriftliches SOW als Anhang haben. Aber selbst dann würden Ihnen die meisten Anwälte raten, die Papierarbeit zu erledigen. Hier ist die Sache: Die Kosten für das Schreiben eines einseitigen SOW sind im Vergleich zu den Kosten eines Streits über den Umfang eines 'einfachen' Projekts vernachlässigbar.

Es gibt keine einzige SDA-Vorlage, die zu jedem Engagement passt, und wer Ihnen etwas anderes erzählt, will Ihnen etwas verkaufen. Die Vertragsstruktur muss zur Preisgestaltung und zum Umfang des Projekts passen. Und die Wahl der falschen Struktur schafft Anreize, die guten Ergebnissen entgegenwirken.

Festpreisverträge

Ein Festpreis-SDA funktioniert, wenn die Projektanforderungen vor Beginn der Entwicklung stabil und gut verstanden sind. Der Entwickler verpflichtet sich, einen definierten Umfang gegen eine vereinbarte Gesamtgebühr zu liefern. Die Budgetsicherheit ist der Hauptanreiz für Kunden. Das Risiko: Wenn sich herausstellt, dass die Anforderungen unzureichend spezifiziert wurden, übernimmt der Entwickler entweder die Mehrkosten oder es beginnen Streitigkeiten.

Zeit-und-Material-Verträge

T&M-Verträge sind sinnvoll für explorative Projekte, Frühphasenprodukte oder jede Situation, in der der vollständige Umfang nicht im Voraus definiert werden kann. Der Kunde zahlt für die tatsächlich geleisteten Stunden zu vereinbarten Sätzen. Sie erhalten Flexibilität; der Kompromiss ist Kostenungewissheit. Budgetobergrenzen und monatliche Decken helfen, dieses Risiko zu steuern.

Vereinbarungen über dedizierte Teams

Für Unternehmen, die ein konsistentes Remote-Engineering-Team benötigen (anstatt einer einmaligen Projektabwicklung), legt eine Dedicated-Team-Vereinbarung die Bedingungen für eine fortlaufende Beziehung fest. Vertragsmanagement für IT-Unternehmen umfasst typischerweise dieses Modell, wenn mit Outsourcing-Partnern gearbeitet wird.

MSA + SOW-Struktur

Größere Engagements trennen oft den rechtlichen Hauptrahmen (MSA) von den projektspezifischen Bedingungen (SOW). Der MSA behandelt IP, Vertraulichkeit, Haftung und Streitbeilegung einmalig; jedes SOW behandelt die spezifischen Liefergegenstände, den Zeitplan und die Bezahlung für ein bestimmtes Projekt.

Nicht alle Klauseln sind gleich gewichtig. Meiner Ansicht nach sind diese fünf Klauseln entscheidend für das Gelingen oder Scheitern von Verträgen. Dies sind diejenigen, bei denen fehlende oder vage Formulierungen reale Streitigkeiten verursachen.

1. Arbeitsumfang und Liefergegenstände

Beschreiben Sie, was gebaut wird, mit so viel Detail, dass jemand, der nicht am Projekt beteiligt ist, beurteilen könnte, ob es geliefert wurde. Funktionale Anforderungen, technische Spezifikationen, unterstützte Dienste und Leistungsbenchmarks gehören alle hierhin. Nennen Sie ausdrücklich, was nicht zum Umfang gehört.

Vager Umfang ist die häufigste Ursache für Software-Streitigkeiten. Die Realität ist, dass die meisten Kunden denken, sie seien klar gewesen. Die meisten Entwickler denken, sie hätten verstanden. Und keiner hat recht. "Eine Website erstellen" ist kein Umfang. "Eine responsive React/Next.js-Anwendung mit den in Anlage A aufgeführten Funktionen erstellen, die mobile Lighthouse-Performance-Werte von 90+ erreicht" ist ein Umfang.

2. Zahlungsbedingungen und Meilensteinplan

Listen Sie jede Zahlung auf: Betrag, auslösendes Ereignis und Zahlungsmethode. Meilensteinbasierte Zahlungen sollten an akzeptierte Liefergegenstände gebunden sein, nicht nur an Kalenderdaten. Definieren Sie die Währung, den Zahlungszeitraum (Net-15 oder Net-30 ist Standard) und die Strafe bei verspäteter Zahlung.

3. Eigentum an geistigem Eigentum

Dies ist die Klausel, die die meisten Kunden zu schnell lesen. Wem gehört der individuelle Code? Wem gehört vorbestehender Code, den der Entwickler einbindet? Ist Open-Source-Software abgedeckt? Der IP-Abschnitt des SDA bestimmt, wer die Software nach der Lieferung nutzen, ändern, verkaufen oder lizenzieren kann. Wenn dies falsch gemacht wird, sind die Folgen teuer. Siehe den Fall Cadence v. Avanti im IP-Abschnitt unten.

4. Vertraulichkeit

Der SDA sollte gegenseitige Vertraulichkeitsverpflichtungen enthalten. Der Entwickler darf keine Kundendaten oder geschützte Geschäftslogik offenlegen; der Kunde darf die geschützten Prozesse oder Werkzeuge des Entwicklers nicht offenlegen. Für solidere NDA-Bedingungen in einer eigenständigen Vereinbarung lohnt es sich, neben diesem auch den Leitfaden So erstellen Sie ein sicheres NDA und den NDA-Leitfaden für Auftragnehmer für Softwareunternehmen zu lesen.

5. Abnahmetest

Definieren Sie, wie der Kunde jeden Liefergegenstand prüft und akzeptiert. Das Prüffenster (5-10 Werktage sind üblich), das Feedback-Format, die Kriterien für das Bestehen und was passiert, wenn der Kunde nicht innerhalb des Prüffensters antwortet (fingierte Annahme).

6. Garantien

Der Entwickler sollte garantieren, dass die Software wie spezifiziert funktioniert, dass der Code original ist (oder ordnungsgemäß lizenziert) und dass die Lieferung keine IP-Rechte Dritter verletzt. Eine Garantiezeit für Fehlerbehebungen nach der Lieferung (typischerweise 30-90 Tage) schützt den Kunden vor Mängeln, die nach dem Start entdeckt werden.

7. Kündigungsbedingungen

Jede Partei sollte mit angemessener Frist kündigen können. Definieren Sie die Kündigungsfrist (30 Tage sind Standard), was mit laufenden Arbeiten geschieht und wie die Schlusszahlung bei vorzeitiger Kündigung berechnet wird. Eine Klausel zur Kündigung aus wichtigem Grund (die wesentliche Vertragsverletzung, Insolvenz oder Nichtzahlung abdeckt) sollte von der Kündigung aus Bequemlichkeit getrennt sein.

8. Geltendes Recht und Gerichtsstand

Nennen Sie das Land und das Bundesland/die Region, deren Recht für die Vereinbarung gilt. Wenn sich Entwickler und Kunde in verschiedenen Ländern befinden, entscheidet diese Klausel, welche Gerichte einen Streit behandeln würden. Lassen Sie sie nicht weg, weil sie sich formell anfühlt. Sie ist eine der praktisch wichtigsten Klauseln in einem grenzüberschreitenden Engagement.

Verwenden Sie diese Vorlage als Grundlage für Ihre Vereinbarung. Die durchschnittlichen Kosten für die Erstellung eines einfachen Vertrags belaufen sich laut World Commerce & Contracting auf 6.900 USD, und Vereinbarungen mittlerer Komplexität kosten rund 21.300 USD. Eine Vorlage spart nicht nur Zeit, sondern auch Geld. Ersetzen Sie alle eckigen Klammerfelder durch Ihre spezifischen Bedingungen. Beauftragen Sie bei komplexen Projekten einen Software-Anwalt mit der Überprüfung der endgültigen Version, insbesondere der IP- und Garantieabschnitte.

Für IT-Unternehmen, die Verträge mit mehreren Entwicklungspartnern verwalten, beseitigt die Zentralisierung aller Ihrer SDAs in einem einzigen Dokumentenmanagementsystem (mit Versionshistorie und manipulationssicheren Signaturen) das Chaos des Hin- und Hersendens von Word-Dokumenten per E-Mail.

Die obige Vorlage hat mehr als ein Dutzend auszufüllende Felder. So gehen Sie jedes einzelne an, ohne Lücken zu hinterlassen, die später Streitigkeiten verursachen.

Schritt 1: Definieren Sie den Umfang, bevor Sie den Vertrag berühren

Öffnen Sie die Vorlage erst, wenn Sie dokumentiert haben, was die Software tatsächlich tun muss. Funktionale Anforderungen, technische Einschränkungen, unterstützte Dienste, Integrationsabhängigkeiten. Alles davon. Der Umfangsabschnitt des SDA ist nur so gut wie das dahinter liegende Spezifikationsdokument.

Fügen Sie bei komplexen Projekten die vollständige Spezifikation als Anlage A bei und verweisen Sie in der Umfangsklausel darauf. Dies hält den Hauptvertrag lesbar, während die vollständigen technischen Details rechtlich verbunden sind.

Schritt 2: Erstellen Sie den Meilensteinplan

Arbeiten Sie rückwärts vom Liefertermin. Teilen Sie das Projekt in Phasen auf (Discovery, Design, Entwicklung, Test, Deployment) und weisen Sie jeder Phase einen Geldbetrag und ein Fälligkeitsdatum zu. Phasenzahlungen sollten ungefähr dem in jeder Phase gelieferten Wert entsprechen.

Faire Warnung: Dies dauert länger, als die meisten Parteien erwarten, insbesondere bei ersten Engagements. Ehrlich gesagt habe ich Teams gesehen, die 20 Minuten eingeplant und zwei Stunden gebraucht haben. Planen Sie 1-2 Stunden mit beiden anwesenden Seiten ein, um Meilensteine und Zahlungen richtig festzulegen.

Schritt 3: Adressieren Sie das IP-Eigentum ausdrücklich

Lesen Sie Abschnitt 3 sorgfältig durch und füllen Sie alle Lücken aus. Wenn der Entwickler proprietäre Frameworks oder Werkzeuge verwendet, die er vor diesem Projekt erstellt hat, listen Sie sie in der Carve-out-Klausel zur vorbestehenden Arbeit auf. Wenn Sie Open-Source-Bibliotheken verwenden, nennen Sie die Lizenzen.

Die Übertragung der individuellen Arbeit (Abschnitt 3.1) ist typischerweise die wichtigste Klausel für Kunden: Sie überträgt das Eigentum am gelieferten Code vom Entwickler auf Sie. Lassen Sie sie nicht vage.

Schritt 4: Legen Sie das Abnahmefenster und die Kriterien fest

Entscheiden Sie über das Prüffenster, bevor Sie es ausfüllen. Zehn Werktage sind üblich. Zwei Wochen geben beschäftigten Kunden genug Zeit, um den Liefergegenstand tatsächlich zu testen; alles Kürzere führt tendenziell zu Streitigkeiten, wenn Prüfer auf Reisen oder anderweitig beschäftigt sind.

Für Abschnitt 5 gehören die Abnahmekriterien in Anlage A. Schreiben Sie spezifische, prüfbare Kriterien: "Die mobile App lädt das Dashboard in unter 3 Sekunden auf einer 4G-Verbindung" ist besser als "die App sollte schnell sein."

Schritt 5: Wählen Sie das geltende Recht bewusst aus

Verwenden Sie für inländische Projekte das Heimatland/-bundesland des Entwicklers (sie sind mit den lokalen Gerichten besser vertraut). Für grenzüberschreitende Projekte kann eine der Parteien eine neutrale Gerichtsbarkeit bevorzugen. Das Recht von Delaware ist üblich für US-amerikanische Tech-Verträge; englisches Recht wird häufig für internationale Tech-Vereinbarungen verwendet. Was auch immer Sie wählen, beide Parteien müssen ausdrücklich zustimmen. Lassen Sie dies nicht leer.

Schritt 6: Unterschreiben Sie mit einer konformen eSignatur

Ein gescanntes Bild einer handschriftlichen Unterschrift auf einem PDF ist in den meisten Gerichtsbarkeiten rechtlich dünn. Elektronische Signaturen, die einen Dokument-Hash und ein zeitgestempeltes Abschluss-Zertifikat erzeugen, sind viel schwerer zu widerrufen. Nach dem ESIGN Act und UETA in den Vereinigten Staaten und eIDAS in der Europäischen Union haben elektronische Signaturen volle rechtliche Kraft für kommerzielle Vereinbarungen. Der Signaturdienst sollte jede Signatur an den kryptografischen Hash des Dokuments binden, sodass jede Änderung nach der Unterzeichnung sofort erkennbar ist.

Die meisten Vorlagen decken die Grundlagen ab. Dies sind die Klauseln, die aus billigen oder schnell entworfenen Vereinbarungen herausfallen. Und tendenziell am wichtigsten sind, wenn etwas schiefgeht. Allerdings sind in der Praxis die Klauseln, die Sie überspringen, immer diejenigen, die Sie am Ende brauchen.

Abnahmetest mit Bestehens-/Nichtbestehenskriterien

Abschnitt 5 in der obigen Vorlage definiert *wann* und *wie* der Kunde Liefergegenstände prüft. Was die meisten Vereinbarungen überspringen: die tatsächlichen Kriterien für das Bestehen. Ohne messbare Bestehens-/Nichtbestehens-Benchmarks wird die Annahme zu einer Verhandlung. Der Kunde kann immer argumentieren, dass die Software nicht "gut genug" ist. Schreiben Sie objektive Kriterien in Anlage A, bevor die Entwicklung beginnt.

Quellcode-Hinterlegung

Wenn Ihr Geschäft von individueller Software abhängt und der Entwickler aus dem Geschäft geht, benötigen Sie Zugang zum Quellcode. Eine Quellcode-Hinterlegungsklausel verlangt vom Entwickler, den Quellcode bei einem neutralen Hinterlegungsagenten zu hinterlegen. Wenn der Entwickler den Betrieb einstellt oder die Vereinbarung wesentlich verletzt, gibt die Hinterlegung den Code an den Kunden frei. Die meisten Kunden denken nie daran, danach zu fragen. Bis sie ihn brauchen. Hier ist die Sache: Hinterlegung ist keine Paranoia, wenn Ihr Geschäft von individuellem Code abhängt.

Haftungszeitraum nach der Lieferung

Abschnitt 7 begrenzt die Gesamthaftung, aber viele Vorlagen gehen nicht auf das zeitliche Fenster ein. Wann endet die Haftung? Wenn ein Defekt 18 Monate nach der Lieferung Datenverlust verursacht, haftet der Entwickler dann immer noch? Definieren Sie die Garantiezeit und das Haftungsfenster nach der Garantie ausdrücklich. Nach der Garantiezeit ist die einzige Verpflichtung des Entwicklers typischerweise, die von ihm verursachten Mängel zu beheben. Nicht Bugs, die durch Kundenmodifikationen eingeführt wurden.

Änderungskontrollprozess

Abschnitt 9 verlangt einen unterzeichneten Änderungsauftrag für Umfangsänderungen. Was die meisten Vereinbarungen vermissen: zu definieren, wer die Befugnis hat, Änderungsaufträge zu unterzeichnen. Wenn ein Projektmanager auf der Kundenseite mündlich eine neue Funktion anfordert und der Entwickler sie baut, schuldet der Entwickler dann Bezahlung? Nur wenn der Änderungsauftragsprozess befolgt wurde. Nennen Sie spezifische Rollen (nicht Einzelpersonen, deren Titel sich ändern), die die Befugnis haben, Änderungen zu autorisieren.

Einhaltung von Open-Source-Lizenzen

Die Linux Foundation berichtet, dass 92 % der kommerziellen Software Open-Source-Komponenten enthalten. Die Lizenz jeder Komponente legt Bedingungen für die Verwendung, Änderung und Verbreitung der Software fest. Eine GPL-lizenzierte Bibliothek kann beispielsweise Copyleft-Verpflichtungen auslösen, die Sie zwingen, Ihren proprietären Code als Open Source freizugeben. Der SDA sollte den Entwickler verpflichten, alle Open-Source-Komponenten offenzulegen und ihre Kompatibilität mit der beabsichtigten Nutzung des Kunden zu bestätigen.

IP-Eigentum ist die Klausel, die die meisten Kunden überfliegen. Und diejenige, bei der die Folgen eines Fehlers am grössten sind. Nach meiner Erfahrung ist es auch die Klausel, die die teuersten Rechtsstreitigkeiten erzeugt.

Der Fall Cadence v. Avanti: Eine 265-Millionen-Dollar-Lektion

Im Jahr 2002 stellte ein kalifornisches Gericht fest, dass die Avanti Corporation gestohlenen Cadence-Quellcode in einem konkurrierenden Produkt verwendet hatte. Die Schadenssumme erreichte 265 Millionen Dollar. Der Fall wird häufig in Software-IP-Rechtsstreitigkeiten zitiert, weil er veranschaulicht, was passiert, wenn das Eigentum am Quellcode strittig ist oder, schlimmer, wenn Code, der nie in ein Produkt hätte aufgenommen werden dürfen, dort landet. Eine gut ausgearbeitete IP-Klausel definiert nicht nur, wem der endgültige Liefergegenstand gehört. Sie verpflichtet den Entwickler, zu garantieren, dass kein IP von Dritten unzulässig integriert wurde.

Die vier IP-Modelle

Vorbestehende vs. massgeschneiderte Arbeit

Die meisten Entwickler bringen Werkzeuge, Frameworks und Bibliotheken mit, die sie vor Ihrem Projekt erstellt haben. Dies sind "vorbestehende Werke" oder "Hintergrund-IP". Der SDA sollte klar identifizieren, welche vorbestehende Arbeit integriert wird, und dem Kunden eine Lizenz zur Nutzung als Teil der gelieferten Software gewähren, ohne das Eigentum an diesen zugrunde liegenden Werkzeugen zu übertragen.

Für einen tieferen Blick darauf, wie die IP-Übertragung in einzelnen Entwicklerverträgen funktioniert, behandelt der Leitfaden IP-Übertragungsvertrag für Entwickler die Mechanik der Übertragung und Lizenzierung des Code-Eigentums.

Work-for-Hire-Doktrin

In den Vereinigten Staaten ist Code, der von einem Mitarbeiter im Rahmen seiner Anstellung geschrieben wird, automatisch ein Work-for-Hire, das dem Arbeitgeber gehört. Code, der von einem unabhängigen Auftragnehmer geschrieben wird, ist *nicht* automatisch ein Work-for-Hire. Der Auftragnehmer behält das Urheberrecht, es sei denn, die Vereinbarung überträgt es ausdrücklich. Diese Unterscheidung stolpert Kunden, die annehmen, dass sie Code besitzen, weil sie dafür bezahlt haben. Das tun sie nicht, ohne eine Übertragungsklausel.

Diese drei Dokumente werden ständig verwechselt. Die kurze Antwort: Verwenden Sie einen SDA für einmalige Projekte und MSA plus SOW für laufende Beziehungen. Jedes hat eine eigene Rolle, und die Verwendung des falschen (oder das Vermischen) schafft Verantwortungslücken.

Für einmalige Projekte deckt ein eigenständiger SDA (wie die Vorlage in diesem Leitfaden) alles ab. Für laufende Engagements mit einem Entwicklungspartner (bei denen Sie mehrere Projekte über die Zeit ausführen) ist eine MSA + SOW-Struktur effizienter. Der MSA verhandelt den rechtlichen Rahmen einmalig; jedes Projekt fügt ein neues SOW hinzu. Unser vollständiger Leitfaden zu Statements of Work behandelt die SOW-Struktur im Detail.

Einen unterzeichneten SDA zu erhalten, bedeutete früher Drucken, Scannen, E-Mailen und Hoffen, dass die Version der anderen Partei mit Ihrer übereinstimmt. Es gibt keinen guten Grund mehr, es so zu tun. Tatsächlich reduzieren Organisationen, die automatisiertes Vertragsmanagement verwenden, die Zykluszeiten laut Untersuchungen der Aberdeen Group um bis zu 50 %.

Was eine elektronische Signatur rechtsgültig macht

Nach dem ESIGN Act (USA) und eIDAS (EU) ist eine elektronische Signatur rechtsgültig für kommerzielle Vereinbarungen, wenn sie:

• Von jemandem mit der Absicht zu unterschreiben angebracht wird
• Mit dem konkreten zu signierenden Dokument verbunden ist
• Dem Unterzeichner zugeordnet werden kann
• Der Datensatz in einer Form gespeichert wird, die später abgerufen werden kann

Kryptografische Signaturen gehen weiter: Jede Signatur ist mathematisch an den Hash des Dokuments gebunden. Ändern Sie ein einzelnes Zeichen nach der Unterzeichnung, und der Hash ändert sich, sodass die Manipulation sofort erkennbar wird. Diese Nicht-Abstreitbarkeit macht die Vereinbarung vor Gericht verteidigungsfähig. Keine Partei kann später behaupten, das Dokument sei verändert worden.

Wie der Signatur-Workflow funktioniert

Dokumentenmanagement für IT-Unternehmen führt typischerweise mehrere SDAs, SOWs und NDAs gleichzeitig aus. Ein speziell entwickelter Workflow verhindert den Versionskontroll-Albtraum, der mit E-Mail-basiertem Signieren einhergeht:

1. 1.
   Laden Sie den fertiggestellten SDA in einen Vertragsmanagementdienst hoch
2. 2.
   Fügen Sie die E-Mail-Adresse jedes Unterzeichners und die Signaturreihenfolge hinzu
3. 3.
   Jede Partei erhält einen sicheren Signatur-Link. Kein Konto erforderlich, um zu unterschreiben
4. 4.
   Signaturen werden angebracht; der Dienst erstellt ein Abschluss-Zertifikat mit Zeitstempeln, IP-Adressen und dem Dokument-Hash
5. 5.
   Beide Parteien erhalten automatisch das vollständig ausgefertigte Dokument
6. 6.
   Der Audit-Trail wird unveränderlich gespeichert und ist für zukünftige Referenz oder Streitbeilegung zugänglich

An die Signatur gebundene Meilensteinzahlungen

Die nützlichste Funktion in einem modernen Vertragsdienst ist nicht die Signatur selbst. Es ist die Verbindung der Signatur mit dem, was als Nächstes geschieht. Wenn ein Entwickler einen Meilenstein liefert und der Kunde das Abnahmeformular unterschreibt, wird der Zahlungsauslöser automatisch ausgelöst. Keine manuelle Rechnungsverfolgung, keine Verwirrung wie "Ich dachte, Sie senden die Rechnung separat". Für Teams, die vertragsgebundene Zahlungen verwalten, beseitigt dies die Lücke zwischen Annahme und Rechnungsstellung.

Für eine vollständige Preisaufschlüsselung der Vertragsmanagement-Pläne behandelt die Preisseite von Chaindoc, was in jeder Stufe enthalten ist.