The Copyrightability of APIs

Apropos to the current discussions in the Oracle-Google trial, I wrote this in 2007:

COPYRIGHT IN HEADER FILES

One particularly difficult issue concerns copyright protection of header files. An individual name or symbol in a header file cannot be copyrighted, but the particular selection of symbols may be. The selection of symbols to be exported is inherent to API design, which could be a copyrightable creative decision. If you have ever heard programmers talking about “beautiful” or “ugly” APIs, you have wandered into the tricky middle ground of barely copyrightable expression.

In my opinion, the most likely scenario is a case-by-case determination. A bunch of constants would probably not support copyright. The entirety of an exported API is more likely copyrightable, but the header files would probably only support a “thin” copyright, where even trivial changes would be enough to avoid infringement. No one really knows, though, because the law of copyright is changing day by day.

For header files in particular, the rationale for copyright protection is substantially weakened when there is a second compatible implementation of a library. In that case, the headers, as creative as they might be, would probably merge into the functional interface supported by many concrete implementations.

For example, take the C++ standard template library (STL). There are a number of different implementations of the STL, all copyrighted by different authors. The STL headers themselves, however, have become just functional descriptions of the underlying copyrighted implementations. All STL implementations must use identical function definitions in the header files, or they would not be source-compatible with each other.

This Fall is Our Last, Best Chance for Patent Reform

Congress returns to work next week. We need you to call your representatives in Congress. Ask them to pass meaningful patent reform, but tell them that we also need to keep the ability to challenge bad patents in the U.S. Patent and Trademark Office.

Patent reform is needed to reign in patent trolls — companies that buy up vague patents with the intent of suing other companies for infringement. There is perhaps no bigger threat to American innovation and entrepreneurship than these entities, which suck an estimated $1.5 billion from the U.S. economy — every week.

But without more support, we are in danger of losing another round of the fight. Our lobbyists tell us that if we don’t pass good patent reform legislation this fall, it will be very hard to pass in the midst of an election year. That means any meaningful reform would likely be delayed until 2017 or even 2018 – giving patent trolls another two or three more years.

At Rackspace, we have been working to support patent reform for years. There has been great progress in building broad support for dealing with patent trolls – just look at the list of companies supporting reform.

But challenges remain: the issues are complex and our opponents have been clever. They have introduced changes to the House and Senate bills designed to weaken our ability to challenge bad patents in the patent office through a procedure called inter partes reviews (IPRs). These changes are technical and hard for non-lawyers to interpret – but their effect will be profound.

Let’s be more concrete – remember when Rackspace was sued for having a smartphone app that rotated? I talk about it a little here:

Patent Reform Video

Rackspace used the IPR procedure to invalidate the patent, thus solving the problem for everyone. As we found out later, invalidating the patent saved about 400 lawsuits against companies all across the United States.

As for us, we will continue to fight – every time, every troll, every patent. And we will continue to win. But if we want to solve the problem, it can’t just be Rackspace, or NewEgg, or Vizio fighting. We all have to do it together.

Patent trolls are everyone’s problem. They are parasites, trying to suck money out of successful companies by abusing the legal system. We will continue to support meaningful reform, but we can’t do this alone. Click on the link to help.

(Cross-posted at the Rackspace blog)

An incomplete, but useful, model of ethical behavior

I have had a number of business conversations recently where the moral concepts of good and evil have been important to the outcome of the conversation. These have been in conversations about ostensibly morality-neutral concepts like programming language selection, the use of patents, and the best business strategies.

What is interesting is that there was broad agreement in these conversations that certain behaviors were "good," others were "evil," and that others were neutral, despite the fact that we didn't explicitly define what made those actions good or evil.

Personally, I believe in Good and Evil in an absolute sense. But not everyone shares my moral and ethical code. So why did we agree? It seems too convenient that my particular moral absolutes would also end up being universally accepted.

In pondering these concepts, I came up with a model that ties the idea of "Good" and "Evil" to the idea of externalities. Broadly speaking, "good" behavior creates value for others through positive externalities, and "evil" behavior imposes costs on others through negative externalities. But what is interesting - and one thing that distinguishes it from a pure utilitarian model - is the way in which it intersects with self interest as well.

Ethical_quadrant

As illustrated here, "good" behavior is on the right and "evil" behavior is on the left, while self-beneficial behavior is up and self-injuring behavior is down. 1

This model maps very easily to traditional notions of right and wrong behavior. Stealing, for example, imposes a cost on someone else in order to enrich yourself: that is pretty clearly in the "selfish" quadrant. Drunk driving is "stupid": it has a high risk of imposing costs on both others and yourself.

On the positive side, someone who is self-sacrificing in order to help others - with Mother Theresa being the archetypical example - is clearly "Altruistic." Finally, things like writing thank-you notes and being punctual are "smart": they produce benefits for you and those around you as well.

What is nice about the model, though, is the way in which it can apply to a number of situations that don't easily lend themselves to traditional descriptions of moral behavior. For example, patent licensing and litigation.

The ethics of patent licensing and litigation

I have long considered patent trolling to be "evil," but this model helps me explain why. Patent trolling is "selfish": trolls use the structural inequalities in the patent litigation system to extract money from others (a negative externality) in return for benefits to themselves. In the most common scenario, a patent troll identifies companies who are (allegedly) already using the patented technology, so there is no compensating transfer of value to the defendant.

This is in contrast to patent licensing that takes place before the commercialization of the patented technology. If someone recognizes the value of a patent, and licenses it with an eye to exploiting the technology in the marketplace, that is an interaction in which both parties gain something that they value - a "smart" behavior.

This is also in contrast to situations in which someone copies an innovation from someone else. The copying of someone else's work is "selfish" behavior, and litigation is justified because it forces the person doing the copying to internalize (and thus ethically neutralize) the previous taking.

Clearly, not every action is only harmful or only helpful. For example, I had a talk with a lawyer who specialized in bringing patent troll cases. He argued that what he is doing is good: his lawsuits are "allowed under the law" (and thus not a taking), and in pursuing the lawsuits, he creates jobs for people in his firm and provides for his family (both of which are positive in this model).

I disagree. In this model, it doesn't matter that an action is "allowed under the law" - what matters is the effect that the action has on others. I also think that benefits to one group don't necessarily translate into something being "ethical" under this model. I am not sure whether I internally use a utilitarian "maximize the sum of the utility for all participants" model, or whether I think that being selfish for an in-group (your firm, your family) is just an extension of being selfish for yourself. Either way, I see patent trolling as wrong.

A more nuanced argument for patent litigation has to do with global incentives. If patents are easier to enforce, then they are worth more, creating a greater incentive to create. More innovation benefits everyone, thus making the short-term costs to patent defendants part of a globally utility-maximizing increase in innovation.

I agree with this argument in theory. If we had a perfect patent prosecution system, such that every granted patent was novel, and nonobvious, and well-enabled, then I would agree there should be very few limits on the enforcement of patents. In the system we have, though, there are invalid and non-enabled patents that get through the patent office. Therefore it makes sense to restrain patent litigation and support the systems that allow patents to be challenged (such as Covered Business Method and Inter Partes Reviews).

The ethics of software development

A more nuanced application of this model applies to software development. Software bugs create costs - negative externalities. We don't know who will bear those costs, but we can reasonably predict that they will occur. Given the existence of bugs, what are our professional duties as software developers?

@Glyph gave a talk at PyCon 2015 called "The Ethical Consequences Of Our Collective Activities" (video) in which he argues that we need ethical principles to guide our work as software developers. Software programs perform actions on behalf of their users; thus, actions that do not reflect the wishes of the user are unethical. This includes both intended divergences from user interests (like spying on user activities) as well as unintended consequences (like security failures).

Examining Glyph's idea in the light of this ethical model, intended divergences are clearly on the "selfish"/"stupid" side of the axis; the only difference is whether the software developer benefits or not from the divergence.

A more interesting question is whether there is an ethical duty to minimize and mitigate "bugs" - i.e., unintended divergence from the user's wishes. I believe that the answer is a qualified yes.

Clearly, there cannot be an absolute duty of correctness in software. We are all human. Mistakes happen. But where mistakes can cause harm to others, it is reasonable to impose a duty of competence on those who practice a profession.

The closest analogy I can think of comes from the American Bar Association's model rules of professional conduct. The very first rule has to do with a lawyer's duty of competence:

Rule 1.1 Competence. A lawyer shall provide competent representation to a client. Competent representation requires the legal knowledge, skill, thoroughness and preparation reasonably necessary for the representation.

The commentary on rule 1.1 specifies that this rule requires that lawyers evaluate the matters before them and make a judgment as to whether they have sufficient skill to respond to client needs. Different matters require different levels of expertise. If the lawyer cannot reasonably handle the matter, they need to include someone else with the requisite expertise.

The commentary also addresses the need for adequate preparation - with "adequate" being scaled to the importance of the matter - as well as the need for lawyers to maintain competence as the profession and the law advance. This specifically requires that lawyers keep up with relevant technology advances. Comment 8 says:

“[t]o maintain the requisite knowledge and skill, a lawyer should keep abreast of changes in the law and its practice, including the benefits and risks associated with relevant technology, engage in continuing study and education, and comply with all continuing legal education requirements to which the lawyer is subject” (emphasis added).

Although there is no widely-accepted code of ethics for software developers, there is a parallel between a lawyer's duty of competence and the ethical duties of a developer. The developer of an application has a duty to reasonably avoid doing harm to others. The magnitude of the duty is related to the scope of the possible harm. Wasting a user's time through inefficient or buggy code is a lower possible harm than exposing a user's bank information through incorrect use of security protocols.

If you accept this framework for ethical behavior, and you agree that it applies to activities like software development, then it has a number of provocative implications. To some extent, there may be an ethical duty to comment your code, to write tests, and to use source control. There is also a duty to know your limits; if you can't be sure that you got the encryption right, bring in someone who can do a code review.

Other applications

There are a number of places where this model makes sense and leads to interesting results:

  • Activist shareholders. Activist shareholders are clearly self-interested; they are in it for the money. But are they "smart" or "selfish"? You can't say without looking at the specific situation. An activist shareholder that leads to company reform and greater efficiency may be doing good and thus be "smart." On the other hand, a corporate raider arbitraging the differential between the value of a company as a whole and the value in parts is more likely to be harming others and thus be "selfish."

  • Servant leadership. Does servant leadership require that someone act against their own self-interest (i.e., be "Altruistic")? I don't think so. While some aspects of servant leadership may require altruistic acts, the focus of "leadership" in general is about accomplishing a goal, and many leaders are rewarded for their progress towards those goals. Even if individual acts may be self-sacrificing, it is likely that servant leadership in general is beneficial to the leader as well (thus making it "Smart"). One measure of a good leader may be the amount that the leader finds win-win ("Smart") solutions.

  • Game theory. This ethical model directly applies to game theory. In general, interactions that can be modeled as positive sum games are "good," zero-sum games are ethically neutral, and negative sum games are "evil."

  • Capitalism and profit-taking. Building on the game theory result above, trade (and capitalism generally) is ethically positive due to the existence of gains from trade. Even in an ideal transaction, however, how "ethical" it is depends upon the split of the gains between the parties. Tim O'Reilly's maxim to "Create more value that you capture" (video) suggests an ethically positive interaction, whereas a transaction in which the vendor captures all the gains is at best ethically neutral. (See also "The Value of Switching Costs".) Although I would argue that repeated positive interactions accrue as benefits in other ways, such as goodwill, that may be more valuable over time than the money from a single transaction.

This model is incomplete. People will disagree about whether something is harmful or helpful at all, and which timeframes should be considered. For example, a doctor giving a shot is doing a short term harm (the pain from the shot) in return for a long term gain (improved health). But in the words of George Box, "all models are wrong, but some are useful." This one helps me evaluate a number of different situations to help me decide how I can act in ways that benefit the world.


<span style="font-size:smaller;>[1] Hugh Smith points out in email that this mapping was anticipated by Carlo Cipolla's "Basic Laws of Human Stupidity, specifically his third law. I'm sure there are others too. I'm a little more generous that Cipolla, though: what he terms "helpless" I term "altruistic". But the concepts are similar and his entire essay is worth reading. (return)

A Model IP and Open Source Contribution Policy

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.

The 2015 Future of Open Source Survey

Black Duck Software and North Bridge Venture Capital just released a the results of their "2015 Future of Open Source" survey. The summary is below.

2015 Future of Open Source Survey Results from North Bridge

Amongst the high level of bizspeak, a couple things stood out to me:

Slide 8: The big number on the slide talks about 78% of companies "running" on open source, but the big news to me is the small number: Only 3% of businesses say that they don't use OSS in any way. From my experience, I would guess that a high percentage of those who say they use no OSS are mistaken.

Open source is becoming a fundamental part of business everywhere, but I still see very little open source strategy at play. There is a huge opportunity for those companies willing to adopt a whole-company strategic mindset towards OSS.

Slide 13: Of the companies surveyed, 50% of engineers were working on OSS projects. There is definitely wiggle room in that number: not only is there selection bias, but "working on OSS" can mean anything from engaging with a community to sysadmin-ing Linux boxes. Still, the raw number is astounding. I believe that this is the reason why new developments and innovations are coming out just as often (or even more often) in the OSS world as in the proprietary world.

Slide 14: 88% of companies expect to increase their engagement with OSS over the next couple years. From a front-line developer perspective, this means that working on proprietary code will increasingly become a net negative. Expertise in a single-company application is less portable (and thus less valuable). Also see slide 20 about recruiting.

Slide 15: 53% of companies surveyed want to make it easier to contribute to OSS. Nevertheless, getting the business leaders and legal departments to agree with engineering can be hard. This is part of what I am going to be talking about at OSCON.

Slide 32: I found the list of the "most valuable OSS projects" surprising. I wonder what measurements they used. I hope it wasn't lines of code. :)

Read the whole thing.