I rarely subtoot, but when I do just to say: if an open source project that your commercial project depends on breaks something in your software stack, causing you trouble, no matter how much, that's your problem and your problem alone.
"The software is provided as is" is a part of OSS licenses for a reason, and unless we have a contract that says otherwise, I'm not part of your bloody "supply chain".
100%. If your software is in production, you should be pinning dependencies to provide a stable and reproducible environment
of course, sometimes upstream might do something you don't expect, like break semver conventions and package an API change in a patch release. But at that point your options are to explicitly freeze that dependency and / or politely let the upstream devs know they broke something downstream
@foosel Well, you *are* part of my supply chain. But it means that I have a risk in my supply chain (as with any supplier). A risk that I alone am taking as the license clearly states that you are (rightfully) not liable for anything.
And not the big question is: Am I willing to take that risk? And what ways do I have to mitigate the risk.
And that is usually the point where people realize that - while OpenSourceSoftware is free - it doesn't mean it comes at no cost.
@heiglandreas @jakob @foosel mitigation is easy, do it like the US and write @bagder an email stating he had to sign some documents.
Or do it like it sounds here: put a lot of pressure, on these lazy, supply chain breaking open source developers. They are shitty people who don’t take the responsibility, they owe the product!*
*talking about me here, just to avoid any misunderstanding!
@heiglandreas @foosel I (and others) call that situation "free as in puppy". There might be less or no initial cost, but there's still an ongoing cost.
Personally, I think of Free Software as "free will": I can decide to audit the code, I can decide whether I take in upgrades or not, I can decide to fix bugs or implement features on my own, I can decide whom I pay to do that work for me. I am not tied to the original author (beyond the terms of the license, of course).
@Doomed_Daniel @anniethebruce @foosel when you take a dependency, as opposed to building something in-house, you become responsible for doing so, and should have a plan for what happens if you need to fork/backport/freeze/etc.
I think the EU CRA helps make these relationships clear and visible https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act if you are a vendor who sells product to people then you are responsible for everything you ship unless you have a specific sub-contract for some dependency, you can't disclaim responsibility to some FOSS volunteer who explicitly doesn't take it so that accountability vanishes into the ether.
@raven667 @anniethebruce @foosel
yeah, it isn't as easy as "just freeze a known-good version to avoid problems", you really need to manage your dependencies.
and of course the modern trend of having a lot of dependencies that by again drag in a shitton of other dependencies doesn't make it easier to get and keep an overview of the versions you're using and when they need updates (and review those) etc
@raven667 @anniethebruce @foosel
yes, you shouldn't try to roll your own crypto ;)
I just dislike that trend of depending on (literally) thousands of micro-libs (many of them as indirect dependency), would be nicer to have a handful of bigger more generic ones so it's feasible to keep informed regarding security fixes and if updates break things etc.
@Doomed_Daniel @anniethebruce @foosel I don't mind too much if things are broken down into little projects but how annoying it is depends a lot on the dependancy management tools helping keep track of it all. I've mostly developed perl projects and used RPM as my packaging format successfully, that has worked well for keeping track of things and perl doesn't have a lot of compatibility breaks. I've some 3rdparty apps which are Python/Django, and while that's a great tool, it really pushed me into building virtualenv instead of packaging anything because of the poor built-in dependancy tracking that interfaces poorly with the system-wide package manager, pip has no problem installing incompatible dependancies that break the app as long as the version number goes up and API breaks across the ecosystem are frequent enough that you can't safely share systemwide libraries without having two apps with mutually conflicting library needs, and you can't easily recreate an install of an app from 6mo ago because of library churn, unless somebody pins all the dependancies in the virtualenv and tracks it. I've actually taken to building RPMs of an entire virtualenv to ensure it's consistent across hosts which seems kind of wild.
The way this seems to be solved for desktop software is with Flatpak where the entire runtime is managed as a single versioned thing regardless of how many smaller subcomponents it's made out of. This is also some of the same thinking which created Enterprise distros, where you treat the whole of EL as a single unit that doesn't break API/ABI, and only need to care about your app and it's uniquely managed dependancies.
@anniethebruce If I understand correctly what this is about, the project maintainer here decided to stop prioritizing security issues, something that cannot be addressed by freezing versions. It could in fact screw up downstream consumers who naively assumed an open source project to come with some security guarantees. Except: most of them never really bothered with timely updates anyway, so this merely makes an issue more obvious which was already there - namely all those commercial vendors not caring about security and merely delegating responsibility to some volunteer they don’t have to pay.
@foosel You are absolutely correct.
/keeping two local forks with the patches we've suggested upstream in the issues we posted instead of bugging them when/if they will be merged.
@foosel one of my earliest Open Source interactions was someone telling 12yo me to fix a bug myself, pay someone, or shut up and wait.
I've been in the OSS trenches ever since.
@foosel To subtoot that subtoot, this also applies to open source projects that depend on other open source projects.
I rarely subtoot, but when I do just to say: if an open source project that your commercial project depends on breaks something in your software stack, causing you trouble, no matter how much, that's your problem and your problem alone. "The software is provided as is" is a part of OSS licenses for a reason, and unless we have a contract that says otherwise, I'm not part of your bloody "supply chain".
manu
Gina Häußge
Molly
zrb
Bernie
concretedog
Alerta! Alerta!
Jakob (Jack/Jackie)
Schrank 
🐘 (er/ihm)
Jean-Baptiste "JBQ" Quéru
Trevor Flowers
Annie
Daniel Gibson
Raven667
Stephan Eggermont
Yellow Flag
Krutonium://
Critical Silence
Karis
Troed Sångberg
MeaningfulBits.eth
Bruce Elrick
Cybarbie
Pete Bleackley
Kristof Provost
TheMagicalC