Balanced Employee IP Agreement: the IP contract GitHub open sourced
GitHub's employee intellectual property agreement, open sourced and reusable
At a glance
- What is it?
- GitHub published the employee intellectual property agreement it signs internally, on the theory that a company should claim what falls inside the job and leave the rest alone. Here is how the three buckets of ownership work and what the text leaves to a lawyer.
- Who is it for?
- BEIPA is a well-argued starting point for a company that wants an IP agreement and does not want to spend its talent's goodwill on one. The three bucket structure is the whole idea, and it holds together because the middle bucket is a licence rather than an assignment.
- Can I use it commercially?
- Yes. CC0-1.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 26 days ago.
- What is it written in?
- GitHub does not report a main language for this repository.
Answers come from the project's GitHub data, last synced on September 28, 2026, and from our analysis. They are not legal advice.
Editorial analysis
Three buckets instead of one claim
Most employee IP agreements answer one question: who owns what you make while you are here. BEIPA splits the answer three ways, and the split is the entire reason the document exists.
The first bucket is work created during the period of employment and within the scope of the job. There the company takes exclusive control. The second bucket is work created outside the job and unrelated to the company's business: the employee keeps exclusive ownership, and the company gets nothing. The third bucket is the one that makes the document interesting. Work created outside the job but related to the company's business stays owned by the employee, and the company receives a non-exclusive, unlimited licence to use it.
The README puts the motivation plainly. It describes the approach as a commitment to employee autonomy and work-life balance for the mind, and says a company using BEIPA does not try to claim control of free-time knowledge production or extend control past the end of employment. The claim it is arguing against is the common one where employers take everything an employee creates while employed, around the clock, and sometimes reach backwards into work done before the job started or forwards into what a former employee builds next.
The middle bucket is also where the commercial argument sits. The README lists as a motivation for employers the point that controlling employee side projects does not contribute to revenue, while a non-exclusive licence to business-related work captures more of what an employee builds in spare hours without the conflict and the attrition that come with confiscating it.
What the repository actually holds
This is a text repository, not a tool. There is nothing to install and no command to run, which is worth saying plainly before anyone looks for a CLI. The tracked files are few enough to list:
.github/
Balanced_Employee_IP_Agreement.md
CODE_OF_CONDUCT.md
CONTRIBUTING.md
Employee_IP_Laws.md
LICENSE.md
README.md`Balanced_Employee_IP_Agreement.md` is the agreement itself. `README.md` is the explanation and the FAQ, and it is by far the longer document, which tells you where the actual argument lives. `Employee_IP_Laws.md` is the jurisdictional reference, and `CONTRIBUTING.md` carries the versioning scheme that the release notes link to. `LICENSE.md` is CC0-1.0, a public domain dedication, which is the right instrument here: a company can copy the text into its own employment paperwork without asking permission or worrying about attribution, though CC0 says nothing about whether the clauses are enforceable in your state.
The repository is not archived, and the last push was on 2026-09-10. It carries three topics, intellectual-property, law and policy, which is an accurate description of a legal text with a contribution process attached rather than a codebase.
Reading the v2 release notes as a diff on the old terms
There are two releases, and the gap between them is the best documentation of how the thinking changed. v1.0.1 came out on 2017-08-23 as a patch release containing what the notes describe as minor corrections: a section reference, grammar, list ordering, a definition and formatting. That same release moved the rendered convenience formats out of the repository and turned them into release assets.
v2.0.0, published 2020-12-14, is a major release and the notes describe three substantive moves. The first is the licence for out-of-scope but business-related IP, which the notes frame as a response to scope and knowledge questions raised against v1. The second removes confidentiality obligations owed by employees to the company, on the reasoning that those are handled by corporate policy and do not need to live inside an IP agreement. The third adds a clause where the employee agrees not to share information that is subject to someone else's NDA or IP rights, described as protecting both sides: it keeps the employee clear of prior commitments and gives the company freedom to operate.
The fourth change is the quiet one. v2 removed the annex that itemised specific United States state laws, in order to genericise the agreement. For a reader outside the United States that is the change that matters most, because the document now describes itself as applicable only to the extent allowed by law where you are.
The recruitment case the README argues for
The FAQ in the README is where the document becomes an argument rather than a contract, and the recruitment framing is the most concrete part of it. The stated reasoning is that your best employees are creative all the time, and the agreement is presented as a recruitment and retention tool on the same footing as other policies that promote autonomy.
The specific claims it makes are that employees who feel they must look over their shoulder and hide personal projects get demotivated and set up for conflict, that employers do not want to push people out who feel they must leave in order to work on a side project, and that a non-compete can trap employees who stay only because they are unsure whether they own what they would build next. It also points at the case for letting employees learn by contributing to their communities, open source included, without needing employer permission.
The employer counter-case is stated just as directly. In the United States, without an express agreement, employers usually own works subject to copyright and hold what the README calls a shop right to use inventions, so an express agreement is a way to get lower risk and more certainty about more situations. The README cites an SSRN paper on human capital law and the reach of intellectual property as an overview of the maximal approach, and a DRUID working paper as well studied evidence for the effect broad employer control has on mobility.
Note the asymmetry in who benefits from each bucket, because it is the part most summaries skip. Bucket one is employer insurance. Bucket three is employer upside without a fight. Bucket two exists for the employee, and a company that expects to be on the receiving end of the agreement is the one that benefits from it being legible.
Where the open source framing stops
It is tempting to read a public domain legal text in an open source repository as an open source policy document. The README explicitly declines that reading. It says BEIPA is not specific to open source, that an employee can equally work on a closed source project in spare time and own it, and that the agreement is mostly orthogonal to open source licensing. Open source adds a separate dimension, permission for anyone to use a knowledge product subject to at most very limited conditions about provenance and sharing, and the IP owner decides whether to go that way.
Two other boundaries are worth naming. First, the disclaimer: the README states plainly that contributors to the project are not the reader's lawyers and that nothing in the repository is legal advice. Contributors here are engineers and policy people, which is visible in the fact that the correction credited in the v1.0.1 notes came from people who spotted drafting problems in the text.
Second, the FAQ links to a section on the jurisdictions where BEIPA is applicable, and that section is the hinge for any real adoption. An agreement that claims exclusive control over a category of work is only as good as the local law that lets an employer claim it, and the release notes show the maintainers treating state-by-state detail as something to strip out so the text could travel. That is a sensible drafting choice and it moves the jurisdiction work onto whoever adopts the document.
Getting a copy your lawyers can read
The README points at rendered formats rather than asking you to convert Markdown: PDF, ODT and DOCX copies are available for download from the latest release. That is the practical path for a document that has to go into an onboarding packet or be reviewed outside a text editor.
The release history is also the answer to the question of how to modify the text. The contribution guidelines describe the versioning scheme that the release notes reference, and a patch release was used for corrections that did not change meaning while the licence change went out as a major version. If your company changes the substance of the clauses, that convention suggests treating it as a new major version of your own copy rather than as an edit.
What the repository gives you is a draft with a public argument behind it and a CC0 dedication on top. What it does not give you is an answer for your state, your industry, or your existing equity and confidentiality terms. The README itself sets the expectation that an express agreement is how you get certainty, which is exactly the certainty this text cannot supply on its own.
Editorial conclusion
BEIPA is a well-argued starting point for a company that wants an IP agreement and does not want to spend its talent's goodwill on one. The three bucket structure is the whole idea, and it holds together because the middle bucket is a licence rather than an assignment. What it cannot do is decide your jurisdiction, your state's non-compete rules, or whether your equity grant conflicts with it. Read `Balanced_Employee_IP_Agreement.md` end to end, then have counsel mark it up before it reaches an offer letter.
Frequently asked questions
What is an employee IP assignment agreement?
It is the express contract that decides who owns the intellectual property an employee creates during a job, instead of leaving it to default law. The README notes that in the United States, without an express agreement, employers usually own works subject to copyright and hold a shop right to use inventions. BEIPA is GitHub's version of that express agreement, released for other companies to reuse.
Does my employer have rights to my intellectual property?
Under BEIPA, it depends on which of three buckets the work falls in. The company takes exclusive control over work created during employment and within the scope of the job, gets a non-exclusive and unlimited licence over work created outside the job but related to the business, and gets no rights at all over work created outside the job and unrelated to the business, which stays with you.
Can you provide an example of an IP assignment agreement?
The agreement text is the whole example, kept as `Balanced_Employee_IP_Agreement.md`, with rendered PDF, ODT and DOCX copies attached to the latest release for download. The repository is licensed CC0-1.0, so a company can copy the text into its own employment paperwork and adapt it, subject to local law and to review by its own counsel.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/github-balanced-employee-ip-agreement)