Gil Yehuda: Hello Everyone and Welcome to the Dash Open Podcast. Dash Open is your source for interesting conversations about open source and other technologies from the Open Source Program Office at Verizon Media, home to many leading brands including Yahoo, AOL, Huffington Post, Tumblr, TechCrunch, and many more. My name is Gil, and I'm on the Open Source Team at Verizon Media. Gil Yehuda: Today on the show I'm excited to chat with Mike Martin. Mike is Verizon Media's Associate General Counsel focused on open source, standards and patents. Welcome to the podcast, Mike. Mike Martin: Thanks, Gil. It's a pleasure to join. Gil Yehuda: It sure is. Mike, you and I, we've been working together for many years. We know each other quite well. I know you're a lawyer and I know you code. Gil Yehuda: What I wanted to do today is actually talk about an area of open source law that is a little less focused on. I will just say, I guess, because we like to say these things, this isn't legal advice. I'm not asking you for legal advice. I'm certainly not suggesting that what you're providing is. We're talking about this stuff. Listeners who are interested in legal advice should find their lawyer and talk to them. Gil Yehuda: But really in that context, I want to just chew the fat on a topic called the contributor license agreement, the CLA, which is a little different than copyright or licenses or traditional open source licenses. It's a little bit of a thing that often gets, I don't know, forgotten, but it's relevant. So I guess to start, because you are the lawyer, can you tell us what a contributor license agreement is? Mike Martin: A contributor license agreement is actually a contract. It's a contract between a person, which can be an individual or it could be an organization, usually a corporation of some kind on the one hand and a copyright owner of some open source project on the other. I think that's probably the simplest place to start. It's this agreement. Mike Martin: Every CLA can have different terms, and that's part of what makes it fun and exciting as a lawyer is to have to dig through these CLAs, because, of course, unlike the open source license agreements that the projects may be subject to, the CLAs themselves are not really standardized. Gil Yehuda: So, Mike, let me ask you, from the perspective of a project, why would a project want a contributor to sign a CLA? Then from the perspective of a contributor, what goes on in the mind of the contributor before he or she signs a CLA? Mike Martin: Yeah, I think there's a number of different ways that you could analyze this, but maybe one helpful organizing principle between all of this is just to talk about trust. Trust is something that's just so important to the collaborative development of any kind of value. I mean just in general. So now we're talking even more broadly than the open source world or even software development. Mike Martin: Trust is fundamental to people working together over an extended period of time in order to build something, to make something that is going to be of mutual value to them and perhaps hopefully to other people. You have special problems with making things that are as abstract, I'll say, as source code, which is, of course, the basis for all software, which is that, especially now where we have technology allows us to copy things digitally, it's very easy to take work that somebody spent months or years building and then just rip it off and copy it and use it on your own. Mike Martin: And so, I would say that, I guess, in the first instance, we have this predicament of people wanting to invest time and doing work both on their own and together as a group, but not really having any good way to ensure that they're not going to get cheated. Like what's the basis of trust? Mike Martin: Now I mean, of course, there's lots of answers to that question. I mean maybe you and I know each other. Maybe we work at the same company. In the abstract, that's the fundamental problem, and I think this is where copyright came in, the first 400 years ago under the Statute of Anne in England. The Sovereign's recognized, look, we've got these great craftsmen out there. I mean, of course, they weren't software developers. They were authors and publishers of authors' work, and they had to have some way to make sure that they weren't going to get ripped off. So copyright came along. Mike Martin: And so, copyright, that's fundamentally what it's supposed to be about, is providing a mechanism for the author of some work to be able to call upon as a last resort a sovereign authority to punish somebody for cheating. But copyright is a fairly blunt instrument we'll say. And so, of course, you want to give people ways to slice and dice it to fit whatever their needs are in a particular situation. Mike Martin: I think maybe I've gone back too far, but hopefully that's helpful in organizing your thoughts around, well, what are we doing here? Why do we have all of this legal language? There is a point, and it's actually a fairly fundamental and profound point that we need to foster trust among people who don't know each other and have no reason to trust each other. Without it, we're not going to be able to build these incredibly complex things that require us to work together. Gil Yehuda: Okay. A very pragmatic way for, let's say, I wanted to cheat you is if you were running an open source project and I wanted to contribute to that project and I contribute code to that project, for all you know I took that code from somebody. I didn't write that code. Gil Yehuda: The fact that I'm the contributor, you don't know me. If you don't know me and I just gave you a whole bunch of really good code, I might have taken that from somebody who really didn't authorize me to use that code. That might be my company that I work for who didn't give me permission. Gil Yehuda: I might be doing it not because I want to hurt you, but because after giving you the code, I want to interview with you to hire me, saying, "Hey, I gave you all this code. Would you hire me for a job?" The whole thing could be a setup. So you need to make sure that I'm not cheating you and I should represent in some manner that the code I'm giving you is actually code that I have the right to give you. That's kind of what the CLA does, right? Mike Martin: That's right. I mean the failure modes that are available in any given situation are as infinite as the variations of human nature. Right? Gil Yehuda: Right. Mike Martin: So, that's one. Gil Yehuda: Well, so if I'm wanting to contribute to, let's say, back to that scenario. I want to contribute to your project and you say, "I don't know, Gil. Before you contribute to this project, you need to sign a CLA." And I say, "Oh, okay. Sure," like I sign anything that's given to me. Is that okay? Can just anyone sign a CLA or is there more to it? Mike Martin: Yeah. I'm really glad that we took this back to the roots. Now in the case of an open source license, I mean, first of all, it's not as long. The CLAs are even shorter than the open source licenses. They're usually, at longest, five or six paragraphs. They're very usually carefully drafted to be in language that isn't as legalese, not as much legalese as you would typically find in a commercial contract. And so, in order to ensure that we are maintaining this trust, we really do want for everybody who signs one of these things to understand what they're signing. Gil Yehuda: Well, let's take that corner, actually. Let's turn the corner for a moment, because I think we've just established that the CLAs are a good thing and you should protect your project. It helps mitigate certain things. But let me give you a scenario and tell me what you think. Gil Yehuda: So here's the scenario. You have a project and I want to contribute to that project. You asked me to sign a CLA, and I do so. Actually, I'm diligent. I go to the legal department of my company and I make sure that they review the text and they approve it. I did everything right. Gil Yehuda: You received the CLA and you receive my contributions. Everyone's happy, except I switched companies. Now I'm working for a different company. You don't know that. I didn't have to tell you. I mean I guess maybe I should have told you, but I didn't. I still have my same GitHub account that I use for pull requests against your account. Now I'm representing my new company, continue to contribute to your project, no CLAs signed there. It seems like there's a hole in the process. Mike Martin: Yeah, that's a pretty big hole. I think this is one of the big downsides to I'll call it the traditional CLAs is that there's sort of a checkpoint of getting one signed before somebody is allowed to contribute to a project. But if they're using a personal email address, then they can do exactly what you just described and completely circumvent that checkpoint after they've moved to a new company. Mike Martin: I mean it might be helpful to just throw out for those who haven't really thought it through maybe or are not lawyers, everybody who works for a company, in the US at least and in many other parts of the world, at least in common law jurisdictions, will sign an agreement with their employer that says that their intellectual property belongs to their employer. Mike Martin: That's just part of the whole system of trust that we've established among employers and employees, is that employees get a paycheck and the employers get the fruits of their labor, which in our economy, at least for software development, that's the intellectual property. So the copyright belongs to the employer. Mike Martin: And so, this is a problem that Gil has described because the new employer owns the copyright, but the existing CLA is with the old employer. It puts no obligations on the new employer to make its copyrighted source code available. There's a logistical problem there that turns into a real legal problem when somebody moves from one company to another. Gil Yehuda: Right. In other words, I guess it sounds like CLAs are a really good idea in theory, but they fall apart in practice. There's just a bunch of holes in the way we're able to implement it that make it less of a protection as we wished it would be. Gil Yehuda: I think that you and I, we've worked together many years, Mike, on projects and we looked at CLAs favorably, saying, well, at the end of the day we want to protect the project. Gosh, if somebody isn't even willing to give us the basic assurance that it's legit code that they're giving us, well, maybe we don't want that code. I mean we're asking for a very small hurdle. Then, over time, we've done this so many times that we've realized this isn't working practically. Gil Yehuda: Practically speaking, there's just so many holes in the process that we've put our heads together and thought about what are other ways that we could protect projects that we run in our open source program, and inspired by what other people do and what I think other people might start doing when they really look carefully and say, "Well, CLAs are good, but ... " Gil Yehuda: I'm wondering if you can share your thoughts about what a person can do, what a project can do to protect them. Well, I don't know, just continue to protect their project without necessarily relying upon the CLA as a vehicle for that. Mike Martin: Let's go back to the trust point just for a moment, because I think one question that somebody might have listening to this conversation is like, "Well, look, I get the point about trust and about getting ripped off, but isn't open source, I mean the whole point is to make that available to everybody?" And so, in some sense, why do we care in the case of open source? This is probably a question that people have. Mike Martin: I think, my sense is it's at least part of what's going on when people just sign these things without worrying, or don't sign them when they move to a new employer. They just don't worry about those things because their attitude is, "Well, look, this is all meant to be in the open anyway." Mike Martin: To be honest, I don't have a lot of personal experience with scenarios in which open source projects have felt the need, or desire at least, to enforce their copyright against third parties. I mean maybe that's something you could talk a little more about, Gil. Gil Yehuda: I ran into two cases where they did. It's rare, but rare things happen. They just happen rarely. I have seen it in my experience where open source projects do fight for their copyright. In one case, basically they found infringement. They found where people gave them code that they shouldn't have gotten, that they should not have had given to them, and they were issued a DMCA takedown. Gil Yehuda: I think it can happen where open source projects accidentally or potentially purposely, it's hard to know,. I'm not even sure how much that makes a difference, I mean from the perspective of a project. If they have code they shouldn't have that really shouldn't have been open, that's a problem for them. They're not in that business of fighting it out. So it happens. Gil Yehuda: We don't use the CLA as much anymore. We use a commit message, a commit message asking the contributor to make some representations. What's a representation? Mike Martin: A representation is a formal statement that you're making in writing that something that you're saying is true. You're making a statement, but it has more formality associated within that. It's a statement that you are holding out to another party as something that they can rely upon. So that's what makes a representation. Mike Martin: Now in a formal contract, there would often be a section that's titled representations and warranties. And so, this would be a list of specific statements that the counterparty in the transaction is making to the other party, like you can rely upon these facts that I'm stating to you to be true. If they turn out not to be true, that's a breach of the contract, and the counterparty can come back and sue for breach of those representations and maybe get damages or whatever other remedies would be available. Mike Martin: So the representation that you're talking about that we've adopted, and at least one or two other companies seem to have adopted, as an alternative practice to the use of a CLA is designed to provide us the key components of the good stewardship that we'd get out of a heavier weight CLA process without, yeah, the heavier weight of the CLA process and also the logistical difficulties that come along with keeping track of who's working at what company and whether they need to be an individual contributor or a corporate contributor and do we have the right agreement given their role. All of that goes away if you're relying on a simple representation that is attached to every contribution in the form of a comment, for example, on the commit. Gil Yehuda: Right. That just seems like a really great compromise, because on the one hand, it's on every commit. So it's fair and it's part of the record and, thankfully, has that feature that it preserves the record of the commit. But it's lighter weight. I mean it's not a contract. I guess it's somewhere in between scout's honor and a contract, right? Mike Martin: Well, I would say it is not a contract, but it is something that could become actionable as a result of. I think the legal term for this would be promissory estoppel. If I make a promise to you that I'm going to do something, and I'm not asking anything in exchange from you for that promise, then we can't have a contract because I'm acting unilaterally in that instance. Mike Martin: But it is part of the common law tradition at least that if you rely upon that promise and, as a result of that reliance, are hurt in some way, that you can come back with a claim of promissory estoppel. You can say, "Look, you promised me you were going to do this and you didn't. Look, I was injured as a result of that promise. So you've got to at least make good on this injury in some way." Mike Martin: I think there's a lot of, of course, defenses that you could have to the promissory estoppel that would avoid the claim. There's probably some elements to it that I'm forgetting or leaving out that are important. But I think that's basically what we're looking for here. Mike Martin: In our case, if I remember the exact language, I mean mostly what we're asking for is a representation of two things. One, that the person who's actually making this contribution is aware that the contributions can be subject to the terms of some specific open source license, which in our case I think is nearly always Apache 2. Gil Yehuda: Yeah. Mike Martin: Yeah, or one of the other open source licenses, just that it's going to be subject to open source, because this gets back to the other question of why are we going through all of this? What's the point? Mike Martin: This hasn't happened since I've been in charge here, but the worst case scenario would be somebody contributes and then claims that, "Hey, wait. I never gave you the copyright to that, and I'm not happy with the direction the project is going. I'm going to sue you for copyright infringement because you're using my source code in your project." That's a threat to the whole project. Mike Martin: So, again, this is really rare, but a good lawyer is going to mitigate against a risk that's so catastrophic as that. Of course, the more contributions that you have and the longer the project goes on, I guess at least mathematically speaking, the greater the likelihood that something like that is going to occur at some point, right? Gil Yehuda: Right. Mike Martin: So the representation mitigates against that risk, one, by getting a statement from the person who's making the contribution at the time that they make it that they understand. The second part of the representation that we're interested in is that they are actually the ones that have the authority, that they have the authority to make the contribution on behalf of the copyright owner. Mike Martin: So in the case of an individual, of course, they have that authority. But this is without asking who employs them or how they've gotten that authority, we're asking them to just confirm that they have that authority. So in the case of a small company, maybe they have that authority without having to go through anybody from legal. But in a bigger company, hopefully that's triggering some people to go circle back if they're not sure and confirm that they can actually do this. Gil Yehuda: Right. So what did we learn? We learned that the basis of open source and really the basis of, gosh, all the human interactions is trust. In order to have trusted relationships between parties who don't know each other, you need some sort of assurances, some sort of basis of trust. Gil Yehuda: Open source is based on this theory that we can work with anyone in the world on this as long as there's this shared good intent. And the experiences told us that most people really do have good intent, and yet that's most. Some people don't. Some people make mistakes. Some people have all types of situations that put them in where there's potential breach of trust, either the optics of such or legitimately violating the terms of what we think would be legit business. Gil Yehuda: So the good lawyers in the open source world have creative things like CLAs, contributor license agreements, to help us in practice. We've implemented them to help projects. We've also seen where they fall short of doing what they're supposed to do. We've come up with some workarounds. I think the story is not done in terms of how these things play out. Maybe we'll have even better ways of working on assurances in the future. Gil Yehuda: But I really thank you, Mike, for shedding a lot of light and really your deep insight and your experience in this very complicated and important topic. So with that, let me just thank you, Mike, for coming. Mike Martin: You're too flattering, Gil. Gil Yehuda: Oh, this was fun. Mike Martin: It's always a pleasure. Gil Yehuda: It is. So thank you again. If you enjoyed this episode of Dash Open and if you want to learn more about the open source program at Verizon Media, or any of the other things that we work on, visit our website at opensource.yahoo.com. You can find us on Twitter, @YDN. Thank you for listening to the show.