Process Mechanics

Social: VanL on LinkedIn VanL on Hacker News Code: VanL on Github VanL on Bitbucket Me: About VanL VanL's physical location

The Copyrightability of APIs

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


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.

By VanL

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)

By VanL

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.


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.

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

By VanL

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.


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

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

By VanL

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.

By VanL

The PSF: Behind the curtain

Several months back I put out a call, asking what people would like to learn about the Python Software Foundation in my talk at PyCon. I got a lot of responses, both in email and twitter.

My favorite was from David Beazley:

Beazley quote

I followed this advice and spent time watching a number of Samuel Beckett plays. I saw one that I particularly remember - a Python-themed version of Waiting for Godot called Waiting for 2.8. I hate to spoil it for anyone who hasn't seen it, but 2.8 never appears.

I also got a lot of requests to talk about the PSF, like this one from Nick:

Nick Tweet

So the first thing is to explain exactly what the PSF does. This is easiest to explain by comparing the Python Community to a corporation. When most people think about the parts of the Python community, they think about it like this:

Python Corporation 1

We of course have Product Strategy and Development - that is Python core dev. We also have R&D in places like PyPy and Numba. We have Enterprise Integration - Jython and IronPython. We also have libraries and SDKs, Addons, and Tooling - packages on PyPI, Anaconda, the SciPy stack, etc. We also have many developer advocates and evangelists all over the world.

In a corporate world, almost everything above is capitalizeable. That's a long way of saying that the people above this line build stuff that is valuable over a long period of time.

There are a bunch of other support functions, though, that support the efforts above. It is mostly what is known as G & A, or "General and Administrative Expense." The PSF takes care of this stuff. And as a general rule, these are the groups that people love to hate:

PSF Corp 2

You all know these groups. IT. Finance. Accounting. Legal. Human Resources. Events and Logistics. Public Relations. Sales and Marketing. The PSF has a significant effort in all of these areas and more. We provide the support functions for many hundreds of thousands of Python users worldwide.

Some of that support is in keeping the infrastructure running - like the infrastructure that hosts PyPI, the mailing lists, and If you deploy Python infrastructure, the PSF helps you.

Some of that support is financial. We directly supported conferences where over 50,000 Python users attended. We sponsored projects and development efforts. We paid for sprints and meetups. If you attended a Python or Python-related conference, chances are that the PSF helped you.

Some of that support is legal. Not only does the PSF handle the IP associated with the cPython and Jython interpreters, we also manage trademark usage requests for "Python," the two-snakes logo, "PyCon," "PyLadies," and more. To the extent that there is a clear public perception of what "Python" is, the PSF helped with that too.

The PSF also created the PSF Code of Conduct, and actively encourages the community to be welcoming and helpful. For example, we don't fund conferences without a code of conduct. That is one reason why it is very unusual to find a conference in the Python ecosystem that doesn't have one.

We field inquiries from the press. We work out payment issues (including international ones) for companies. We keep the books straight and the lights on.

So what are the problems? There are a number of them. We're not perfect. This is supposed to be no holds barred look at what the PSF does, so I will tell you what some of the key problem areas are, and what you can do about them.


The first problem is simply time. The PSF has exactly one full-time employee and three part-time employees. Everyone else at the PSF, and those who are working on PSF events like PyCon, do so as a service to the community. Even those few people who are employees serve far more than they would if this were just a job.

Now I am not complaining about this.

On a concrete level, though, people working on PSF things are limited. There are more things that we would like to do - and there are even some people who have stepped up to help. But communicating and managing and teaching takes time. It is difficult to do all those things and still have time to get the immediate items done.

So what can you do?

First, say thanks. If you see someone helping out at a conference, buy them a beverage. Recognize others for what they do. Find someone who has written a library that you can't live without and tell them what their work has done for you. You can do that via email or social media.

Second, the best thing that you can individually do to help the Python community is to reach out, lift, and mentor others. There are always new people. It doesn't matter if they are new to Python, or new to your meetup, or new to your mailing list. Welcome them in and show them the ropes. Bonus points if you bring in someone who doesn't look like you.

Third, for those who are trying to work with others in the PSF, we need you to persevere and be understanding. I heard the story of a new contributor who felt turned off because it was hard to contribute. No one was mean, but no one made the time to help someone new come in. Thankfully, she persevered and was able to land some code. She got over the hump.

There shouldn't be a hump to get over before people can contribute. But there is. Please persevere.


The second major challenge is empathy. A lack of empathy is the biggest strategic weakness in the Python community. By empathy I mean a willingness to place yourself in another's shoes and try to see the world through their eyes.

I believe that the PSF is better at this than most open source communities. I am regularly impressed with the wonderful people in the Python community that go out of their way to help others. Nevertheless, this is still a weakness.

A lack of empathy is expressed through being dismissive of others and their point of view. It doesn't matter if you agree or not. It doesn't matter if that person is wrong. It matters if you try to understand that person and their viewpoint from the perspective of their lived experience.

Banksy quote

This is one of my favorite quotes. As I think of it, every person is the hero of their own story. They are trying the best they can and doing good. It is a failure on our part if we dismiss people as wrong without taking the time to understand why they think they are right, or why they think their contribution is valuable.

Yes, there are trolls. But they are one out of 100, or one out of a thousand. We should eject those who are intentionally or persistently abusive.

There are a few people in every community I am in that I pretty much never agree with. But behind those few people are many others who think the same way. When I take the time to understand, I do better. Sometimes I am convinced. A lot of times not. But those people who think that I am doing it wrong teach me more than all of those who agree with me.

What can you do?

Stop labeling. Wait before you attach labels to people, or conduct, or arguments that don't take into account the content and intent of what people are saying. It's ok to have those labels - they are meaningful to you. But if you want to connect with a person, you need to reach out and start from where they are, not from where you are.

Always give people the benefit of the doubt. One of the difficult things about our society is that more and more of our discussions come through as pixels, not people. It is easy to misunderstand a statement posted on the Internet or sent through and email if you don't have the cultural and personal context that drove that statement.

This doesn't excuse things when people get hurt. As @jacobian correctly pointed out to me, intent isn't magic. But we should always, always assume that people are trying to do good and strive to understand others in that light.


The third biggest problem we deal with in the PSF is a lack of responsibility.

We have many people who are willing to criticize how something is done. Many of those criticisms are correct. And, truth be told, I find great value in being told when I am doing something wrong.


Too many of us stop when we have raised our voice to complain, without taking responsibility to take the next step. At minimum spend the time to work out and politely express what could be done better, or even step up and help. Does this mean that if you don't like a library you need to become a core maintainer? Of course not. But it does mean that we need to take responsibility for the burdens that we ask others to take for us.

There was a thread recently where a long-time and prolific contributor described how people would insist on changes to his libraries. Users felt entitled to criticize and insist that work be done on their behalf with no thought for how that would fit within that developer's other demands.

This is not good enough. It is a failure of empathy and responsibility. It is not kind, and it needs to stop.

So what can you do?

Stop before you complain, directly to a person or generally on the Internet. Do your homework. Remember, people are always trying to do their best. Was there a problem that prevented the result you want? Find out first.

Second, look for ways that you can engage constructively. Do that instead.

Be specific and constructive. Do you still think that you should speak out? Isolate the change that needs to be made so that your feedback is actionable. "It doesn't work" isn't a bug report and "It sucks" isn't a feature request.

The next question asked what advice I might have for open source projects that want to grow up to be the PSF:

grow up

Don't rush it. You can and should set rules of the road and expectations early on, but make processes as lightweight and informal as possible.

Default to openness - but realize openness is not really an end in itself. Openness is the start of communication. What you really want to do is to understand and empower, not just check a box.

Culture matters. Build one that reflects the best of who you are. The best determinant of which technology will succeed is not the technology itself, but instead the strength and vitality of the community around it. If you put obstacles in the path of people participating with you, you put obstacles in the path of your own success.

There have been anomalies - technologies or projects that have succeeded despite a difficult or toxic culture. The time when projects or companies can succeed with toxic cultures is quickly disappearing into the rear-view mirror.
In the PSF, what we consciously try to encourage is a culture of service.

I'm going to go out on a limb because I know there are a number of people who disagree with me here. I believe that the culture of service is what sets the Python community apart from almost every other community I know. The PSF doesn't pay its directors or committee members. While we PyCon doesn't pay speakers or organizers for their service.

Don't mistake me. I am not saying that people should never be paid when they provide valuable services. I think it is wrong when commercial interests see communities as the equivalent of contractors that they don't have to pay. I also think it is reasonable to have paid positions that help empower others.

But a group where everyone only interacts if they are paid is not a community. It is a bunch of mercenaries.

A community that reaches out to serve and to help others becomes deeper, richer, and better over time. This is the reason why we reach out to others. This is why the PSF cares so much about including others, because they are our friends - or at least we hope they soon will be. Reach out and serve another person and you will find a friend.

Threats and opportunities

I got a final question via email - what are the greatest threats to Python and the Python community? What are our greatest opportunities?

In my opinion, the greatest threat to the Python community is that we are not adapting to changes in the industry fast enough. I am worried about technical shortcomings that lead people to choose other technologies, even if they would prefer to be in Python.

I don't think that other languages must "lose" for Python to win. But every time someone says, "I love Python, but I had to do my new project in ______," I get a little worried. Software is an ecosystem, and when our ecosystem shrinks, the opportunities available for all of us get diminished.

The term “software ecosystem” was coined about ten years ago in a book written by David G. Messerschmitt and Clemens Szyperski. In this book, they laid an extended argument that different people and companies, acting with their own interests in mind, can be thought about as an ecosystem just like the natural ecosystems around us. The term stuck. Even though the specific roles that Messerschmitt and Szyperski imagined haven’t caught on, the concept has. For example, Stephen O’Grady from the analyst firm RedMonk named his blog “tecosystems" after this concept, "because," as he says, "technology is just another ecosystem."

Python has a huge and vibrant ecosystem. Everyone in the Python community is a beneficiary of this fact. But Python has lost something in the transition: underdog status.

It was ten years ago that Paul Graham wrote “The Python Paradox,” in which he said:

"[P]eople don't learn Python because it will get them a job; they learn it because they genuinely like to program and aren't satisfied with the languages they already know.

Which makes them exactly the kind of programmers companies should want to hire. Hence what, for lack of a better name, I'll call the Python paradox: if a company chooses to write its software in a comparatively esoteric language, they'll be able to hire better programmers, because they'll attract only those who cared enough to learn it. And for programmers the paradox is even more pronounced: the language to learn, if you want to get a good job, is a language that people don't learn merely to get a job.”

Isn’t it funny that ten years ago Python was considered “relatively esoteric”? This is the most recent ranking of programming languages based on a cross-tabulation of github projects and stack overflow questions. Python comes in a solid #3. In other publications, Python is a solid top-4 or top-5 language, and is considered a “safe and well-supported” choice by publications like CTO magazine.

Why does underdog status matter? Because in 2015, there is no more Python paradox. A number of key developer communities have moved on, setting the stage for Python to be disrupted (in an Innovator's Dilemma sense). I may talk a lot about improving our community, but I think the Python community is our greatest strength. Our weakness, right now, is technical.

From a technical perspective, three threats I worry about most, and they are all related: multicore, mobile, and package management. From a language standpoint, I am really worried about Javascript and Go.

The reasons Javascript worries me should be broadly apparent. It is the most widely deployed language on the planet except for C and C++. It is dynamic, it is getting lots of funding, and it is an intrinsic part of the web.

As for Go, that is a more fundamental threat. Go is close to the metal, has an easy-to-understand concurrency model, is mostly low friction, and is "close enough" to good that it is becoming a language of choice for networked applications. It also has a deployment story that is way better than it is for Python: Copy the binary and it's done!

Go also has the advantage that it has full-time developers working on nothing but improving Go. Twenty years on, and we still don't have full-time developers working on Python. Every core dev in Python is contributing "on the side."

The problem with Go is that any code written in Go is dead code. Because of the static linking, because the primary compiler uses an unusual calling convention, any effort that people put into Go software is locked into the Go ecosystem. Unlike, say, Rust, there is no way to use Go for the things that it is good at and use Python in the places where it shines. If someone makes the shift to Go, they have to go all-in. It makes the choice stark.

What is our greatest opportunity? That is easy - schoolkids. Python either is, or is becoming the dominant teaching language across the world. Organizations from middle school on up to universities are adopting Python as their teaching language.

The Raspberry Pi includes Python 3. MicroPython is incredibly successful in the embedded world. The BBC Microbit is going to be distributed to every single child in the UK - and it will be programmable in Python 3.

With so many new people being exposed to Python, we have the opportunity to create great new things. We have dedicated, wonderful people who are trying to move the world forward. If we are able to evolve so that we can address our challenges, Python has the potential to be the dominant dynamic language worldwide.

By VanL