Gegenstand der Nutzungsbedingungen

Die nachstehenden Nutzungsbedingungen regeln die Inanspruchnahme des Service „Software Engineering Services“ (im Folgenden „GitLab“) betrieben durch das IT Center der RWTH Aachen University. Zweck des Dienstes ist die sichere und versionierte Speicherung und Verwaltung von Software-Code, der im Rahmen von Forschung und Lehre entwickelt wird.

GitLab wird auf zwei unterschiedlichen Serverinstanzen angeboten.

Die Instanz „git.rwth-aachen.de“ wird mit einer „GitLab for Education“ Lizenz betrieben und darf nur für die Ausbildung von Studierenden und das Entwickeln von OpenSource Software ohne Gewinnerzielungsabsicht genutzt werden. Die Einhaltung der zugrundeliegenden Lizenzbedingungen von GitLab (https://about.gitlab.com/terms/#edu-oss) ist dabei verpflichtend.

Die Instanz „git-ce.rwth-aachen.de“ unterliegt einer „Community Edition“ Lizenz. Sie bietet gegenüber der „GitLab for Education Edition“ weniger Funktionen, die Lizenzbedingungen erlauben aber eine freiere Nutzung.

Die hier aufgeführten Nutzungsbedingungen müssen von Nutzenden vor der Nutzung des Services beim Login in die jeweilige Instanz akzeptiert werden. Nachdem die Nutzungsbedingungen in GitLab einmal bestätigt wurden, ist keine weitere Bestätigung notwendig, sofern die Nutzungsbedingungen sich nicht ändern. Möchte ein Nutzender die Nutzungsbedingungen in GitLab erneut einsehen so kann er/sie diese über die URL https://git.rwth-aachen.de/-/users/terms bzw. https://git-ce.rwth-aachen.de/-/users/terms erneut abrufen. Zusätzlich werden die aktuellen Nutzungsbedingungen in unserem Dokumentationsportal veröffentlicht.

Bei Verstoß gegen diese Nutzungsbedingungen behalten wir uns die Sperrung einzelner Projekte und Accounts vor.

Inhalte der Projekte

Die zentralen GitLab-Instanzen dienen der Verwaltung von Softwareprojekten im Rahmen von Forschung, Lehre und Verwaltung.

Dabei muss inhaltlich zwischen beiden Instanzen unterschieden werden. Das GitLab (git) der RWTH Aachen in der Ultimate for Education Edition ist lizenzbedingt ausschließlich für die Nutzung im Rahmen der Lehre oder für OpenSource lizenzierte Projekte ohne Gewinnerzielungsabsicht bestimmt. Das GitLab (git-ce) der RWTH Aachen in der Communiy Edition ist zusätzlich auch für Zwecke der Forschung und Verwaltung verfügbar.

Die GitLab-Instanzen werden über ein nächtliches Backup gesichert. Dieses Backup dient allerdings nur einer möglichen Wiederherstellung des Gesamtsystems im Fehlerfall und nicht zur Wiederherstellung einzelner Nutzendendaten (Repositorys). Dieses Backup wird 365 Tage aufbewahrt und enthält einen Datenbank-Dump sowie Konfigurationen, die zur Wiederherstellung der GitLab-Instanzen als Gesamtsystem notwendig sind. Die einzelnen Repository-Daten werden nicht gesichert. Folglich ist es nicht möglich, ein gelöschtes Repository wiederherzustellen. Aus diesem Grund ist der Nutzende selbst dafür verantwortlich, seine Repository-Daten (Nutzdaten) zu sichern. LFS (Large File Storage), Registry, Artefakte und Uploads werden im von der GitLab-Instanzen seperaten Object-Storage (S3) gespeichert. Diese Daten sind georedundant auf mehrere Standorte verteilt und werden nicht durch ein Backup gesichert.

Rechte und Pflichten der Projektinhaber

Die Projektinhabenden übernehmen die Administration von Mitgliedern, sowie die Konfiguration innerhalb ihrer GitLab-Projekte. Die Rolle des Projektinhabenden setzt einen geeigneten Single Sign-On-Account (DFN-AAI) voraus. Die Accounts von GitLab Nutzenden sind personengebunden und dürfen nicht weitergegeben werden. Somit übernehmen die jeweiligen Nutzenden die volle Verantwortung für ihren persönlichen Account und müssen die Zugangsinformationen sorgfältig und vertraulich aufbewahren. Darüber hinaus übernehmen die Projektinhabenden die Verantwortung für die Inhalte ihrer Projekte. Insbesondere trägt der Projektinhabende bei der Nutzung von GitLab die Verantwortung dafür, dass die Lizenzbedingungen von GitLab eingehalten werden.

Die Nutzenden sind verpflichtet, eine primäre E-Mail-Adresse im Account zu hinterlegen. Diese E-Mail-Adresse muss erreichbar sein und sollte regelmäßig überprüft werden. An diese E-Mail-Adresse werden wichtige Informationen übermittelt.

User-Lifecycle

Der GitLab User-Lifecycle ist ein Prozess, der es ermöglicht, veraltete User-Accounts, die nicht mehr genutzt werden, aus dem System zu entfernen. Dieser Prozess unterscheidet sich bei den beiden Instanzen git.rwth-aachen.de und git-ce.rwth-aachen.de, da hier unterschiedliche Nutzendengruppen tätig sind.

Verlust der Hochschulzugehörigkeit

GIT

Nutzende mit Studierenden- und/oder Mitarbeitendenstatus der RWTH Aachen University oder von Hochschulen aus dem NFDI4Ing Konsortium, können sich über den SSO (Single Sign-On) Login einloggen und erhalten so einen Account auf der Instanz, mit der Berechtigung zum Erstellen von persönlichen GitLab Projekten und Gruppenprojekten. Nutzende die sich mit einem GitHub Account einloggen, erhalten nur die Berechtigung zur Mitarbeit in bestehenden Projekten, zu denen sie eingeladen werden müssen. Da die Nutzenden, die sich ausschließlich über GitHub authentifizieren, keine eigenen Projekte erstellen können wird für diese Nutzenden keine Lizenz benötigt. Sie werden als sogenannte externe Nutzer markiert.

Verliert nun ein GitLab Nutzender seinen Studierenden- oder Mitarbeitendenstatus, hat er keine Berechtigung mehr GitLab weiterhin zu nutzen und eine Lizenz zu verwenden. In diesem Fall wird der Nutzende in GitLab blockiert und kann nicht mehr auf seine Projekte zugreifen.

Während des User-Lifecycles wird zunächst geprüft, ob der Nutzende Gruppenprojekte besitzt, in denen er als einziger Projektinhabender eingetragen ist. Sollte dies der Fall sein, so werden automatisch alle Gruppenmitglieder des jeweiligen Gruppenprojektes darüber informiert, dass ein neuer Gruppeninhabender benannt werden muss. Sollte sich hier innerhalb einer Frist von acht Wochen niemand per E-Mail an servicedesk@itc.rwth-aachen.de melden, so wird ein vom IT Center bereitgestellter Systemnutzer als Inhaber eingetragen, damit das Gruppenprojekt weiterhin nutzbar bleibt. Ist der Nutzende nicht alleiniger Inhaber eines Gruppenprojekts besteht kein Handlungsbedarf für dieses Projekt.

Persönliche Projekte werden, nachdem der Nutzende blockiert wurde, exportiert und diesem Nutzenden über einen Download-Link zur Verfügung gestellt. Gruppenprojekte werden aufgrund des Inhaber-Wechsels nicht automatisiert exportiert. Der Nutzende wird über die anstehende Löschung in 12 Wochen per E-Mail informiert und erhält zeitgleich den Download Link zu seinem Projekt-Export. Nach Ablauf von acht der 12 Wochen erfolgt eine Erinnerung per E-Mail, dass die Löschung kurz bevor steht.

Nach dem Ablauf weitere vier Wochen wird der Nutzende noch ein letztes Mal über die Löschung informiert. Der bereitgestellte Export wird dann für weitere vier Wochen vorgehalten und dann automatisch gelöscht.

GIT-CE

Voraussetzung für die Nutzung von GitLab (git-ce) ist die Zugehörigkeit zu einer am NFDI4Ing Konsortium beteiligten Universitäten und Einrichtungen, wozu auch die RWTH Aachen University zählt. Der Studierenden- oder Mitarbeitendenstatus wird in diesem Fall nicht geprüft. Das bedeutet, dass auch RWTH-Partner den Dienst nutzen können.

Sobald die oben genannte Voraussetzung nicht mehr gegeben ist, werden die betroffenen Nutzenden für die Nutzung von GitLab ausgeschlossen. In dem Fall, dass ein Nutzender zu spät bemerkt, dass er die Nutzungsberechtigung verloren hat und das Projekt nicht mehr rechtzeitig exportieren konnte, kann dieser einen Export des persönlichen Projektes beantragen. Dazu ist es notwendig eine E-Mail an servicedesk@itc.rwth-aachen.de zu senden.

GitHub Benutzer werden in GitLab als externe Benutzer behandelt, d.h. sie können in Projekten mitarbeiten, aber keine eigenen Projekte erstellen. Demnach ist ein Export von Projekten nicht vorgesehen.

Inaktivität

Hat sich ein GitLab Nutzender seit 24 Monaten weder eingeloggt, noch Änderungen an einem Projekt vorgenommen (commit, push), so gilt dieser Nutzende als inaktiv.

Der User-Lifecycle Prozess soll in diesem Fall sicherstellen, dass sich keine unnötigen Daten ansammeln, insbesondere keine persönlichen Daten von Nutzenden. Daher werden Nutzende die GitLab 24 Monate nicht genutzt haben, per E-Mail über die anstehende Löschung in 12 Wochen informiert. Nach acht vergangenen Wochen erhält der Nutzende eine Erinnerungsmail. Gibt es auch nach weiteren vier Wochen keine Nutzung von GitLab, so wird der Nutzende gelöscht.

Dazu wird zunächst überprüft, ob der Nutzende alleiniger Inhaber eines Gruppenprojektes ist. Ist dies der Fall werden alle Gruppenmitglieder informiert, dass ein neuer Gruppeninhaber benannt werden muss. Sollte sich hier innerhalb der acht Wochen niemand via E-Mail an servicedesk@itc.rwth-aachen.de melden, so wird ein vom IT Center bereitgestellter Systemnutzer als Inhaber eingetragen, damit das Gruppenprojekt weiterhin nutzbar bleibt. Ist der Nutzende nicht alleiniger Inhaber eines Gruppenprojekts besteht kein Handlungsbedarf.

Bevor der Account des inaktiven Nutzenden gelöscht wird, werden die persönlichen Projekte exportiert, sofern vorhanden. Der Download-Link zum Export, sowie eine letzte Information über die Löschung des Accounts, werden dem Nutzenden abschließend per E-Mail zugesandt.

Der bereitgestellte Export wird dann für weitere vier Wochen vorgehalten und anschließend automatisch gelöscht.

Einmalige Anmeldung ohne Nutzung

Hat sich ein GitLab Nutzender einmalig angemeldet und damit einen Account erstellt, diesen aber innerhalb von 12 Wochen nicht wieder genutzt, also keine eigenen Projekte erstellt und auch an keinem Projekt mitgearbeitet, so wird dieser Account gelöscht und der Nutzende per E-Mail darüber informiert.

Hinweise zur Löschung

Die Löschung eines Nutzenden-Accounts meint nicht nur das Löschen eines Benutzers, sondern auch das Löschen aller Projekte in seinem Namensraums. Ein Namensraum beinhaltet alle persönlichen Projekte, dabei ist es irrelevant ob jemand anderer in dem Projekt Maintainer ist oder nicht. Es ist ebenso irrelevant ob es öffentliche, private oder interne Projekte sind. Alle Projekte im Namensraum werden gelöscht. Das ist technisch von der Anwednung so vorgesehen.

Beispiel:

User: MeinBeispielUser

Namespace: https://git.rwth-aachen.de/meinbeispieluser

Projekte: MeinBeispielProjekt (https://git.rwth-aachen.de/meinbeispieluser/meinbeispielprojekt)

Im Projekt "MeinBeispielProjekt" gibt es weitere 20 Beteiligte und 3 weitere Maintainer. Der Nutzer "MeinBeispielUser" verliert die Berechtigung GitLab zu nutzen, weil er nicht mehr an der RWTH Aachen studiert. Der Nutzer wurde wie eingangs beschrieben angeschrieben und über die anstehende Löschung informiert. Nach 12 Wochen wird nun der Nutzer "MeinBeispielUser" gelöscht und damit auch sein Projekt "MeinBeispielProjekt". Die 23 anderen Nutzenden können nun auch nicht mehr auf das Projekt "MeinBeispielProjekt" zugreifen, da dieses nach der Löschung nicht mehr existiert.

Daher nochmal der folgende explizite Hinweis:

Jedem Projektinhaber muss bewusst sein, dass mit seinem Ausscheiden auch Projekte, die ggf. für andere Teilnehmende ungemein wichtig sind, mit dem Erlöschen des Namespace gelöscht sind. Daher sollte vor dem Ausscheiden aus der RWTH ein Export des Projektes gemacht werden. Sollte jemand anderes an dem Projekt weiterarbeiten, so ist demjenigen der Export zu übermitteln. Das sind Schritte die zu einer angemessenen Übergabe von Projekten gehören. Es ist davon auszugehen, dass dies jedem Teilnehmenden bewusst ist, denn ein Projekt Restore von einzelnen Projekten ist nicht vorgesehen.

Projekt-Lifecycle

Der Projekt-Lifecycle stellt sicher, dass inaktive GitLab Projekte zeitnah entfernt werden, um notwendige Ressourcen für andere, aktive Projekte bereitstellen zu können. Wurde ein GitLab Projekt 24 Monate lang nicht genutzt, wird automatisch der GitLab Projekt Lifecycle Prozess für dieses Projekt aktiv. Gibt es wichtige Gründe, ein Projekt länger als 24 Monate ungenutzt auf GitLab abzulegen, so sieht der Lifecycle eine Whitelist für solche Projekte vor. Dabei wird das Projekt standardmäßig für ein weiteres Jahr, ab dem Datum der Whitelist-Eintragung, aus dem Lifecycle ausgeschlossen. Nutzende die einen wichtigen Grund vorbringen, können Ihr Projekt mit einem Verlängerungsantrag per E-Mail an servicedesk@itc.rwth-aachen.de auf die Whitelist setzen lassen. Es ist dem Nutzenden zusätzlich jederzeit möglich das Projekt in GitLab zu archivieren, wodurch es ausschließlich für lesende Zugriffe verfügbar ist und vom Lifecycle ausgeschlossen wird. Außerdem wird ein Projekt automatisch aus dem Lifecycle Prozess entfernt, sollte es wieder Aktivität im Projekt geben. Das sind beispielsweise Commits, Issues, Kommentare, Milestones, Wikis oder Mitgliedschaftsänderungen.

Da es sich bei GitLab Projekten sowohl um persönliche als auch um Gruppenprojekte handeln kann, muss beim Projekt Lifecycle zwischen diesen beiden Projektarten unterschieden werden.

Bei einem persönlichen Projekt wird der Projektinhabende zunächst automatisiert per E-Mail informiert, dass sein Projekt seit 24 Monaten nicht genutzt wurde und es wird die automatische Löschung des Projektes angekündigt. Projektinhabender ist derjenige, in dessen Namensraum sich das Projekt befindet.

Der Projektinhabende hat nun 25 Wochen Zeit sich zu melden und einen Eintrag auf die Whitelist zu beantragen, das Projekt zu archivieren oder eine Änderung an dem Projekt durchzuführen. Nach dieser Änderung gilt das Projekt im nächsten Prüfvorgang wieder als aktiv. Wenn innerhalb von 12 Wochen keine nutzerseitige Aktion erfolgt, wird die erste Erinnerungsmail versendet. Die zweite Erinnerung erfolgt daraufhin nach weiteren 12 Wochen. Hat sich auch nach einer weiteren Woche nichts am Status des Projekts geändert, so wird angenommen, dass das Projekt nicht mehr genutzt und auch nicht mehr benötigt wird. Dies führt dazu, dass das Projekt exportiert und anschließend gelöscht wird. Der Projektinhaber wird per E-Mail über die Löschung des Projektes informiert und erhält einen Download-Link über den die exportierten Daten noch vier Wochen heruntergeladen werden können. Nach Ablauf dieser vier Wochen ist der Download-Link ungültig und der Export wird ebenfalls gelöscht.

Bei einem Gruppenprojekt unterscheidet sich der Prozess dahingehend, dass die Benachrichtigungen per E-Mail an alle Projektinhaber gesendet werden. Dies schließt auch vererbte Gruppenberechtigungen aus übergeordneten Gruppen mit ein.

Rechte und Pflichten der Projektbeteiligten

Die Accounts der Projektbeteiligten sind personengebunden und dürfen nicht weitergegeben werden. Somit übernehmen die Projektbeteiligten die volle Verantwortung für ihren persönlichen Account und die sorgfältige Aufbewahrung der Zugangsinformationen. Projektbeteiligte Personen die keinen Single Sign-On Account haben und sich über einen GitHub-Account einloggen, können erst nach Hinzufügen durch einen Projektinhaber an bestehenden Projekten mitarbeiten, jedoch keine eigenen Projekte erstellen.

Quota

Je Projekt wird per Default ein Quota von 2 GB eingeräumt. In begründeten Ausnahmefällen kann diese Quota-Grenze erhöht werden. Hierzu ist eine E-Mail an das IT-Servicedesk zu senden und der Mehrbedarf zu begründen. Sollte das Quota überschritten werden, erfolgt eine automatisierte E-Mail-Benachrichtigung an den Projektinhaber mit der Bitte um Reduzierung des Datenbestandes. Sollte dieser Bitte nicht nachgekommen werden und kein Antrag auf Mehrnutzung gestellt werden, behalten wir uns vor, das Projekt zu sperren.

Kosten

Die Nutzung von GitLab ist kostenfrei; ein Rechtsanspruch auf Registrierung und Nutzung besteht nicht.

Sicherheit

Das IT Center übernimmt die Verantwortung für den Betrieb von GitLab. Dies umfasst die (virtuelle) Hardware der Server, die Betriebssysteme sowie die installierte Software. Das IT Center übernimmt keine Haftung für Schäden, die unter anderem durch die Nutzung von GitLab entstehen.

Haftung

Die RWTH haftet unbeschränkt bei Vorsatz oder grober Fahrlässigkeit, für die Verletzung von Leben, Leib oder Gesundheit und nach den Vorschriften des Produkthaftungsgesetzes.
Bei leicht fahrlässiger Verletzung einer Pflicht, die wesentlich für die Erreichung des Vertragszwecks ist (Kardinalpflicht), ist die Haftung der RWTH der Höhe nach begrenzt auf den Schaden, der nach der Art des fraglichen Geschäfts vorhersehbar und typisch ist.
Eine weitergehende Haftung der RWTH besteht nicht.
Die vorstehende Haftungsbeschränkung gilt auch für die persönliche Haftung der Mitarbeitenden, Vertretenden und Organe der RWTH.

Datenschutz

Die Erhebung, Nutzung und Verwendung personenbezogener Daten erfolgt unter Beachtung der einschlägigen Datenschutzbestimmungen. Insbesondere werden keine personenbezogenen Daten unbefugt an Dritte weitergegeben.