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
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.
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.
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.
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.
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.
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
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.
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.