Object of the Terms of Use

The following Terms of Use govern the use of the service "Software Engineering Services" (hereinafter referred to as "GitLab") operated by the IT Center of RWTH Aachen University. The purpose of the service is the secure and versioned storage and management of software code developed in the context of research and teaching.

GitLab is offered on two different server instances.

The instance "git.rwth-aachen.de" is operated with a "GitLab for Education" license and may only be used for the education of students and the development of open source software without the intention of making a profit. Compliance with the underlying license terms of GitLab (https://about.gitlab.com/terms/#edu-oss) is mandatory.

The instance "git-ce.rwth-aachen.de" is subject to a "Community Edition" license. Compared to the "GitLab for Education Edition", it offers fewer functions, but the license conditions allow a freer use.

The terms of use listed here must be accepted by users before using the service when logging into the respective instance. Once the Terms of Use have been confirmed in GitLab, no further confirmation is required unless the Terms of Use change. If a User wishes to view the Terms of Use in GitLab again, he/she can retrieve them again via the URL https://git.rwth-aachen.de/-/users/terms or https://git-ce.rwth-aachen.de/-/users/terms. In addition, the current terms of use are published in our documentation portal.

In case of violation of these terms of use, we reserve the right to block individual projects and accounts.

Contents of the projects

The central GitLab instances are used to manage software projects in the context of research, teaching and administration.

In terms of content, a distinction must be made between the two instances. The GitLab (git) of RWTH Aachen University in the Ultimate for Education Edition is intended exclusively for use in the context of teaching or for open source licensed projects without the intention of making a profit. RWTH Aachen University's GitLab (git-ce) in the Communiy Edition is additionally available for research and administrative purposes.

The GitLab instances are backed up via a nightly backup. However, this backup is only used for a possible recovery of the entire system in case of failure and not for the recovery of individual user data (repositories). This backup is kept for 365 days and contains a database dump and configurations necessary to restore the GitLab instances as a whole system. The individual repository data is not backed up. Consequently, it is not possible to restore a deleted repository. For this reason, users are responsible for backing up their own repository data (payload data). LFS (Large File Storage), registry, artifacts and uploads are stored in the object storage (S3) separate from the GitLab instances. This data is geo-redundantly distributed across multiple sites and is not backed up.

Rights and duties of the project owners

The project owners take over the administration of members, as well as the configuration within their GitLab projects. The role of project owner requires a suitable single sign-on account (DFN-AAI). The accounts of GitLab users are personal and may not be passed on. Thus, the respective users assume full responsibility for their personal account and must keep the access information carefully and confidentially. In addition, project owners assume responsibility for the content of their projects. In particular, when using GitLab, the project owner is responsible for ensuring that GitLab's license terms are adhered to.

Users are required to provide a primary email address in the account. This e-mail address must be accessible and should be checked regularly. Important information is transmitted to this e-mail address.

User Lifecycle

The GitLab user lifecycle is a process that enables the removal of obsolete user accounts that are no longer used from the system. This process differs for the two instances git.rwth-aachen.de and git-ce.rwth-aachen.de, as different user groups are active here.

Loss of university affiliation

GIT

Users with student and/or employee status from RWTH Aachen University or from universities in the NFDI4Ing consortium can log in via the SSO (Single Sign-On) login and receive an account on the instance with permission to create personal GitLab projects and group projects. Users who log in with a GitHub account will only receive permission to contribute to existing projects, to which they must be invited. Since users who only authenticate via GitHub cannot create their own projects, no license is required for these users. They are marked as so-called external users.

If a GitLab user loses his student or employee status, he is no longer authorized to continue using GitLab and to use a license. In this case, the user is blocked in GitLab and can no longer access their projects.

During the user lifecycle, the system first checks whether the user has group projects in which he is the only project owner. If this is the case, all group members of the respective group project are automatically informed that a new group owner must be named. If no one responds by e-mail to servicedesk@itc.rwth-aachen.de within a period of eight weeks, a system user provided by the IT Center will be entered as the owner so that the group project can continue to be used. If the user is not the sole owner of a group project, no action is required for this project.

Personal projects are exported after the user has been blocked and made available to this user via a download link. Group projects are not exported automatically due to the change of owner. The user will be informed about the upcoming deletion in 12 weeks by e-mail and will receive the download link to his project export at the same time. After eight of the 12 weeks have expired, a reminder is sent by e-mail that deletion is imminent.

After the expiration of another four weeks, the user will be informed one last time about the deletion. The provided export is then kept for another four weeks and then automatically deleted.

GIT-CE

The prerequisite for using GitLab (git-ce) is membership of a university or institution participating in the NFDI4Ing consortium, which includes RWTH Aachen University. Student or employee status is not checked in this case. This means that RWTH partners can also use the service.

As soon as the above-mentioned requirement is no longer met, the affected users will be excluded from using GitLab. In the case that a user notices too late that he has lost the usage authorization and could not export the project in time, he can request an export of the personal project. To do this, it is necessary to send an email to servicedesk@itc.rwth-aachen.de.

GitHub users are treated as external users in GitLab, i.e. they can contribute to projects but cannot create their own projects. Accordingly, exporting projects is not provided.

Inactivity

If a GitLab user has neither logged in nor made changes to a project (commit, push) for 24 months, this user is considered inactive.

In this case, the user lifecycle process is intended to ensure that no unnecessary data accumulates, in particular no personal data of users. Therefore, users who have not used GitLab for 24 months will be informed by email about the upcoming deletion in 12 weeks. After eight weeks have passed, the user will receive a reminder email. If there is still no use of GitLab after another four weeks, the user will be deleted.

First, it is checked whether the user is the sole owner of a group project. If this is the case, all group members are informed that a new group owner must be named. If no one responds via e-mail to servicedesk@itc.rwth-aachen.de within eight weeks, a system user provided by the IT center will be entered as the owner so that the group project can continue to be used. If the user is not the sole owner of a group project, no action is required.

Before the account of the inactive user is deleted, the personal projects are exported, if available. The download link for the export, as well as final information about the deletion of the account, will be sent to the user by e-mail.

The provided export will then be kept for another four weeks and then automatically deleted.

One-time registration without use

If a GitLab user has registered once and thus created an account, but has not used it again within 12 weeks, i.e. has not created any own projects and has not collaborated on any project, this account will be deleted and the user will be informed of this by e-mail.

Notes on deletion

Deleting a user account means not only deleting a user, but also deleting all projects in his namespace. A namespace contains all personal projects, it is irrelevant if someone else is maintainer in the project or not. It is also irrelevant if they are public, private or internal projects. All projects in the namespace will be deleted. This is technically intended by the application.

Example:

User: MeinBeispielUser

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

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

In the project "MeinBeispielProjekt" there are 20 more participants and 3 more maintainers. The user "MeinBeispielUser" loses the authorization to use GitLab because he is no longer a student at RWTH Aachen. The user was contacted as described above and informed about the upcoming deletion. After 12 weeks the user "MeinBeispielUser" will be deleted and with it his project "MeinBeispielProjekt". The 23 other users can access now also no more to the project "MeinBeispielProjekt", since this does not exist after the deletion any longer.

Therefore again the following explicit reference:

Each project owner must be aware that with his departure also projects, which are possibly immensely important for other participants, are deleted with the extinction of the namespace. Therefore, an export of the project should be made before leaving the RWTH. If someone else continues to work on the project, the export should be transferred to them. These are steps that belong to an appropriate handover of projects. It can be assumed that every participant is aware of this, because a project restore of individual projects is not intended.

Project lifecycle

The project lifecycle ensures that inactive GitLab projects are removed in a timely manner to provide necessary resources for other, active projects. If a GitLab project has not been used for 24 months, the GitLab Project Lifecycle process automatically becomes active for that project. If there are important reasons to keep a project unused on GitLab for longer than 24 months, the lifecycle provides a whitelist for such projects. By default, the project is excluded from the lifecycle for an additional year from the date of whitelisting. Users with an important reason can have their project whitelisted by sending an extension request by email to servicedesk@itc.rwth-aachen.de. It is also possible for the user to archive the project in GitLab at any time, making it available for read-only access and excluding it from the lifecycle. In addition, a project is automatically removed from the lifecycle process if there is activity in the project again. This includes commits, issues, comments, milestones, wikis, or membership changes.

Because GitLab projects can be both personal and group projects, the project lifecycle must distinguish between these two types of projects.

In the case of a personal project, the project owner is first automatically informed by email that his project has not been used for 24 months and the automatic deletion of the project is announced. The project owner is the person in whose namespace the project is located.

The project owner now has 25 weeks to get in touch and request an entry on the whitelist, archive the project or make a change to the project. After this change, the project is considered active again in the next review process. If no user action is taken within 12 weeks, the first reminder email is sent. The second reminder is then sent after another 12 weeks. If there has been no change in the status of the project after a further week, it is assumed that the project is no longer being used and is also no longer required. This leads to the project being exported and subsequently deleted. The project owner is informed by e-mail about the deletion of the project and receives a download link via which the exported data can be downloaded for another four weeks. After these four weeks, the download link is invalid and the export is also deleted.

For a group project, the process differs in that notifications are sent to all project owners via email. This also includes inherited group permissions from parent groups.

Rights and duties of the project participants

The accounts of the project participants are personal and may not be passed on. Thus, the project participants take full responsibility for their personal account and the careful storage of the access information. Project participants who do not have a single sign-on account and log in via a GitHub account can only contribute to existing projects after being added by a project owner, but cannot create their own projects.

Quota

A quota of 2 GB is granted per project by default. In justified exceptional cases, this quota limit can be increased. To do this, an e-mail must be sent to the IT service desk and the additional requirement must be justified. If the quota is exceeded, an automated e-mail notification is sent to the project owner with a request to reduce the amount of data. If this request is not complied with and no request for additional use is made, we reserve the right to block the project.

Costs

The use of GitLab is free of charge; there is no legal claim to registration and use.

Security

The IT Center assumes responsibility for the operation of GitLab. This includes the (virtual) hardware of the servers, the operating systems as well as the installed software. The IT Center assumes no liability for damages caused by, among other things, the use of GitLab.

Liability

RWTH shall be liable without limitation in the event of intent or gross negligence, for injury to life, limb or health and in accordance with the provisions of the Product Liability Act.

In the event of a slightly negligent breach of an obligation that is essential for achieving the purpose of the contract (cardinal obligation), the liability of RWTH shall be limited to the amount of the damage that is foreseeable and typical for the type of transaction in question.

RWTH shall have no further liability.

The above limitation of liability shall also apply to the personal liability of employees, representatives and bodies of RWTH.

Data security

The collection, use and utilization of personal data is carried out in compliance with the relevant data protection regulations. In particular, no personal data will be disclosed to third parties without authorization.