The open source software community has gone through it's share of shocks recently. The first of these latest rounds coming in the form of projects relicensing their software from open source licenses to business source licenses, sometimes known as BUSL licenses.
This was first started with MongoDB in 2018, followed by ElasticSearch in 2021, and then recently by HashiCorp and Redis in 2024. The core issue at the center of these open source relicenses is the perceived lack of contribution to the project by companies with means, specifically large cloud providers, that offer their own hosted version to their customers.
The companies that have chosen to relicense in this manner view the actions of the cloud providers as threats to their own ability to build a business on top of their open source project and the relicensing is an attempt to curb that threat.
The actual lack of contribution to these projects by the large cloud providers is a bit up for debate and something that I'm not going to address in this post. That said, it is a common reason that is cited for the change so I think it's worth mentioning.
The relicensing issue is something that has been slowly boiling in the background for a little while now sparking debates about the longterm sustainability of open source in the current economic environment and tech ecosystem. The recent event with xz and liblzma has really brought the sustainability conversation screaming to the forefront with renewed energy and urgency.
On March 29th, 2024 CVE-204-3094 was published alerting the wider Linux community to a backdoor vulnerability in liblzma that had made its way into some upstream linux distributions. This vulnerability targeted SSH via liblzma and if it had made it to wide distribution would have been a MAJOR issue for large amounts of the servers that run the internet. There is a lot of depth to the liblzma exploit but for this video the important thing to focus on is HOW the malicious actor, JiaT75, was able to get the malicious code into liblzma in the first place.
To pull this exploit off required a lot of time and patients on the part of the attacker. The entire timeline of the attack began in early 2022 and went on until it was finally discovered in March of this year. The interesting, and frankly alarming, thing about this attack is that it didn't exploit buggy code in the wild but first infiltrated the project itself and then worked on getting the malicious code commited to the project.
The initial infiltration, gaining the ability to commit to the project, was done via social engineering attacks on the sole maintainer. This was accomplished by pressuring the maintainer of liblzma to integrate new pull requests via good cop-bad cop, posting on email lists ratcheting up the urgency of a change and then swooping in posing as a new, helpful, face to take some of the pressure off of a clearly overwhelmed maintainer. At this point the bad actor was given commit access to the project and the exploit was underway. The only reason that this good cop-bad cop method of pressure worked was that it leveraged behavior exhibited by users of a project that is seen by open source maintainers all the time.
At this point you're probably thinking, "What does re-licensing and the infiltration of a library used by Linux distributions have anything to do with each other or the sustainability of open source at large?". The answer to that is OWNERSHIP.
The ownership I'm talking about here is not of the legal variety but of the communal and personal. Viewing the long term trends of open source as well as looking at specific examples of issues like liblzma it's pretty clear to me that open source has an ownership problem. Users of open source software don't feel any sort of communal or personal ownership towards the projects that they use and depend on. This is clear in how some users treat maintainers. More like a retail clerk to boomer style scream at rather than a fellow human to collaborate with to solve a problem. This behavior stems from users viewing open source projects like a paid for product than a community resource.
This phenomenon has really ramped up in the last 10 or so years of open source riding on the proliferation of package registries and package managers. In the early days of the free software and later open source movements it was clear that the software that was shared was a community resource. I think this was largely driven by the fact that to interact with and use open source software you had to have your own copy of it. This requirement to have your own copy of a dependency provided downstream users of a project more agency than if it was delivered via a package registry.
If we want to ensure the sustainability of open source into the future first we have to change the culture of how we as users engage with open source. We need to take more responsibility of ownership ourselves AND foster that responsibility in others around us. This change lies with us not the maintainers or companies sponsoring the work. If we don't make this change the landscape of open source will look very different to what we have enjoyed to this point.
This was first started with MongoDB in 2018, followed by ElasticSearch in 2021, and then recently by HashiCorp and Redis in 2024. The core issue at the center of these open source relicenses is the perceived lack of contribution to the project by companies with means, specifically large cloud providers, that offer their own hosted version to their customers.
The companies that have chosen to relicense in this manner view the actions of the cloud providers as threats to their own ability to build a business on top of their open source project and the relicensing is an attempt to curb that threat.
The actual lack of contribution to these projects by the large cloud providers is a bit up for debate and something that I'm not going to address in this post. That said, it is a common reason that is cited for the change so I think it's worth mentioning.
The relicensing issue is something that has been slowly boiling in the background for a little while now sparking debates about the longterm sustainability of open source in the current economic environment and tech ecosystem. The recent event with xz and liblzma has really brought the sustainability conversation screaming to the forefront with renewed energy and urgency.
On March 29th, 2024 CVE-204-3094 was published alerting the wider Linux community to a backdoor vulnerability in liblzma that had made its way into some upstream linux distributions. This vulnerability targeted SSH via liblzma and if it had made it to wide distribution would have been a MAJOR issue for large amounts of the servers that run the internet. There is a lot of depth to the liblzma exploit but for this video the important thing to focus on is HOW the malicious actor, JiaT75, was able to get the malicious code into liblzma in the first place.
To pull this exploit off required a lot of time and patients on the part of the attacker. The entire timeline of the attack began in early 2022 and went on until it was finally discovered in March of this year. The interesting, and frankly alarming, thing about this attack is that it didn't exploit buggy code in the wild but first infiltrated the project itself and then worked on getting the malicious code commited to the project.
The initial infiltration, gaining the ability to commit to the project, was done via social engineering attacks on the sole maintainer. This was accomplished by pressuring the maintainer of liblzma to integrate new pull requests via good cop-bad cop, posting on email lists ratcheting up the urgency of a change and then swooping in posing as a new, helpful, face to take some of the pressure off of a clearly overwhelmed maintainer. At this point the bad actor was given commit access to the project and the exploit was underway. The only reason that this good cop-bad cop method of pressure worked was that it leveraged behavior exhibited by users of a project that is seen by open source maintainers all the time.
At this point you're probably thinking, "What does re-licensing and the infiltration of a library used by Linux distributions have anything to do with each other or the sustainability of open source at large?". The answer to that is OWNERSHIP.
The ownership I'm talking about here is not of the legal variety but of the communal and personal. Viewing the long term trends of open source as well as looking at specific examples of issues like liblzma it's pretty clear to me that open source has an ownership problem. Users of open source software don't feel any sort of communal or personal ownership towards the projects that they use and depend on. This is clear in how some users treat maintainers. More like a retail clerk to boomer style scream at rather than a fellow human to collaborate with to solve a problem. This behavior stems from users viewing open source projects like a paid for product than a community resource.
This phenomenon has really ramped up in the last 10 or so years of open source riding on the proliferation of package registries and package managers. In the early days of the free software and later open source movements it was clear that the software that was shared was a community resource. I think this was largely driven by the fact that to interact with and use open source software you had to have your own copy of it. This requirement to have your own copy of a dependency provided downstream users of a project more agency than if it was delivered via a package registry.
If we want to ensure the sustainability of open source into the future first we have to change the culture of how we as users engage with open source. We need to take more responsibility of ownership ourselves AND foster that responsibility in others around us. This change lies with us not the maintainers or companies sponsoring the work. If we don't make this change the landscape of open source will look very different to what we have enjoyed to this point.