zlacker

I think that this part of it could break either way, but the concern is that when faced with a choice between being liable for their own code or being liable for open source code, most companies will choose to write their own code. If so, that would be a net harm to open source and user freedom. I'm not sure it'll happen, but it might.

The biggest issue I see with this law is around liability for open source projects that people are using directly. It'll be disastrous if all open source software ceases to exist or be available in Europe because volunteers face legal liability if their code has a bug. In theory this could even impact people outside of Europe if they don't prohibit access to their code by EU citizens.

I release a lot of code on github. Most of it is just random crap that I wrote to solve a specific need or to explore an idea, and I put it up under an open source license because why not? If it helps someone, that's great. Now I need to be concerned that the random "example-service" project I wrote in C and published a decade ago to go with a blog post I wrote will end up costing me all the money I have ever or will ever earn in my career.

>>rebecc+(OP)
>>> when faced with a choice between being liable for their own code or being liable for open source code, most companies will choose to write their own code.

Not even FAANG can achieve this for 1/10th of the code they rely on.

>>rebecc+(OP)
> >>> when faced with a choice between being liable for their own code or being liable for open source code, most companies will choose to write their own code.

All those coding jobs lost to AI will be regained when everything needs to be reinvented in-house.

>>lifeis+y
Hmm. They can probably find other companies willing to sell them support contracts, and take on that liability. Even for things that are open source. You're back to the old enterprise software model then, really, even if the code in question is "officially" open source. You won't be able to run versions that your supplier hasn't certified, and the rate of change will slow to a crawl.

>>sevagh+O1
Whenever there is some kind of innovation like AI that makes people think that their jobs will go away the easy response is that there will always be someone that can’t figure how to get it to work and skills just start to shift to that like prompt engineering or vector databases.

>>rebecc+(OP)
> most companies will choose to write their own code.

That might depend on the ubiquity of the OSS in question. If a company's option is to rely on a piece of open source software that has been used billions of times over without incident versus rolling their own solution that at best has only been tested in-house, could they say the latter is really the safer bet?

>>lifeis+y
A capitalistic corporation seem to be a terrible way to maintain software since the "means of production" is in the workers' heads. Especially with these new management fads punishing loyalty. The attrition just makes stuff collapse from unknown complexity.

It is not surprising that volunteer run projects kinda can keep up.

>>flir+i2
> You won't be able to run versions that your supplier hasn't certified, and the rate of change will slow to a crawl.

Interesting times indeed. Though I think open source software generally is reliable enough that companies will simply continue business as usual and take on all the liability. They have enough deep pockets to pay compensation that one time something goes wrong, or at least that's my impression.

>>zumina+z3
I'm not saying this will happen, just that it's the one of the concerns that people have. I can certainly see the argument that some companies will go this route. It might not be the most rational decision, but people aren't always rational. Having something in your control often _feels_ safer.

>>zumina+z3
Well let's say an incident happens. A big one. Lots of egg on C-level face.

Would those execs rather . . .

a) publicly berate and fire the internal developer who created the problem

or

b) have to point out that the opaque series of tests internally just wasn't up to snuff and promise to improve them?

When the bug's in OSS and the company is held responsible, there is no option a.

Unless the OSS projects themselves are staffed up and able to provide legal responsibility, why use them?

>>rebecc+(OP)
I think I must be misunderstanding. The article makes it seem like the user of open source code is responsible for making sure it is suitable and they are liable for when it fails. Doesn't that mean that someone who merely releases code onto GitHub will, in fact, not be liable, since it is the user of said code that is liable?

As far as

> when faced with a choice between being liable for their own code or being liable for open source code, most companies will choose to write their own code. If so, that would be a net harm to open source and user freedom

goes, even if that is true (I'm not really convinced) it doesn't really matter. What matters is finding the correct answer to "who is responsible" to which the answer can't be "nobody". And if it can't be nobody, then it must be somebody. And if it must be somebody, it absolutely shouldn't be some random guy who never specifically signed off on your usage of their open source code.

>>rebecc+(OP)
I think this is roughly correct. There is already a trend in many companies toward actively eliminating or minimizing external open source dependencies in their code bases for supply chain reliability and security reasons. Adding significant new liabilities to the use of external open source dependencies will only encourage this trend.

At the very least, I think it will have a chilling effect on the production and use of open source.

>>rebecc+(OP)
Writing their own code is not mutually exclusive with open sourcing it. Arguably it might even be safer to open source it, since more eyes will be on the code looking for bugs.

Some of the biggest open source projects are owned by megacorps, like React (Facebook), TypeScript (Microsoft), and Tensorflow (Google). And it's clear from these examples that their stewardship has wrought benefits for both the company and the community. The company benefits from what would otherwise be their internal tooling becoming an industry standard - Facebook doesn't need to train React devs after hiring them. And the code is more robust as more people use it - Microsoft doesn't even need to use its latest TypeScript version, they can just wait for the community to test it for them...

>>flir+i2
No, they can't. Paying for all code by paying employees or paying third parties is still paying for all code. That's not feasible. The EU regulators are simply nuts.

>>crypto+em
The hypothetical company that warranties log4js is selling many of those contracts, but only doing the authentication work once for each release.

>>jchw+P8
There are two issues here. The first is when there's some product that's being sold. It could be directly, like selling someone software, or indirectly, like selling them a device that includes software. In that case, whoever sold the thing is responsible for all of the software.

I think that's more-or-less fine. There's a concern that companies don't want to be responsible for open source code, and will write everything in-house instead. I wouldn't be surprised if some companies do that, even if it's a bad idea. I don't know how common it'll be, but the worst case scenario is that it turns out to be bad for developers and for free software.

The second, murkier issue, is what happens when there is no selling involved at all. If I download a debian iso, or clone some random repository on github, then there has been concern that the author of that code will be financially liable for any errors in the software. That would be very, very bad. Early versions of the law seem to explicitly say that it would be the case. More recent versions seem like they might have an exception so long as there is absolutely no money changing hands. It's unclear what would happen in cases where open source software accepts donations. It could still end up being harmful to individual developers and to open source software in general. It's hard to say.

>>rebecc+mI
> the worst case scenario is that it turns out to be bad for developers and for free software.

Which would in turn be very bad for society.

>>squigz+7W1
To be clear I agree with this, I didn't intend to downplay the impact of that consequence. I think the continued existence of free software is both a practical and moral necessity.

What I was trying to communicate here is that I think meaningful negative impact to free software and to developers is a worst-case scenario and not the most likely scenario. It's plausible, and we should be concerned, but I think there's also a plausible outcome that is neutral or positive for free software if companies end up contributing more to free software as a way of ensuring they are meeting their obligations under the law.

>>rebecc+Lt2
Thanks for the clarification :)