I’m not a big fan of legal documents. I just don’t have the resources or ability to reasonably defend myself from a lawsuit; retaining a lawyer for a dozen hours would literally bankrupt me. Even if I were able to defend myself against legal challenge, standard contracts for software consulting are absurd. Here’s a section I encounter frequently:

Ownership of Work Product. All Work Product (as defined below) and benefits thereof shall immediately and automatically be the sole and absolute property of Company, and Company shall own all Work Product developed pursuant to this Agreement.

“Work Product” means each invention, modification, discovery, design, development, improvement, process, software program, work of authorship, documentation, formula, data, technique, know-how, secret or intellectual property right whatsoever or any interest therein (whether or not patentable or registrable under copyright or similar statutes or subject to analogous protection) that is made, conceived, discovered, or reduced to practice by Contractor (either alone or with others) and that (i) relates to Company’s business or any customer of or supplier to Company or any of the products or services being developed, manufactured or sold by Company or which may be used in relation therewith, (ii) results from the services performed by Contractor for Company or (iii) results from the use of premises or personal property (whether tangible or intangible) owned, leased or contracted for by Company.

These paragraphs essentially state that any original thoughts I have during the course of the contract are the company’s property. If the ideas are defensible under an IP law, I could be sued for using them in another context later. One must constantly weigh the risk of thinking under such a contract. “If I consider this idea now, I run the risk of inventing something important which I can never use again.”

If you’re contracted to work on an open-source project, the ramifications are bigger than just your life. Any code you write or data structure you invent is the company’s property. You’ve got to trust that the company will make that code available under the project’s license. If they don’t do that, you’re stuck: you can never implement that idea in the OSS project without running the risk of a lawsuit. Any work you do for the contract is potentially toxic, and must be withheld from the project and all its users, not to mention your future employers.

You’d think IP lawyers would realize this is counter-productive, right? Contracts like this give you huge incentives to ignore the client’s problems, to not listen to their ideas, to not think about solutions, because every novel thought carries an unknown risk of being locked away forever.

I prefer informal contracts–an agreement that tries to express the reasonable obligations of two parties to each other in clear, sensible language. It’s legally indefensible, I’m sure. I just want to understand my obligation to the company, and express my dedication to that task, my abilities and shortcomings, as well as possible. I also have an obligation to the open-source community–especially Riemann’s users–to make improvements widely available. Balancing those takes care.

So here’s an example of the sort of agreement I usually propose, instead:

Hello there!

This is a contract between Kyle Kingsbury (I, me), and FooCorp.

Time

I’m going to help you instrument your systems with Riemann. I’ll do my best to be available from 1000 to 1800 Pacific, every weekday, to speak with FooCorp’s engineers, and may be available during other times as well. We can negotiate together to figure out what schedule makes sense.

FooCorp will probably ask for features, research, documentation, or other improvements to Riemann. In addition to regular business hours, I may work on these problems “whenever I feel like it”–nights, weekends, etc, so long as the FooCorp employee I’m working with approves. I’ll do my best to provide realistic time estimates for any significant undertaking, and suggest alternatives where sensible.

I’ll keep a daily log of the hours I work, and a high-level overview of what I accomplished each day.

Termination of contract

I’ll complete up to 80 hours of work specifically for FooCorp. At any time, either I or FooCorp may terminate this agreement for any reason–for instance, if I complete all the work FooCorp asks for, if my work is unsatisfactory, or if I accept a job offer which prohibits outside employment. I’ll clearly communicate if any circumstances like this arise, and ask FooCorp to kindly do the same.

If this happens I’ll do my best to reach a good stopping point, and continue supporting FooCorp through Riemann’s open-source channels.

Ownership of work

Riemann is an open-source project. Any code, documentation, features, etc I produce which are suitable for the whole community will be integrated into Riemann’s codebase, published on Github, and licensed under the EPL. FooCorp may, at their discretion, be thanked in the web site for their feedback, advice, financial support, etc. “This feature brought to you by…”, that sort of thing.

Riemann has specific design goals. If FooCorp requests features which don’t make sense for Riemann’s design, I may refuse to make those changes. However, I’ll do my best to suggest an alternate design (e.g. a library or standalone program) and help build that, instead.

Whenever FooCorp requests, I can create works (documentation, software, etc.) which are not released as a part of the open-source project. This closed-source work will be delivered to FooCorp and will be their responsibility to maintain. I assign to FooCorp full ownership of this closed-source work, and unlimited reproduction rights, distribution rights, sublicensability, transferability, etc.

Open-source code will likely be easier for FooCorp to maintain, and will receive community-generated improvements. For instance, I may fix bugs in open-source features later, and you can take advantage of those improvements.

Ownership of ideas

I may sign a nondisclosure agreement with FooCorp. Since all of Riemann’s ideas are open-source, there is no risk in disclosing those ideas to FooCorp. I will not, to the best of my abilities, make use of or disclose proprietary or secret information from FooCorp in any context other than our work together.

I may make use of proprietary or secret information to improve the open-source Riemann, but not in a way which discloses that information. For instance, I might discover that your company needs to push information about 2 million users through Riemann, and improve performance to allow that. I won’t disclose that you have 2 million users–but I will write and release the code to make it possible.

Any unique information, algorithms, data structures, vague notions, etc. I invent or research during this contract are not FooCorp’s property, and may be disclosed or integrated into my work at any time. For example, if I realize I can improve performance by reorganizing streams in a certain way, FooCorp can’t sue me if I make that performance improvement after our contract is over.

No warranty

I make no guarantee as to the correctness, safety, performance, etc of any works produced, but I’ll certainly do my best during the contract. My goal is to get clean, fast, tested, runnable code into your hands. FooCorp is welcome to ask for help after our contract ends, through open-source, personal, or business channels–but I am under no contractual obligation to fulfill those requests.

In practical terms, if I build something for you, let’s test it during the contract and make sure it works! That way I can fix it if there’s something wrong.

Payment

When our contract is over (due to early termination or at the end of 80 hours), or every 30 days, whichever comes first, I’ll email an invoice to FooCorp for the hours of work completed. FooCorp will mail a check to Kyle Kingsbury within 30 days of that email receipt.

My hourly rate for this contract is $100/hr.

Thanks for your consideration, and I look forward to working with you!

–Kyle

My contracts are significantly shorter than the standardized consulting contracts I usually see. They also emphasize different things. Typical contracts spend a lot of time concerned with listing rights, which is important because in a legal dispute you need to point to those exact words in the document. Typical contracts, on the other hand, give little guidance about how the relationship should work. I try to emphasize the role of good communication–pointing out places where we might disagree, or where it’s important to come to a shared understanding as the relationship evolves. I try to suggest specific hours for my availability, which is something many contracts don’t address at all. I also try to give examples to justify the terms I’d like to use–under the hypothesis that if we understand the spirit of the agreement, we’re less likely to argue over technicalities.