At the upcoming Open Source Summit in Los Angeles, Lars Kurth, director of Open Source Solutions at Citrix and chair of the Advisory Board of the Xen Project at The Linux Foundation, will be delivering a wealth of practical advice in two conference talks.
The first talk is “Mixed License FOSS Projects: Unintended Consequences, Worked Examples, Best Practices” and the second talk is “Live Patching, Virtual Machine Introspection and Vulnerability Management: A Primer and Practical Guide.”
Here, Kurth explains more about what he will be covering in these presentations.
There are thousands of open source licenses, and some are incompatible with each other. What are the issues about mixing licenses that you will be discussing in your talk?
Lars Kurth: License compatibility in general is fairly well understood. One of the areas I am focusing on in this talk, is that lots of open source projects start off as single license projects and over time additional licenses start to be incorporated into the codebase. This is true for many open source projects such as the Linux Kernel, QEMU, the Xen Project, the BSDs, and many others.
What most projects fail to do as new licenses are added is evolve best practice around mixing licenses as new licenses are added. This can lead to barriers for license and patent conscious adopters or contributors of a specific project.
For example, in the Xen Project, we came across the case where an organization’s IP lawyer wanted to know answers to questions like why certain licenses existed in the codebase, before they would approve code contributions by their employees. The whole process took more than half a year and was extremely painful, but it prompted us to introduce a set of Best Practices, so we would never have to go through such an exercise again.
Are there any examples of mixing licenses that can lead to disaster?
Kurth: Thanks to FOSS license compliance tools, such as FOSSology, we rarely see FOSS stacks that contain incompatible licenses. What does happen, occasionally though, is that licensing constraints can limit the ambition of open source projects. A high-profile example was Hyperledger’s attempt to include Ethereum’s C++ client, which ultimately failed because it would have required re-licensing some of Ethereum’s runtime from GPL-3 to Apache 2.0.
In projects that contain components with multiple licenses, choosing a component’s license without appropriate foresight can lead to situations that requires re-licensing a component to implement a new feature. The risk of this happening is high, when code refactoring is required. The only way to avoid this is to treat the license of a component like an architectural system property. Because re-licensing a component in projects with multiple licenses can’t be excluded, I will walk through a worked example on how to do this in my talk.
As Open Source is taking over the world, what risks do you see of mixing licenses? What else can people look forward to in your talk?
Kurth: This talk will highlight some risks and solutions to the problem of adding additional licenses as projects grow. One thing that I also think be really interesting is the risk of mixing GPLv2 code with GPLv2 or later code (GPLv2+). Linux for example contains 14 percent of code licensed under GPLv2+. Many projects unintentionally or even unknowingly do this without understanding potential consequences. To find out more, come and see the talk!
Let’s focus a bit on your other presentation. Why is live patching important?
Kurth: The importance of live patching of the Xen Project Hypervisor came to light when several cloud providers including AWS, Rackspace, and IBM SoftLayer had to reboot large numbers of servers in their fleets in late 2014 and again early in 2015 due to two Xen Project vulnerabilities. Applying security patches is not an easy task when thousands of servers running critical business applications require a reboot after a patch has been applied.
Hypervisor reboots inconvenience cloud customers, which is why the Xen Project developed Hypervisor Live Patching — first released in June 2016. This enables Xen users to apply security patches in real-time, without reboots, power cycles, or workload migrations.
What will you be talking about in regard to live patching?
Kurth: The process of patching a live hypervisor or kernel is not an easy task. What happens is a little bit like open heart surgery: The patient is the hypervisor and/or kernel and precision and care are needed to get things right. To do this safely requires expertise and appropriate build and test capabilities. In this talk, I will cover how Hypervisor Live Patching works, and how Live Patches are built and tested. I will also show how XenServer combines Linux and Xen Project Hypervisor Live Patching in a combined and easy-to use solution.
Besides Live Patching, we will also give a brief overview of the Xen Project Vulnerability Management process and how it was impacted by the introduction of Live Patching. In addition, we will briefly introduce Virtual Machine Introspection, which has been shown to detect and protect users from 0-day vulnerabilities such as EternalBlue.
Check out the full schedule for Open Source Summit here. Linux.com readers save on registration with discount code LINUXRD5. Register now!
