 My name is James Bottomley and I'm here to talk to you today about a title that is somewhat of a false pretense, I'm afraid. The reason this came about is because the original title of this talk turned out to be rather too scary and controversial for the program committee. But since I am now here and it would take a large amount to drag me off the floor, we can actually change it and put back the original title that I submitted to the conference, which is the essential guide to hacking the legal system. Oh, Mike's eyes are popping out of his head. For open-source developers, of course. I was also supposed to put my Twitter handle on, which was on the previous slide, but I have to warn you that for me, Twitter is pretty much a write-only system. So if you want anything that's real-time instant messaging, you can find me on Matrix. And so that's my Matrix ID, or just by email. Being a kernel developer, we all use email all the time anyway. So it's no hardship for anybody. So before we get into this, I should tell you a little bit about me. So I've been a container evangelist for a long time, actually since 2011. Before 2011, I hated virtualization, so I had a road to the Damascus conversion. What that actually means is nobody else would offer me a job other than somebody in containers, so suddenly I learned to like them. I have been an open-source advocate for an incredibly long time. I was actually chair of the Linux Foundation Technical Advisory Board and on the Linux Foundation Board of Directors for about nearly 10 years from 2006, actually it was until 2014, so eight years. And one of the things that being chair of the Technical Advisory Board included at those times was trying to sort out a lot of thorny legal issues that happened to come along with open-source, which we'll get into. I'm also a kernel hacker, a SCSI subsystem maintainer, peer-risk architecture maintainer, so I do a lot of technical stuff. On that resume, nowhere is the word lawyer, so I have no legal qualifications whatsoever. These are a load of controversial opinions which you are free to disagree with. But that being said, let's get into the controversial opinions. So the original title of the talk was hacking the legal system, so what do you mean by this? So the Oxford English Dictionary defines hack as to use a computer to gain unauthorized access to data in a system. Who would agree with that definition? Tim. Okay, justify it. First question goes to him. So what Tim did is he gave me the Humpty Dumpty interpretation, which is a word can mean anything I wanted to mean. So for the rest of the world, hack can mean this. But the point is that most of us in this room who work on computer systems would describe ourselves as hackers. And we don't mean we spend our ages all day trying to break into computers to steal people's data. What we actually mean is that we try to cleverly use or adjust a computer system or program for an unintended purpose. So you take something that existed and you give it a use or do something to it that actually expands its range to a whole new system. This is essentially the genesis of open source. This is what open source is. You take an idea that somebody else did and you make it larger, make it more expansive, go on and on. So this is why open source people describe themselves as hackers. This is the meaning of the word hack that we're going to apply to the legal system in this talk. So since we're on the Humpty Dumpty and getting into what words mean, what does it actually mean to hack the legal system? When it sounds taking something and repurposing, I mean law is all about statutes. It's supposed to be immovable, right? Once it's written, it's set in stone, courts interpret it. How do you hack the legal system? Well, hacking the legal system really just means making it work to your purposes. That's nothing else. And if you think about where all the laws come from, so this is the United States Congress building, legal hacking or hacking the legal system has been going on an incredibly long time. All you basically have to do is to go up to that building, apply a huge amount of money in bribes. Did I say bribes? I'm terribly sorry. I meant lobbying. A huge amount of money in lobbying and laws will magically get rewritten or written for your specific use case. This definition of hacking the legal system has been fair play for centuries, right? Have enough money, find a Congress critter, pay him enough through lobbyists, and you will get what you want out of the legal system. I mean, for some things out of the legal system, it takes enormous financial amounts to do this. You're talking millions to billions of dollars. Some hacks are really simple. I mean, if you can present your Congress person with an idea that he can sell to his constituents as having brought money back to his own constituency, chances are you can get your legal hack for almost free. This is how most of the pork appears in the US spending budget, for instance. But if you want something specific, often you have to pay for it. So the problem in early days of open source, and I should also apologize to free software, people, everything, the acronym for free open source, Libra, whatever, is just getting so long that it's so difficult to use. So everywhere, I'll be saying what I'm used to, which is open source, but you can interpret this to be whatever term you wish for open source, because basically the true nature of open source is it's a bunch of individuals who wouldn't particularly agree on anything except the code, all marching in sync together towards one specific goal, and when they get there, they all split off, you know, have schisms, and then come back together to do some other purpose. It's not about everybody agreeing with everybody. So I'm using my definition, you're free to use your own. The other question we should probably get into is, why is there so much interest in legal systems and open source? I mean, this isn't really that usual for, you know, you come out of university with a degree in computer science or physics or whatever, and the first thing you do is witter endlessly on Debi and legal about legal issues. Open source attracts this for some reason. And the real truth is it's historical. This is Monty Python's Four Yorkshiremen sketch. If you've never seen Monty Python, the sketch is brilliant. It's the one they did at the Hollywood Bowl. It basically, it's about four people from Yorkshire who go around making up wilder and wilder stories about their youth until exhausted by the lack of invention where they sink back and go, and if you tell that to the young people of today, they'll not believe you. So the object is basically that old people always invent stuff and it was never as bad as they said. Oh, I should also mention since the Code of Conduct now precludes, you know, humour for our accents regions, whatever, in Yorkshire as a region, that's its regional flag. I was actually born in Halifax, so that's the real one, not the one in Canada, which obviously makes me a card-carrying citizen of the country of Yorkshire or as we like to call it, God's Own Country, and therefore perfectly entitled to use the accent even for humorous purposes. But the point I'd like to get to is it really, really was that bad in those days. Open Source began with no support from anybody and no backing from the legal system and it was really unlikely that we would actually get any. You know, no money, no corporate support, which will be surprising to all of you today because LinuxCon is essentially a corporate conference. Nowadays, corporations are falling all over themselves to get on the open source bandwagon, show their open source credentials, do everything. Back in those days, open source free software was a pariah. You know, no corporation really wanted to touch it. It had no buy-in from anybody. And certainly it had no issues that Congress would want to touch. There was no way an open source person could convince Congress to do anything in legal terms to support open source because it wasn't really a vote winner for the constituency and they were long-haired, smelled a bit, didn't have any money. So, every inch of the ground that open source stands on today was fought for by someone and that fight was often done in legal terms. Hacking the legal system was actually one of the weapons of choice we used for this. So the first ever hack to the legal system happened long, long after open source was born. So I'm not going to bore you with history but you know that long, long before any of the licensing issues or anything came along, source code was born free and then large companies of whom my employer IBM was one decided to take it and imprison it behind copyright and licensing and then all source became closed until Richard Stallman came along in 1985 and decided that he didn't like it. So this was actually our first big legal hack. The copyright system was used to close off what had been formally open source and make it available only to people who control the copyrights of the code. So this was effectively using a system that was designed to protect books and songs and radio and using it to protect software instead and just in case that didn't work they also used patents as well. So the whole of the IP arsenal was arranged against source code to try and close it all up and the clever legal hack that the Free Software Foundation came up with was to reverse the concept of copyright turn it into copy left and use the weapons of... I mean it's wrong to call them the enemy because they're all our friends today. They're always the enemy. Now they're our friends. But to use the weapons of the people who are fighting us against them. This is precisely what copy left does. It's definitely a hack on the legal system because it involves using all of the provisions of the copyright code to actually force the source code to stay open. This is what the GPL family of licences does. Like I said it was conceived in 1985 by Richard Stallman and the Free Software Foundation. It is sort of the first actual open source legal hack I can find so I have to give him credit for that. I won't go into what's happening to the Free Software Foundation at the moment but I will say that some of the deeds are great enough to stand on their own regardless of personalities or factionalization or even scrubs by various corporations and this was definitely one of the first. They took what existed and there was no modification of the statutes required. They just turned the very provisions of the Copyright Act back against the corporations who wanted to keep the code free and forced it to become open. Like I said it was exemplified by the GPL family of licences. Now in the strictest sense being open source people you think of hacking as modifying the code. So in the true, really, really strict sense of modifying the legal code this wasn't a hack because it didn't do anything it took exactly what existed and used it to a different purpose to achieve its aims. Now in the broader definition of hacking that is definitely still a hack but in the code definition we use perhaps it isn't. But anyway it changed the use case but not the code and thanks to this we actually now have a section opened up in the law all about open source licences and licensing and everything else. The GPL has been fought over in court so the theory upon which this hack was based has now been proven in the legal system. But one of the things you might be interested in is the first actual hack to the law. So how in an open source fashion do you change the statutes? Well we can't hack the statute itself because you need to pay Congress. Everything that's written in law comes out of the houses of Congress and is signed off by the President in the United States. There are a lot of legal systems in the world but the point is that US law isn't all statute law. There's this thing called common law that runs through a lot of the English legal systems that is inherited by the US as well and we can hack that. So common law basically means legal determinations that are not based on statute but are instead based on precedent and expectation and there is an amazing amount of that. This thing that you probably heard a lot of in the Supreme Court battle, Stare decisis is one of the main pillars of common law. It's very simple. All it means is that one future judge would respect what a previous judge decided. It basically is Latin for let stand what is decided. So it means that once a legal decision is made every other decision after it should respect that legal decision if it's handed down by the highest court. But once the decision is made by the court from which there is no appeal that decision has to be respected and obviously given what's going on in Texas Stare decisis is not doing very well in the United States together at all today but that's okay because we don't rely on it. The other thing that common law is based on is an expectation of the parties. Common law particularly the common law of contracts that underpins most of industry today is based on the expectations of parties. So the way you change common law in the United States today is by changing the expectation of the parties. The parties have different expectations going into a contract into a license into whatever the law that governs it has changed. So how do we do this? The way we did this is by something called the developer certificate of origin. Who's actually heard of this one? There were a few people in the room. This is a contribution system pioneered by the Linux kernel for making contribution to open source projects very easy. It's actually online at developercertificate.org if you want to look it up. It's basically phrased as a set of representations. I'm not going to put it up because it's not really that germane to what I'm talking about. But you signify your agreement with the representations by a fixing signed off by and your email address into the source code that usually goes into the Git commit. There's usually a chain of signed off by's from everybody who took the patch and transmitted it into the Git tree. This is what we mean by developer certificate of origin. What it did is it swept away the old idea that you had to have contribution license agreements or contribution agreements or some other legal mechanism to make a real genuine contribution to a project under the license. Instead all the developer has to do is put signed off by at the bottom of their email address into the source code. I've just told you everything is good. What actually is the problem? Well, the problem in the early days was that the DCO actually only works for individual contributors. It doesn't work for corporate works for hire. The reason for this is the issue of agency. Agency is another massive area of common law. What it means is it's the law of how a corporation can act because if you want to sign a contract with let's say your telecom provider as Verizon and you want to sign a contract with Verizon, you can't go and knock on the door of Verizon the company and find it and get it to sign the contract because Verizon the company is just an idea. It's made of a body of people. It has no arms and legs. It can't take any actions on its own. So the law of agency is how individuals act on behalf of a company. Corporate councils actually spent a lot of time and money for a long, long time trying to reduce the agency for intellectual property to be what they call principles of a company, which usually means directors or vice presidents and above. And if they succeeded in doing that, this means that developers have no agency in the IP rights they are required to give up under the signed off by because they're effectively signing off to a license that certainly requires copyright and also may require patents. And if they're not directors or above of the company under the current law of agency, they have no agency to do the signed off by. All signed off bys and work for hire would be invalid. So fixing the agency problem actually meant hacking common law. So let's do a description of how the hack was made. The DCO itself was invented for the Linux kernel in 2005, hot on the heels of the SCO dispute. The idea was to track and verify all contributions to the Linux kernel such that if somebody like SCO ever came along again and tried to claim the code, we would have provenance of the entire history backed by an immutable source control system that would prove exactly where it came from. It was actually written by a lady called Dan Peters who's now I believe at Wikimedia Commons, although I might have that wrong, but there were many, many different ways of doing this. There was sort of a huddle of Lina's lawyers and a few other people trying to figure out how the hell we would do this because the lawyers told us right, in order to present this in future you have to have contribution agreements for the Linux kernel and we basically said that would destroy our development velocity, we're not doing it, come up with something else. And eventually after months of haggling, they did come up with something else, which was the DCO and signed off by. And they figured it had enough agency that it would work. Then there was a very wise copyright lawyer, one of the world-renowned experts of copyright who actually joined the Linux Foundation around 2007. Her name was Karen Copenhaver and as soon as she saw what we'd done with the DCO she immediately appreciated the agency problem that we were actually setting ourselves up for on down the line. And so what she did in collaboration with a echelon of kernel developers and the technical advisory board was formulate what was effectively a multi-year, in fact it was a decade plan to fix this agency problem. The reason I'm telling you about it now is because it is fixed. The strategy we adopted was basically to expand the DCO far and wide beyond the kernel. If we could make it the de facto contribution agreement, all of the witterings by all of the corporate lawyers about who had agency for IP would go out of the window because every corporation was now relying on this agency being granted by the developers. It didn't matter what the corporate lawyers thought, what was happening in the world today was that everybody was relying on agency by developers and agency was granted because everybody's expectations were that agency existed. And when this happens the laws are changed and this is actually what happened to make the DCO workable as it is today. In 2021 we have hundreds of projects with DCO sign-offs. They're relied on by thousands, tens of thousands, hundreds of thousands of companies. It is now too late to go back to the idea that only directors and buffs have agency for intellectual property in a company. It is now de facto accepted that an engineer who does a work for hire and contributes it to a project under a sign-off by has the agency for all rights required that the corporation requires to give that contribution effect in the project. This is now pretty much an immutable fact. We've had 15 years, well 14 years to work on this it's too late to go back to your court. So the final thing I'd like to get, well I suppose I should pause there and ask if anybody this is supposed to be a conversation these are my opinions. Anybody have any counter opinions you want to raise before I get on to the last topic which is owning your own copyright. This is another hack to the legal system but it's a slightly different one so we might as well pause here. Yes, Mr. Bird. So Tim's comment is I may have just made the life of the open-source program offices a little more difficult at this time. I presume the reason for that comment is because you thought none of the corporate councils had noticed this. Is that the basis of your opinion? I don't think there's any corporate council who hasn't noticed this. There are a bunch of corporate councils who are starting to band together and try and say this more forcefully which is partly the reason for this talk but it is my firm belief that this is way too late. The position as an open-source program office that you need to take is this is Stare decisis. You know, you did it a decade ago. It is too late to go back. Developers are agents for intellectual property required to contribute under open-source licences get over it. I mean, what is going to happen? Who's going to sue? Let's say some corporation were nuts enough to do that. It hasn't been tested. This is correct. Okay, so Tim says the issue is it's still a problem convincing managers that it's okay to contribute code. And the answer to that is that the desire to contribute code on a corporation was almost non-existent back then. Now, as I said, everybody else is tripping over themselves to get on the bandwagon. The bandwagon effect is forcing managers to contribute. They can raise legal issues as a slight barrier but we have lots of people who can go and talk to them and say, you know, that's not really a barrier. And the thing you say is, well I work for Corporation X and you're right, there may be a legal problem here so we should not contribute. We'll let Corporation Y and remember if we don't contribute and we're worried about this that also means we can't make use of open-source. Right? So we'll cut ourselves entirely off from the open-source ecosystem and flounder around until we die while our competitor Corporation B takes all of this open-source code and takes a better platform and kills us in the marketplace. Is that really the end-point you want from this conversation? Will that work? Well, yes, but it won't work. Well, I thought you were sitting around drinking martinis. Sorry. So what Tim said is I'm creating work for the open-source program office but I think they need to do more than just sit around and drink martinis so I think evangelizing on this point is a key thing that the open-source program office should be doing. So unfortunately I may have applied the electric cattle prod to your backside and you have to go and do something about it now but I'm not going to apologize for that. Okay, sorry. Any more questions about the DCO and what we've done? So the question is, is there anything I want to say about CLA's? All I really want to say about CLA's is that A, they're pretty much pointless. Anything you can do with a CLA you can do with the DCO. A lot of lawyers claim you need so CLA stands for Contributor License Agreement. It's usually a signed piece of paper between a project and a developer to make a contribution, often electronically signed. And lots of projects claim that the contribution isn't correctly made unless you have a CLA and there's another claim that it insulates the project from legal risk. Both of these claims are complete rubbish. The contribution made under a DCO has just as much standing as the contribution made under a CLA. All of the legal points a CLA would fail under which is basically where somebody is lied or there's been mismanagement or misrepresentation going on. A CLA does not protect you from. All it does is it gives you a legal piece of paper to say you shouldn't have done that, that was naughty. And the DCO provides exactly the same protection. So there is no more legal safety from a CLA than from a DCO. CLA's are also being used in the marketplace by corporations to actually try and take more rights than the license requires. CLA is often not reciprocal. That means that if you sign let's take the Apache CLA for instance. This is a standard CLA that everybody adopts. What it actually, and every Apache project that I know of uses it including OpenStack what it actually says when you sign it is I contribute all my licensing rights in this code to the foundation. It does not say as long as they license it under Apache 2 it says all my rights. And then the foundation licenses it into the project under Apache 2 but they still retain the rights that I signed off on. And what this means is that if a clever corporation and I won't mention any names but Elasticsearch might come to mind also were to adopt this process that makes them the sole deciders of who the license of the project can be and gives them carte blanche to relicense all that code you thought you were contributing under a free license. This is the trap that CLA's are setting you up for. And indeed when things like the license of Elasticsearch change to SSPL there was a lot of complaints and backbiting about this and the reason a lot of developers have tripped up into signing contribution agreements that basically gave away all their rights and allowed the relicensing is precisely because the Apache foundation was doing it so it must be good. CLA's are bad from this point of view because people rarely read them and they don't understand what they're signing and often they're signing way more rights away than they should be giving. So that's why CLA's are bad and what they're going on about is they're just friction. They're sand in the process. Open source is all about process velocity. Anything which interferes with the wheels of open source turning is bad and having to pause, get a CLA often if you're a corporation signing a CLA you need to get your lawyer to agree which can take months it's bad for the open source ecosystem. So CLA's are bad on three grounds. Is that enough of a reason for you Jeff? Okay. Any other questions? Right, then we can move on to owning your own copyrights in open source. So copyright ownership is actually the key to rights enforcement in the entire open source ecosystem. If you don't own your own copyrights you can't do any enforcement. Now, I know most of you modern web kids who contribute code to all of the fancy go and python and node projects under the Apache license think this doesn't matter because those licenses are permissive so there are very few rights to preserve by legal action. So in theory copyright is something you shouldn't be worried about. In fact a lot of people haven't been worrying about it for a while which is how come the SSPL relicensing happened because they weren't paying attention to the rights they were giving away. But the point is permissive licenses have obligations too. The Apache license is not just a hey we give it away you can do anything you want with it it has a specific set of obligations including how users use patents, how contributors are credited and so on. And the key one that you might be interested in as open source developers is preserving authorship. As an open source contributor your contribution record is your key to getting a new job joining a new community being known for who you are. And if somebody can take that away from you I think you wouldn't like that. And if you don't have a license to your code they're entitled to do that. They'll have committed an offense under the license but you can't sue for it because you don't have standing. You're not the author you don't own the rights. And that means that if anybody does this to you and let's say you were just working on behalf of your company and it was all work for hire and somebody actually stole your code and put their own name on it you'd have to go to your corporate council and say I don't like this can you do something about it because you can't do anything about it yourself without owning the code or without some type of ownership in that code. So obviously the first route to owning your own copyright is actually to ask your employer. It's not as bad as you think. So a lot of employers, especially for well known open source developers and remember the market is frothy for open source at the moment. I think I read a report a week ago that said open source developers are the hottest commodity ever. So you have a lot of leverage when negotiating your employment agreement and even after negotiating your employment agreement. And so asking for a right to own the source code that you're actually going to be contribute is not such a fast stretch. I mean when I joined IBM I did it. So what I have now is joint ownership of any code I contribute along with IBM. Joint ownership is actually usually a good way of doing it because what that means is I myself own all the rights to enforce and I could if I wanted to. But the corporate being counters at IBM also get counted as their contribution because they're joint owners, right? So everything I create, the ownership is split between myself and IBM. And the corporate councils at IBM seem to think this is a reasonable way of accounting for a project. And I don't think it's impossible for any of you in the room to also negotiate something similar. A lot of people are afraid to and the reason you're afraid to is because when you're negotiating for a job you always feel like you're sort of the underdog. I mean the thing you're usually fighting for is you know I want the salary and I want the benefits then when you've got it all you think oh my god so now do I upset the apple cart and ask for copyrights and open source and everything but the answer is yes. Usually they are willing to deal. But assuming they are not willing to deal there are actually strategies you can use involving legal hattigry to achieve the same ends and so this is what I'll tell you about at the moment. Hacks for copyright ownership. So I'm sure you've all signed agreements with a company in the US. Every company from the smallest to the largest for something to do with software which is effectively intellectual property forces you to sign a statement of prior inventions. It will always have been somewhere in the packet that you signed when you joined the corporation. They will not have left it out because it's a key cover your business mechanism for the company. So somewhere some time you'll have signed this. Most people just sign and say I have no prior inventions. What you're supposed to do is to actually fill in all the prior inventions that you may have created for some other company or prior inventions you have claimed to that you might then see your employer for. It's usually just supposed to be a list of what you worked on before and often when you're actually given this thing to sign it's usually in this huge bundle of stuff in the first day they say they're going come on come on you've got to get your badge you've got to go up you've got to go and see so and so sign all that stuff so you just go through it you sign it on the nod nobody ever realises what they've done but that form would have been there somewhere. The key promise that this form binds you to is not actually incorporating any of these prior inventions into the code. So if you leave the list blank you're not promising not to incorporate anything into the code but the point is it's a cover your ass mechanism for your employers. What it does is if you incorporate code on the list you promise not to you've lost they can sue you fire you do whatever because it's your fault right any monetary consequences would devolve on you because of what you signed and it was on the list. However you left the list blank so nothing is on that list you signed it you promise not to incorporate it and another key to that list is you promised full disclosure and you didn't fully disclose so now code from a prior project got incorporated in this company's thing it was a project you worked on it must have been you who did it it's your fault and it's your fault for not disclosing it. This is the whole purpose of this piece of paper they make you sign and you lose again that's why it's a cover your ass mechanism but the key point for all of you here is that statement also represents a list of projects which are de facto outside of the scope of work so all of the projects you've listed there are outside of your scope of work for hire so anything you work on that was on that list worked on in your free time cannot be claimed by your employer. This is how you get all of the code contributions you want to do in open source outside of your employer's control. All you do which is what I've done for every company since time immemorial is actually list all every open source project you work on or would like to work on on that list what that basically means is that anything on that list I can work on it I don't have to ask my employer for permission to do so I'm free to sign a contribution agreement the free software foundation if I insist and tell them that yep I have the sovereign right to this code because it is on that list and it's outside of my work for hire. And obviously because of that your employer would have no basis for claiming any work on that list in the future because they signed it too so it's a binding contract between the two of you that says all of these things listed we've already agreed are not going to be part of my employment brilliant there's no come back for them there's no come back for you the only problem is you also promised not to work on them for your current employer so the only problem you have under this is when your employer actually asks you to work on a project that you've already listed on the schedule right and that is the point at which you could open negotiations for an agreement to own your own copyrights and open source with this leverage if you really wanted to. This gives you a way back in a legal way because basically either we have to rewrite my employment agreement Mr. Employer or just give me blanket ownership and we won't mention this anymore everything will be okay so this is what actually allows you to claim ownership of all of your copyrights now the problem for all of you is if you're all safely employed you can't pull this trick until you actually move to your next employer because what you signed for your current employer is already done but it is a trick you can use in your future jobs and I encourage you to do so so conclusions legal hackery occurs every day well for people with enough money to burn however and I hope I've given you examples at least three it's quite easy to work creatively outside congress to achieve the same legal hackery you wanted both in common law and just by simply using the things that have been created to ensure some end goal for a completely different end goal another different form of hackery most open source projects depend on this if this hadn't been done in the early days chances are there would be no open source today and you can depend on it too if you want to try the trick for owning your own copyrights the next time you get a new job so with that I would say that this was all done with everything open source this presentation is actually a web page using impress.js you can download it play with it and modify it if you like it it's by a guy called buttocksoper I have extensively changed it but all of the changes are in the presentation if you download it of course that does make me a web developer which in kernel terms is now even lower on the totem pole and rust developers so I'm really doing badly the presentation is available at handsonpartnership.com press slides linux.com 2021 the reason it's linux.com is because this was supposed to be presented in Dublin and apparently this event is substituting from Dublin so even though I stand however far away from Dublin it is notionally I'm there so you can all buy me an Irish whiskey after this and the reason you have to do this as well as the Linux foundation is using some proprietary piece of web thing called shed.org that doesn't seem to allow me to attach this presentation to it so this and I will actually do a write only tweet giving you this as well if my twitter handle was on the slides also JJB underscore so you should be able to find it and with that I'll say thank you and call for questions if there are any did you ask all of your questions in the middle so nobody has anymore that they can think of well if there are none I will say thank you very much okay there's one so Tim asks do I expect an FSF response to this talk I will have to ask disingenuously why you think I would get an FSF response to this talk because I've just praised them for the first legal hack what is it you think I should be wary of right so what I should say is that first of all creating new DCO so Tim's comment there was a blog post by the FSF about their desire to create a new DCO creating new DCOs is very bad the copyright of the DCO is owned by the Linux foundation it's immutable for a reason and the reason is the hack that we all rely on that brings the DCO into existence and causes it to work because for everybody's mind to be changed everybody's sort of opinions and expectations to be changed there needs to be one thing they all think they mean when they say DCO if there are many things you would build a gap through which lots of corporate lawyers could slither over doubts about which DCO were they signing and was the code properly contributed so preventing fragmentation of the DCO is key to preserving the ecosystem of the DCO and all of the guarantees that we rely on and therefore for that reason the FSF were being a bunch of pillocks when they did this and they have already been forcibly told by a lot of people in open source and they will be being told even by the people who fund them so I believe effectively hopefully this topic is over the DCO was crafted in such a way that as far as we can tell and we have had a lot of really strange situations that want to be covered by the DCO the current DCO actually covers all of them so there is no need to modify it but the flip side of this is that modification of the DCO would be the way by which you destroy the DCO ecosystem and all of that code upon which is sort of legal contribution provenance as your companies rely so not modifying the DCO is both nice because we think we got it right first time which is unusual and also a requirement because once you start modifying it you will fracture the ecosystem you will destroy the expectations and the guarantees and you will reverse our hack to common law that actually makes it all work and that stands a chance of causing a lot more damage than anything else do that sort of answer your question so the question is have I heard of blockchain and NFT NFT means non-fungible tokens right I've heard of them so the question is do I know anything about blockchain and NFTs how they can make a contribution to the DCO ecosystem so I have to say that there is a similarity between the way DCO works and the way blockchains and NFTs work because I didn't actually really get into the DCO ecosystem I made a whole talk on that and I only have 5 minutes left to do all of this but the point about the DCO is somewhere you need an immutable record of who did what and that only came about in the Linux kernel because at the same time we adopted the DCO we also adopted Git so the DCO and its guarantees don't mean much unless you have a provably immutable repository collecting all of the signed off buys these are the filing cabinets that people actually did with contribution agreements and actually the fourth reason Jeff's already gone that you should never do contribution agreements is because they're pieces of paper and people lose them right once you've lost them you have no proof the proof should always be in the source tree and so Git because it's based on this sequence of immutable hashes is all very like a blockchain in that regard it doesn't have any of the cryptographic stuff but you can't modify a previous thing and not have the modification detected so it basically gives us it's not really a blockchain it's much more like a transparency log but it shares a lot of the commonality with things like blockchain and NFTs for that reason so this is a piece of learning I won't really say that I mean it's arguable that Git came before blockchain so perhaps we were first perhaps blockchain was first but it's definitely a parallel sequence of learning that we still make use of if that was the thrust of your question okay any more questions well with that I'll say thank you very much and I hope you've enjoyed this talk as much as I enjoyed giving it particularly as it might be my last now that I went back to my original topic thank you