Contributor notice templates

Our Terms ask you to tell the people whose work BuiltBrief reads before you connect their repositories. These templates help you do that. Replace everything in [brackets].

They are a starting point, not legal advice. The right notice depends on where your people work and how you use BuiltBrief. Please review them with your own counsel.

You can link to our page for developers, BuiltBrief and your work, from any of these notices.

1. General notice

For email, Slack, your handbook or a team wiki.

Subject: We're using BuiltBrief on [repositories]

Hi team,

From [date], we're using BuiltBrief on these repositories: [list]. BuiltBrief reads pull requests, issues, CI results and deployments through a read-only GitHub App, and writes a [weekly] brief about what was built, what shipped and what's blocked.

What it reads: PR titles, descriptions, comments and reviews, short diff excerpts, issues, CI results and deployments. It doesn't store code or diffs.

What it doesn't do: it doesn't score, rank or compare individual people, and it doesn't track activity or working hours. We won't use it to evaluate, discipline, pay or make employment decisions about anyone.

Who sees the brief: [owner name] and [up to 5 readers, by role]. You can read the same brief too: [how to get access]. If something's wrong or missing context, you can add a note next to it.

How long it's kept: briefs are kept for up to 13 months.

Questions or concerns? Talk to [contact name], or read BuiltBrief and your work.

2. GDPR privacy notice (EU and UK)

Use this where the GDPR or UK GDPR applies. BuiltBrief collects data from GitHub rather than from people directly, so this follows Article 14, with Article 13 points included.

Privacy notice: BuiltBrief

Who is responsible. [Company legal name], [address], is the controller. Contact: [privacy contact]. Data protection officer: [DPO contact, if any].

What we use and why. We use BuiltBrief to produce regular briefs about the work in our GitHub repositories: what was built, shipped or blocked, at the level of work, repositories and teams. BuiltBrief does not score, rank or monitor individuals, and we don't use it for decisions about individual employees.

Personal data involved. Your GitHub username and ID, and personal data that appears in pull request and issue titles, descriptions, comments, reviews and diffs on the connected repositories, together with timestamps and statuses.

Source. The data comes from our GitHub repositories: [list or "repositories in the [org] GitHub organization connected to BuiltBrief"].

Legal basis. Our legitimate interest in understanding progress, delivery and risk in our software work (Art. 6(1)(f) GDPR). We have weighed this against your interests. The processing is limited to work-level reporting, with no individual evaluation. [Optional: and our works agreement dated [date].] You can ask us for details of this balancing test.

Recipients. BuiltBrief, our service provider in the USA, processes the data for us under a data processing agreement. It uses sub-processors, including Cloudflare (hosting and email) and Anthropic (the AI model that writes summaries). The brief is read by [roles].

Transfers outside the EU/UK. Data is processed in the USA. Transfers are protected by the EU Standard Contractual Clauses [and the UK Addendum], and by the EU-US Data Privacy Framework where a provider is certified. Ask [privacy contact] for a copy.

How long. Code, diffs and PR text are processed and not stored by BuiltBrief. The AI provider may keep them for up to 30 days. PR metadata, digests and briefs are kept for up to 13 months, and deleted within 30 days if we stop using BuiltBrief.

Automated decisions. None. BuiltBrief is not used to make decisions about you.

Your rights. You can ask for access, correction, deletion or restriction, and data portability where it applies. You have the right to object at any time to processing based on our legitimate interests, on grounds relating to your particular situation. You can also complain to a data protection authority, such as [authority for your country].

3. New York electronic monitoring notice (Civil Rights Law §52-c)

Does it apply? New York requires employers with a place of business in New York to give prior written notice if they monitor employees' telephone, email or internet access or usage by electronic means. BuiltBrief reads work product that people have submitted to GitHub. It doesn't monitor email, browsing or devices. Whether that counts as monitoring under §52-c isn't settled. Consult counsel. Many employers give the notice anyway, because it's simple to do.

What the law requires if it applies:

give the notice on hiring to every employee who may be monitored (and, in practice, to current employees now);
get each employee's written or electronic acknowledgment;
post the notice somewhere conspicuous and easy for employees to see.

Notice of electronic monitoring

[Company legal name] gives this notice under New York Civil Rights Law §52-c.

Please be advised that any and all telephone conversations or transmissions, electronic mail or transmissions, or internet access or usage by an employee by any electronic device or system, including but not limited to the use of a computer, telephone, wire, radio or electromagnetic, photoelectronic or photo-optical systems, may be subject to monitoring at any and all times and by any lawful means.

Specifically, we use BuiltBrief, which reads pull requests, issues, CI results and deployments in [repositories] through GitHub, to produce work-level briefs. It does not score or rank individuals, or track activity or working hours.

Acknowledgment I have received and read this notice. Name: ____________ Signature: ____________ Date: ________

Delaware (19 Del. C. §705) and Connecticut (Conn. Gen. Stat. §31-48d) have similar employer notice laws. Check with counsel if you have employees there.

4. One line for `CONTRIBUTING.md`

For repositories with outside contributors, add:

This repository uses [BuiltBrief](https://builtbrief.com/legal/for-developers), which reads pull requests, issues and CI results to write work-level briefs for [Company]. It doesn't score or rank contributors. Questions: [contact].

5. Works council system description (Germany)

Why this is needed. In Germany, the works council (Betriebsrat) has a right of co-determination over technical systems that are objectively capable of monitoring employees' performance or behaviour, whatever the employer intends (§87(1) No. 6 BetrVG). A system that reads GitHub pull requests will likely be treated as capable of that. You will usually need to inform the works council early, including about AI use (§90(1) No. 3 BetrVG), and agree a works agreement (Betriebsvereinbarung) before you connect repositories. Have German employment counsel review it.

The stub below is in German, because that is how you'll usually submit it.