Personal data in RefPerSys

Like git the RefPerSys system will keep a small amount of personal data. FWIW, git has a git config command where you would configure a limited amount of personal data: every one knows that he/she should

git config --global user.name "John Doe"
git config --global user.email johndoe@example.com

before using git.

what kind of personal data?

In RefPerSys, it will be the same, as documented in our refpersys-design.pdf draft document (figure 4, page 23, section §3.4.2 concrete examples of objects, commit 34794f43) -which you can build with LaTeX utilities using cd doc/design-ideas followed by ./build.sh.

The amount of data is similar and close to what git processes: your first and last name, your email.

By social convention, only a given human contributor is allowed to add more personal data about himself/herself (e.g. a phone number, an age, etc...). However, we are not naïve: we do know that, in principle, the RefPerSys could make HTTP requests (e.g. using QNetworkRequest or libcurl, etc...) to access e.g. Google. For a detailed analysis, read for example Shoshana Zuboff's paper Big other: surveillance capitalism and the prospects of an information civilization

why RefPerSys would use personal data?

Exactly like in a wiki system or in a LibreOffice document , it is useful to record what human being has contributed some particular piece of data or of knowledge to RefPerSys. Concretely, some expert system rule in RefPerSys might be represented by an object with an hypothetical attribute authors associated to a set of persons reification (i.e. to a set of RefPerSys objects representing or reifying human beings).

How could RefPerSys know about the person using it?

Technically, a running ./refpersys process might be informed of the identity of the current user through perhaps some REFPERSYS_USER_OID environment variable (see environ(7) and getenv(3), etc...), or later with getuid(2) combined with getpwuid(3)

future examples of personal data uses.

attributing authorship

We could easily imagine that specific components of the knowledge base of RefPerSys would carry the identities of the human contributors to RefPerSys. This will facilitate communication between humans: e.g. if person A knows that rule R has been recently edited by persons B and C, then person A could send an email to persons B and C asking for clarification.

user specific preference

Each user could have his/her preference. Not only graphical ones (which font should be used, what background color is preferable) but also more semantic ones: "to what depth a given complex data structure would be displayed", or about the frequency of garbage collections, etc....

relation with  git

It is highly probable that we could simply use git facilities to find out what person has contributed to what. It is however more convenient to also keep that information inside RefPerSys. Using just git would require us to parse the output of git diff on JSON data, which is not convenient.

relation with European GDPR

Since we are not lawyers, it is not known to us why using git (or gitlab) is legally conforming with General Data Protection Regulation. Some lawyers told verbally us that they don't know why git is GDPR compliant, but presume it is (by some common sense argument) until some court decided otherwise.

It is also not known -since we are not lawyers- to us why RefPerSys is GDPR compliant, but by socially requiring that each contributor commits (using a signed git commit, so with a git commit -s his own personal data himself, we believe acting in good faith.

Important warning

Once a human being has registered himself/herself in RefPerSys, it is technically difficult (and perhaps practically impossible) to remove such personal data. By analogy, it would be difficult to remove every contribution to GCC made by Basile Starynkevitch.

Beware that we are not lawyers, and are not qualified to give any legal advice

Caveats relating to disseminating the notice

In the RpsQCreateContributorDialog class, a cogent notice is being displayed, warning the potential contributor of the ramifications of adding herself as a contributor with respect to her personal data. As of now, this notice is hard coded in the RpsQCreateContributorDialog::RpsQCreateContributorDialog() constructor.

However, there are a few points to consider with this approach.

1. From a legal point of view, the user has no way of reading this notice, until (s)he explicitly clicks the Create | create Contributor menu option. This is analogous to a purchaser of proprietary software not being able to read the EULA (End User License Agreement) until (s)he explicitly starts the installation process. In both cases, there are grounds for the malicious contributor and end user to wrongfully claim that owing to an unforeseen bug, the notice / EULA was not displayed. However, if the notice/EULA file is provided as a separate file which can be read by the contributor / user, in addition to being displayed at the appropriate context, then one important grounds for malicious intent are mitigate.
2. If the notice is hard coded, the contributor does not have an easy way to share the notice with her lawyer if (s)he chooses to do so before registering as a contributor. However, if there is a separate notice file, that file could be easily shared with contributor's lawyer if (s)he wished to do so. So, we are facilitating the chance for the contributor to take legal advice before registering as a contributor. Again, this prevents any malicious person from taking advantage of this loophole
3. Since RefPerSys is GPL licensed, any contributor could potentially change the wording of the personal data notice. If the notice is hard coded, changes to the notice could be git committed along with other changes to the window_qrps.cc file, and a quick glance at the git diff might result in the reviewer missing out on a change to the notice. However, if the personal data notice is in a separate file, even a quick glance at the git log and diff will make it immediately apparent that the notice has changed.
4. If the personal data notice is in a separate file, we could have the option of creating a Git pre-commit hook that computes the MD5 digest of that file and thereby either emits a warning or aborts the commit if there is a change to the notice.

The considerations above could apply after our primordial bootstrap milestone has been reached. Before that, nobody cares, since nobody is using RefPerSys except some team members.