smoliicek/fdwg-agreements
0
0
Fork 0
forked from fdwg/fdwg-agreements
Code Pull requests Activity

Initial commit

Browse source
This commit is contained in:
Michael Winters 2026-05-05 17:15:57 -05:00
commit ea67a9faef
Signed by untrusted user: mwinters
GPG key ID: F72C1429A9440862
3 changed files with 375 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

216
README.md Normal file
View file

@ -0,0 +1,216 @@
# FDWG Authorized Analytics Volunteers — Signatory Record
This repository is the authoritative record of volunteers who have executed the **Fedora Data
Working Group Authorized Analytics Volunteer Agreement** ("the Agreement"), and who are therefore
recognized as Authorized Analytics Volunteers under GDPR Article 29 for purposes of FDWG analytics
work.
Note that the current agreement is in Draft status, pending full review by the Fedora Council.
Should they approve the language as-is, this agreement will become binding.
---
## Quick start: How to sign the Agreement
If you have been asked to sign the Agreement to participate in FDWG analytics work, the steps are:
1. **Read the Agreement.** The current adopted version is
[`agreements/volunteer-access-agreement-v0.3.1-draft.md`](agreements/volunteer-access-agreement-v0.3.1-draft.md).
Do not skim. The obligations are real and continue after your involvement ends.
2. **Make sure your GPG key is registered in FAS.** This is required. See "Registering a GPG key in
FAS" below if you have not done this.
3. **Fork this repository** and create a branch.
4. **Add an entry to `signatories/signatories-v0.3.1-draft.yaml`** in the form described in the
"Signatory entry format" section below. Make sure all fields are correct — especially
`agreement_version`, `agreement_sha256`, and `attestation`.
5. **Commit the change with a GPG-signed commit** (`git commit -S -m "Sign Agreement: [your FAS
username]"`). Push to your fork.
6. **Open a pull request** against the main branch of this repository. The PR title should be `Sign
Agreement: [your FAS username]`.
7. **Wait for the Delegate to review and merge.** You will become an Authorized Analytics Volunteer
at the moment of merge. Do not begin processing FDWG data before that point. Note that this does
not automatically grant any access rights.
---
## Signatory entry format
Each entry in `signatories.yaml` must have exactly this structure:
```yaml
- legal_name: "Jane Carolyn Doe"
fas_username: "jdoe"
date: "2026-05-04"
agreement_version: "1.0"
agreement_sha256: "[sha256 hash of the agreement file you are signing]"
attestation: |
I have read the Authorized Analytics Volunteer Agreement
version 1.0 (sha256 above) and agree to be bound by it.
The legal name above is mine and is associated with the
FAS username above.
```
Notes:
- **`legal_name`** is your real legal name. This is a deliberate departure from Fedora's general
pseudonymity-friendly posture; see "Why the legal name requirement" below. If you have a strong
reason this is impossible, contact the Delegate before opening the PR.
- **`fas_username`** must match the FAS account you authenticated with to open the PR.
- **`date`** is the date of execution, in ISO 8601 format (`YYYY-MM-DD`).
- **`agreement_version`** must be the version of the Agreement you read and are signing. It must be
the current adopted version (you cannot sign an outdated version).
- **`agreement_sha256`** is the sha256 hash of the agreement file. Compute it with `sha256sum
agreements/volunteer-access-agreement-v[VERSION].md`. The hash pins your signature to the exact
text you read; if the Agreement is later amended, your signature continues to refer to the version
you actually agreed to.
- **`attestation`** must be reproduced exactly as shown in the template, with the version number
updated to match what you are signing. Do not paraphrase or shorten.
The Delegate will reject pull requests where any of these fields is missing, malformed, or
inconsistent with the others.
---
## What the Delegate verifies before merging
The Delegate (currently **Michael Winters**, FAS username **`mwinters`**) verifies, before merging:
1. The pull request is from an FAS-authenticated account.
2. The commit is GPG-signed.
3. The GPG key used to sign the commit is registered in FAS for that account.
4. The signatory entry is well-formed (matches the schema above).
5. The `agreement_version` and `agreement_sha256` refer to the current adopted version of the
Agreement.
6. The `fas_username` in the entry matches the FAS account that opened the PR.
7. The attestation language is reproduced exactly.
If any check fails, the PR is closed with a comment explaining why. The volunteer is welcome to fix
issues and re-open.
The Delegate does not exercise discretion beyond these checks. Admissions are mechanical: if the
checks pass, the PR is merged; if they fail, it is rejected.
---
## Registering a GPG key in FAS
This is a precondition for signing. The process:
1. If you do not have a GPG key, generate one. See the [Github
docs](https://docs.github.com/en/authentication/managing-commit-signature-verification/generating-a-new-gpg-key)
for guidance on key generation appropriate for code-signing use.
2. Export your public key: `gpg --armor --export [your-key-id]`.
3. Log in to FAS at https://accounts.fedoraproject.org/ and add the key to your account profile.
4. Configure git to sign commits with that key: `git config --global user.signingkey [your-key-id]`
and `git config --global commit.gpgsign true`.
5. Verify by making a test commit and checking `git log --show-signature`.
If you already have a GPG key registered in FAS for other purposes (package signing, etc.), you may
use the same key.
---
## Why the legal name requirement
Fedora generally permits pseudonymous participation. This Agreement is one of the few places where
it does not, and the reason is specific: the Agreement creates personal commitments that survive the
volunteer's involvement (confidentiality continues indefinitely, §4.4). For obligations of that
character to be meaningful, the controller — Red Hat, acting through the Council — needs to be able
to identify the human on the other side, not just an account.
A few notes on how this is implemented:
- The legal name is recorded in `signatories.yaml`, which is part of the public history of this
repository. If you have a serious reason your legal name should not be in a public Fedora record
(personal safety, professional separation, etc.), contact the Delegate **before** opening a PR.
The Council has authorized the Delegate to record legal names in a non-public manner in such
cases, with the public file showing FAS username only. This is an exception, not the default; the
default is that the legal name is public.
- The legal-name assertion is on your good faith. There is no notarization or external verification
step. The point is that you have affirmed it, not that anyone has checked it.
- The legal-name requirement applies *for purposes of this Agreement only.* It does not change your
status under any other Fedora policy, the FPCA, or general Fedora participation norms.
---
## Amendments to the Agreement
The Agreement may be amended only by Council resolution (see Council resolution §4). When an
amendment is adopted:
- The new version is added to this repository as `agreement/v[NEW_VERSION].md`. Old versions are
retained, not deleted.
- Current signatories are notified by the Delegate.
- Each current signatory must execute the new version within the period specified in the amending
resolution, by adding a new entry to `signatories.yaml` referencing the new version and hash.
- Signatories who do not re-execute by the deadline are deemed to have terminated their Agreement
under §11 and lose their Authorized Analytics Volunteer status.
- Historical entries referencing prior versions are preserved unchanged. Each entry is a record of
what was agreed to at the time it was made.
The hash-pinning in each entry is what makes this work: your past signature is permanently bound to
the text of the version you actually read. Future versions are separate signatures requiring
separate consent.
---
## Termination
You may terminate your participation at any time. Two options:
1. **Pull request:** Open a PR that adds a `terminated_date` field to your entry in
`signatories.yaml`. The Delegate will merge it. Effective on merge.
2. **Direct notice:** Email the Delegate at fedora@mwinters.net. The Delegate will record the
termination in the repository.
The Council, through the Delegate, may also terminate any volunteer's Agreement on behalf of the
controller. This is rare and would normally follow specific cause (incident, breach of obligations,
etc.).
Note that the obligations in §4 (confidentiality) and §10 (incident reporting for incidents arising
from data accessed during the term) survive termination.
---
## What this repository is not
- It is not a record of access. Being an Authorized Analytics Volunteer is a precondition for FDWG
access, not the access itself. Access is granted through FDWG's own processes after admission.
- It is not a place to ask questions about the Agreement. Use the [FDWG Matrix Room
`data`](https://matrix.to/#/#data:fedoraproject.org) or contact the Delegate directly.
- It is not the right place to contest or appeal a decision by the Delegate. Concerns should be
raised with the Council through normal channels.
---
## Repository integrity
This repository is hosted on Fedora-controlled infrastructure at
**https://forge.fedoraproject.org/commops/fdwg-agreements**. Branch protection is enabled on `main`:
- No force-pushes.
- No history rewriting.
- All merges via PR.
- Required GPG-signed commits.
- Merges only by the Delegate or other Council-authorized accounts.
The combination of Fedora-controlled hosting and branch protection is what makes this repository a
durable record suitable for the controller's GDPR Art. 5(2) and Art. 24 accountability needs.
If you notice any apparent integrity issue with this repository (history rewriting, missing entries,
anything that does not look right), please report it to the Delegate immediately under §10 of the
Agreement (incident reporting).
---
## Contacts
- **Delegate:** Michael Winters, fedora@mwinters.net, FAS: `mwinters`
- **Fedora Council:** https://docs.fedoraproject.org/en-US/council/contact/
- **For Privacy Statement DSR requests (not Agreement matters):** [pagure.io/fedora-pdr](https://pagure.io/fedora-pdr)

159
agreements/volunteer-access-agreement-v0.3.1-draft.md Normal file
View file

@ -0,0 +1,159 @@
# Fedora Data Working Group - Authorized Analytics Volunteer Agreement
**Version:** 0.3.1-draft
---
## 1. Purpose and scope
1.1 The Fedora Project publishes activity data about its contributors (account records, commit history, mailing list and forum posts, group membership changes, and similar records) through its public services. The Fedora Data Working Group ("FDWG") consolidates and correlates this data to produce statistical reports on community health — understanding which efforts successfully recruit and retain contributors, and which work areas need support.
1.2 This processing is conducted under the legitimate interests of the Fedora Project as declared in the Fedora Privacy Statement, specifically the basis stated for "research activities, including the production of statistical reports."
1.3 This agreement governs the relationship between the Fedora Project ("Fedora") and a volunteer ("you", "the Volunteer") who is granted access to FDWG analytics data. By signing this agreement, you become an *Authorized Analytics Volunteer*: a natural person acting under the authority of the controller within the meaning of Article 29 of the General Data Protection Regulation (Regulation (EU) 2016/679).
1.4 Where an obligation in this agreement refers to data, infrastructure, or actions you do not in fact have access to or perform, the obligation is satisfied trivially with respect to those things. The agreement is written to cover the full range of FDWG analytics work; not every clause will apply to every volunteer's day-to-day activities.
## 2. The FDWG data layering model
2.1 FDWG operates a privacy-by-design data layering model as a measure under GDPR Art. 25. Three categories of dataset are recognized:
(a) **Raw data.** Contributor activity data as ingested from Fedora's source systems. Contains direct identifiers (usernames, email addresses, etc.) and is treated as personal data under GDPR.
(b) **Pseudonymized data.** Data derived from the raw data in which direct identifiers have been replaced with opaque GUIDs through a key (the "pseudonymization mapping") held only on FDWG-designated infrastructure. Pseudonymized data remains personal data under GDPR (Art. 4(5)) but is materially less identifying.
(c) **Aggregate outputs.** Statistical outputs (counts, distributions, time series, reports) computed from pseudonymized data, presented at a level of aggregation that does not identify any individual contributor. Aggregate outputs are intended for publication and sharing outside FDWG.
2.2 Access to each tier is controlled by FDWG infrastructure separately. Your access at any given time is whatever you have been granted; this agreement does not itself grant access. Where this agreement imposes obligations relating to a particular tier, those obligations apply to you to the extent you have access to that tier.
## 3. Purpose limitation
3.1 You may process FDWG data only for the purposes set out in §1.1: the production of statistical aggregate outputs about Fedora community health, and the production and maintenance of the datasets and supporting infrastructure that enable such outputs.
3.2 You will not use access granted under this agreement for any of the following:
(a) Producing outputs that identify, profile, or single out individual contributors, except where the individual is the data subject themselves and they have requested information about their own data through a documented process.
(b) Marketing, recruiting, evaluating, ranking, or making decisions about individual contributors.
(c) Research published outside Fedora's analytics outputs (academic papers, third-party publications, personal blog posts containing non-aggregate data, etc.) without prior written authorization from the Council or its delegate.
(d) Any purpose unrelated to the statistical aggregate outputs described in §1.1.
3.3 You may choose your own methods, tools, and analytical questions within the purposes set out above. Method-level autonomy is expected; purpose-level discipline is required.
## 4. Confidentiality
4.1 You will treat FDWG data as confidential. The fact that the constituent source datasets are individually published by Fedora does not make the *correlated* form non-confidential: correlation across systems creates a more identifying data set than any individual public source, and that combined view is not itself public. Pseudonymized data, although it does not contain direct identifiers, remains personal data and is similarly confidential — combinations of fields within it may be identifying, particularly within small sub-communities.
4.2 The pseudonymization mapping (the key linking GUIDs to direct identifiers) is the single most sensitive artifact in FDWG. It resides only on FDWG-designated infrastructure and may not be exported, copied, transmitted, or made available to any person or system outside that infrastructure under any circumstances. The protective value of pseudonymization depends on this isolation.
4.3 You will not disclose, share, transmit, or make available FDWG data to any person who has not signed this agreement, except as required by law or with the prior written authorization of the Council or its delegate.
4.4 The confidentiality obligations in this section continue after your work with FDWG ends.
## 5. Prohibition on re-identification
5.1 You will not attempt to re-identify any individual contributor in pseudonymized data, whether by correlating GUIDs against external information, by inferring identity from combinations of fields, or by any other means.
5.2 Aggregate outputs published outside FDWG must not identify or enable identification of individual contributors. You will apply, at minimum, the following published-output rules:
(a) **Cell suppression.** Aggregates with fewer than five distinct contributors will be suppressed or grouped, unless an exception is documented and approved.
(b) **Small-community awareness.** For SIGs, working groups, or sub-projects with small membership, aggregates may identify individuals even above the §5.2(a) threshold. You will exercise additional judgment in these cases and prefer suppression where in doubt.
5.3 Where a contributor has opted out of public display of a particular FAS field (per the Fedora Privacy Statement, "Publicly Available Personal Data" section), no FDWG output — aggregate or otherwise — will re-expose that field, whether directly or by inference. Opt-out state must be reflected in pseudonymized datasets at the point they are produced.
## 6. No contact, no targeting
6.1 You will not use access granted under this agreement to contact any contributor, whether the contact is for analytics-related purposes or otherwise. The Fedora Privacy Statement is explicit that aggregated information from research activities "is not used to contact the subjects of the report"; this prohibition extends to all FDWG data.
6.2 You will not use access granted under this agreement to target, profile, or intervene with respect to any individual contributor — including for purposes that might otherwise be welcome (e.g., "reaching out to lapsing contributors"). Such interventions, if they are to occur at all, are decisions for Fedora's leadership through its own channels and on its own lawful basis, not consequences of analytics access.
## 7. No redistribution of FDWG data
7.1 You will not extract, copy, publish, or redistribute FDWG data outside FDWG infrastructure and authorized local copies under §9, except in the form of aggregate outputs satisfying §5.2.
7.2 Re-publication of individual public datasets in their original form, from their original sources, is not restricted by this agreement. The restriction is on FDWG-internal data products: correlated raw data, the pseudonymization mapping, and pseudonymized datasets.
## 8. Respect for opt-outs and erasure requests
8.1 You will respect FAS account opt-outs as reflected in the data made available to you. Where opt-out information is propagated through FDWG infrastructure, you will use the most current data available at the time of analysis.
8.2 Where you receive notice (through FDWG channels) that a data subject has exercised a right of erasure, restriction, or objection under the Fedora Privacy Statement:
(a) FDWG will update the pseudonymization mapping and pseudonymized datasets to reflect the request, within fourteen (14) days of notice. Depending on the nature of the request, this may include removal of the individual's records, severing of the GUID-to-identifier link, or restriction of further processing.
(b) On notice that a GUID has been withdrawn or restricted, you will cease processing records associated with that GUID in any new analyses, and delete or render inaccessible any local copies under §9 containing those records, within fourteen (14) days of notice.
(c) Where prior published aggregate outputs were derived in part from the affected individual's data, no recomputation or alteration is required — historical statistical aggregates do not constitute personal data of any single individual, and the Privacy Statement explicitly preserves the historical record of contributor activity.
## 9. Local copy handling
9.1 Where your analysis requires local copies of FDWG data on your own systems:
(a) Local copies must be stored on devices under your direct control, with reasonable access protections (full-disk encryption, account password, screen lock).
(b) Local copies must not be stored on shared or third-party systems (cloud notebooks, shared drives, AI/LLM service contexts, public code repositories) unless the service is explicitly approved by FDWG for this use.
(c) Local copies must be deleted when no longer needed for the analysis at hand, and at the latest when your participation in FDWG ends.
9.2 Raw data and the pseudonymization mapping carry additional restrictions:
(a) Raw data should be processed on FDWG infrastructure where possible. Local copies of raw data are permitted only where required for specific tasks (e.g., debugging an ingestion pipeline) and must be deleted promptly on completion.
(b) The pseudonymization mapping must not be held in local copies on personal systems under any circumstances. It resides only on FDWG-designated infrastructure.
9.3 You will not commit FDWG data to source control, public or private, even briefly. Code that processes such data is fine; the data itself is not.
## 10. Incident reporting
10.1 You will notify FDWG leadership without undue delay, and in any event within seventy-two (72) hours, on becoming aware of:
(a) Any unauthorized access to, or disclosure of, FDWG data in your possession or under your control;
(b) Any loss of a device containing local copies under §9;
(c) Any published aggregate output that, on reflection, you believe may identify or enable identification of individual contributors contrary to §5.2;
(d) Any apparent re-identification of an individual in pseudonymized data, whether achieved deliberately or noticed inadvertently;
(e) Any compromise, suspected compromise, or disclosure of the pseudonymization mapping;
(f) Any contact, attempted or actual, with you from a third party seeking access to FDWG data.
10.2 The seventy-two-hour figure is borrowed from GDPR Art. 33's controller-to-supervisory-authority timeline; it gives the controller enough margin to meet its own obligations if escalation is required. It is not itself a regulatory deadline binding on you, and good-faith promptness is what matters.
## 11. Term and termination
11.1 This agreement takes effect when both parties sign and continues until terminated.
11.2 Either party may terminate this agreement at any time, by notice to the other. On termination:
(a) Your access to FDWG infrastructure will be revoked;
(b) The local-copy obligations in §9.1(c) become immediate;
(c) The confidentiality obligations in §4 continue indefinitely;
(d) The incident-reporting obligation in §10 continues for any incidents arising from data accessed during the term.
## 12. No employment, no compensation, no warranty
12.1 Nothing in this agreement creates an employment, agency, or contractor relationship between you and Fedora or Red Hat. Your participation is voluntary and uncompensated.
12.2 Fedora makes no warranty as to the accuracy, completeness, or fitness for purpose of any data made available under this agreement.
12.3 You participate at your own risk and on your own responsibility, save that nothing in this agreement is intended to limit Fedora's responsibilities as controller under applicable data protection law.
## 13. Relationship to other agreements
13.1 This agreement is independent of and additional to the Fedora Project Contributor Agreement (FPCA). The FPCA addresses intellectual property in your contributions; this agreement addresses your access to and processing of personal data on Fedora's behalf.
13.2 In the event of conflict between this agreement and the Fedora Privacy Statement as it applies to the controller, the Privacy Statement governs the controller's obligations to data subjects. This agreement governs your obligations to the controller.
## 14. Governing law
## 15. Amendments
15.1 This agreement may be amended by the Council. Material amendments will be communicated to current Authorized Analytics Volunteers, who may either accept the amended terms or terminate under §11.

0
signatories/signatories-v0.3.1-draft.yaml Normal file
View file