github / balanced-employee-ip-agreement

GitHub's employee intellectual property agreement, open sourced and reusable

Balanced Employee IP Agreement (BEIPA)

BEIPA takes a balanced approach to assigning control of intellectual property (IP) created by an employee. The company gets exclusive control of IP created in the scope of an employee's job. The employee maintains exclusive control of IP created outside of their job and not related to the company's business. For IP created outside of an employee's job but related to the company's business, the employee maintains ownership and the company gets a non-exclusive and unlimited license. A company using BEIPA doesn't try to claim control of an employee's free time knowledge production, nor does it try to extend company control past the period of employment. Think of BEIPA as a commitment to employee autonomy and "work-life balance" – for the mind.

BEIPA was started as a reusable version of GitHub's employee IP agreement. Your company can use BEIPA too, and modify it as needed. If you'd like to help improve BEIPA for everyone, file an issue or make a pull request. While aiming to maintain the same "balanced" policy, we're keen to see feedback and suggestions for improving BEIPA and associated documentation. Please read our contributing guidelines and instructions.

Contributors to this project are not your lawyers and nothing in this repository is legal advice. See extended disclaimer below.

PDF, ODT, and DOCX copies of BEIPA are available for download.

FAQ

Why are employee IP agreements deemed necessary by employers?

In the United States, without an express agreement employers usually own works subject to copyright and have either ownership or a "shop right" to use inventions. With an express agreement, employers can obtain lower risk, more certainty, and more control over more IP in more situations – so it's easy to understand that robust IP agreements with employees (and contractors) are necessary. But it's possible for IP agreements to go too far...

How does BEIPA differ from other employee IP agreements?

Many employee IP agreements are very generous – to employers. To the extent allowable by law, employers get control over everything employees create while employed, 24/7, over work created before their employment, 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.

BEIPA only claims exclusive control of what the employee creates during the period of employment and within the scope of their job, and non-exclusive freedom to use other creations relating to the company's business. There surely are many other approaches to relatively "balanced" employee IP policy. We encourage progressive companies and workers to share their agreements and lessons.

Why would an employer want to use BEIPA?

Your best employees are creative all of the time. BEIPA is good for recruitment, retention, and motivation – just like other practices and policies that authentically promote work-life balance and autonomy:

• Employees who feel they need to look over their shoulder and hide personal projects are demotivated and set up for conflict.
• You don't want to push out employees who feel they need to leave in order to work on a personal project.
• You don't want to keep employees who are staying only because they're uncertain whether they have the rights needed to leave and work on a side project full time.
• You want to encourage employee learning through creation and contributions to their communities (e.g., through open source), unhindered by need for employer permission.
• Controlling employee side projects does not contribute to revenue or profit.
• Having a non-exclusive license to employee IP related to the business maximizes benefit from employees' 24/7 creativity without the above downsides.

Why would an employee want to use BEIPA?

You don't want to have to look over your shoulder or hide, feel forced into staying or leaving, or discouraged from learning and contributing with free time projects, because the employer may be claiming to own your creations. You can know that your employer has made an authentic commitment to (at least) one aspect of work-life balance.

Why is BEIPA good for innovation? For society?

We know that societies and industries prosper when there is clear and fair (thus efficient and legitimate) property ownership and high labor autonomy and mobility. Employer control of all IP created by employees, even created during free time and not related to the business, sets up conflict, is perceived as unfair, and has employees and their ideas trapped. The effects of such control projected into the future (or not) has been well studied: the non-enforceability of non-compete agreements in California is one of the key advantages Silicon Valley has had over other regions, where employees have to wait years to strike out on their own.

Broad adoption of BEIPA should have similar beneficial effects for the communities and industries in which BEIPA is adopted.

What does BEIPA mean for open source?

BEIPA makes it clear that an employee can contribute to open source projects in their free time, without needing employer permission. But BEIPA is not specific to open source: An employee can also work on a closed source project in their spare time, and own it. BEIPA controls when an employer owns IP created during a period of employment, and when an employee does (and when the employer gets a non-exclusive and unlimited license). Open source adds another dimension, permission to anyone to use a knowledge product (e.g., software), subject to at most very limited conditions concerning provenance and sharing.

The IP owner of a knowledge product can decide to release the product as open source, whether the owner is an employer or employee, but doesn't have to. So BEIPA is mostly orthogonal to open source, but it will probably result in somewhat more open source developed by employees, simply because it removes a barrier or uncertainty around doing so.

A different employee IP agreement could stipulate that all IP created by the employee will be released as open source. That's not what BEIPA does, but if you know of such an agreement used in the wild, we'd love to hear about it (and about other more esoteric employer/employee balanced or generous to the public employee IP agreements, perhaps involving joint ownership).

What does BEIPA mean for patents?

BEIPA covers all forms of IP. A BEIPA covered employee can file a patent on work outside of the scope of their employment, and the employee would own it (if it is related to the employer's business, the employer automatically gets a non-exclusive license).

If employer and employee have particular patent objectives, they could be spelled out in a different or complementary IP agreement or other policy. One example of such an agreement is the Innovator's Patent Agreement from Twitter, a commitment from a company to its employees that the company will not use patents in offensive litigation without the permission of the inventors. Other pertinent policy choices include participation in anti-troll and non-aggression networks such as LOT and OIN, as well as contributing to open source projects.

In what jurisdictions is BEIPA applicable?

BEIPA was initially written for the United States. Version 2.0 also incorporates language necessary for use in Germany. Feedback on making it more useful in any jurisdiction is most welcome.

Even within the United States, limits on employer ability to claim all employee-created IP vary. In California the main difference made by BEIPA is that IP developed with company equipment or relating to the company's business, but in an employee's free time and which the employee is not involved in as an employee, is not owned by the company (but the company does get a non-exclusive and unlimited license if the IP relates to the company's business). This recognizes that from the employee perspective, segregating one's life activities based on ownership of devices at hand or relatedness to an employer's potentially vast range of business that an individual employee is not involved with as an employee imposes significant cognitive overhead and often doesn't happen in practice, whatever agreements state. It also recognizes from the employer's perspective that the employer has a real interest in being able to use any IP created during an employee's term of employment that is related to their business (note this expands and makes explicit the traditional "shop right" to use in lieu of demanding exclusive control). In some states with less employee-friendly law, BEIPA makes a bigger difference relative to the maximum employer control allowable by law often baked into employee IP agreements.

See Laws Concerning Employment Agreements and Intellectual Property Assignment for a collection of some laws regulating employee IP agreements. Some of these may be helpful information for or even required notifications to covered employees. Currently only U.S. state laws are included. Contributions to coverage of other jurisdictions are welcome.

Can I use BEIPA?

From an IP (copyright) perspective, the agreement is dedicated to the public domain (see license below), so the answer is yes. But please be reminded that it is offered without warranty (see disclaimer below).

How is BEIPA pronounced?

In English, think Beijing. Say Bay-pa.

In other languages, use the natural pronunciation based in the spelling.

What are some other relatively balanced approaches?

Employer

Defaults matter a lot, but clear and well-executed processes that allow employees to own personal projects or contribute to open source can also contribute significantly to balance. A Model IP/OSS Policy documents such processes in an employee IP agreement, based on practice at Rackspace. Google has publicly documented some of their processes for personal project ownership and releasing open source.

Employee

ContractPatch, information about negotiating employment agreements for open source developers.

Public Policy

Various U.S. states are considering non-compete reform, tracked at Fair Competition Law.

Acknowledgements

@hoolio, @jessephus, and @talniv, with feedback from GitHub employees and external counsel, created GitHub's employee IP agreement, which BEIPA makes reusable.

Disclaimer

GitHub, Inc. is not a law firm and does not offer legal advice. GitHub, Inc. and contributors to BEIPA offer no warranty of any kind and disclaim all forms of liability for BEIPA. Consult with your own attorney before using BEIPA.

License

Dedicated to the public domain under CC0-1.0 by GitHub, Inc. and contributors.

Note that CC0-1.0 does not grant any trademark permissions.

Norms

If you adapt BEIPA's text for your company's use other than by replacing bracketed [] fields, please change its name or state that you've changed the agreement so its no longer BEIPA. If you wish to attribute BEIPA, a link to its repository would be nice. If you'd like to tell us about how you've used BEIPA, or give us feedback, please do.

balanced-employee-ip-agreement's Issues

Length of IP assignment

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

Clarifying what would be outside the scope of employment, but related to the Company's business

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?

Preferred attribution?

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?

Reconciling an IP agreement vs. IP provisions in Employment/Contracting contract

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?

Set issue/PR response expectation in CONTRIBUTING.md

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

Maintaining as a GitHub open source project?

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

Statutes in Exhibit A are poorly formatted

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

Meta issue

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.

Elaborate on what "keeping this information confidential" entails

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.

Make "such as libgit2 or Git" less specific

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?

Model Company Employee Agreement Creation and Ownership of Intellectual Property

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.

Granting the company to act as your agent and attorney-in-fact does not feel balanced

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.

Announcement on github.com/blog

When we're ready.

Possible integration tests

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

Sounds pretty hypocritical

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.

"accounting issues, revenue recognition and the like"

(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?

"IP Protection" potential FAQs

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.

IP records protection

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.

Ambiguous as to when employee acts "as [the employer's] employee or contractor"

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.

New York State?

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.

Outside Work: Obligations or Suggestions?

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.

Company laptop vs resources?

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

IP developed before employment

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

Employee IP agreement for P.R.China

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.

Will "established players" buy into this?

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.

Violates the idea-expression divide

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

Add required notices exhibit

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.

unable to build with pandoc/basictex minimal

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?

"open-sourced World of Warcraft add-ons"

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.

Models for encouraging co-ownership

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.

No such agreement is required if the software is free

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.

Version # and versioning

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.

Move generated pdf/odt/docx out of repo into releases

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?

Employees can't verify "prospective Company product[s] or service[s]"

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.

Variants

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

Clarify whether agreement has been used to cover businesses (vs just individuals)

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!

Copyright infringement by employee under BEIPA

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

Internally document industry IP agreement practices

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

Use well-known public licenses to license from employee to company?

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.

Reflect any further changes in jessphus-clarify-ip-agmt

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

Further Assurances by any other name...

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?

Computer furnished to you by the Company?

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.

Prior Art: Reviewers Editions

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.

Database right (Europe, Korea, Russia, Mexico)

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.

Employee IP agreement for Germany / Europe

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

Incorrect reference to previous section

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

What is Section 2?

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!

README/FAQ needs thorough review

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

Provide ODT and DOCX versions? PDF?

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.