Why Read the Contract?

Open Source, at it’s core, is a legal matter.  Most people in the Open Source community don’t see it that way.  But consider this.  This is code.

class HelloWorld {
 public static void main(String[] args)
  {
   System.out.println("Hello World!");
  }
}

If this was a bit longer and not so common it would be an example of “proprietary code” owned by my current employer.  In fact, I really should add the text “//Copyright (c) 2010 Yahoo! Inc.   All rights reserved.”  to the code.  Legally, I don’t need to since it is the default fact, but it’s considered a good idea to.  If I was unemployed, or had a contract that permitted my ownership of my code, then the code would be mine.  As my code, I can add any terms of copyright to it.

If I add the Apache 2.0 License to the code (assuming I have the authority to),  then it becomes “Open Source” code.   There’s nothing intrinsically better or worse about the code.  It’s the same code.  But if I publish it, and accept other people’s improvements to it, then it could become better code by virtue of transparency and participation.  (Just like the Enterprise 2.0 benefit of knowledge sharing — but with legal strings attached.)

I could add different licenses the code that render it Open Source.  Some licenses are permissive — allowing you to do things with the code with few or no restrictions.  Some are restrictive — requiring you to comply with certain conditions that may not be in your immediate best-interest.  Some extent their restrictive terms so that they apply their restrictions beyond your use of my code, but also to other code you wrote.  In effect, removing your freedom of licensing your code as you choose.

The specific wording in the license agreement makes a huge difference — just like editing the syntax of computer code.  Lawyers who are not trained to program code might not appreciate how eliminating a seemingly extra semicolon could crash a computer.  Developers who are not trained in legal text drafting might not appreciate how replacing one word with what seems to be a synonymous word makes the difference between winning or loosing a lawsuit.

The code license is only one part of the equation.  What makes Open Source interesting is the potential for participation — in a sense, to crowdsource development and improvements.   Most lawyers advise that you have a legal agreement in place to govern that activity.  Let’s take the following case (that I just dealt with at work).

A company offers Open Source code on a public website (in this case GitHub).  A developer at my company wanted to add  functionality to the Open Source code to make it even better.  She offered to contribute her improvements to the Open Source project — for free, of course.  The company who owns the project responded that in order to accept a contribution, she would have to sign a CLA — a contributor’s license agreement.  CLA’s are  common in Open Source projects.  They protect the project owner from liability that can arise by accepting the contribution.  The contributor usually has to warrant that she wrote the code and has the authority to make the contribution that she wishes to make.  The contributor also gives the recipient a license to use the code.  In other words, the recipient wont be accused of stealing code —  the CLA is proof that the contributor is really giving a contribution.

Much like there are different kinds of Open Source licenses, there are different kinds of CLAs.  But most developers (and other mere mortals) will sign anything presented to them if it stands in their way of getting something they want.  Professional developers know that they have to ask permission before signing legal documents.  Here’s why:

The developer gave me the CLA she was asked to sign.  It contained the following text (I removed the Project name):

Subject to the terms and conditions of this Agreement, [...] You acknowledge and agree that project shall be deemed to be the sole and exclusive owner of all right, title, and interest in and to the Contribution, including without limitation all related copyrights, know-how, inventions, patents, patentable material and ideas, trade secrets, trademarks, trade dress, and droit moral and you irrevocably assign to project all right, title, and interest that you may possess in the Contribution including without limitation all related copyrights, patents, patentable materials and ideas, trade secrets, know-how, trademarks, and droit moral. You agree to execute all documents necessary and/or requested by us to secure our rights in the at no additional cost, provided, however, that you shall not be responsible for the preparation of such documents. You will sign any such applications, upon request, and deliver them to us. Project will bear all expenses that we cause to be incurred in connection with such copyright, trademark, and/or patent protection. Project shall have the right to use or not use the Contribution and to use, reproduce, re-use, alter, modify, edit, create derivatives of or change the Contribution as project sees fit and for any purpose in project’s sole discretion.

You agree to help us, upon request and at Your normal billing rate, in preparing U.S. and foreign copyright and/or patent applications relating to the Contribution and in the prosecution and/or defense of any lawsuit relating in any way to the Work.

Read it carefully:  by contributing to the project, she would be assigning ownership of her code to them — not just licensing code to them.  She would be agreeing that her company would to help them assert their ownership of her (our) code, allow them to do anything they want with it — and provide legal support for them to prosecute or defend their entire project anywhere in the world — even part of the project that she did not contribute to.  In other words — she can be nice and give them code to help them out.  But if she does, then her employer has to be prepared for just about anything.  If the Open Source committers happen to be patent trolls, or worse, involved in illegal activities, then all contributors (of even the smallest bug fixes) have committed to help them out.  Do you think it’s a good idea to sign this CLA?

Agreements like this take the generous act of contributing code and turn them into a trap.  Note: most CLAs I come across do not contain these clauses.  The CLA that I implemented in my company does not (it’s basically the Apache CLA with negligible edits).  I understand from my colleagues at other large and well-known Internet companies (Google, Facebook, etc.) that they do the same as we do at Yahoo!  And I’m proud of that, since it’s not evil, it’s open and respectful to the contributor.

I recently learned about a new initiative called Project Harmony.  The project attempts to bring together many diverse perspectives on the issues related to CLAs and find some way to clarify what should and should not be in a CLA.  It’s pretty clear that there are differing opinions about what is a “good” CLA.  And the legal issues are huge. So no one is sure what will result from the project.  My hope is for clarity — so that anyone reading a CLA would know the terms and can make an informed choice about signing it.  The project is in it’s early formative stages.   I believe they will soon have a public web presence and announce their mission statement.  My take on it is positive and hopeful.  If they can clarify CLAs such that major Open Source participants prefer to use their text (because it is clear and socially preferred by most mainstream Open Source parties), then it will be a much-needed success.

Share/Save

Tagged as: confusion, contracts, legal, Open Source