 Our last speaker is Simon Phipps. Thank you very much. Well, thank you for staying to the end of the afternoon. I appreciate that. So I've got a talk for you that I'm testing on you to find out whether this is the way that I'm going to spend all my conferences for the coming year. And the talk is called Don't Send an Engineer to Do a Lawyer's Job. This was inspired by a thread on the Apache legal mailing list in 2015. And in this thread, somebody came onto the mailing list with a request on behalf of their company. And to my eyes, at least, this thread embodied every single thing that an experienced lawyer who was coming into free and open source communities for the first time should absolutely not do. And so I've read through it, and I've riffed on that theme and put together for you a set of lessons, really, that are drawn from my experiences of watching repeated encounters with communities by legal staff and by the engineers who are supported by that legal stuff. It's not intended as a criticism of the company, and so I've not named the company that's involved. There is one person in the room who already knows who that company is, which is Fontana down here, because he made a critical comment during the conversation. So I've warned him that he's in the presentation, and he's sworn to secrecy over who the company actually is. I've got to give disclaimers, so other approaches are possible. May include nuts. I'm not a lawyer and could plausibly play one on television. There is another problem with this presentation, which is I couldn't come up conceivably with any pretty pictures to put up, so there are instead gratuitous cat pictures during the presentation. I'd introduce here this is Poppy, our cat, and this is Ophelia, and they'll pop up during the presentation just to make it less boring. So the background to the talk, in this thread on Apache Legal, a representative of a very well-known company that was already active in the Apache community showed up and asked for some variations to some of Apache's standard terms. Now, if you're at all involved in the Apache Software Foundation, you'll know that showing up and asking for variations to terms is not a great way to make yourself popular. So this company had sent one of their Apache member staff, somebody with an Apache.org email address, to make sure that they had as much stature as possible in the conversation. It turned out once we dug into it that the changes they wanted to make related to patent rights. And the writer of the thread is apparently a member of the open source team at the company and appears, strongly appears, to be following directions from legal counsel. But the legal counsel involved never shows up on the thread. And we never find out who that person is. It's also likely that this is not an example of their previous behavior or of their later behavior. But one of the messages in the thread indicates a new general counsel had recently been appointed at the company. And it looks extremely likely that this whole move was at the direction of that new general counsel who had just come in from an extremely notoriously toxic corporation that should also remain unnamed and clearly had limited experience of dealing with communities of any kind, least of all open source communities. So that's the background for you. In the initial email, the engineer brought in a legal agreement for Apache to consider changing their software grant agreement. They wanted to put a new project into the Apache incubator. And evidently, they downloaded the standard SGA and the legal counsel had read through it and said, these terms aren't quite right. Please, could you go get Apache to change them for us? And they had drafted a completely new version of the SGA and attached to the email, the initial email in the thread, there was this new SGA. And we'll say more about that in a moment. So I would like to suggest to you that any community that has got legal documents has got those legal documents to create a set of freedoms and to create an environment of certainty for the people who are contributing to the project. And those legal agreements create that certainty. And they are usually a consensus activity. And so for you to come in and suggest that you want to change them is for you to come in and challenge the environment of certainty that the developers are currently enjoying. And that's the reason you will get rejected. It's not because they hate you or because they dislike your corporation. It's because they've already done this and you weren't there and now you're coming in and trying to open the old issue again. And so they will typically push you away if you try and do that. If you do find a bug in an agreement, well, that's great. But raise it sometime when it's not urgent. Raise it when people are going to be happier about talking about it. OK, click. Oh, this is exciting. I mean, let's have Ophelia back again. So the next thing they did was they attached the document. And the document didn't have a red line. So there was no information saying what they had changed in the document. There was also no narrative about the changes explaining what changes had been made. And there was also no justification for the changes. Now, as you know, open source communities are really not excited about being given very large dumps of fater-complete work and being asked to merge them in with the source code. And the same applies to legal documents. That environment of consensus and certainty should not be modified by a completely new version that appears from the ether. And consequently, I would say that combining a large dump of change and a lack of rationale is probably the very best recipe to make yourself unpopular in a community. And unfortunately, this person did both. Just as a side note, this whole phrase, here's a special agreement we need you to sign, which normally goes along with an NDA or something, is another really great way to get yourself out of favor in a community. Now, to explain why that is, an open source community is a multilateral environment. There are many parties involved, and they have multilaterally reached agreements. And that multilateral state is actually what creates the freedom. And as soon as you enter into that multilateral environment and start creating one-to-one bilateral relationships, you undermine the whole community's freedom. And you do that for two reasons. First of all, you create contexts where some people are not permitted to participate. And secondly, you create an instrument of power for the party creating the agreement because they can threaten to modify it or to withdraw it at any time as a sanction for behavior that isn't required. So any kind of agreement that is bilateral being imposed within a community which is multilateral is automatically going to be considered bad, whether it's an NDA, whether it is some kind of a software licensing grant, whether it is a patent license. Anything bilateral is going to be rejected. And it's a really bad idea to bring it into the community. The engineer who came in also indicated that, really, this wasn't his thing. And he came in with lots of cut and paste sections that had clearly come from an internal email. And one imagines that he received an email with little bars around it saying, you can make this bit public. And so he cuts and pastes and sticks it in the message and sends it off to Apache. And while it's inevitable that there will be people in your company who you need to bring to consensus before you can act with a community, it's really a bad idea to send into the community to negotiate a powerless proxy. And that applies to code contributions as well as it applies to engagements over administration or over legal agreements. If your company has been thinking of having an open source department that will have all the people who face the open source community and what they will do is submit code on behalf of the real developers who live in secret in a back room, that's not going to work. And you know that's not going to work. Well, it doesn't work for legal agreements either. You really have got to send in an empowered expert to go make the negotiations. And so there's quite a few people in this room who are that sort of empowered expert, people like Fontana down here comes into public discussions and represents his employer and does it in a very thoughtful and integrated way in the community. Well, that's how you do it. You send a lawyer. You don't send an engineer unless that engineer happens to be Roy Fielding, in which case there's no problem. OK, cat picture. So the correspondence begins to get frustrated by being told, well, you don't know what you're doing, do you? And begins to suggest that maybe what should happen is they should get their people to talk to our people. And so he actually asks at one point to have their attorney speak to your attorney. Now, there are actually legal advisors at Apache who are helping the board with legal decisions. But it's not normal for you to ask to speak to them as the first activity. You should probably come into the community and talk to the legal discuss mailing list. And have your open conversation, because you're trying to affect this multilateral environment. And immediately trying to go into a bilateral negotiation is a sign of distrust and a sign of disrespect. If a patchy says to you, our lawyer would like to talk to you about this, that's fair enough. But for you to show up and ask for a one-on-one with a patchy's lawyer is, again, not going to make you any friends. So that kind of persisted for a little while in the conversation. And then the writer began to get more frustrated and tried to encourage a patchy to create a special process. This is an urgent code contribution. It's got to be made really fast. We need to fix this solution. Here, let's resolve it this way. Now, a patchy has got well-worn processes for making decisions. If you go into the Apache legal mailing list, you'll find there are a number of people there who will say to you that there's no rush, that they've got to make decisions slowly. And it's not a matter of the process being slow and broken. It's slow by design. It's working when it's slow. It's broken when it's fast. And so it was a big error, I think, to do this. And as indeed one of the correspondence on the mailing list said is that their new way was simply a way of avoiding the people with the most experience who were going to spot the defects. And that was probably actually what the company wanted, was to avoid the people who really knew what was going on. So now they begin to play the wounded card. We're just trying to make a contribution. Why are you making this so hard for us? We're just trying to make a contribution. And this was the point of which one community member, who to remain nameless, was pointed out that a substantial change that had been made in the unread line document was to remove a patent grant to future patents filed by the company on the code they were contributing. And it seemed likely that this company had decided they wanted to remain free to file patents on ideas that were embodied in the code and then potentially pursue the Apache community for them later. And that did lead to a momentous point where this person who pointed this point out was said to be an extremely clever person by Jim Jagielski, who was the president of Apache at the time. Something that I believe you have a gold badge or something. I don't know that has that on. So they were trying to hide things. And it's not always easy to hide things from communities. So they try their last ditch attempt. But unfortunately, the president of Apache said no and said that the changes may be framed as making a clarification to the SGA. But actually, those clarifications are of primary benefit to your company. Now, I think to everybody, all of us who have been reading the mailing list, this was exactly what was going to happen from the very first post. I don't think anyone was in any doubt that the request was going to be declined. But then the next thing that happened after that was, well, it turned out they were very comfortable with the SGA after all. And within 12 hours of being told, no, you can't do this, they said, oh, well, to hell with it, we'll sign it anyway. And so if you want to round out your mis-experience with the community, a great way to do it is when you lose is to show that you had just been playing a corporate game all along. That will make sure the next time you make a request for a change, no one gives you the slightest time of day. So to summarize for you, what did they do wrong? Well, first of all, they sent a non-expert, unempowered proxy. Secondly, they tried to act bilaterally in an environment which is inherently multilateral. Thirdly, they tried to circumvent the well-worn accepted consensus, the consensus which creates the freedom that the community enjoys for developing software. Fourthly, they condescended to the community. At one point, they said that no one here is an expert, let's get our lawyers together. And I think it was actually Roy Fielding that popped up around that point and said, you know, I have a good idea what's going on here. They tried to change the license, and if there is ever one thing to tell your counsel, it is you can't do that. You're used to doing commercial negotiations, and those are where two companies are trying to broker a non-combat zone between their two competing objectives, and you change the license agreements in that world. This is not that world. That license is not a bilateral peace treaty between two warring companies. This is a multilateral statement of rights by a collaborative community, and you never change it. It's possibly hard to change most license agreements that have been in use for any length of time. They sickly tried to dump an unexplained set of changes, and seventh and worst, they tried to conceal their true self-interest. And I think that those are probably the seven lessons that you should give to your counsel to explain how to deal with an open source community. So what should they have done? Well, they should have found an empowered and qualified person who was not acting as a proxy, but was acting in their main job. They should have understood Apache's process and followed that process and been told by Apache when the process needed changing rather than suggesting the process needed changing for them. They should have made the changes. If they thought the SGA was wrong, they should have made the changes before they had a problem rather than tried to make changes in response to their perceived problem. They should have made sure they did all of their talking in community spaces so that everybody can participate from the community. Community spaces don't need to be public. Apache has private mailing lists that are members only when things shouldn't be made public to the general public. But Apache generally is not happy about you trying to have one-on-one conversations with people to circumvent the community. And don't try and go lawyer to lawyer with open source communities until the community invites you to do it. You'll know if you get it right, because at the end of the process, your lawyer will be told either that they're the cleverest person in the room or they'll be told that they should apply for membership of the community or they will generally be consulted over future activities. They'll be treated as a community member. And the truth is that lawyers are the members that we need in our communities. We've got plenty of developers and we've got plenty of users, but actually it's really good to adopt a lawyer too so that you can get that expert opinion without having to pay for it. And so that is everything that I was going to say to you. And a gratuitous cat thanks you for your time. And I would be very happy to entertain questions or to receive your permissions for future work. So I'm not a lawyer, but your talk was very focused on the process and the mistakes they made. But from my understanding, and here I want you to correct me, they also tried to change something that was like a core part of Apache because they understand it, Apache license compared to the short licenses like BSD or MIT, basically Apache has patent retaliation. So basically if someone sues over a patent they have on a software that is Apache, they lose the right to use the software or something like this. And they basically try to remove this. So please correct me if I'm wrong if I have a poor understanding of this whole thing. That isn't actually what they tried to remove. So when you donate software to the Apache Software Foundation, they ask you to sign a contributor agreement. And that contributor agreement doesn't actually transfer the copyright to Apache, but it does give Apache all of the rights that are implicated in the Apache license. One of those things includes an unlimited license to the patents. And the reason that they ask for that unlimited license to the patents is to inoculate the Apache Software Foundation and its members and its software users from any possible patent action in the future. What this company was trying to do was to remove that compulsion to provide a patent license to the Apache Software Foundation, presumably because they quite fancied the idea of filing some patents later and attacking the members. Now it is true to say that the Apache license itself also has a patent retaliation clause in it. It's beyond the scope of discussing this afternoon, but that wasn't what they were trying to circumvent here. They were trying to circumvent something actually more fundamental. They were trying to avoid giving any rights whatsoever to future patents. Why were they trying to join Apache if they wanted that particular sort of change? Why not just pick a different license or go elsewhere? Did they just fail to understand or was there something more subtle to it? I think that is a fine question. So the company involved is heavily involved in other projects at Apache. And this was another project that they were adding to their portfolio. And I have a very strong suspicion the situation arose because a new general counsel had come in and they hadn't had a general counsel before that. And they had been working on the advice of external counsel, I believe. And I think the general counsel came in and said, you know, this ship you're running here is terrible. It's going to sink. You've got to start paying attention. And this was the first case after the GC had come in. I think it was probably a consequence of that. The company involved was a consistent contributor to Apache and it continues to be a consistent contributor. And as you saw at the end of the process, they worked out that they weren't going to get away with it this time anyway. It was probably something of a learning experience for the general counsel. I just want to make a comment that my heart goes out to the poor engineer because what I suspect actually had been happening was the general counsel was, let me go tell them I'm going to go on the list and do it. And the engineer was like, no, wait a minute. No. Knowing that he could at least make some attempt at the conversation. So you may have more information from the experience to know that or not. No, I was just reading them. Everything I've said is all derived from making unwarranted assumptions about these matters, these messages on the mailing list. I did actually write to the people involved on the mailing list and asked them if they wanted to explain what was really going on. And they didn't reply to my emails for some reason. Any other questions? Awesome. Thank you, Simon. Thank you.