# DEVA Awards SEA

- Channel: [Devcon 7 SEA](https://streameth.org/devcon_7_sea)
- Date: 2024-11-16
- Duration: 18:55
- Watch: https://streameth.org/watch/673818451b0f83434d226075

## Transcript

Awesome. Hi, everybody. I'm Hart, and today I'm going to be talking about how to open source code. I think this is going to be a little more pragmatic than some of the previous talks, but I'm going to start by talking about some open source background. Why do we open source? And a little bit about the Linux Foundation with a focus on why you should care about my opinion on how to open source code. Then I'm going to go into some open source table stakes, some stuff that you really need to get right if you want to properly open source code. This will include software licensing, IP protections, and best security practices. And finally, I'm going to talk about open governance and open communities. So let's get started. So let's recall, why do we open source code? There are two main reasons. The first is so others can verify, examine, and learn from our code, right? If we want people to be able to trust what we're doing, we have to show them the code. And open sourcing also has many benefits around things like software security. But probably the main reason why we open source code is so that others can use and even contribute to our code. There are many economic efficiencies of working together in open source, and a large ecosystem around a piece of open source code ensures that even if one organization goes away, development will continue. So open source software has won in the broader ecosystem. If you're a developer, you probably know this, but for many commercial applications, even a typical commercial application, even if it's closed sourced, 90% of a modern application's code base is open source. And if we look at how software is built today in the world, and even commercial software, sourced, 90% of a modern application's code base is open source. And if we look at how software is built today in the world, and even commercial software, this is sort of what it looks like, right? People start with an open source software framework, and then they use custom code and existing libraries to solve problems. And this can lead to tremendous economic efficiencies. I know this is a cypherpunk track, but if you're trying to convince your boss that you should be able to open source your code, the economic efficiencies are a great argument. But open source is most efficient when multiple companies, entities, or people collaborate to build software that they all need in the open. And you can think of this as decentralized development. And this is the problem that the Linux Foundation solves. We solve decentralized development for open source code. And when multiple companies, entities, or individuals want to collaborate on open source software but don't trust one single party to own the code, they turn to the Linux Foundation. And this is something that blockchain people tend to be inherently comfortable with, which is fantastic. So I don't want this to be an infomercial for the Linux Foundation, but I do want to present some facts and figures that can hopefully convince you that we have the data and the experience to properly give advice on open source code. So we are behind some of the most critical projects in the world. Probably everybody knows the Linux kernel. Maybe you use Kubernetes if you do cloud development. But you may not know that a large part of the world's telecom stack runs on Linux Foundation open source code. Or that if you have a new car, it probably runs on Linux. Maybe using something like automotive-grade Linux. There's fun projects too, like the Academy Software Foundation, which hosts software where Hollywood uses to make animations, and also stuff like RISC-V. Just some numbers. I'm not going to read these to you, but hopefully I can convince you that we've seen it all when it comes to open source. And why am I here? Well we have a number of projects in the Ethereum space as well. Many people here may know Basu which is one of the core Ethereum execution clients. We also have a number of other tools for Ethereum in our open source ecosystem like Web3J which you might have used to develop on Ethereum or Pal, which is a brand new lab for privacy for EVMs. And again, all of these code bases are completely free and open to use. So you can go do it today if you want. All right, so let's get into the meat of the talk. Let's talk about open source software table stakes. What do you need to do to make sure you have a good experience open sourcing your code? And let's look at a definition of open source software. It's a type of software in which source code is released under a license. And the key word here is license. And obviously, a license is, in this case, a legal document that expresses rights and responsibilities around the code. So there are three typical types of open source license we see today. We have business licenses, which are typically very restrictive software licenses that may require payments to a developing company for use. We have copy left licenses, like a GPL license, where modifying the software requires you to contribute back any derivative works or things you build on top of the software. And finally, we have permissive licenses, which really let you use and modify the software in any way that you like. And I'm going to go into a little more detail about all of these licenses. So let's start with BSL licenses. So technically, a business source license is not an open source license, it's a source available license. And the source code is public, but you're only allowed to use the source code if you've met certain characteristics. And this is sort of viewed as a compromise between proprietary software and open source software. If you want to gain some of the benefits of people seeing and trusting your code, but you want people to pay for it, this is what people typically do. BUSL is an example of this. And in the Ethereum space, Arbitrum Nitro has this license. Now, let's talk about copy left licenses. These are open source licenses that require users to make available all derivative works. So if you modify the code and use it in something, you typically have to make the source of that something available for free and also licensed under this copyleft license. Copyleft licenses are often very hard to use commercially. Notable examples are MPL, GPL, and LGPL. And in the Ethereum community, Geth is a notable example. So I'll put this quote from Richard Stallman about GNU and copyleft licenses and I will issue a warning about copyleft licenses. The goal of copyleft licenses is to increase contributions by legally requiring them and the unfortunate reality of these licenses is that people just won't use your code if there are any viable alternatives due to the potentially cumbersome legal requirements. And I'll say it's very hard to relicense to a permissive license from a copyleft license, so choose carefully. And finally, there are permissive licenses. These are open source licenses that let you modify and use code freely. Most commercially used open source licenses that let you modify and use code freely. Most commercially used open source code at this point in time does use permissive licenses because they're by far the easiest to use. And if you want to maximize community adoption of your code, we definitely recommend you use a permissive license. You've probably seen Apache 2 and MIT as examples of this. There are lots of projects, but in the Ethereum space, Basu has an Apache license. So before we go any further, I just want to mention some common licensing pitfalls. Most of these I've talked to at this conference and seen people make these mistakes. So what I want to talk about is being very careful with code you use, right? And this is kind of an LGPL dependency issue. So when you use a combined work with LGPL code, which means you're putting LGPL code into your something bigger and using that, people sometimes think that you can link it if it's in a separate folder. But as this provision shows, you can't really have compile time dependencies for LGPL code. It has to be a runtime dependency. So carefully check your dependencies. And finally, you know, be careful with licenses that don't have IP protections. This is an example from an anonymized company documentation that basically says, we're going to use a permissive license for code, but we're going to enforce patents on this code, so you still need to pay us to use this code. Read carefully. This company is actually very transparent, and if you use code from less ethical and transparent people, you might be rolling the dice on a lawsuit. So in summary, I'll say pay very close attention to the licenses and licensing requirements of open source projects you use. I personally recommend that you use Apache 2 for your own code because it's a permissive license and it has explicit patent grant protections. And if you want to make a proprietary code vase visible to others, maybe use a BSL license. Right. Let's move on. We've been talking about IP protections. So what do you do when you need to protect your code against IP issues? Sometimes contributors might unintentionally or maliciously add some code that has some form of IP protection to your project. And it turns out we at Linux have had a big issue with this. Does anybody know of the SEO Linux disputes? Yeah, some people. So these were a huge number of lawsuits, essentially because the kernel did not have explicit IP protection on it. And to do this, folks at the LF created the developer certificate of origin. And we recommend that for your code you either use a developer certificate of origin or a contributor license agreement. It's very important to have these legal frameworks around your code and this is especially important if you're taking contributions from outsiders. So just as an example, this is the DCO right here. That's it. It's very easy to set up on GitHub using commits signed with the dash S flag. It takes a little bit getting used to, but once your contributors are used to it, it's very, very easy. Right. So in summary, be sure to have legal protections for your code. If you don't, people that can be sued will be very hesitant to use your code. We actually require this kind of protection for all Linux Foundation projects. If you contribute code, you have to have this protection. And you should have it, too, for your open source software. We use the DCO, but again, a CLA is perfectly acceptable. So what about security? Obviously, security is critical for any software, not just open source software. And we could do a whole conference about open source security, and there was one last month, actually. But I want to briefly emphasize some things that might be different for open source. And those are vulnerability disclosures, SBOMs, or software bills of materials, and authenticating software. So I will say we have a great organization in the Linux Foundation called the OpenSSF, which has all of your open source software best practices. Go check it out if you have any questions on security. It's a great source just to make sure you're doing everything you need to be doing. Right. So what about security vulnerability disclosures and pipelines? An obvious advantage of open source software is that community members can find and report bugs. And the key point is you want to make this as easy as possible for them, right? You don't want contributor friction to be an issue. It doesn't really matter the exact method in which you set things up, as long as it's easy to follow. I'll say that in the LF, many of our projects have been using the GitHub tooling, not all of them. BASU, for instance, has seven reporting channels, which can be a challenge for us to handle, but we do. Now, moving on. Recall that I said modern software was built like this, right? This is very nice and efficient, but it introduces a number of problems, right? If you build on software with security bugs, you might have a real problem. And it turns out that a lot of the big attacks that have been publicized and caused a lot of problems recently have been due to these so-called software supply chain attacks. And the solution to stopping these attacks is generally what's called a software build of materials, or SBOM. Has everybody here heard of SBOMs before? Some people? Great. OK, if you haven't, you should definitely check this out. What SBOMs let you do is they let you keep track of all the code you pulled into your open source software project. If there are bugs, you can quickly find them and update them, right? And I also encourage you to carefully examine the code you use to make sure it's well maintained. You know, don't pull in code from some random developer who hasn't updated it four years ago. And I will, again, well-run open source projects are very careful with the dependencies they use. And there are a lot of good tools to help with this. Guac is excellent, but there are many others as well. Right. So I'll briefly touch on software and artifact authentication. If you build in a popular open source project, people will attempt to impersonate you. This constantly happens for us at the LF. You know, just last month we had people create a bunch of fake NPM packages to try to impersonate you. This constantly happens for us at the LF. Just last month, we had people create a bunch of fake NPM packages to try to impersonate us. But there are plenty of tools that you can use to sign and authenticate code. Six Store, I think, is an excellent example of this, although I do wish and think they should be run on the blockchain. All right, so we've covered some basic stuff. What about building an open community? So if we go back to our definition of open source software, one key thing here is this phrase collaborative public manner. And this is important because the freedoms provided by particularly a permissive license allow large and diverse communities to form around popular software, right? This allows for those economic efficiencies of open source. So when we talk about open development and open collaboration, we don't just mean open source, right? We also mean open development, which means there's a community actively building open source code in the open, and open governance, which means that procedures and roles for the community, how decisions and priorities are made for the project, and the roadmap are openly defined and managed. So I'm going to go through a few open source models of governance here. And this is a continuum. It's not sort of, you know, it's only these four things, just to give you a flavor of how you should set up your open source project. So the sort of least open form is called what I like to call a public demonstration. And sort of the code is just open source. It's just there. It's not really updated. There's not necessarily a roadmap. You could be less polite and call this a code dump. Then we sort of move on to open company products. And this is when a company or entity open sources a piece of software that constitutes a product, right? It doesn't allow outside contributions or makes them very difficult, but it keeps a roadmap, you know, has regular releases and follows best security practices. And as we sort of get more open, we have benevolent dictator projects. And this is when an organization or individual open sources their code and allows contributions from external contributors but ultimate authority of the project is still that one benevolent organization and Finally we have true open governance and this is code with you know transparent documentation decentralized meritocratic governance hosted under a neutral entity and Anyone can join their, clear processes for leadership, and no restrictions on who can join and become a leader. Right? So we can go a little bit more into details on these sort of code models, right? I certainly believe that opening code in a kind of public demonstration is better than not opening code at all, right? Third parties can audit your code, see what you're doing. People will trust you. The biggest pushback we get from this, particularly from big companies, is that there's reputational risk. And my response is usually that if you're trying to build a production system, you shouldn't be embarrassed to let others see your code. That's a problem if that's the case. Once we sort of move on to a more open product, it can be a little bit easier than a public demonstration, but it's still hard to get others to use your code, because the model requires a very high level of trust in the company. What happens if the company changes direction and abandons the software or goes out of business? That might be a problem for you and your business if you're building on this code. And then sort of a benevolent dictator model, right? This is increasing in openness but it still means that competitors in your space or those who don't trust your company or entity are unlikely to participate. So it's easier to get contributions and have you have people participate than just an open product, because people can make typically small changes. They can fix bugs. They can work on their pain points. But ultimately, it's not open governance. And then finally, we have fully open governed projects. This strongly incentivizes companies or other entities or people to contribute because they can play a role in governance proportional to their contributions. A diverse set of contributors means that potential users can easily be convinced of the long-term stability and viability of the project. And this will increase overall use of the project. And the main drawback of this is it's the community project now. It's not just your project. And people that participate should receive governance powers proportional to their contributions. Right. So about governance, I will encourage you to carefully choose projects to use or contribute to based on which style of governance is utilized by the community. And whatever governance you do choose, make sure you document it clearly. If your main goal is growing a community, we strongly recommend openly governed projects, as we've talked about for the last two minutes. Right? So finally, I want to talk about some best practices for growing a community. So one best practice is open source bureaucracy. And this is what I've said before, although I haven't really called it this, is that the most successful projects that have stood the test of time have neutral open governance models where those who do the work make the decisions. Right. Again, not very cypherpunk, but the longest lasting, most successful open source products also have a good commercial support ecosystem, right? And a diverse commercial support ecosystem. Because the people that make money off the code can put it back into contributing to the code. It's difficult to attract investment from potential competitors if one entity owns or controls the code base. So we recommend a neutral home or setting up some kind of owns or controls the code base, so we recommend a neutral home or setting up some kind of neutrality around the code base. And finally, it's very important to have transparent documented governance. So people looking to contribute are going to want to know exactly how they can participate, and they don't want to be surprised. So right, this seems hard. What should I do? Well, take a look at the Linux Foundation or another open source software foundation, something like the Apache Software Foundation, as a home. So the LF's role, again, is to serve all of the big companies in technology. You know, it's hard to put an open source community together. We have experience there. And with us and all these other software foundations, you know, the same legal structure that for us at least protects the kernel and Kubernetes can also protect your project. And finally, you know, I do want to emphasize and mention that contributing code or a project is completely free and open to anyone. So any Linux Foundation project, you can come join, you can use the code, you can contribute the code. It's all free and completely open. So yeah, come find us at Linux Foundation Decentralized Trust if you have any questions. And thank you very much for your time. All right. Thank you once again, Hart, for that. We do have a few questions here. Can you explain the differences between MIT and Apache 2.0 licenses? Great question. This is a hard question. And the true answer may not even be legally known, because we have not had court cases that have separated these licenses. Again, not a lawyer. This is not legal advice. The main difference is the Apache 2.0 license has explicit patent protections. So this has not happened yet, but there might be a case where there's a successful patent lawsuit against an MIT code base, but not against an Apache 2 code base. For now, that hasn't existed. You know, for now, they're mostly identical. They're compatible licenses. You can use them interchangeably. But, you know, if you're extra paranoid, you might want to use Apache 2. Right. What are the most effective revenue strategies to ensure the financial sustainability of an open source project and how can you build enough community interest to reach that sustainability? This is also a great question. We could spend an entire talk on this. It really depends on your business model. There are a number of successful open source business models. I'm sure many people in the room have them. But the big thing is that people should be successfully using the open source software in commercial businesses. Whether it's selling services on the open source model. That's a very popular one, right? You know, selling premium products on top of the open source model, you know, or software. Those are sort of two of the main models. There are many more. But again, the key is building a commercial ecosystem around this. If I knew the answer to that in every kind of application, you know, I would be a billionaire software executive. I am not. So, you know, I'll say it does depend on the project. Maybe in another life. Okay, on to the next question. Fascinating talk, but how do we get the average people to actually care about open source software? That's a great question. We're always at the Linux Foundation, you know, looking to do that more. I think it's a much easier conversation to have with developers. I don't know, I don't know I have a necessarily good answer to that question. I think it's a difficult problem. People have to understand software and software development first. So it's a hard question. The next one says, you talk a lot about governance. Can on-chain governance help with this? Potentially in the long run, on-chain governance can help. Right now, lawyers are very uncomfortable and the precedent really hasn't been set. I'm optimistic in the long run that we can have at least some governance on-chain. Yes. All right. How many of these best practices do you wish were not needed in a world with better legal frameworks and or less frivolous lawfare? Well, I certainly wish we had a less crazy software patent system where we didn't have to, you know, constantly engage in, you know, mutually assured destruction patent practices and things like that. So, you know, I would love to see that cleaned up. You know, some of the licensing is that, you know, companies, you that companies do need to make money off of open source software, but I certainly think the patent system is a mess. How do I... Oh, sure, yeah. How do you envision open source software evolving in a world that's increasingly dependent on decentralized and privacy-focused solutions? Well, decentralized solutions inherently mean more people have to come together to solve problems, right? And that's going to mean a bigger role in open source because, you know, the only way people can build software together is effectively is really in a neutral home, right? We're going to have to have, you know, decentralized neutral homes for software. So I think decentralized technology is going to really accelerate the development of open source and the use. We're already seeing a lot of this in the banking industry. All right. Are there any resources to help transition from a benevolent dictatorship to an open governance model? Absolutely. We have a ton of this at the Linux Foundation. Go look at our website, come talk to us. This is a very common question we get asked quite a lot, and we have a lot of experience doing this. All right. On to the last question. Does the LF look at public good funding experiments in the Ethereum ecosystem? We periodically look at funding. We're a non-profit, so we don't have a ton of money to give away. We obviously don't have a token. But certainly our maintainers and projects look at funding opportunities for themselves. All right. Thank you so much for that. And thank you to every single one of you. Can we please give a hearty round of applause? Thank you.