github / balanced-employee-ip-agreement Goto Github PK

I don't think integration tests are necessary for this project, but here are some that could be nice:

• Links in README and agreement work
• Statute texts in Exhibit A match texts found at reference links (#28 could complicate)
• Updates to agreement get new version in accordance with #27 outcome
• Updates to agreement don't make readability scores significantly worse
• Spelling and grammar checks

Non-automated versions can be documented with #27

(emphasis added)

By signing this agreement, You grant or assign to the Company all rights and interests in all Company IP, including any IP that you have developed or are developing before, through and beyond the date you sign this document.
[...]
If you incorporate your own IP into a Company product or service, it's still yours, of course, but you grant the Company a nonexclusive, fully paid-up, royalty-free, perpetual, worldwide license to use it without restriction.

I'm not sure how the bolded part relates to the second excerpt. Are they redundant? (Nor how it relates to preceding "as its employee" statement.)

I failed to notice this before first sketch of FAQ, bolded part of below probably needs to be removed or changed:

How does BEIPA differ from other employee IP agreements?

Many employee IP agreements are very generous – to the employer. The employer gets control of everything the employee creates during the period of employee, 24/7, and sometimes anything created before the period of employment, and sometimes control over what a former employee can create (through "non-compete" terms). BEIPA only claims control of what the employee creates during the period of employment, and only creations made for or relating to the company's business. There surely are other "balanced" employee IP agreements in use. We hope so, and encourage progressive companies to share their agreements and lessons.

The 'd' in open-sourced makes it a bit idiosyncratic. Why not "open source"?

Game add-ons are a nice example of something totally uninteresting to GitHub and unambiguously personal projects but using this example promotes a bit of a negative and possibly male stereotype of developers. Well, it made me roll my eyes.

Also, I wonder whether we should avoid calling out another brand name here.

There's probably something that would work nicely no matter what industry employer is in, but a silly suggestion: "open source mail reading program", a reference to so-called Zawinski's law.

The README makes clear that no trademark rights are granted, but the document itself uses a name + acronym that seems intended to be used as a mark in essentially commercial documents (BEIPA). It would be handy if you clarified in the README whether or not the mark “BEIPA” can be used, or if it needs to be stripped out before the document is re-used.

Related, and perhaps broader, it would be good if you indicated (despite CC-0) what your preferred norm for attribution to GH/BEIPA is — indicated in the document? Only indicated if copied verbatim? Indicated elsewhere?

You are responsible for keeping this information confidential, including after you end your work for the Company.

This seems like it can have wildly varying interpretations and consequently expectations of what an employee's responsibility is regarding what an employer could consider confidential.

A lot of previous contracts I have turned down, have had confidentiality statements where I am not even able to reuse thoughts that the employer considers confidential - all those learned skills and processes, they are confidential business know-how, in your next role you must never use anything you learnt, or even do anything we do, as we'll suspect you learnt it from us! Naturally, that busts the idea-expression-divide, but it doesn't stop their legal team from applying the pressure like an intellectual zombie virus.

So could be nice if the implementation of this responsibility was covered much in the same way as the copyrightable materials in the prior segments, as no complaints on that 👌

It would also be nice to cover the difference between confidentiality obligations and and privacy obligations, as many contracts treat them as the same, even though their practical implementation is quite different. The way I think about it as so:

• privacy means the identities are confidential, but the stories are not, however if a story could reveal the identities, then you must alter the story or not tell it
• confidentiality means don't discuss the story and optionally the company too.

These were copy-pasted verbatim into preformat blocks, and need to be viewed with soft-wrap to be readable without horizontal scrolling. A few options:

1. Preformat statute text with linebreaks, indentation
2. Markdown format statute text with as much fidelity to original as possible
3. Format statute text with HTML blocks within the markdown
4. Change the agreement source format from markdown to something else, probably HTML or ODT/DOCX
5. Do nothing, keeping copying verbatim is a win and viewers should soft-wrap, and most real users will use a version copied into a more traditional document format anyway

This may not be the appropriate medium to discuss this but looking at this problem of 'my IP vs. the companies IP' from a different perspective, I'm curious what processes/practices GitHub or other organizations have implemented internally to encourage IP contributions from employees to the company domain. Are there public examples of incentive models, co-marketing programs, attribution guidelines, equity-split scenarios, etc. that could encourage employees to more readily co-invest in their IP with their companies?

Also curious if there are adaptations of BEIA that would work for service industries where the company may be building product on behalf of their clients and therefore may not have ownership of the IP their employees create directly.

As noted in #17:

Compliance with state law: "Certain states, including California, have laws related to the assignment of inventions and require that employees be given notice of those laws. You acknowledge you have reviewed the list is attached as Exhibit A." [Which is 3 pages of such notice for 8 states.] Should probably add a similar collection of jurisdiction notices to the BEIPA repo for easy reference.

7. IP protection. The Company might someday need to show the work that went into the development of IP that it uses or has used, or to make government filings to establish that it owns the IP or has rights over it. To help in those situations, you agree not to destroy any records you maintain relating to the development of any Company IP or IP under License (together, "All IP"), and, if the Company asks, to provide those records to the Company.

Is the obligation to keep and provide records intended to apply to work on, say, a personal open-source project incorporated into company products that the employee continues to develop after leaving the company? That could get very sticky.

You agree to help the Company secure and defend its rights in All IP, including after you leave the Company. For your help the Company will compensate you at a reasonable rate.

While the employee is employed at the company, is this compensation intended to be in addition to regular employee compensation?

In the case of IP under License, is the thought here to provide help defending the company from a suit for infringement of the IP, say if the employee assigned IP under license to another company that brought suit for infringement? Wouldn't the documented License suffice?

If the Company is unable to secure your help, you authorize the Company to act on your behalf (as your agent and attorney-in-fact) in securing all rights related to All IP.

If the intent is perfection of ownership rights, like copyright registration ahead of an infringement suit, why is this for All IP, as opposed to just Company IP? Won't the written license grant of the IP agreement itself provide all the necessary evidence for IP under License?

I'm going to open some number of issues and pull requests here in working on making the agreement re-usable and various messaging and questions along the way.

Some of those will have to do with making the rationale/FAQ in the README accurate and palatable.

(1.1) Why is this? In order to operate and do business, the Company needs to be clear on what IP it owns and has rights to. This is true both from an internal perspective (e.g., accounting issues, revenue recognition and the like) as well as an external one (e.g., customers want to know that the Company has the legal rights to the products and services it's providing).

How IP ownership relates to accounting issues and revenue recognition seems kind of obscure. Is there a clearer statement of internal perspective? What about company not wanting to get sued?

Can we commit to maintaining it? Are there reasons not to other than labor constraints?
Either way, should we invest in defining contributor guidelines?

https://docs.google.com/viewer?url=https://processmechanics.com/static/2015-07/ModelCo_IP_Policy.docx

Blog post about https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/

Based on policy used at Rackspace.

Just noticed, have only skimmed but maybe worth a mention in FAQ, maybe to learn from.

Thank you for putting the work into creating an agreement that is significantly more balanced than anything else out there.

This sentence still feels like it is overly granting rights to the Company at the expense of the employee and might be able to be made more balanced:

You authorize the Company to act on your behalf (as your agent and attorney-in-fact) in securing all rights related to Company IP and Your IP licensed to the Company under this agreement.

One way it could immediately be more balanced is require the company to at least try to contact the employee first before using the power, like so:

In the event that the Company is unable, after reasonable effort, to obtain XYZ, you authorize the Company...

Even with that change, granting anyone to act on my behalf is something I only would want to do to someone that I completely and wholeheartedly trust – even if the power granted is somewhat narrowly defined as related to Company or My IP. For instance, under BEIPA a company could sign a patent application on my behalf, attesting that I believed it was novel and worthy of a patent, even if I did not believe so. If the patent was issued I would forever have my name tied to the patent even though I never signed it or believed it was novel. I also understand the Company without this power the employee would be able to essentially hold the company hostage by refusing to sign as an inventor of a patent (which tips the power too far back to the employee). What other instances might this be power be used and abused?

What else could be done to make it more balanced? It could be much more narrow by specifically naming which instances it applies to, i.e. "prosecute, register, perfect, record, or enforce". Perhaps more language clarifying that it is only "to act for and in behalf solely to execute and file XYZ". Are there any other ideas? I don't seem to have any that feel satisfactory.

This is not balanced at all: the employees do not have any ownership over the product of their labor. A better approach is to make your software (i.e. GitHub) free software and do not assign IP ownership at all, leaving the product collectively owned by all past, present, and future employees.

Is there a contradiction in these two bits (emphasis added)?

Why is this? ... The Company isn't interested in misappropriating your personal work and doesn't believe that a project belongs to it simply because you happen to have used your Company laptop when developing it.

...

What the Company owns ... was developed or promoted with Company branding or resources

("Company" is "GitHub" in the current agreement we use, obviously.)

I added (#29 and #34) these to the repo just before making public after reading an item on a checklist for releasing new open source projects that asks if distribution with a convenient and standard mechanism (such as a package repository) has been set up. There's no appropriate package repository for BEIPA, but pdf/odt/docx are pretty "convenient and standard" (for various meanings of the terms, or not). But there's no reason for these generated artifacts to be in the repo rather than release assets. Right?

I believe GitHub employee @zcbenz 's work on libyue is bound with BEIPA so I'm raise the issue here.

What if employee violates copyright laws when he/she is doing work under BEIPA? Does the document say anything about this? Should the employer be responsible for the violation if they get sued? It would be better if the FAQ section could include this.

@zcbenz clearly violates copyright laws in his work, see the issue and Hacker News discussion

Note that he also did this in the past in work time for GitHub official project Electron, see the complaint here: electron/electron#5172 (comment)

CC @hoolio @mlinksva @defunkt @nathansobo

Moved here: https://discuss.bevry.me/t/contracts-legal/800?u=balupton

Hi! First off, I really appreciate this being made available.

I'm wondering whether anyone has knowledge of whether GitHub has used this agreement for contracting services from business entities, for whom a representative might sign.

Thanks!

Hi github,

In paragraph 2, there is mention of "Section 2" but I can't figure out what it is in reference to.

2. What the Company doesn't own. If you create IP that doesn't fit into one of the categories listed above, the Company doesn't own it. In other words, the Company doesn't own any concepts, designs, developments, discoveries, ideas, improvements, trade secrets, or any works of authorship that you develop, invent or create that do not meet any of the conditions above in Section 2.

Help!

Every bit of it I just made up. Pull it apart. Open specific issues/pull requests if you have focused feedback.

https://github.com/github/balanced-employee-ip-agreement/blob/master/README.md

"Company IP" includes concepts, designs, developments, discoveries, ideas, improvements, inventions, trade secrets, trademarks, and works of authorship.

That part still seems to violate the idea-expression divide (excerpt below), as only expressions of ideas are copyrightable, but the quoted clause is claiming ownership of more than just expressions.

Additionally, in Mazer v. Stein, 347 U.S. 201, 217 (1954), the Supreme Court stated "Unlike a patent, a copyright gives no exclusive right to the art disclosed; protection is given only to the expression of the idea—not the idea itself."

To address this, BEIPA can make its state specific employee protections available to all, such as Californa's protections of employee inventions, such that all employee's globally share equal protections. As well as stating explicitly:

Ideas including concepts and strategies, are not copyrightable, due to the idea-expression divide, with only their particular expression at a company being copyrightable.

As right now with BEIPA:

• It is written to violate the idea-expression divide
• Not all employees globally have equal IP assignments (as BEIPA is written to be catch-all except for specific state exceptions and employee negotiated amendments).

I want to be as welcoming as possible to potentially hard/substantive suggestions/questions, but also set expectation that it'll take time to get responses to those (and maybe also point to disclaimer again there).

Thanks to everyone for all the previous and ongoing hard work on the documents here!

The README notes:

Many employee IP agreements are very generous – to employers.

and...

If you've worked in the technology space before, there's a good chance that you've run across one or more of these in the past.

Every employee or contractor is going to be signing an employment or contracting contract. These documents almost always contain IP provisions. These documents are referenced in the BEIPA:

The Company owns any IP ("Company IP") that you create, or help create, during the term of your employment or contract work, within the scope of your employment or contract.

Is it the community's and by extension GitHub's experience that employment contracts they are using do not contain any IP provisions? Based on the statements above, are we collectively assuming they are at odds with each other? If not, does the community have experience integrating the terms in the BEIPA into employment contracts (one document seems highly preferrable to two)? If they are expected to be at odds with each other does the community have experience with dispute resolution to share?

Thanks for creating these documents, I really like the idea!

I would very much love to see a version that applies to Germany and/or Europe, however, I do not have the necessary legal knowledge to do the transformation. (There was a slight understanding on Twitter yesterday: I do not need a translation in order to understand the document, but in the current state it most likely does not apply.)

As there are many common regulations in Europe, I guess the solution can be as follows:

• exchange the regulations by those applicable for Europe
• add an addendum for each country (as done with the states)
• get translations for the specific countries

As FLOSS is on the European political agenda, maybe the EU Administration would even sponsor the translations?

I'm sorry that I cannot contribute more than the issue and my enthusiasm. Hopefully somebody is as motivated and more qualified. :)

It looks like the default basictex minimal package (90mb instead of 5gb!) includes xelatex but does not include the font required to render the U+FF3F full width underscore characters on MacOS 13.3.

The specific error is:

WARNING] Missing character: There is no ＿ (U+FF3F) (U+FF3F) in font [lmroman10-regular]:mapping=t

I assume there's simply a different font being used by default in the full installation? Is it possible to document what font can be specified via the -V 'mainfont:' CLI parameter so that it's buildable with a more minimal latex install?

The initial version should have some kind of identifier, and there should be some expectation set for how updates will be handled. Obvious options:

1. Version numbers, probably using loose translation of semantic versioning
2. Hash of document, any change gets new hash; requires precise rule about what is hashed
3. Date-based version, update gets new date-based version
4. Don't identify versions

I appreciate them all and they 1-3 mutually exclusive, but aren't often strung together. I don't know that there's a dominant practice. I suggest 1 for familiarity.

The BEIPA says that "[t]he Company owns any IP... that you create, or help create as its employee or contractor." It is unclear whether this intended to cover any work done during the term of the employee's employment (and which satisfies an "additional condition"), or only work performed within the scope of the employee's responsibilities to the employer.

@seanlee14 recording side project I mentioned. Search for examples of:

• Employee IP Agreements that have been made public from other companies
• Employee IP Agreements provided as templates, particularly for software industry
• Employee IP Agreement terms, gist but not full text of which have been revealed in online discussions, eg Google: https://news.ycombinator.com/item?id=1969979 https://www.quora.com/Does-Google-require-that-employees-grant-them-the-copyright-to-all-code-they-write-while-employed-by-Google-or-are-employees-allowed-to-own-their-own-non-commercial-side-projects/answer/Theodore-Tso-1
• Law review articles giving review of or recommendations for current practice for employee IP agreements; http://home.sandiego.edu/~lobel/ one probable author

Purpose: [in]validate https://github.com/github/balanced-employee-ip-agreement#how-does-beipa-differ-from-other-employee-ip-agreements

Many employee IP agreements are very generous – to the employer. The employer gets control of everything the employee creates during the period of employee, 24/7, and sometimes anything created before the period of employment, and sometimes control over what a former employee can create (through "non-compete" terms). BEIPA only claims control of what the employee creates during the period of employment, and only creations made for or relating to the company's business. There surely are other "balanced" employee IP agreements in use. We hope so, and encourage progressive companies to share their agreements and lessons.

Two things here seem to cry out for FAQs...I'm not sure of the answers:

IP Protection. The Company might someday need to show the work that went into the development of a project. To help in those situations, you agree not to destroy any records you maintain relating to the development of any Company IP (e.g., email, repo, or chat threads) and, if the Company asks, to provide them.

You're agreeing to never delete email? I wonder how this works from employee perspective and separately if it would conflict some company's retention policies and thus should not be in reusable agreement? I assume it makes sense but stating why in FAQ could help deflect unease.

You agree to help the Company secure and defend its rights in Company IP, including after you leave the company, and you authorize the Company to act on your behalf (as your agent and attorney-in-fact) in securing all rights related to Company IP.

A FAQ about what kind of obligation "help" entails also might be useful.

The Company recognizes that you may be engaged in work that requires you to submit code to entities other than the Company, such as libgit2 or Git.

Maybe instead:

The Company recognizes that you may be engaged in work that requires you to submit code to entities other than the Company, such as open source projects used by the Company.

Or something more elegant?

Issue ahead of a possible PR.

Current section 3 reads:

Contribution of your IP to Company projects. If you include your own IP – such as IP you created prior to working for the Company – into a Company product or service, it's still yours, of course, but you grant the Company a nonexclusive, irrevocable, fully paid-up, royalty-free, perpetual, sub-licensable, transferable, worldwide license to use it without restriction in any way or implementation, in modified form, or as is, by itself, or incorporated into another product or service ("License"). If you include your name in any project over which the Company would have rights under this Agreement, such as in a copyright notice or a comment in code or documentation, then the License covers the rights associated with that use of your name as well.

If the point is a completely permissive license---essentially waiver of exclusive rights against the company---why not license "your own IP" to the company under the terms of well-known form public licenses?

Setting other feedback I may have on section 3 as currently worded aside for the moment, consider:

Contribution of your IP to Company projects. If you include your own IP – such as IP you created prior to working for the Company – into a Company product or service, it's still yours, of course, but you grant the Company a license to use it ("License"). The terms of that license are those of The MIT License (as standardized by SPDX) for software, configuration, and other engineering work, and otherwise those of the Creative Commons Attribution 4.0 International license. ...

(This is just a first stab. If there's interest, I might propose different language in a PR.)

I see a few advantages to this approach:

1. The usual license litany---nonexclusive, irrevocable,...---is a potent, magic-words sleep spell. If the agreement wants to read plain, it'd do better without it.

2. Even if the standard licenses use much the same kind of jargon, many folks have experience with how they're used, and what they mean. That being the case, referencing the jargon in a preexisting license isn't hiding the ball, but still cleans up the terms.

3. There are extensive resources for not-so-lawyers about MIT, CC-BY-4.0, and their ilk. For CC-BY, the authoring institution itself provides explainers. MIT has been analyzed repeatedly, in print and online.

Most potential users probably ultimately deliver contracts to employees in a paper-like format. I'm not sure what the best way to export a markdown document to one of these is (or import markdown into), so I doubt this knowledge is widespread. Possible solutions:

1. Provide recommended instructions on exporting or importing markdown, preferably usable for users of any of Google Docs, Libre Office, and Microsoft Office.
2. Provide canonical ODT and DOCX versions project generates from markdown
3. Switch source format from markdown to ODT or DOCX (also see #28)
4. Do nothing, the world should move to using markdown natively, let people not there yet figure it out

PDF is easy to generate from document formats and not as useful for any use case requiring modification, so did not directly address in solutions above.

In Section 2, the text appears define what the Company does not own by referencing what the Company does own, saying "the conditions above in Section 2", but that's the same section we're currently in. I assume it should say "the conditions above in Section 1".

Are the terms of "Your contributions to non-Company projects" intended to create binding obligations, or just state preferred company practice? The company could fire for failure to abide by them, but of course in work-for-hire situations, they can fire you anyway.

Hi. Not a lawyer. Looking at using Beipa in EU, and it looks like an IP assignment is valid in certain EU countries only if the length of assignment is specified. So, at the end of section 1), I would add: ", indefinitely (or alternatively the maximum period allowable by law in case a specific period needs to be assigned as per applicable law or 100 years if that maximum is not specified by law).

In section "7. Cooperation" I read:

To help in those situations, you agree to maintain all records relating to the development of any Company IP, and, if the Company asks, to provide those records to the Company.

I think that giving the responsibility for IP record protection to the employee poses the company at risk for different reasons:

1.- Looking at ISO 27002, there is a security control regarding records "18.1.3 Protection of records". That control begins with:
"Records should be protected from loss, destruction, falsification, unauthorized access and unauthorized release, in accordance with legislatory, regulatory, contractual and business requirements."
If there are records relevant to the company regarding IP, the company should require the employee to provide them to the company while at work. By doing so, the company can perform a proper backup of that information, and avoid the employee (or future ex-employee) from losing it.

2.- There is another ISO 27002 security control which which gives a hint about what should be considered when an employee is fired, "9.2.6 Removal or adjustment of access rights". That control ends with:
"In cases of management-initiated termination, disgruntled employees or external party users can deliberately corrupt information or sabotage information processing facilities."
Again, you can't trust a former employee with keeping those records for the company's good.

3.- Again, thinking about information security, there is another security control affected here, "8.1.4 Return of assets". That gives more hints:
"In cases where an employee or external party user purchases the organization’s equipment or uses their own personal equipment, procedures should be followed to ensure that all relevant information is transferred to the organization and securely erased from the equipment (see 11.2.7).
In cases where an employee or external party user has knowledge that is important to ongoing operations, that information should be documented and transferred to the organization.
During the notice period of termination, the organization should control unauthorized copying of relevant information (e.g. intellectual property) by terminated employees and contractors."
Maybe what BEIA proposes sounds good if we are talking that the employee works on open source projects for the employer, and that he works on personal open source projects at the same time. But BEIA says "But BEIPA is not specific to open source", and then we can go into problems (from my point of view).

These are just a few that come to my mind to support my suggestion: it is a VERY BAD idea to delegate IP record management on employees.

Noticed the "versioning" bit in CONTRIBUTING. Folks may be interested in the "Reviewers Edition" system I cooked up for functional prose:

https://www.npmjs.com/package/reviewers-edition-parse

The intended use case was legal forms on commonform.org, but I've applied it to tagged releases on GitHub, as well.

For those coming from SemVer:

1. No x.y.z software-style numbers, but still machine-readable. SemVer-looking version numbers applied to functional prose can't mean what SemVer says they mean. Versions with different meaning ought to look different.
2. No 0.y.z "hole" in the semantics.
3. Direct focus on the message intended from maintainers to consumers, rather than vague functional criteria that only get fuzzier when applied to prose, rather than code. New Reviewers Editions tell users what they should review and assess, based on the Reviewers Edition of the copy they're already using.

Before first pass at making reusable (#1) those changes should be reflected here.

To the extent allowable by law, employers get control over everything employees create while employed, 24/7

How is that different in any practical terms from

The Company owns any IP ("Company IP") that you create, or help create as its employee or contractor, but only if it meets one or more of these additional conditions: The IP was (i) related to an ... prospective Company product"

Everything that the company is honestly interested in is related to a prospective Company product. So at best, this might protect you from bad faith, ie., the company claiming your IP to be theirs despite not actually interested in developing it into one of its products. But try to prove that.

and sometimes even to gain control over what former employees create through "non-compete" terms. For an overview, see The New Cognitive Property: Human Capital Law and the Reach of Intellectual Property.

How is that different in any practical terms from 7 ("IP protection")?

If you switch from employee A to employee B and develop a product for B, this allows A to file a patent on that product, claiming you developed the core idea during your old contract. 7 forces you to support that claim. In particular, it isn't possible for you to claim that the patent is invalid. This is, in disguise, exactly one of those "non-compete" terms criticized by "The New Cognitive Property".

All in all, this is a hypocritical agreement. It it guilty of exactly those sins which it criticizes.

From my own negotiated IP agreement with my current employer, they included wording similar to ¶1(i):

The IP (i) related to an existing or prospective Company product or service at the time you developed, invented, or created it,

Except in the smallest of companies, it's probably impossible for an individual employee to know what might be a "prospective" Company product or service at any given time. In my agreement, this was changed to something like:

The IP (i) related to an existing or demonstrably prospective Company product or service of which you had knowledge at the time you developed, invented, or created it,

A related clause also required me to have been directly involved with the existing or demonstrably prospective product or service in the two years prior.

Can we put together a working group to evaluate if this BEIA if legally enforceable in New York State?

My understanding of NY State's (regressive) laws are that IP created by computer programmers is owned by the employer, onsite or offsite business location, on company property or on employee-owned property.

So because of the regressive law, your BEIA will get thrown out by a NY State court. Can we think about this or address this?

I personally would like to start a NY-based advocacy group to lobby Albany to change our regressive laws. I am seeking others in NY State who would be interesting discussing this with me.

The European Union, Korea, Russia or Mexico have a specific intellectual property right protecting databases, separate from classical copyright.

It doesn't look like this right is considered in BEIPA, probably due to its US-centricity. It probably should be corrected.

To give a concrete example, an example of licensing leveraging this right is the Open Database License, which is a copyleft license. This licensing is what is used for OpenStreetMap, which is attracting more and more attention from big corporate players.

2. What the Company doesn't own. If you create IP outside the scope of your employment or contract or before or after your employment or contract ("Your IP"), the Company doesn't own it. This is true regardless of the computer you use to develop Your IP, including the one furnished to you by the Company.

I think the computer that the employee uses to develop his personal side project is relevant for a number of reasons:

1.- Imagine you work in an office and use the corporate desktop to write your side project outside of working hours (during your lunch, or after EOB). Imagine you're called by your Manager and he notifies you that you are fired. After that, you are not allowed to use your desktop anymore (IT has probably disabled your user account). If you want to get a copy of what you had on your computer the Manager will have to allow you to do it, and if you are leaving on bad terms that can be problematic.

2.- Imagine that you work from home, with a corporate laptop running, connected to the corporate Active Directory. If you are fired, you can't login again. You have the laptop at home, but you can't access your code.

3.- Imagine that you want to develop an Apple iOS application, but you don't have money for the required software license. Or you want to develop using a development tool which has an expensive license. I don't think the employer will be very happy seeing that you use paid tools for your personal benefit.

4.- How are you going to extract the personal IP from the corporate computer? Are you going to connect a USB to extract it, are you going to upload it to your personal Dropbox? Are you going to send it by email as an attachment?
From a cybersecurity perspective, all these are situations that your Security Team may have restricted, or your security corporate policies won't allow you to do.

Honestly, there are more cons than pros to using a corporate computer while developing your personal IP. I would discourage using a corporate computer for any personal purpose.

For these reasons I recommend removing that idea about using the corporate laptop for your personal side projects, or give two options and let the company choose:
a) What the employer can include in the terms if they're ok about using corporate computers for this.
b) What to include if they don't want corporate computers (or corporate resources) used for personal side projects.

Are there any additional resources that could be linked to in order to help understand what is "within the scope of your employment" versus what is "relates to the Company's business" versus what is not related to the company business at all? It seems like understanding those phrases (I'm not a lawyer) are very important to understand what BEIPA is all about.

In the FAQ in the README.md a clarification is given about patents and seems to imply that unless the employer has specific patent objectives (and thus falling under the scope of employment), that under BEIPA the employee could in their spare time file patents for things they are doing within the scope of their employment (say some code they were asked to write) but that action of filing patents isn't within scope (the company didn't ask them to file patents) so the employee would own the patents? Is this an incorrect interpretation of how 'scope of employment' works?

Our legal team has draw up a version of BEIPA that applies to the laws of the People's Republic of China. And, we are willing to release to the public domain under CC0-1.0.

If anyone is interested in it, please click brickdoc/balanced-employee-ip-agreement for the full article.

When we're ready.

I'm just getting up to speed on this BEIPA project (and on the workings of GitHub generally). I am a lawyer who founded and manages a firm that serves, almost entirely, startups and entrepreneurs (or those joining or exiting such companies). We normally represent the company, formally speaking, though the companies we represent are typically controlled by a single founder or a pair of co-founders. We also strive to draft shorter, more readable legal documents. I appreciate the spirit of balance that this project is trying to promote in the relations between companies and employees over the issue of IP creation and ownership.

One issue that I'd like to acknowledge is that if a company and its founders try to be more reasonable / middle of the road with a document like this, they run the risk that later investors – especially institutional/professional investors advised by the types of law firms that draft very aggressive IP provisions – will object to it as insufficiently protective of employer IP and essentially force the company (e.g., in advance of a Series A round) to amend all such agreements back to one of the more aggressive forms. They might view going back to such typical agreements as "cleanup," though I imagine that the status of this project as an offshoot of GitHub's own employment agreement does lend it a good measure of credibility. Generally, in startup land, the desires of institutional investors – who take the approach of locking everything up tightly – tend to get a lot of traction in standard documents and are portrayed as "standard."

It might help to drive adoption if some high-profile, successful entrepreneurs or some well-known VCs came out in support of this as beneficial for both employees and employers. Something similar happened regarding the issue of post-termination exercisability of options; no longer is 30-90 day PTE seen as obligatory but it took some time to get there.

I hope this comment is not out of place.