Perfectly. Thank you for visiting. Um, let's get started. So, today I'll talk about open source software and its institutional implementation, as well as lessons learned from the Linux Foundation. So what am I going to look at?
I'll talk a little about the history of open source at the Linux Foundation, mainly to convince you to pay attention to my point. I will cover some important aspects of open source for institutions, such as software licensing, intellectual property protection, security best practices, and finally, I will talk a little about open governance and communities. The usual disclaimer applies. So let's begin. Hmm, there's a very widespread perception, especially in the blockchain community, that open source is Cypherpunk, right?
We have Vitalik's blog where he talks about making Ethereum Cypherpunk again. And if you've read the Ethereum Foundation mandate, right? There is a lot of emphasis on open source code. But it turns out code. But it turns out that open source code is everywhere source code is everywhere .
So even in a typical closed corporate code base , 90% of the code base of modern applications is open. And if you're interested in these particular facts and figures, we have them all on the Linux Foundation's research website. Be sure to check them all out. And maybe some of you are developers and you build that way. But when people usually build all their applications, they start with an open source framework.
They write a little bit of their own code to put everything together, and they use open source libraries to solve problems. We call it the open source hamburger. And why do they do this? Well, open source has enormous value for businesses. And I'm not going to read all of it, but I hope I can convince you that businesses see tremendous value in open source and working with open source.
And how does it work? Well, there is a kind of virtuous cycle or flywheel around open source software. Open source projects exist, and they are used to create commercial products that are put into production use. You know, they bring money to people, and then some of that profit goes back into the projects. So, it's kind of a beneficial or rewarding cycle around open source software development.
Hmm, but this is especially powerful or amplified when a truly open source community forms around a project. So , here I have a breakdown of Kubernetes, which is a Linux Foundation project. Hmm, contributions by company, and the big drop is Google at the bottom. Uh drop is Google at the bottom. Uh , and you can see that over time their share of the total contribution has decreased.
While their absolute contribution has not diminished over time, it has allowed them to build a large community around Kubernetes, and this is one of the reasons why Kubernetes is so ubiquitous today. Uh, and that's what the Linux Foundation exists for , and that's what we exist for. This is to solve the problem of collaboration for open source work. Uh, when multiple companies or individuals want to collaborate on open source software, but they don't trust one party to own the code, that's the problem that the Linux Foundation solves. And it's always great to talk to blockchain experts about this because they really understand the benefits of decentralization.
I don't want this to be a commercial for LF commercial for LF , but I just want to tell you about the breadth of the Linux Foundation's work. I hope you will take my opinion on open source issues seriously. We have a bunch of projects, maybe some things you didn't know were in the Linux Foundation, like RISC-V, I mentioned Kubernetes. Um, you know, really interesting things like the Academy Software Foundation, which does animation for Hollywood films. Um, we're a huge organization.
I'll just give some numbers here. Um, you know, lots and lots of code, developers, ecosystems. Um, you know, and I just want to show you this, so when I say, you know, we've seen something, um, we have numbers to back it up . And why am I here today? Well, we actually have a lot of Ethereum projects or Ethereum-related projects at the Linux Foundation.
So, there are people here who, I assume, are familiar with Besu or have used Besu. You know, it's something like, um, 15-20% of the like, um, 15-20% of the main network, I guess. Hmm, a bunch of tools, um, and, um, you know, things that are very EVM-related, like, um, Lineth and Hyperledger Iroha. Hmm. So, the point I want to make now is that institutions already know and trust open source software, but you have to make them happy if you want them to use it.
Hmm, and especially in the blockchain space, following open source software best practices can make its implementation much easier. So let's start with this. So, one thing I want to start with is I want to start with is , um, just some important points. For example, what do you need to do right if you want institutions to use your code or use your software? So let's take a step back.
Let's define what open source software is, shall we ? The important thing about this definition is that it is released under license, right? And it's just a legal document that, um, captures and officially expresses a set of actions regarding software. Who here loves software licensing ? Nobody, exactly.
Nobody likes it. Um, but, you know, you'll have to deal with that if you want your project to be used properly. There are three main types of open source licenses. There is a BSL license, a copyleft license, and a permissive license. You may have heard of some of them.
Um, I'll take a quick look at them. So, the BSL license is not technically an open source license. This is an . Um, the code is public, but the use is legally restricted, right? It's essentially, well, you know, proprietary software, but people can check out your code.
Um, and examples of projects in this area projects in this area that you might know about are things like Arbitrum Nitro. Um, it's, you know, useful when you want to create proprietary software, um, but, you know, there are a lot of caveats. Of course, we don't accept BSL licensed code, ahem BSL licensed code, ahem , and other organizations don't necessarily like it either. Um, copyleft licenses are licenses that require users to provide access to all derivative works. Um, so if you modify the code and use it in something else, you need to make all the source code for that something else available for free.
Um, you know, it has great principles, but it's very difficult to use commercially because companies worry that if they use GPL code somewhere, it will be reused somewhere else, and suddenly they have to release every line of code they've ever written. Um, so the goal is to increase user contributions to the code base by requiring them to make a legislative contribution. Unfortunately, people simply don't use your code if there are any viable alternatives due to legal requirements. Um, and I will say that it's very difficult to relicense things to relicense things . The relicensing of OpenSSL is a well-known example of this.
And finally, there are permissive licenses. When you think about open source and being able to do whatever you want with the code, that's exactly what a permissive license covers. We recommend this if you want others to use your code because it's definitely the easiest to use, companies are happy with it, especially if you're using Apache 2. So, we default to permissive licensing at the Linux Foundation. Here are some common mistakes I'll make...
Oh, I hope I don't make them . I'll briefly review, be careful with your addictions. We see that a lot of people, uh, misunderstand or misuse the LGPL dependency. Be careful. Er, and, er, be very careful with licenses that don't have intellectual property protection.
So, one of the reasons we recommend Apache 2 for projects is that it has clear patent grants. And some other permitting licenses don't have them. Therefore, we urge you to be careful. Uh, again , just a summary, if you're, you know, mostly looking at your phone, please pay attention to the licensing requirements, and we recommend that you default to Apache 2. Great.
Um, and I'll just point out what the mandate of the Ethereum Foundation is on this. Um, they also support, you know, copyright licensing. Um , but we've generally found it very difficult to get institutions to use an open source copyright license. Perfectly. So what about other legal protections and intellectual property protection?
I hinted at that. Um, well, open source software developers may inadvertently or maliciously add code that has some form of intellectual property protection. Um, this is what really worries the institutions. They are always worried about patent lawsuits. Um, and um, this is not a hypothetical thing at the Linux Foundation.
If you want to know more, there's been a whole series of lawsuits surrounding this. Um, and that led to us creating what we call a Developer Certificate of Origin, or DCO. Um, whether you use DCO or CLA, it's important to have the appropriate legal framework around your code to address such intellectual property restrictions. And I know that maybe if you work at a startup, this might not seem important, but it's something that institutions will definitely want to know and check. If you're wondering, this is DCO.
This is what it looks like. You can automatically sign it on GitHub. Just, you know, use your commits with the S flag. It's generally pretty easy to do. Of course easy to do.
Of course . So I urge you to have legal protection for your code. We will require some form of intellectual property protection for all LF property protection for all LF projects, and you probably should too if you work with open source. We like DCO, but, you know, you can also use CLA for different things. So let's move on .
Let's talk a little about security. This is obviously a big project. There are several differences in open source, and importantly, institutions will want to be able to verify that you are following security best practices. So the three things I'm going to talk about today are vulnerability disclosure, S-bombs or software bill of materials, and, uh, software authentication and artifacts. I will note that we have a subsidiary foundation within the Linux Foundation called the Open Source Security Foundation.
Be sure to check this out. Here are all the best practices you should follow for security, whether you are an open source project or not, especially if you are an open source project. So be sure to check this out if you have any questions. Uh-huh. So, one of the benefits of open source is that community members can find and report bugs.
You want to make this as simple as possible. Uh, you need a security response team, and you want the institutions to be able to participate, uh, in this process and be very familiar with it. Uh, we have a lot of different ways to do this in LF. Uh, a lot of our projects use GitHub tools. Some projects have very complex pipelines.
So, I think Besu currently has seven reporting channels. I might be wrong on one or two things right now. Uh, but, but this is a more complicated option. How many people know this XKCD? Yes.
Of course, it's become much more difficult lately with all these attacks on software supply chains . You all have probably seen many of them. You know, I could do a whole talk about this, or fill a lot of slides with it. But, uh a lot of slides with it. But, uh , software supply chains are really problematic.
And this is very important, what concerns the institutions. If you just look at these numbers, it's just scary, isn't it? So, Black Duck annually audits the most important open source software code bases. Last year at this time they reviewed 1000 code bases. 81% of them contain high-risk or critical vulnerabilities critical vulnerabilities .
That's, uh, pretty bad, isn't it? You know, when you have a dependency on an open source library with a critical vulnerability. You know, old open source components, you know, you need to update your dependencies more often than every 4 years. So the way we solve this, and the way that, you know, institutions will particularly like, is through programmatic lists of materials lists of materials . Hmm, this is essentially a kind of dependency tree of all your, uh, code that you've ported into your project.
Hmm, we encourage you to track all your code. Uh, and be very careful with the dependencies you use. Hmm, you know, it's ideal to have as few dependencies as possible. And in many cases, it 's worth making the effort to rework something, uh, rather than having it as an addiction having it as an addiction . There are many good tools to help you with this.
Uh, there's the Squawk tool, and there's a bunch of things you can check there. Perfectly. And finally, uh, if you create a popular project, people will try to impersonate you. I'm sure people in the audience have come across , you know, rogue NPM rogue NPM packages or Rust packages or Rust crates or something like that, where people try to, uh, create something similar to your project to get people to install malware. We get this all the time.
Uh, but we encourage you to use tools to sign and authenticate, uh, artifacts. Six doors is a artifacts. Six doors is a great tool if you haven't seen it yet . Very useful for authenticating your project. And finally, I'll say a few things about AI.
You may have seen some news recently about all the AI attacks. You know, I'm sure everyone here has seen it. This makes security management very difficult, but we recommend having a policy for AI participants. The Linux kernel AI participants. The Linux kernel is an example of such a policy.
And we recommend considering publicizing security bugs reported by AI. This makes managing your security list much easier. And it's unlikely to lead to new attacks because enough people have access to these models, so you can consider the bugs public. And finally, I will say that verifiability is important. So, just being able to show institutions that you are following best security practices is extremely beneficial.
We have a scorecard on OpenSSF. I definitely encourage everyone to check it out. It is very easy to set up, especially if you already follow security best practices. Perfectly. And finally, I want to talk about management.
One of the things the Linux Foundation does is define and establish open governance for projects. If we go back to our definition of an open source software license, right? The key phrase at the end is a key phrase at the end is a joint public approach, right? And this is what allows large and diverse communities to form around popular open source software projects. And this allows people to contribute to and benefit from these projects.
So when we talk about open source software and open source development, it actually gets mixed up, but we're actually talking about three separate things. We have open source code, which is just code. We have open development, which means the community builds on open source code. And finally, we have open governance. And that's really when their procedures and roles for the community, uh roles for the community, uh , decisions and priorities are regulated openly are regulated openly , uh, like a roadmap .
So, there are many different types of open source governance. Uh, I'll cover four broad categories here. First, we have a public demonstration. And that's just when someone puts code out into the open, right? This is a code dump.
Um, and you know, as many of you probably know, you probably don't want to build based on a code dump. And institutions don't do that either. The next option is kind of an open product, right? Imagine a company or organization that opens up the source code of a software but does not allow external contributions. But maybe it shows a roadmap, you know, regular releases and follows security best practices.
Some open source projects operate as a benevolent dictatorship, where an individual or company opens up the source code, they allow contributions, but the ultimate authority is this benevolent body. I use that in quotes for a reason. And finally, there is true open governance, right? This is code with transparent documentation, meritocratic management. We have this concept called doocracy, where those who do something get the right to decide, and management rights are distributed in proportion to how much you do.
And these projects are very inclusive. Anyone can join and contribute, and there is a clear path for leadership. So, I would say that institutions are much more likely to accept your project the more open it is. Uh, open management helps avoid vendor lock-in. It provides a guarantee of long-term safety and reliability of the project.
Uh, and people will just trust you more if your open source project is open to the government. And, uh, finally, I will say, you know, whatever management model you choose, it's very important to document your management. This is how people trust you and understand the consequences of using your software. Okay, I think I'm out of time on this, and I have a slide for questions, but I don't think I've been allotted time for questions. But I will be there .
So if you have any questions, just come, please come, please , find me, send me an email, and email, and , uh, thank you very much for your time.
Automatic transcript — names and jargon may be misspelled.
