 Hey everyone, thank you for coming to this session. My name is Ravi Devineni. I'm a senior director of engineering for a team that leads Cloud and DevOps at Northwestern Mutual. I'm honored to be joined by Shantanu Singh, who's our assistant legal counsel. We're here to talk about open source and how large fintech organizations can reap the most benefits from open source. To the standard disclaimer, all the content discussed here is the opinion and experiences of the speakers and does not represent any specific company. A little bit about Northwestern Mutual. NM is a financial services company headquartered in Milwaukee, Wisconsin. We started as a mutual in 1857, established for the benefit of our policy owners. Today, 165 years later, we're a Fortune 90 company with more than 4.9 million clients. We're still a mutual though. We have a unique culture deeply dedicated to helping people achieve financial security. Northwestern Mutual is the largest direct provider of individual life insurance in the US. We have high degrees of customer satisfaction with 97% of policy owners staying year after year. In addition to that, we're working on some amazing technologies in Cloud and DevOps and open source work and some very challenging problems to solve. We have been trying to bring digital transformation to a 160 year old company. And we're a very inclusive and diverse workplace. The agenda for today, we're gonna talk about what open source means for a fintech organization and what are the various benefits and the pitfalls and some of the ways that we have found useful to navigate these pitfalls. Shantanu here is a lawyer and I'm an engineer. So with each of these, we're gonna approach this from two different angles, bringing two different perspectives, one from a legal standpoint and another from an engineering standpoint. We'll also talk about our lessons that we learned in this journey. We'll start about benefits of using open source from a legal standpoint. Shantanu. Thanks Ravi and thank you, Linux, for extending the invitation for Ravi and I to speak today. Open source technology has the power, as we all know, to reshape our understanding of property rights by emphasizing the importance of community-driven innovation. In contrast to traditional property rights, which are often built upon the idea of exclusivity, the open source philosophy fosters a sense of belonging and collaboration, allowing individuals and organizations to work together towards a common goal. In the world of intellectual property, open source licensing is a game changer. How? It breaks the mold of the typical ownership structure. This novel approach, found in open source licensing, offers a more flexible and adaptable framework for granting permissions for use, adaptation, and sharing of creative and derivative works, which encourages a more dynamic and innovative environment that encourages the recombination of unique ideas. The open source model's emphasis on community involvement and shared responsibility can lead to the development of robust, reliable, and efficient solutions. By pooling resources and knowledge, open source projects can tap into the collective intelligence and expertise of contributors from various backgrounds and disciplines, resulting in a wealth of diverse perspectives and ideas. In the financial services, this is no different with the advent of fintech technology and the advent of research and design into interoperability of APIs between different financial institutions and the concept of data ownership and the concept of open banking. If we go back to open source more generally, open source is approached to property rights, as previously mentioned, can actually enhance the development process by reducing development cycle time, creating intellectual property that is actually more accessible, more reliable, due to the many eyeballs that have been on the project. Ultimately, this will lead to higher quality products and services. Open source models can also inspire new ways of thinking about collaboration and resource allocation. By challenging the traditional notions of ownership and control, open source projects can lead at one side of the spectrum to greater participation of folks who do not have to be employees or subcontractors to a project, but also into innovative partnerships, joint ventures, and cooperative efforts that leverage the strengths of multiple entities for the greater good. I'd like to conclude this slide by just re-emphasizing that open source technology has in a very great way redefined property rights and as it develops and matures, this concept of what it means to own code or to own technology is changing. Back to you, Ravi. Thank you, Shantanu. The first and the foremost benefit from an engineering standpoint is that it's faster time to market, right? We don't want to write everything from scratch, right? Companies benefit from having their employees work on what provides them the most business value, but as a part of application development, there are many standard things such as operating systems and content management and authentication, database connectors, making HTTP requests. These are standard problems that every company needs to solve no matter what kind of applications they build. And there are many established open source solutions that solve for such problems. Using these solutions essentially frees up the engineers to work on niche problems that an organization needs them to solve. Now, since we're using components, established components for standard problems, it becomes cost-effective, right? Most of the open source has no licensing fees. This creates a pretty big advantage when you consider the total cost of ownership. Transparency is obviously another one, right? When you go look at an open source component, typically all the code isn't GitHub in a repo for everybody to look at, not just the code, right? But the contributors, the number of open pull requests, number of open issues, bugs, it's all there for anyone to see. You can, in theory, see exactly what you're getting. And the power of community is a major factor too. And there are a lot of organizations that support open source movement. Linux Foundation, for example, the very fact that we have a major conference to promote open source is a pretty powerful thing. Not only Linux Foundation, we have Apache Foundation, we have CNCF. If you go to opensource.com, you can find an exhaustive list of these nonprofit companies that support this initiative. Many companies like Google and Facebook also support open source. In addition to all of this, we have thousands of passionate engineers creating components and contributing to solve all kinds of real-life problems. And finally, recruiting, right? Every organization wants such passionate engineers. Companies want programmers that solve problems, right? Programmers that get a lot more gratification just by solving a problem and less by the material reward involved. So companies using open source software can definitely attract such talent. Now let's talk about the other side of the coin, right? Problems with using open source. And we'll start with the legal perspective. Shantanu. Thanks, Ravi. As we've mentioned earlier, open source has great benefits. But like with anything, there are downsides that you have to manage, which from a legal perspective can best be understood if we see property rights, traditional property rights as a bundle of sticks where each stick represents a right or permission that if given to somebody is essentially a grant that you have a right or permission to do something with that intangible property right or tangible property right. In the past, that bundle of sticks has been more of an all or nothing game or it's been one where to get that stick you actually have to pay money. Whereas with open source, even though that concept still exists, what motivates the transition of one stick to another person is the concept of community-based development. The rights and permissions of a project are premised on what the community needs and what the collaboration needs rather than what a cost center or a profit center needs. This bundle of sticks analogy in open source licensing provides, in my opinion, a more fluid and adaptable framework for intellectual property management that is premised on the needs of the community rather than the need for revenue. Each stick and the bundle corresponds to a particular right as previously mentioned. And if you separate these rights and allow creators to selectively grant or withhold them based upon what the community needs and based upon what's best for the community, that will foster this community-based innovation that we've been discussing. A great example is the Afaro GPL license. That community-based need is the innovation to build very complex, very transformative software applications, but not so others can monetize it at the expense of community work. That concept of working off of the collaboration of others and monetizing what in essence, from those who seek to monetize it as free labor is an element of this bundle of sticks concept of where a specific right on distribution has been curtailed. So this versatility in open source licensing, in my opinion, encourages the growth of diverse and thriving communities that are adaptable to the changing needs of consumers, the changing need of the end user of the software. And this adaptability is fact dependent and circumstance dependent. And open source is well suited for having that type of flexibility. If we look to the bundle of sticks analogy further as an approach to property rights, we can also see that if we as a community are able to grant specific rights in some circumstances and other rights in another, it does create a diversity of ideas and perspectives, but it also creates a diversity of dependencies which can create some form of legal risk for a community that is not cognizant of how they are building their project with dependencies related to others. Thanks again, Ravi. When considering the implementation of open source software, let's say the Fintech project, it's essential to evaluate several key aspects to ensure compliance and minimize potential risks. If you have a solid understanding of these factors, you can make informed decisions about whether the open source project is suitable for your organization and how it may be suitable. I don't want to turn this presentation into one that's heavy on legal analysis, but there is a certain thing that we do have to consider which is what is, excuse me, what are the different types of open source licensing frameworks? As presented on this chart, you can see that on one side of the spectrum, there is a group of permissive licenses and then on the other side, there's ones that are strongly protective. And on the permissive side, you essentially get most of the sticks in that bundle that you want. On the strongly protective sides, the sticks that you get likely are very selective. They're not representing the entire bundle, so it's imperative for end users and communities that are users of open source to understand what those permissions and restrictions are. After you evaluate your legal rights and permissions and obligations, which could include attribution and an obligation to contribute back, your code built by you or a corporation after you've cleared those hurdles and understanding, the next thing to do is to evaluate your dependencies. Is the open source you want to use dependent on a wide variety of other projects? Once you understand the scope of what the projects that you would like to rely upon are governed by and also understand from a functionality perspective of whether those open source components represent points of failure or security risks because they are not meeting a persona of what constitutes a reliable project that could be based upon your risk tolerance or the company's risk tolerance, a threshold of specific number of contributors, a specific frequency of pull request, a specific frequency of force, reading the newspapers and other industry journals to see how reliable the software is and whether that software will present any security risks. Once all that's clear, you also now have to look at your product's deployment strategy. As you can see in the graphic, there is a concept of network protective licensing where communities understand that the software developed is very powerful, but however, they do not want others to use that software to monetize it for personal gain or for corporate gain. So what does this require on your engineering teams? Well, from a legal perspective, there should be training and socializing concepts to these engineering teams if you're a corporation and if you're an individual doing some self-directed learning to understand the principles of open source and where there are different types of permissions and different types of obligations and the associated risks with each of these concepts. The goal is to make informed decisions, maximize your success and minimize the downside risk that requires an understanding of some of these legal principles and the general legal framework that open source puts forth in how that is distinct and different from proprietary commercial rights which are more exclusive than inclusive. If there is a collective understanding of these concepts, the likelihood of project success, whether for your own individual product or for an organization's project, that success and the probability of that success increases. Back to you, Ravi. Thank you, Shantanu. From an engineering perspective, the biggest problem of using open source is the security risk it poses. There are thousands of vulnerabilities that exist in open source software and these vulnerabilities are made public knowledge. Equifax, for example, it's a very well-publicized case. 150 million people's personal data got exposed. That's pretty much every single adult in the US. That's all of us. Equifax had to pay 1.4 billion to get out of that. The reason that happened was Equifax had a version of open source component, Apache structs 2.2 or something. They had a vulnerability that was discovered in 2017 and they never patched it. And sure enough, it got exploited. And this is just one example, right? If you start looking, there are several such cases that happen all the time. So a lot of the security vulnerabilities, the question becomes, can we actually trust open source software? How reliable is the source? There's a style of supply chain attack called next-gen attacks, right? There are some pretty evil people out there who take the initiative and actively inject malicious code into all these public open source components, repositories. So every time a distribution or a download happens, their malicious code gets injected into various places. To these people, right? The major open source repositories like Docker Hub, Maven Central, PyPy, they are reliable channels for distributing their malware. Remember the whole concept of open source is built on this idea of trust, right? With thousands of contributors, it is very hard to distinguish between a good actor and a malicious one. So if you read about the breach about solar winds and back from 2020, this is exactly what happened there. Many of these dependencies use some kind of versioning and there's active development happening on many components. Now there are direct dependencies and then there's dependencies of dependencies, also called as transitive dependencies, right? It goes many levels deep and it's super complex. The need for updates in patching is constant. If you don't change your application at all, your application can become quickly vulnerable. This is what happened with Acrofax and support also, right? That's a problem. If we run into some issues with some components, what do you do, right? We can make an issue in GitHub and hope it gets fixed or we could contribute ourselves and hope it gets accepted. There is no active support for any of these open source components. With all these issues, it begs the question, is open source really free, right? What is the total cost of ownership? But it's not all bad news, right? I mentioned many nonprofit organizations working tirelessly to solve such problems. So we'll talk about a few solutions here. So we'll start from an engineering perspective. So first, every company needs to know what open source software they have in use. Without that, they are flying blind, especially large companies that have been doing technology for many decades. Things grow organically, like a forest, right? Like how do you take inventory of a forest? It's a hard problem, but it is definitely something that needs to be solved. And not just the inventory, right? But a complete line of sight into what open source is being used and where and what versions are we using? How current are we with those versions? If a vulnerability gets detected, we need to be able to exactly pinpoint what parts of the company's code base is affected, the impact radius, right? All of this allows us to respond very effectively when new vulnerabilities are discovered. If you don't have an open source inventory, this is where you start, right? One of the ways to do this is to scan your SCM system. You can scan all the repos and extract dependencies and map it all out. Next is software bill of materials, right? A software bill of materials, SBOM, is essentially a list of components that make up your software, right? Simple. It's basically a document that has various nested parts. The standard format for it is called SPDX, but it can be created in a nested JSON as well. If you know precisely what components are in your software, you can get a clear vision of the risk involved. But how is it different from the inventory we talked about earlier? Inventory is the macro. What are all the dependencies that are used at my company across all of my software? SBOM is the micro, right? At a specific application level, what exactly is involved in my software? There are various open source components that generate SBOMs, right? SIFT and I've named a few here. Next one is security scanning of the dependencies. In 2022, there have been over 25,000 vulnerabilities that have been discovered. It's close to 8,000 in 2023 already. This averages to about 68 vulnerabilities being discovered every day. That's 68 new vulnerabilities being discovered every single day. We need to be ahead of the game. We need to know exactly what vulnerabilities live in our ecosystem, right? This scanning needs to be embedded into your CI CD pipelines with the ability to block a release when certain high vulnerabilities are detected. How do we do this? Several tools can help. There's an OVAS project in the mix too, some commercial tools and this is not an exhaustive list. Again, each one of these tools have several pros and cons. You just need to figure out which one is right for you. Next one, health score of dependencies, right? Not all the open source components are created equal, right? Like you can see some stats here, 75% of the code bases have at least one high vulnerability, 88% of the code components have been essentially abandoned, right? In such an environment, the question really becomes, how do we pick a good open source dependency for use? Open source OSSF has a project called Scorecard. It's an automated tool that evaluates the component in various areas and assigns a score. Some of the areas are, does this component have UCI best practices, for example? Or is it maintained actively? Does it have branch protection? What vulnerabilities does it have, right? Are the dependencies pinned, for example? And if you look at various such areas and we can come up with an overall score and this is a very useful tool for determining whether to determine whether a dependency is healthy or not. The next one is to centralize all ingress, right? Like once you do the analysis, you create your own block list, right? A list of components that must be blocked from entering your ecosystem. Once you do that, you have to centralize the ingress too. There should only be a single entry point for all the open source software for entering into your ecosystem. It's possible the developers today are downloading components on their local. It's possible various build systems are doing that. We just cannot have so many, right? We need one. We, you need a single entry point that's, so if you have a single entry point, it's easy to create a gate of sorts, right? A simple rule that blocks dependencies if they are on the list. This is essentially a dependency proxy, right? Several tools support this feature, a GitLab, Artifactory and all of those. Now let's talk about some of the legal aspects of dependencies, Shantanu. So what are some of the risks that can be presented by an open source licensing framework? And what is it that can be done by the community and the end users to manage that will be the subject of my further comments throughout this presentation. As we discussed, open source can provide multiple benefits due to its inherent openness, but that inherent openness can also lead to legal challenges and intellectual property risks. How is that? As we mentioned, the flexibility that's offered by only giving specific sticks out of that bundle for the purposes of what that community needs and for the purposes of what that collaboration should look like for a given project is also a predicament where if end users or contributors or colleagues, other interested parties fork source code from those projects without an understanding of what sticks were given to them, they open themselves up to inadvertently infringing on certain copyright laws through their modification or distribution of open source works when they didn't have the necessary permissions. So there's also the risk of proprietary technology becoming open source unintentionally. What does that mean? Well, for some parties, they would like to mix open source code with proprietary source code. And this is not a theoretical example. We're all aware of the various issues that developed with hypervisors and Linux drivers and router firmware, as well as software API integrations and standardizations. Because of the lack of the clear boundaries of what was open and what was closed, it led to a great deal of confusion and legal risks manifested for some parties where they had to disclose their code as open source or their frameworks as open source in contravention to their perspective, which was using those rights to generate revenue through proprietary licensing models. Now, open source technologies can also be subject to compliance surprises that may disrupt functionality and negatively impact the consumer experience. The open nature of these projects can make it difficult to control and monitor contributions leading to unexpected issues arising from the integration of non-compliant components. What is non-compliant? Well, it could be code that is not allowed to be contributed to other projects. It could be proprietary code that has been contributed to an open source project, therefore creating security risk and intellectual property risk of the original licensing owners. However, people and companies have successfully created licensing models to get the best of both worlds. The open source model and the proprietary model and that has been commonly referred to as dual licensing where a product is offered under both an open source license and a commercial license and it usually plays out with open source software, getting a great deal of traction within corporations or within the general public. And because of this open source adoption, it serves as a signal to the maintainers of the project that there is an opportunity to monetize the product with services and maintenance. Well-known examples exist in the marketplace for this type of dual licensing model. In conclusion, while the open source models inherent openness presents legal challenges and intellectual property risk, careful management of these risks and a clear understanding of the rights associated with these risks is very critical to have as a foundational principle of any open source community and any open source user. These risks are within your control and management. And if you are able to navigate what can sometimes be a complex landscape between open source and proprietary technology, businesses will be able to leverage the benefits of open source while minimizing its legal pitfalls. Back to you, Ravi. Thank you, Shantanu. So in all of this, there are some key lessons that we learned and this is the crux of our message. Open source has so many pitfalls that if an organization is going into this unaware, they could be facing some serious consequences. It's only a matter of time. Organizations, especially fintech ones, need to be approaching open source very consciously. Having an enterprise policy is a must. An enterprise policy that basically outlines what is your stance on open source? What is your acceptable usage policy? What is our risk tolerance? And who are the decision makers and who are the parties with accountabilities? And all of this helps tremendously. Once you have a good policy, that's a good start, but a policy is just a document. A document doesn't really do anything. There needs to be some strong governance around this. For example, if you have an accepted usage policy and there are teams that are violating that policy, there needs to be accountability. Next, automation is the key. There are thousands of dependencies that teams use to build software. There is no way that a team or a change committee can review all of them. The process needs to be as automated as possible. Automated governance is the only viable way to implement a governance process for open source. And finally, Shantanu already touched upon this a bit, but he will speak about the critical part. Lawyers play with all of this. Shantanu. Thanks, Ravi. In conclusion, lawyers can support DevOps team in somewhat critical ways. One is they can advise the team as to what are the legal obligations of an organization for risk management and cybersecurity management. Can rules be developed to not put code into production that does not meet an individual or an organization's risk tolerance relative to cybersecurity risks? Second is as to licensing. What is the organization or individual's risk tolerance for the types of licenses that project is willing to depend upon for whatever purpose that project and software is intended to accomplish, whatever that value proposition is to its consumer base. In conclusion, we would like to thank the Linux Foundation for inviting us, Ravi and I to give this presentation. We hope you've come away with foundational knowledge from a wide variety of perspectives that can help the audience and those who watch this manage their open source projects in creative, effective ways to maximize the opportunity and reduce the risk of your efforts. Thank you.