Neues Vertragsthema bei Entwicklungsprojekten: Projektplattformen

Egal, ob es einen ausführlichen Vertrag für das Projekt geben soll oder nicht, insbesondere aber wenn „agil“ gearbeitet wird, ist die Handhabung der Entwicklungs- und Projekt-Plattform eine vertragliche Regelung wert. Diese hat starke Gegensätze unter ein Dach zu bringen. Drei wichtige Antagonismen sind (zu allen Antagonismen von Projektplattformen Schneider, ITRB 8/2020):

• Datenschutz vs. Urheberrecht
• Datenbankschutz vs. Daten- und Geheimnisschutz
• Transparenz vs. Arbeitsrecht.

Hintergrund

Projektplattformen und deren Einsatz sind bislang kein übliches Thema für Projektverträge. Bei Verträgen zum „klassischen“ Vorgehen erscheint eine Regelung nicht erforderlich, bei Verträgen, die explizit agiles Vorgehen regeln, mag der Zugang zu Infrastruktur und deren Beistellung (z.B. unter „Mitwirkung“) vorgesehen sein. Typisch und regelgerecht (s. zum agilen Manifest Schröder/Stiemerling, ITRB 2019, 183) wäre bei Verträgen für agiles Vorgehen andererseits, dass entweder kein Vertrag oder nur ein Minimum vorliegt (s. Redeker, ITRB 2020, 147; zu Vergütung OLG Frankfurt a. M., Urt. v. 17.8.2017 - 5 U 152/16, CR 2017, 646).

Antagonistische Problemfelder:  Tatsächlich sind nicht nur die Beistellung der Plattform und der Zugang zu regeln. Vielmehr sind mit der Kooperationsform mittels Projektplattform Probleme verknüpft, in denen gegensätzliche rechtliche Anforderungen aufeinanderprallen und einen Ausgleich verlangen. Die drei wichtigsten dieser Problemfelder sind nicht unmittelbar mit dem Gefüge der Hauptpflichten, sondern eng mit der agilen Vorgehensweise verbunden.

1. Datenschutzrechtliche & urheberrechtliche Verantwortlichkeit

Der Kooperationscharakter bei agil/scrum legt sowohl Joint Control als auch gemeinsames Urheberrecht (s.a. Keye, ITRB 2020, 75) nahe, die scheinbar sogar zusammenpassen.

• Datenschutzrechtliche Anforderungen

Joint Control:  Eine BGB-Gesellschaft wäre als Joint Control zu sehen, Art. 26 DSGVO. Das datenschutzrechtliche Risiko des Art. 26 DSGVO, für die Partner nach außen zu haften, ist aber meist bei einem Projekt nicht erwünscht. Es könnte eine Zurechnung von Datenverarbeitung aller Subunternehmer eines Auftragnehmers gegenüber dem Auftraggeber wie auch umgekehrt erfolgen, sodass allein schon deshalb eine vertragliche Grundlage erstrebenswert erscheint, die das Innenverhältnis regelt. Wenn man das Entstehen von Joint Control vermeiden will, bleibt nicht viel anderes übrig, als den Kooperationsgedanken aufzugeben. „Collaboration“ ist aber fundamental für agil und insbesondere scrum.

Auftragsverarbeitung:  Wäre der Projektvertrag als Werkvertrag zu qualifizieren, jedenfalls nicht als BGB-Gesellschaft, wäre ein Auftragsverarbeitungs-Vertrag (Art. 28 DSGVO) für den Plattform-Betrieb sinnvoll, bei dem hinsichtlich der Mitarbeiterdaten des Auftraggebers dieser die Weisungshoheit hätte. Die gemeinsame Verwaltung und Nutzung der Daten, wäre dann insoweit allerdings aufzugeben.

• Urheberrecht

Miturheber:  Für die urheberrechtliche Qualifikation der Zusammenarbeit liegt Art. 8 UrhG nahe, was mangels anderweitiger Regelung dazu führt, dass die Rechte nur gemeinschaftlich ausgeübt werden könnten (Art. 8 Abs. 2 UrhG). Das ist eher noch weniger gewollt als Joint Control. Andererseits kann die Auswertung der Plattform dazu verhelfen, den jeweiligen Anteil der Beteiligten an der Schöpfung der Ergebnisse zu ermitteln (s. Welser/Hoppen, CR 2020, 350).

Bearbeitung & Vertrieb:  Für die evtl. Fortsetzung der Arbeiten mit Dritten benötigt der jeweilige Projektpartner das Bearbeitungs- und ggf. auch noch Vertriebsrecht. Gemäß § 8 Abs. 2 S. 1 Hs. 2 UrhG sind Änderungen des gemeinschaftlichen Werkes nur mit Einwilligung sämtlicher Miturheber zulässig. Bei Arbeitnehmern ist das unproblematisch, bei Freelancern ein Problem, da explizite Zustimmung bzw. Verzicht erforderlich.

Rechtseinräumung:  Es bestehen hinsichtlich der Rechtseinräumung der Teammitglieder gravierende Unterschiede für Auftraggeber und Auftragnehmer:

• Auftraggeber-Mitarbeiter:  die Mitarbeiter, die der Auftraggeber für Workshops, Team und Betreuung des Projekts (etwa auch als Stakeholder) beistellt, sind meist seine Angestellten. Wenn deren Tätigkeit und Mitwirkung im Rahmen ihrer Aufgabe liegt und schöpferischen Charakter hat, erfolgt eine Art automatische Rechtseinräumung an den Auftraggeber als Arbeitgeber, § 69b UrhG. Ob dieser schöpferische Grad der Leistung erreicht wird, ist eine andere Frage. Aber auch § 69b UrhG gilt nicht uneingeschränkt. Grundsätzlich müsste die Aufgabe, wenn nicht andere Vereinbarungen mit dem Angestellten getroffen sind, auch auf die fragliche Projekttätigkeit gerichtet sein, also etwa Anforderungen auszuformulieren (gehört wohl noch zum Job), Programmieren, Organisieren, Workshop-Beiträge usw. Das mag bei manchen Mitarbeitern aus der Fachabteilung nicht mehr zum Job gehören, sodass die Frage ist, ob der Automatismus des § 69b UrhG einsetzt.
• Auftragnehmer-Mitarbeiter:  Auf der Seite des Auftragnehmers werden sogenannte Freelancer eingeschaltet, für die der automatische Rechtsübergang nach § 69b UrhG nicht gilt. Es wäre also unbedingt zu empfehlen, zwecks Verwendbarkeit der Ergebnisse ohne Risiken, dass der Auftragnehmer mit seinen Subunternehmern entsprechenden Rechtseinräumungen schriftlich vornimmt. Das reicht aber nicht, um das Datenschutzproblem zu lösen.

Antagonismus:

• Datenschutzrechtlich ist die Verarbeitung der Daten der jeweils eigenen Mitarbeiter auf der Plattform evtl. noch durch Art. 6 DSGVO, § 26 BDSG gedeckt. Die Verarbeitung auch durch den jeweils anderen Vertragspartner und damit der für die Kooperation gewünschte Austausch der Daten ist nicht abgedeckt. Selbst wenn Joint Control gewünscht wäre, würde dies noch keine Rechtsgrundlage für diese Art der Verarbeitung der Daten bieten.
• Das urheberrechtliche Anliegen, für die Verwertung die Beiträge mit Hinweis auf den Bearbeiter zu dokumentieren und die Anteile danach zu ermitteln, stößt an datenschutzrechtliche Grenzen.

2. Projekt-Ende:  Datenbankschutz vs. Daten- und Geheimnisschutz

Spätestens bei Projektende prallen das Interesse jedes der Partner an der Herausgabe der Daten und Inhalte der Plattform – zusätzlich zum Code – und Datenschutzbelange aufeinander. Typisch für agile Projekte ist, dass es kein über den Fertigstellungsgrad deutlich definiertes Ende des Vertrags bzw. der erfolgreichen Erfüllung des Vertrags gibt. Die Rechtseinräumung ist auch bei agil eher nur für das (erfolgreiche) Projektende vorgesehen, wenn es überhaupt eine Regelung gibt (s. z.B. OLG Frankfurt a. M., Urt. v. 29.10.2013 – 11 U 47/13, CR 2014, 506 zur Wirkung der Freischaltung und Bezahlung).

• Wer „bekommt“ bzw. wem „gehört“ was?

Bei dieser Frage wird meist an den Quellcode gedacht. Weitaus weniger sichtbar ist die zu Grunde liegende Gestaltung der Rechte an der Plattform und deren weiteren Inhalten (teils Vorstufen zum Code). Will der Auftraggeber bei vorzeitigem Ende der Projektarbeit das Projekt mit einem Dritten fortsetzen und die Software erstellen, braucht er die bisherigen Ergebnisse in kommentierter Version und die Vorstufen („Entwicklungsmaterial“) zumindest, soweit diese noch nicht abgearbeitet sind.

Agile Konsequenz:  Die agile Kooperation ersetzt gerade die üblichen vertraglichen Vereinbarungen und deren Anlagen, so etwa das Lastenheft und auch das Pflichtenheft. Das Lastenheft wird substituiert durch Tickets, Cases, Stories usw., wobei eng zusammengearbeitet wird, so etwa bei Backlog, Sprintplanung und Review. Für diese agile Kooperation dient die Plattform, die häufig faktisch vom Auftragnehmer zur Verfügung gestellt wird, mit der die Tickets verwaltet, die Projektfortschritte erfasst und die Projektergebnisse festgehalten werden.

Tendenz:  Rein physikalisch/eigentumsrechtlich „gehören“ diese Inhalte bei dieser Konstellation tendenziell dem Auftragnehmer. Bei einer solchen Konstellation der Kooperation ist Auftragsrecht anwendbar, womit sich die Herausgabepflicht für das „Erlangte“ rechtfertigen ließe. Dem könnte das „Herstellerrecht“ entgegenstehen.

• Datenbankschutz:

Evtl. bilden Tickets, Stories, Cases und Testmaterialien (unabhängig davon, ob sie selbst urheberrechtlichen Schutz als Texte, Zeichnungen usw. genießen) in der Plattform eine Datenbank i.S. des §87a UrhG. Dann wäre die Frage, wer deren Inhaber, wer also der Hersteller ist. Das richtet sich danach, wer die wesentliche Investition getätigt hat. Das muss nicht der Auftraggeber sein, das könnten beide bzw. alle Vertragspartner sein. Jedenfalls hätte der Auftraggeber Interesse, die Datenbank herausverlangen zu können, auch wenn er nicht der Betreiber der Plattform ist. Dem könnten wiederum Datenschutzbelange wie bei 1.a) entgegenstehen.

• Datenschutz:

Unter Datenschutzaspekten gilt das Minimierungsgebot, auch die Pflicht zur Pseudonymisierung und auch die gegebenenfalls sehr wichtige Löschungspflicht. Das Problem der möglichen Auskunft und Bereitstellung einer Kopie der personenbezogenen Daten an Mitarbeiter gemäß Art. 15 Abs. 1 und 3 DSGVO, evtl. sogar unter Rekonstruktion alter Daten sei hier nur erwähnt (s. z.B. , LAG Baden-Württemberg, Urt. v. 20.12.2018 – 17 Sa 11/18, CR 2019, 304 m. Anm. Lensdorf und Korch/Chatard, CR 2020, 438 sowie Härting, CR 2019, 219, mit Vorschlägen zur Begrenzung des Anspruchs). Vereinfacht könnte man sagen, dass Daten nur dann, wenn sie unbedingt notwendig sind, verarbeitet werden dürfen und dies nur solange, wie dies der Fall ist. D.h. dass tendenziell möglichst früh zu löschen wäre.

Antagonismus:  Unter Gesichtspunkten der Rechte an den Ergebnissen wie auch an den Materialien kann die Löschung in erheblichem Widerspruch zum Interesse am Bestand des Datenmaterials insbesondere auch als Datenbank stehen. Insbesondere beim Ende des Projekts, gleich aus welchem Grund, wird der Auftraggeber mindestens ebenso wie der Auftragnehmer großes Interesse daran haben, eventuell für die Fortsetzung des Projekts durch Dritte an die zwischenzeitlich erreichten Ergebnisse und das angefallene Datenmaterial zu kommen. Das angefallene Datenmaterial ist besonders wichtig im Hinblick auf das Verständnis, welche Anforderungen etwa noch nicht umgesetzt sind, also die verbliebenen Tickets, Stories usw., die aber vielleicht schon aufbereitet sind. Die Rechtslage kann hier sehr gegensätzlich sein:

• Datenbankhersteller und Verantwortlicher sind nicht identisch bzw. müssen nicht zwingend die gleiche Rechtsperson sein.
• Die Löschung steht eventuell der Herausgabe entgegen (wenn etwa die Mitarbeiterleistungen abgerechnet sind).
• Zugriff:  Schließlich steht im Raum, dass der Server nur dem Auftragnehmer zusteht und vom Auftragnehmer dem Auftraggeber während der Projektlaufzeit zur Nutzung (unentgeltlich?) zur Verfügung stand, was sofort beendet werden kann, wenn auch das Projekt beendet ist. Damit hätte der Auftraggeber keinen Zugriff mehr.

• Geheimnisschutz

Geheimnisschutz und offene Teams passen nicht gut zusammen. Ob und inwieweit an Datenpools ein Geschäftsgeheimnis bestehen kann, wird stark vom Einzelfall und insbesondere davon abhängen, ob die konstitutiven Sicherheitsvoraussetzungen („angemessene Geheimhaltungsmaßnahmen" gem. § 2 Nr 1 Buchst b GeschGehG) erfüllt sind. Daran bestehen bei stark kooperativ ausgelegten Plattformen durchaus Zweifel, wenn offene Teams gebildet werden.

Antagonismus:  Je stärker die Teams sich selbst ihre Aufgaben verteilen und auch ihrer Zusammensetzung, was im Rahmen der Flexibilität sehr förderlich sein kann, umso weniger wird die nötige Sicherheit praktisch gegeben sein (schriftlich ließe sie sich einfordern, aber das Problem bleibt immer in der Praxis, ob das Maßnahmenbündel eingehalten wird).

3. Transparenz und Fortschrittskontrolle vs. Arbeitsrecht

Wie sich schon aus der Funktion als Mittel zur Projektverfolgung und Zuordnung von Aktivitäten nach ausführenden, Zeit und Ergebnis ableiten lässt, ist eine solche Projektplattform zwangsläufig auch immer geeignet zur Mitarbeiter-Kontrolle. Die Mitarbeiter werden in ihrer Leistung insoweit transparent.

Mitbestimmungspflicht:  Das bedeutet, dass eine solche Einrichtung mitbestimmungspflichtig ist (u.a. nach § 87 Abs. 1 Nr. 6 BetrVG). Beide Vertragspartner haben evtl. das Problem, zuerst eine Betriebsvereinbarung zu schließen, bevor die Projektarbeit mit Nutzung der Plattform beginnt. Die jeweilige Vereinbarung kann aber nicht das zugleich bestehende Datenschutzproblem für bei Verarbeitung der Daten der Mitarbeiter des jeweils anderen Vertragspartners leisten. Zudem besteht in der Praxis wohl eine Tendenz, die technische Einrichtung, hier die Plattform, sehr genau zu beschreiben und zu bezeichnen, sowie deren Funktionen mit einzubeziehen und gegebenenfalls auch zu beschränken. Das kann es schwierig machen bzw. verunmöglichen, die Plattform auszutauschen oder deren Update vorzunehmen.

Dilemma:  Inwieweit dabei auch noch die jeweilige Vertragspartei berechtigt und in der Lage sein soll, Kenntnis von diesen Daten zu nehmen, wäre eine typische Frage der Vertragsgestaltung und auch der datenschutzrechtlichen Regelungen, spielt aber auch bei der Frage der Mitarbeiter-Transparenz eine erhebliche Rolle. Insbesondere könnte durch zu starke Annäherung und Vermengung der beiderseitigen Mitarbeiter und damit auch der Mitarbeiter-Daten der äußere Eindruck von Arbeitnehmerüberlassung bzw. Leiharbeit entstehen oder anders: es kann sehr schwer werden, entkräftendes Material aufzubieten falls dieser Gedanke widerlegt werden müsste (s.a. Antoine/Conrad in: Schneider, Handbuch EDV-Recht, 5. Aufl. 2017, C. Arbeitsvertragsrecht; Martina, CR 2019, 339; Kühn/Wulf, CR 2018, 417).

Antagonismus:  Die Funktion des Projekts baut auf ein Werkzeug auf, dessen Verwendung noch der Beteiligung weiterer Gremien und erfolgreicher Verhandlungen bedarf, die - ähnlich wie das Datenschutzthema- zu Minimal-Lösungen tendieren.

Fazit für die vertragliche Regelung

Die Parteien sollten das Thema der Beistellung der Projektplattform und deren Nutzung regeln, auch wenn etwa bei agil bzw. scrum vertragliche Regelungen verpönt sind. Die Notwendigkeit der Regelung gilt auch für traditionelle Verträge, bei denen Entwicklungsplattformen eingesetzt werden. Die oben dargestellten Gegensätze der diversen Problem- und Themenfeldern verlangen einen Ausgleich durch vertragliche Regelungen. V.a. für den Datenschutz, aber auch für Arbeits- und Urheberrecht sind die Regelungen für konstruktive Zusammenarbeit statt Überraschungen durch „No-Gos“ notwendig.