← Process Mechanics

A Model IP and Open Source Contribution Policy

By VanL Tags: Open Source

Many times I come across companies that have open source policies that are just backwards. For many companies, their default legal position is that they don't want anything to do with open source. They don't want their partners working with it, they don't want their suppliers working with it, and they especially don't want their employees working with it.

This is despite the fact that in the last "Future of Open Source" survey, 97% of companies surveyed use open source as part of their product or operations.

Obviously, this kind of contradiction creates problems and stresses. I can't solve all of these problems... yet. But one issue that frequently comes up is how a company can deal with the interactions between its own developers and the open source community.

To help solve that problem, I am releasing a Model IP and Open Source contribution policy based upon the policy we use at Rackspace. Take it, use it - it is released under a Creative Commons CC-BY license. If you click through above the it is available for download in lawyer-friendly .docx format.

This policy reflects many years worth of development, some of which took place before I even came on board at Rackspace. The actual writing didn't take that long, of course. The work went into the development of the specific language, understanding, and arguments that allowed us to implement a policy that worked for for our executives, and our lawyers, and our technical population.

Caveats

This policy is not for every company. Even if your company has a very similar outlook to Rackspace, your specific needs or strategies are different. You will need to look at what will work for you.

Also, I am not your lawyer. I probably don't even know you. We have no attorney-client relationship. This information is given for your information and amusement only. This information is provided without any warranties, duties, or guarantees. You have been warned.

A detour into philosophy

There are a number of philosphical points of view that are reflected in this document. If you don't agree with underlying framework for understanding and creating value with IP, then you will likely not like (or even understand) this policy. So let's take a minute and break them out.

Developing employees is a better investment than developing many kinds of IP.

This is the key assumption, and it is controversial in some circles. This is about your business philosophy, not the law.

Most companies take the approach that they are better off capturing all the possible IP output from each employee and keeping it within the company. The "capture it all!" philosophy comes from an effort to eliminate downside risk. If you don't know what might be valuable in the future, then you try to hold on to everything to avoid letting out the goose that lays the golden eggs.

In contrast, this IP policy comes from an effort to maximize the value of each employee's contributions, even if the place where the IP is most valuable is in outside hands. There are other ways that IP provides value other than keeping things secret or licensing them for money.

This policy builds on the assumption that only some parts of a company's IP matter to the company. The other parts of the company's IP can be more profitably used in developing the culture in the workplace, the capabilities of the employees, and the reputation and mindshare of the company.

Because of this assumption, this policy requires a high degree of internal self-knowledge and self-confidence within company leadership about what the company does to provide value.

Contributing to existing projects

Let's be more concrete: Let's look at the case of a patch to an existing OSS project. The chance that your company will have unique, valuable IP in a patch provided to an existing open source project is very low. The project is already in the sphere of public knowledge. If the patch is not shared, it probably stays within the mind of the one employee who developed it, and it can even be a financial burden to the company to maintain as a parallel, non-integrated patchset over time.

On the other hand, letting out the IP associated with the patch builds the employee's knowledge base and reputation. It shows that the company is invested in the development of that employee and creates a sense of empowerment and autonomy. All of these benefits also lead to higher morale and better employee retention.

Releasing company IP to the outside world

The trickier issue has to do with the release of company-developed IP to the outside world. This policy takes the pragmatic view that not everything should be released - but that many things can be.

This is because only a fraction of the company's efforts actually provides differentiating value to customers. Regardless of what you do, or what business you are in, or what your product is, you spend a lot of time, effort, and money on stuff that either serves your internal needs or is simply "table stakes" for customers.

At a high level, this should not be controversial. From an accounting perspective, companies already break out "G & A," or "General and Administrative Expense." This is finance-speak for overhead - things that companies do that don't directly build products or create revenue.

But let's look within a revenue-producing, you-sell-it-for-money product. A "product" is usually not a singular entity. Instead, it is a bundle of lots of little services, or code, or components. While each of these little pieces may be necessary to the final product, most of them are not differentiating to the customer. They don't provide a reason to buy.

A few simple examples: Screws and nails are essential parts of a house, but only rarely do buyers care about which screws and nails are actually used. A smartphone dialer (the number pad used to input the phone number) is a necessary part of the smartphone product, but buyers only really care that it is there and that it works.

You can break apart every product into smaller and smaller bits, and you will find that most parts of most products are necessary, but they don't actually drive customers to buy. Any parts of your product that don't drive customers to buy are candidates for sharing.

Build assumptions about trust and judgment into your agreements with your employees.

Your employees have already made a substantial commitment to your company. They are trusted to exercise their discretion on behalf of the company all the time. So, where possible, build on those assumptions in your employment agreements. It is better to have a flexible policy that implements an expectation of good judgment and honesty than to have a rigid policy that ends up creating compliance headaches because you can't anticipate every situation.

It is true that you need to "trust but verify" by building checks into the process. But starting from the assumption that your employees can exercise judgment makes many things easier. And if you can't trust your employees, well, you need much more help than I can give you.

Finally, optimize for easy compliance.

Policies are overhead. The most effective policies are the ones that receive the highest voluntary compliance. Sometimes policies can be effectively enforced, sometimes they can't. A strict, "optimal" unenforced and unenforceable policy is far worse than a less-constraining policy that has high voluntary buy-in.

The policy

This policy takes the form of an IP assignment agreement between an employer and an employee. It has some legalese, but the jargon is kept to a minimum. The agreement as a whole is designed to be read and understood by the employee. Remember, the goal here is voluntary compliance. The employees will have a hard time with voluntary compliance if they feel like they have been given an inscrutable wall of small print.

Unfortunately, there is only so much you can do to make things simple: it is eleven pages long, with three of those pages providing state-specific guidelines that govern employer-employee IP agreements. But the agreement as a whole tells a logical story, roughly based on the chronological experience between the parties.

The Preamble

Diving into the policy itself, it is worth starting with the preamble. The preamble is designed to be a combination executive summary and announcement of the core principles motivating this agreement:

ModelCo employees are productive and creative individuals. ModelCo has a responsibility to safeguard our corporate interests, but we also value and respect the personal initiative of our employees. We hired you because we believe in you, your skills, and your value, and we recognize you will have many opportunities to do and create cool things outside of your employment here. We support your independent efforts to build, and create, and contribute, and we want to provide clear communication and guidelines about how to do so properly. We want to make sure that we set common expectations so that we are never in an adversarial position relative to our employees. The legal terms below flow from these objectives.

Three points to take away from this preamble. First, this sets up a position of mutual respect between the company and the employee. Both are entering into this agreement to provide something of value.

Second, the purpose of this agreement is to provide rules and guidelines to coordinate the employer and employee's mutual efforts.

Third, and this will be important later on, we never want to be in an adversarial position with our employees.

Section 1: Definitions

The definitions of "Confidential Information" and "Intellectual Property" are relatively straightforward. There are two important definitions, though, that pave the way for the later sections. The first is the definition of "Company Resources":

“1(c): Company Resources” means any action or Intellectual Property that meets at least one of the following conditions: created (1) acting at ModelCo’s direction, (2) in connection with your employment by ModelCo, (3) for use by ModelCo, (4) during your working hours as a ModelCo employee, or (5) using ModelCo equipment other than a ModelCo-provided laptop or ModelCo-provided mobile phone.

This is an important definition because it defines Company Resources in a way that includes time, direction, and intention. In most IP agreements, "Company Resources" are defined relative to the use of equipment. This definition includes most uses of company equipment, but also makes clear that intention and direction also count.

This definition also includes a siginificant give-back to the employee: they can use their company-provided laptop and mobile phone to do personal work. This is a reflection of the fact that we all live mixed lives these days, with work and home life both blending together. This avoids a trap for the unwary and makes it easier for employees to comply with the policy overall.

The second important definition is the definition of an "Open Source Project":

1(d): “Open Source Project” means a project that (1) has its complete source code, documentation, and build files available to the public under a license accepted by the Open Source Initiative as an open source license, (2) is downloadable by the public without registration, payment, or any other type of consideration, and (3) is publicly advertised and available on the World Wide Web.

This definition is designed to prevent some types of possible gamesmanship. Per this definition, a project only counts as open source if it is not only licensed appropriately, but is widely available to the public for free. An "open source project" that only exists on your server at home isn't really open source.

Section 2: Ownership of IP Created Prior to Your Employment

IP created prior to employment belongs to the employee. Period. The employee can also continue to develop Prior IP, as long as the employee does so without using Company Confidential Information or Company Resources.

One noteworthy bit is that this policy recognizes repo commits as a reasonable method of proving that something was truly prior IP in the case of a dispute.

Section 3: Ownership of IP Created Using Non-company Resources

This is the next section because most developers will want to know if they will be allowed to have side projects. The answer to that question is yes - but the policy has some important nuances. Keep in mind that these guidelines are for new side projects created by employees, not on company time.

Section 3(a): No Subject Matter Conflicts

You will not knowingly participate in the development of IP related to a current or planned Company product, service, technology, or offering without prior authorization from the ModelCo IP Committee. Authorization may only be provided on a per-project basis. Knowledge of a product, service, technology, or offering includes knowledge of perceived gaps or opportunities for add-ons, extensions, improvements, complementary technologies, or value-added services.

This is one section where employees are expected to use their judgment. The policy doesn't try to spell out every possible situation. Instead, it spells out that employees cannot put themselves into conflict with the employer.

Sections 3(b)-3(c): Notice, not permission

Employees are required to give notice of their side projects in a very low-ceremony way: by sending an email.

3(b): Notice to Company. You will promptly notify the ModelCo IP Committee using the proper channel (currently by email to ipc_notice@modelco.com) whenever you start any new project that involves the creation or development of IP. The proposed project and resulting IP must be described in enough detail to allow the Company to understand the scope, purpose, timeline, and any known conflicts. You must also promptly notify the IP Committee if the nature or scope of an existing project changes significantly.

As I stated earlier, one of the keys to a successful policy is voluntary compliance. We want to provide as small a barrier as possible to employee creativity, while still giving the company the chance to track and respond ongoing projects.

From the business and legal side, though, this is one of the parts that makes people worried. It is up to the company to review and keep up with these new project requests. If the company does nothing, the project is deemed OK:

3(c): Authorization. The Company understands that you may not know the full scope of ModelCo’s business activities, and so a project may pose an inadvertent subject matter conflict. To address the possibility of inadvertent subject matter conflicts, the IP Committee will have sixty (60) days (the “Notice Period”) to provide an initial response to your request.... If no response is provided within the Notice Period, your participation is deemed to be authorized within the scope and purpose of your notice. If the Committee responds to your notice with anything other than clear words of authorization, you may not participate in the project.

"What if we miss something?" they say. "What if there is a new project that crosses into company territory, and we let it go?"

There are a couple responses to these worries. First, don't do that. This is low-ceremony and low-overhead for a reason. It doesn't just make compliance easier for the employees, but it makes it easier for the employers as well.

Second, you need to look at the actual risk, not the theoretical risk. Let's say that in one area of the company they have a plan to implement a new product with feature X. In another part of the company, an independent engineer decides to start a new project providing the same feature X.

Note that this is an issue of two strands of independent development; if the employee was already aware of the parallel development effort, then they would already be barred from creating a subject matter conflict.

What are the reasonable responses?

First, you have an employee who has self-identified as being interested and capable in an area that the company has deemed strategically important. Invite the employee to join the effort!

Second, if feature X is so easy to implement that a single engineer is able to make it work in a couple months of off-hours work, then perhaps feature X is not the differentiator you are looking for, and the product offering needs to be further refined.

Section 4: Ownership of IP created using Company Resources

This part of the policy is about the other side of the bargain: there are certain things that companies pay their developers to do, and they want to own those things. The position taken by this policy is that anything made with Company Resources (which includes company information, direction, and time) is owned by the company, regardless of whether it is part of your official "job description" or not.

4.1: Ownership of Company IP. Any IP created by you using Company Resources belongs to ModelCo (“Company Intellectual Property” or “Company IP”), whether or not the IP is related to your specific job duties. By signing this agreement, you hereby assign and promise to assign all right, interest, and title to all Company IP to ModelCo. In addition, you promise to cooperate with ModelCo in securing and protecting our rights in Company IP that is created by you, whether or not you continue to be employed by ModelCo, and you hereby appoint ModelCo as your limited agent for that purpose.

4.2: Release of Company IP

The ModelCo IP Committee is the only entity authorized to establish new licensing terms for any piece of Company IP. If you believe that your work would be beneficial to release as open source or otherwise license, send an email describing the suggestion to the IP Committee at IPC@modelco.com.

The policy also makes explicit that the company's authorized representatives (here, the IP Committee) is the only group authorized to license out Company IP, for example to create a new open source license. While the process around release is deliverately simple (again, set an email), and the policy is relatively open, each company needs to decide whether the release of particular IP is strategically the right thing to do.

As an aside, at Rackspace we have found that in most cases, our employees already have a good idea about what is and is not sensitive and what can and should be released. We have only had to deny a handful of requests over the past several years.

4.3: Exceptions

With the ongoing and written approval of your manager, you may use Company Resources for the creation and development of IP to be contributed to existing Open Source Projects or to be used as part of any Non-Code Works, as those terms are defined in this Agreement. The ability to use Company Resources to contribute to Open Source Projects or to develop Non-Code Works does not change or supersede your day-to-day job responsibilities as set by your manager. In all cases, you shall exercise good judgment and act consistent with The Company’s core values.

This section peels back some of the more absolute rules to give employees the flexibilitiy needed to develop their skills and participate in various communities. It opens the door for people to work on open source projects, even at work. But these exceptions represent a couple of key compromises:

  • You need the approval of your manager. The existence of a policy that allows employees to contribute to OSS projects does not mean that employees can substitute OSS work for whatever they have been assigned to do.

  • You need to use good judgment. It is true that asserting that employees must use good judgment and adhere to company values is not enough to deter all bad behavior. But by making the requirement explicit, it allows poor judgment to be dealt with as a violation of the policy without trying to specify all the ways in which people can do stupid things.

4.3(a): Contribution to Existing Open Source Projects

You may contribute your original code in your own name and under your own copyright to existing Open Source Projects that do not directly compete with a Company-sponsored project or product. You may contribute to existing Open Source Projects that are directly competitive with a Company-sponsored project or product where you have received prior authorization from the ModelCo IP Committee.

This policy allow carte blanche contributions to open source projects that are not competitive with company-sponsored projects or products. This provision is to minimize conflicts of interest as well as reducing the possibility of inadvertent IP release. Competing projects are whitelisted on a per-project basis.

Within Rackspace, we have even gone further, and allow contribution to all established open source projects, even ones that compete with our sponsored projects and offerings. We only ask that employees talk with us and explain why they want to contribute and what they hope to improve.

4.3(b): Non-Code Works

Not everything that people do is just code. One of the pitfalls of overbroad IP policy is that it captures things that are beneficial to the company, like creating and giving presentations, writing books, etc. This section gives employees the freedom to create in other ways but with a few specific restrictions.

4.3(b): Non-Code Works. Employees are encouraged to create non-executable copyrighted works (such as books, speeches, articles, and publications, collectively “Non-Code Works”) and can do so in their own name and with their own copyright, without any prior approval, subject to the following:

i. Notice Required for Compensated Works. You must provide notice to the ModelCo IP Committee at least ten (10) business days prior to publishing any Non-Code Works for which you expect to receive compensation in any form from any third party. ModelCo may, at its discretion, require you to forego any compensation for work done using Company Resources.

ii. Credit to the Company. You may state that you work for the Company in your background or biographical material. If you developed any part of the work using Company Resources, you may say that the Company sponsored the creation of the work provided that you do not represent the work as an official the Company publication.

These sections are designed to address double-dipping (for conflict of interest purposes), to give appropriate guidelines for talking about the developer's employment.

There is also a special restriction for those employees who create non-code works as the output of their job responsibilities:

iii. Limitations on Non-Code Works. This section does not apply to any Non-Code Works made in the course of employment or with Company Resources (such as documentation, teaching curricula, business plans, etc.). This section also does not give any right to use or publish any Confidential Information or to use any ModelCo trademarks in a Non-Code Work.

If your company has a someone whose job it is to create written or visual materials, then those materials created at the direction of the company should be treated as work output, and not as something that was created for personal development.

Section 5: Limitations and Restrictions

Sections 3 and 4 provide considerable freedom for employees to engage outside the company; section 5 provides guidelines and guarantees that make sure that the company isn't harmed.

Section 5.1: Confidential Information

Employees have a duty to keep Confidential Information confidential, whether it belongs to the company or a third party. Unauthorized release of Confidential Information may result in an injunction.

Section 5.2: No Conflicts of Interest

You will not solicit, enter into, or accept any contract or agreement with the Company, any of its employees, agents, or customers (collectively “Conflicted Parties”), for the purchase, license, or paid use of any IP which you have created or in which you have any right, title, or interest. In the event that an authorized agent of the Company, or a Company customer, approaches you about a possible contract, your conflict of interest must be disclosed and waived, in writing, by one of the Company’s Associate General Counsel or the Company’s General Counsel.

Conflicts of interest are poisonous. I have almost never seen an occasion where overlooking a conflict of interest led to a good outcome. For that reason, many of the restrictions in section 5 deal with various types of conflicts.

This section is designed to prevent the situation where an employee develops something with an eye to selling it back to the company later.

Technically, such development would already be a subject matter conflict as discussed in section 3(a), which forbids employees from developing new projects based upon "knowledge of perceived gaps or opportunities for add-ons, extensions, improvements, complementary technologies, or value-added services." This provision is designed to provide an absolute bar to such activity.

Two real-world wrinkles. First, what if an employee creates a mobile app, or a service, where they don't know if someone is a Conflicted Party or not? How can the employee be sure to stay in compliance? That led to the following clause:

5.2(a): Mass-market offerings. It is not considered a conflict of interest to provide a service or software product accessible to the public in general, including possible use by Conflicted Parties, provided that 1) there is no direct contact with any Conflicted Party; 2) the terms offered to Conflicted Parties are identical to the terms available to all members of the public; and 3) you do not use your relationship with ModelCo, nor any Confidential Information, to establish, advertise, develop, or serve any customer.

Second, some moonlighting arrangements, even if they would otherwise be acceptable, require a restriction on the employee's actions, like a noncompete. This sort of arrangement required another clause:

5.2(b): No restrictions on work. You will not enter into any agreement during the term of your employment with the Company that would restrict the type of work you may perform at the Company.

5.3: Covenant not to Compete

During the term of your employment, you will not solicit, enter into, or accept any contract or agreement with a Company competitor or any of its agents for the purchase, license, or paid use of any IP which you have created or in which you have any right, title, or interest.

This is another type of conflict of interest - providing personally owned IP to a competitor. If a competitor is interested in a particular piece of IP, then it is probably applicable to the company as well.

5.4: Covenant not to Sue

In consideration for your access to the Company’s Confidential Information, you hereby covenant not to sue the Company or the Company’s customers in any venue, for any reason, to enforce any right associated with IP which you have created or in which you have any right, title, or interest.

One of the worst situations is to be in a lawsuit between an employee and employer. Again, by putting the employee and company on different sides of a lawsuit, it creates divergent and conflicting interests. Thus, all suits between the employee and the company over employee IP are prohibited.

5.5 Shop Rights

If you use, embed, or otherwise bring IP which you have created or in which you have any right, title, or interest into the Company in such a way that the Company or any of the Company’s customers may be liable for infringement of that IP, you hereby grant a worldwide, fully-paid-up irrevocable license to the Company and the Company’s customers for such use.

This provision is based upon personal experience: I saw a situation where an employee brought some software into a company and built it into a product. When the employee was fired some time later, he sued the company for copyright infringement.

Therefore, this clause provides a check on the employee's ability to bring individually owned IP into the company. If employee-owned IP comes into the company for whatever reason, then the company and its customers get a license.

5.6 Freedom of Action

Nothing in this agreement shall restrict the Company’s freedom to pursue any business opportunity, course of development, or business plan regardless of any information disclosed by you to the Company at any time.

A final variant of the conflict of interest scenarios: the company can pursue business ideas wherever they find them, regardless of where that idea came from.

Implementing the policy

In concrete terms, there are a few items that are needed to implement this policy.

  • Again, and most important: you need to have your own attorneys look at it. I am not your lawyer, and this is not legal advice. You will probably have other documents and agreements that apply; those need to be harmonized with this document.

  • You should be able to customize this by doing a search and replace, changing "Model Company" and "ModelCo" to your company name.

  • You need to have an IP Committee set up that has both the appropriate authority and knowledge to review submissions that come in under this policy.

  • You need to have appropriate email addresses, lists, or workgroups set up. In particular, the email addresses IPC@modelco.com and ipc_notice@modelco.com are referenced in the text of this document.

  • There are a few specifics you may want to change: the notice period (set in the model as 60 days), the choice of law (Texas).

Final thoughts

There is a lot more to the policy. I have only highlighted a few key provisions that help provide the balance between the two parties that made this an acceptable policy for everyone within Rackspace. I invite you to read the whole thing. Feedback is also welcome - click the email link above.

It took a long while to get to this policy, both in terms of understanding and discussing the acceptable tradeoffs and business issues, and in terms of getting feedback from developers. I want to thank Tina Wuest and Glyph Lefkowitz in particular for their feedback. But the time was worth it; I have been told by a number of people, developers, executives, and lawyers, that they consider this the best policy in the industry. I hope that it proves useful to you too.