Share

cover art for Are Legislations Good or Bad for Open Source?

My Open Source Experience Podcast

Are Legislations Good or Bad for Open Source?

Season 2, Ep. 7

Governments around the globe have been recognizing that open source code is a core dependency in every modern software solution. Whether or not it is a good thing that is still a question. But one thing is for sure, if you are involved in an open source project or selling a product or service that depends on one, this will affect you!


In the commercial world, when something goes wrong with a product or service that a company provides, the company is liable for damages. So, what happens when a solution that contains open source code fails? And especially, what happens if the bug or vulnerability was introduced by the open source component? Who is liable? Is it the developer? Is it the open source community? Is it the company who used the code? Or?


In this episode of the My Open Source Experience Podcast, Ildiko and Phil are chatting with Amanda Brock. Before becoming the CEO of OpenUK, Amanda used to be a lawyer. With that background, it is no surprise that she keeps a close eye on the legislations and regulations that governments have been creating around open source. The group talks about this ongoing work, and how this affects people and companies in the ecosystem.


In this episode, you'll learn more about topics, such as:

- CRA (Cyber Resiliency Act)

- PLD (Product Liability Directive)

- The challenges with some of the current regulations and what to look out for


It is crucial to help government officials and regulators understand the methods, processes and dynamics of open source communities and overall ecosystem. Everyone who's part of this ecosystem plays a role in educating those who don't have the expertise and the experience, including YOU!


Amanda's books: https://amandabrock.com/books/

More episodes

View all episodes

  • 8. Reasons Why You Have to Work Upstream

    45:25||Season 2, Ep. 8
    If you do open source right, you get a lot of benefits, both as an individual and as a company or orgnization. On the other hand, misconceptions about open source often lead to bad decisions, where everyone in the ecosystem suffers.Hear from experienced members of the ecosystem who you need to get involved, what to look out for, and how to approach your involvement the right way!In this episode:Amanda Brock lists some of the biggest benefits of getting involved in open source as an individual, such as access to knowledge and new information first hand.Wayne Starr has been working on oepn source projects as part of his job for years. He shares his experience with different configurations to allocate his time to upstream work, which has been ranging from 100% all the way down to 20%.Clare Dillon shares a story to highlight how budget allocations can discourage teams within companies from collaborating, and how to approach this challenge when it arises.Stephen Walli explains the challenges the open source ecosystem is facing when approaching to secure the software supply chain, and examples to efforts to address them.Gregory Kurtzer introduces Open Enterprise Linux Association (OpenELA), and talks about the importance of having non-profit organizations to protect open source software and communities.
  • 6. Building and Maintaining Large Open Source Communities

    45:46||Season 2, Ep. 6
    In this episode of the My Open Source Experience podcast, Gregory Kurtzer shares his experience in creating and guiding multiple open source Linux operating system projects.Have you ever wondered why there are multiple Linux distro projects in the open source ecosystem? What goes into creating a distro once you have access to the kernel? Gregory shares his experience creating multiple projects, and shares how the motivation and process were different every time.Also, have you thought about what would've happened if Linus Torvalds had went on to work for a corporate organization as opposed to the Linux Foundation? Well, for a little while he did, and that caused a big disruption in the ecosystem, open source and commercial alike. This example shows very well why you cannot leave the control in other companies' and individuals' hands, when you have hard dependencies on open source projects, and also gives you a hint why single-vendor projects are significant risk factors.Learn more about why and how community has been key to the success and longevity of the Linux kernel and operating systems to reach the popularity and significance they have today, why non-code contributions are crucial to the sustainability of the ecosystem, why your open source project needs marketing and ecosystem development, and more.
  • 5. How to Successfully Argue for Open Source Investment

    41:29||Season 2, Ep. 5
    We can establish that if you are using any (semi-)modern digital infrastructure or applications, then you are depending on open source software. Have you ever thought about that as actual dependency? Considering that you are not neglecting the building blocks of the software solutions that you are creating and selling, why do you do that with your open source dependencies?Learn more about why you have to invest in open source projects and how to decide what level of involvement you should have in each from Stephen Walli.Find out what drives companies to open source projects that started out as InnerSource, without the intention to open them up to the world later, and what happens when you don't let your developers work on open source projects anymore from Clare Dillon.Learn how to explain open source involvement to people who are fearful and sceptical about it from Wayne Starr. And listen to Wayne and Stephen to talk about how they and their companies are using SBOMs, and why you need to think more about using those for packages that you need to build, or hardware, before you apply the concept.
  • 4. FOSS Makes a Difference, Even in the Military

    51:34||Season 2, Ep. 4
    Have you ever wished your company was moving faster with developing new solutions? Or, that maintaining software wasn't such a huge burden?In this My Open Source Experience podcast episode Ildiko and Phil are talking to Wayne Starr. Wayne shares his experiences, related to open source throughout his career up until today. From discovering FOSS as a kid, through working for the U.S. Air Force to joining Defense Unicorns for the specific reason of working on open source software full time, which has been allowing him and his company to move faster, produce more reliable solutions and share knowledge more efficiently, all at the same time.Using open source software is a great first step, but to gain all the benefits, one has to invest and get involved in the projects. Wayne shares tips and tricks on- how to advocate within your company for investing in and contributing to open source projects,- what to do when you face greater resistance than what you think you can handle- how to build and advocate for an open source projectand more!
  • 3. Open, Collaborative SW Development, Why and How

    48:52||Season 2, Ep. 3
    Did you know that collaborative software development existed before the term 'open source'? Do you know what important role open source foundations play in the ecosystem? Do you understand the difference bewteen 'upstream project' and 'downstream product', and why it matters?In this episode of the My Open Source Experience podcast, Stephen Walli talks about how software development, and the various industries depending on it, have been evolving. Stephen shares the process of creating an open source project, and then a community around it, how open source foundations protect open source porjects as well as the ecosystem around them, and shares a collaboration example from the Eclipse ecosystem. The group also touches on the importance and challenges of culture change within industries and companies alike.
  • 2. The Secrets of InnerSource

    44:37||Season 2, Ep. 2
    Did you know that you don't need to work in a public environment to practice open source methods and practices? It's called InnerSource, and your company can start practicing it today!Just like open source, InnerSource also has its rules and practices, which you will need to follow if you want to succeed. For example:- You might need a license for your InnerSource project- Just because it's internal, it doesn't mean your project doesn't need to be advertised- Building a community around your project isn't straightforwardIn this My Open Source Experience podcast episode, Ildiko Vancsa and Phil Robb are chatting with Clare Dillon about InnerSource, including good and bad practices, challenges and experiences. The group also discusses parallels between InnerSource and open source and highlights issues that still need solutions in both ecosystems.
  • 1. Introducing Season 2

    37:06||Season 2, Ep. 1
    This episode of the My Open Source Experience podcast kicks off Season 2! Ildiko and Phil talk about news and highlights of what happened in the open source landscape in 2024, focusing on the time period since the last episode of Season 1. They also share what topics are coming in Season 2!
  • MOSE Shorts - 15: Don't Make These Mistakes When Using AI

    08:03|
    Did you know that you will need to spend more time and effort doing code reviews before using AI-generated code?AI is heavily utilized in work environments already, it enhances efficiency and productivity. But, it can also be an increased risk factor in your company or open source project, if you are not careful.In this MOSE Short segment, Aeva Black, Ildiko and Phil talk about the risks that come with using AI, if people try to cut corners and trust the tool blindly. For example, have you ever merged code in a rush? You might know the person who submitted it, or it looked good at the first glance and you didn't have the time to dig deeper into it. While humans also make mistakes, when you know someone's work you have some reassurance that they will keep the quality standards that you are used to. We often trust machines the same way, as we are used to the deterministic output that most tools produce. AI, however, while it is a tool, you cannot predict the output it is creating and you also cannot trust it. Aeva describes an example where there was a security vulnerability hidden in the otherwise good looking, AI-generated code. The group also discusses further social implications of using AI to generate email responses or convincing, but fake content.