zlacker

[parent] [thread] 59 comments
1. sevagh+(OP)[view] [source] 2023-12-29 18:40:30
I find this article and the reactions here confusing. This seems to me like unequivocally a good thing for open-source devs.

Making commercial vendors who rely on open source software liable for bugs is fantastic news, that's how it always should have been. You can't have a commercial company throw their hands up and say "well github.com/cutefuzzypuppy is at fault for writing an open-source npm package we used so harm to our customers is not our fault!"

replies(7): >>omnico+u1 >>kragen+r3 >>rebecc+X3 >>golol+n7 >>zoogen+3j >>grumps+xt >>tesdin+F62
2. omnico+u1[view] [source] 2023-12-29 18:46:10
>>sevagh+(OP)
The article is misleading unless you read the whole thing and the reactions are standard knee-jerk ones from HN users that didn't need to read past "EU" to assume the worst possible misinterpretation.
replies(4): >>within+K2 >>sevagh+43 >>notfed+I3 >>tracer+O5
◧◩
3. within+K2[view] [source] [discussion] 2023-12-29 18:51:36
>>omnico+u1
I read the article, but it was quite ambiguous, at least to me. It isn't very well written / clear on what is actually going on.
replies(1): >>omnico+q3
◧◩
4. sevagh+43[view] [source] [discussion] 2023-12-29 18:53:00
>>omnico+u1
Yes, the author of the article is all over the place

>But what if you’re just part of a collaborative open source project, give away your app, or if there’s open source code in the product you put on the market? Who gets blamed when open source might be the heart of the problem?

Every other sentence is dripping in "sympathy for open-source creators", but buried in the subtext is "sympathy for the innocent commercial vendors who decided to rely on open-source projects."

>So, how is open-source software implicated? If a commercial software product causes harm, whoever put the software on the market will soon be strictly liable.

Good!

>You will need to prove that your code wasn’t to blame to escape the costs. But what if you’ve embedded open-source code, used open-source tools, or called open-source APIs? Under the pending rules, you’d be liable for any errors in those sources as well, regardless of whether you directly contributed or not.

Better! Now a big evil company _can't_ pass the buck to the unpaid hobby project creator!

replies(2): >>curt15+od >>MaxBar+Ng
◧◩◪
5. omnico+q3[view] [source] [discussion] 2023-12-29 18:55:04
>>within+K2
I agree it's very ambiguous, but if you read the whole thing it's clear that when dev A releases code under an open source license and it's included in a commercial product by company B that then harms person C, the liability will be on company B. Most of the hot-under-the-collar responses here are assuming it will fall on dev A, which is a misinterpretation the article's author did not do much to discourage.
replies(2): >>sevagh+n4 >>Mauran+I5
6. kragen+r3[view] [source] 2023-12-29 18:55:06
>>sevagh+(OP)
i think the article is deliberately written to be confusing
replies(1): >>hutzli+O6
◧◩
7. notfed+I3[view] [source] [discussion] 2023-12-29 18:56:21
>>omnico+u1
Are we reading the same article? The final paragraph even says:

> My prediction, for what it’s worth, is that open source’s days outside academia and hobbyists are numbered.

8. rebecc+X3[view] [source] 2023-12-29 18:57:03
>>sevagh+(OP)
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.

replies(6): >>lifeis+v4 >>sevagh+L5 >>zumina+w7 >>jchw+Mc >>jandre+xe >>chatma+Pl
◧◩◪◨
9. sevagh+n4[view] [source] [discussion] 2023-12-29 18:59:09
>>omnico+q3
Actually, I may have missed buried lede in this case where there is no company B, and citizen C is harmed by dev A's github project.

That is actually kinda concerning, if my MIT license of "no guarantee" won't protect me.

Other commenters who got it:

>>38808821

>>38808756

replies(1): >>fipar+S6
◧◩
10. lifeis+v4[view] [source] [discussion] 2023-12-29 18:59:29
>>rebecc+X3
>>> 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.

replies(2): >>flir+f6 >>rightb+R7
◧◩◪◨
11. Mauran+I5[view] [source] [discussion] 2023-12-29 19:06:45
>>omnico+q3
That completely ignores the second half of the article. I agree that it's confusing why the article goes into so much depth on "companies are now liable, similar to how everyone expects" in the first half when the main talking point is/should be "open source devs are now liable if consumers use their software directly" (as discussed in the second half).
replies(1): >>tesdin+972
◧◩
12. sevagh+L5[view] [source] [discussion] 2023-12-29 19:07:03
>>rebecc+X3
> >>> 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.

replies(1): >>zitter+H6
◧◩
13. tracer+O5[view] [source] [discussion] 2023-12-29 19:07:25
>>omnico+u1
The article literally ends in bold with "Someone, or some entity, will need to accept financial and legal responsibility for what the project does in consumer hands. No license can insulate them from that. " If people are having a fearful reaction to the article it's the authors fault.
◧◩◪
14. flir+f6[view] [source] [discussion] 2023-12-29 19:09:28
>>lifeis+v4
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.
replies(2): >>Aerbil+b8 >>crypto+bq
◧◩◪
15. zitter+H6[view] [source] [discussion] 2023-12-29 19:11:58
>>sevagh+L5
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.
◧◩
16. hutzli+O6[view] [source] [discussion] 2023-12-29 19:12:57
>>kragen+r3
Maybe, but maybe the legislation also is:

"What if an open source project is used directly by consumers, and causes them harm? The public policy is clear: they must be compensated. Does it matter if they signed a license or didn’t pay someone? Their business is bankrupt, their files are in a hacker’s hands, or their own customers are suing them. Someone should be strictly liable. But who?

The EU is grappling with that very question, and it culminates in whether “open source” is exempt from liability in a law designed to protect consumers. So far the answer is “probably not?” Exemption means consumers bear the cost – exactly what the law is trying to change. Perhaps if the open source in question remains an academic or research tool, versus reaching consumers, we’re okay? The proof may come when the first consumer demands compensation, and the courts step in. But lawmakers know enough to realize that much of the open source out there – by definition – belongs to no one, or many someones, or really nobody that can be named and made liable. So waiting on a court case might provide clarity but no compensation and no one to even argue the case. Not the clarity a law is designed to provide."

But I rather think that no, the law just talks about products where you pay money for. And when I pay money for something, I do expect liablity in some way and this is allright. But it is not allright to mix them both up for politicial support (or whatever the motivation here is).

replies(2): >>orwin+be >>mlinks+8s
◧◩◪◨⬒
17. fipar+S6[view] [source] [discussion] 2023-12-29 19:13:19
>>sevagh+n4
That is concerning, but I think the author’s interpretation of the upcoming regulation may be wrong.

See here for example: https://www.euractiv.com/section/digital/news/eu-updates-pro...

Specifically: “The Directive will not apply to free and open-source software developed or supplied outside a commercial activity. The liability rules apply when the software is supplied in exchange for a price or personal data used for anything other than improving the software’s security or compatibility.”

IMHO the original article is either wrong or trying to spread FUD.

My take is, if this law passes, I’m an EU citizen, and I use your MIT software without paying you and without engaging with it through some service of yours (e.g. sevaghbook.com) then you’re not liable if I get damaged.

replies(2): >>dqv+Je >>trepri+Cy
18. golol+n7[view] [source] 2023-12-29 19:16:46
>>sevagh+(OP)
Very bizarre, the implication is literally reversed in the analysis of the problem versus the actual problem.
◧◩
19. zumina+w7[view] [source] [discussion] 2023-12-29 19:18:04
>>rebecc+X3
> 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?

replies(2): >>rebecc+x8 >>drewco+s9
◧◩◪
20. rightb+R7[view] [source] [discussion] 2023-12-29 19:19:39
>>lifeis+v4
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.

◧◩◪◨
21. Aerbil+b8[view] [source] [discussion] 2023-12-29 19:21:18
>>flir+f6
> 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.

◧◩◪
22. rebecc+x8[view] [source] [discussion] 2023-12-29 19:23:20
>>zumina+w7
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.
◧◩◪
23. drewco+s9[view] [source] [discussion] 2023-12-29 19:28:17
>>zumina+w7
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?

◧◩
24. jchw+Mc[view] [source] [discussion] 2023-12-29 19:47:06
>>rebecc+X3
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.

replies(1): >>rebecc+jM
◧◩◪
25. curt15+od[view] [source] [discussion] 2023-12-29 19:50:09
>>sevagh+43
So can we expect popular yet understaffed open source software -- like OpenSSL -- to get a lot of paid code review or patches?
replies(1): >>mistri+Vu
◧◩◪
26. orwin+be[view] [source] [discussion] 2023-12-29 19:54:33
>>hutzli+O6
> But I rather think that no, the law just talks about products where you pay money for.

Ianal but my intuition is that you're on point.

◧◩
27. jandre+xe[view] [source] [discussion] 2023-12-29 19:57:07
>>rebecc+X3
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.

◧◩◪◨⬒⬓
28. dqv+Je[view] [source] [discussion] 2023-12-29 19:58:10
>>fipar+S6
Why none of these articles (neither TFA nor the one you're linking) link to the actual directive is beyond me.

But here it is:

https://www.europarl.europa.eu/RegData/etudes/BRIE/2023/7393...

> With the aim of not hampering innovation: (i) free and open-source software developed or supplied outside the course of commercial activity, as well as (ii) the source code of software, should be excluded from the definition of products covered under the proposal.

replies(2): >>fipar+gC >>eggsbo+mF
◧◩◪
29. MaxBar+Ng[view] [source] [discussion] 2023-12-29 20:10:47
>>sevagh+43
The end of that paragraph continues in the same line:

> Worse still, how will you in turn identify or sue the collaborator or collaboration that actually wrote the faulty open-source code to recoup your costs? In that case, the license you signed likely insulates your open-source partners from your claims.

I sincerely hope this will never become a possibility. The chilling effect would presumably be catastrophic for Free and Open Source software in the relevant legal jurisdiction. Why would anyone voluntarily release their code as FOSS if it opens them up to lawsuits?

30. zoogen+3j[view] [source] 2023-12-29 20:21:40
>>sevagh+(OP)
> This seems to me like unequivocally a good thing for open-source devs.

I'm not certain the second order (or later) effects will necessarily be unequivocally good. Software supply chains are more like a double pendulum in that changes are probably chaotic enough to obscure their effects.

For example, my very first thought was that large businesses are generally risk adverse specifically in the realm of liability. Have you ever read a TOS? It feels to me the major elements of that interminable document are statements that limit liability. It is to the point of humor that we engage in the clicking through the "I accept" of a software license like some strange universal ritual. This is the realm we are dealing in here, deep and arcane. The ubiquitous TOS ritual should remind us all that software is beholden to forces outside of itself.

Companies go through insane effort to avoid legal liability. This law is going to change that calculus. If the cost of covering that change is high this could precipitate a change to closed-sourced alternatives that come with some delegation of liability. For the cynically minded, companies that offer equivalents to OSS that come with a liability waver might see an ascendance and potentially offer a good investment opportunity. Alternatively, repackaging existing OSS as a commercial product while only adding some legal liability as an add-on might become a viable business.

Those considerations challenge any argument towards unequivocally stating this is a good thing, even if there are definitely positive aspects to this change.

replies(1): >>mistri+0J
◧◩
31. chatma+Pl[view] [source] [discussion] 2023-12-29 20:38:59
>>rebecc+X3
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...

◧◩◪◨
32. crypto+bq[view] [source] [discussion] 2023-12-29 21:07:51
>>flir+f6
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.
replies(1): >>flir+Ay
◧◩◪
33. mlinks+8s[view] [source] [discussion] 2023-12-29 21:19:07
>>hutzli+O6
The CRA is not about liability or consumer compensation. The remedies for non-compliance are fines or removal of a product from the EU market. The forthcoming update of the Product Liability Directive, which will probably take a similar approach (exempting open source unless it is placed on the market, so as the article describes, developers of products that are placed on the market are responsible for the security of their products, including open source incorporated in said product) on the other hand is.

I only skimmed the OP and doubt it's intentionally confusing, but it is confusing because its prediction of doom is wacky. Manufacturers (eg developers of IoT devices, the insecurity of a major impetus for the legislation, apps, etc) will need to adopt modern development practices such as updating their dependencies when a vulnerability is known -- and that includes manufacturers that wrap a mostly open source codebase in a final product or monetise an open source codebase in various ways called out in the legislation.

Yes if a consumer is harmed by a completely open source thing not placed on the market, say something in Debian, they will not be able to sue the developers, and the developers aren't subject to fines etc under the CRA. That's the balance intended by the legislation (after lots of attempts to get it right), to not wreck incentives to develop open source, but to make product developers more responsible. In other words, the public policy is not exactly as you state it. :)

replies(1): >>kragen+hF
34. grumps+xt[view] [source] 2023-12-29 21:28:57
>>sevagh+(OP)
How in the world is this good for devs? It's terrible. Do you really think that "big corp" will not figure out how to pass the liability directly to the author?

What will happen the opensource world once you're held liable for some moron who uses some software I wrote for myself? or incorrectly uses it?

do you really believe the curl should be held liable because some POST failed and a user lost something over it?

what about my old backup scripts? I need to remove them from my repos?

replies(1): >>moses-+1D
◧◩◪◨
35. mistri+Vu[view] [source] [discussion] 2023-12-29 21:36:48
>>curt15+od
expect new, certified companies with security and finance, to become the officially required caretakers along with many fees; expect new monetized systems to distribute security patches passed through new bureaucracies, with logging of the government ID of all recipients; expect the restriction of new security patches to authorized users only.
◧◩◪◨⬒
36. flir+Ay[view] [source] [discussion] 2023-12-29 21:57:59
>>crypto+bq
The hypothetical company that warranties log4js is selling many of those contracts, but only doing the authentication work once for each release.
◧◩◪◨⬒⬓
37. trepri+Cy[view] [source] [discussion] 2023-12-29 21:58:08
>>fipar+S6
Basically EU will treat open source devs as idiots by preventing them from making living off it. And you feel that's fine?
replies(2): >>warkda+PB >>fipar+SB
◧◩◪◨⬒⬓⬔
38. warkda+PB[view] [source] [discussion] 2023-12-29 22:18:24
>>trepri+Cy
If open source devs make a living off it by charging users for money (or PII), the devs should be liable for the code they are selling. It does not matter if it is open source. Whoever makes a commercial offering based on that software must be liable.
◧◩◪◨⬒⬓⬔
39. fipar+SB[view] [source] [discussion] 2023-12-29 22:18:50
>>trepri+Cy
I have no idea how you interpret it this way.

How does being liable for damages caused by software or services you sell equate to being an idiot? I just see it as the normal way to do business, and the reason why limited liability (the way I’ve been doing business for more than 2 decades) exists.

replies(1): >>trepri+2U
◧◩◪◨⬒⬓⬔
40. fipar+gC[view] [source] [discussion] 2023-12-29 22:21:53
>>dqv+Je
Thanks for linking to the actual directive!

In light of it, I think the article I found didn’t link to it out of sloppiness, because their summary seems reasonably accurate to me, and the fine article didn’t link to it because they want to spread FUD, as the text you quoted directly contradicts some of the fear mongering in the original article.

◧◩
41. moses-+1D[view] [source] [discussion] 2023-12-29 22:28:20
>>grumps+xt
I read the article twice, because the link title made me think that I as an open source contributor and publisher liable for complaints.

My reading of the text is that the one actually selling the software product is the one having to abide by this law. Am I incorrect?

How could this be negative? I presume that most publishers of open source software would prefer that some Silicon Valley Unicorn did _not_ half-heartedly integrate their library, causing security issues and tainting their library name?

replies(1): >>grumps+D11
◧◩◪◨
42. kragen+hF[view] [source] [discussion] 2023-12-29 22:47:31
>>mlinks+8s
as i understand it, the problem with some of the previous drafts of the produt liability directive was that by making a commercial product open-source, you could become liable for how random people who weren't paying you used it

consider ghostscript, for example, which is open-source and a commercial product from artifex. the license terms are such that you generally only have to pay for it if you're embedding it in a printer, which many manufacturers do. but virtually every gnu/linux box has it installed without needing to pay for a license. suppose a security vulnerability in ghostscript (of which there have been a number) allows an attacker to own a million ubuntu machines and inject ransomware into thousands of companies in the eu who have no relationship with either the ubuntu company or with artifex

as i understand it, previous drafts of the product liability directive would have made artifex liable for damages in this situation, creating a strong incentive against making any commercial software open-source. do we know this cra avoids making artifex liable for fines? it seems that liability for fines would create the same kinds of incentives

has this been fixed?

as you likely know, i think a necessary and nearly sufficient step to solving the iot security problems is requiring the firmware to be open-source so that consumers can update it whether the manufacturer wants to or not

replies(1): >>mlinks+801
◧◩◪◨⬒⬓⬔
43. eggsbo+mF[view] [source] [discussion] 2023-12-29 22:48:14
>>dqv+Je
Still not clear for me. What about a company open sourcing some libraries used in its product. Will it be liable? Or would this be 'supplied outside the course of commercial activity'
replies(1): >>dqv+161
◧◩
44. mistri+0J[view] [source] [discussion] 2023-12-29 23:15:57
>>zoogen+3j
> Alternatively, repackaging existing OSS as a commercial product while only adding some legal liability as an add-on might become a viable business.

bingo

replies(1): >>jahav+RR
◧◩◪
45. rebecc+jM[view] [source] [discussion] 2023-12-29 23:50:28
>>jchw+Mc
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.

replies(1): >>squigz+402
◧◩◪
46. jahav+RR[view] [source] [discussion] 2023-12-30 00:55:33
>>mistri+0J
It's called tidelift.com
replies(1): >>mistri+gX
◧◩◪◨⬒⬓⬔⧯
47. trepri+2U[view] [source] [discussion] 2023-12-30 01:20:52
>>fipar+SB
Example: I will make a library controlling some integrated circuit as open source and charge money for commercial use. My software has a little bug that occasionally causes misreading of the IC values. A military software company uses my open source library in their nuke platform. My library misreads values on one nuke that goes off. Are you telling me I am going to be liable for that? Let's say independent multi-pass root cause analysis pinpointed the problem to my library and only to my library.
replies(2): >>mark_u+s01 >>fipar+u01
◧◩◪◨
48. mistri+gX[view] [source] [discussion] 2023-12-30 02:00:14
>>jahav+RR
this looks interesting https://www.bestpractices.dev/en

... from a longer transcript here https://www.infoq.com/presentations/security-supply-chain-os...

◧◩◪◨⬒
49. mlinks+801[view] [source] [discussion] 2023-12-30 02:40:13
>>kragen+hF
Wish I could say for certain, but we'd need the final texts of the CRA and PLD, and EU lawyers, to say for sure. This is the sort of situation that the general aim of the EU policymakers seems to be to avoid what they'd see as loopholes, where a business is avoiding responsibility simply by making a product open source, and avoiding destroying open source. It's plausible, perhaps likely, that open source ghostscript would be exempt, but the one there's a transaction for (clearly being placed on the market -- that, rather than "commercial product" is the key concept) would surely not be. The same vulnerability might impact both, but the developer may only be responsible for the latter. It's possible under the CRA artifex could be considered (very late addition) the steward of the open source version, which was intended largely to cover (give some responsibility to) foundations, but without any real penalties -- but, we'll see.

I'm not surprised that's what you think. I'm doubtful anywhere close to sufficient, as much as I'd like that to be true. The focus of the CRA is of course to make the manufacturer be responsible, including for providing security updates for as long as the product is expected to be used (5 years or more typically). There probably is a weak recital suggesting manufacturers might make source code available to other undertakings so that they might provide security updates after the original manufactuerer's support period, but no enforcement of this, and explicitly not requiring open source. Seems like a potential area for future regulation to improve upon.

replies(1): >>kragen+k51
◧◩◪◨⬒⬓⬔⧯▣
50. mark_u+s01[view] [source] [discussion] 2023-12-30 02:45:31
>>trepri+2U
My take would be that if the military company paid you for the commercial use right, then you have "sold" the software and yes you would be liable. If they used it in an open source compatible way (no actual license is stated), and did not pay you for it then no, you would not be liable.
replies(1): >>trepri+A11
◧◩◪◨⬒⬓⬔⧯▣
51. fipar+u01[view] [source] [discussion] 2023-12-30 02:45:44
>>trepri+2U
If you did not sell the library to the military software company then no, it’s them whom are liable (assuming they did sell their software, that uses your library, to whomever had the nuke that went off) and not you.

IANAL but it seems clear cut to me: if you asked for money in exchange for your software (or to access to your software through an API or similar), or if you asked for personal information (in exchange for your software) then you’re liable, otherwise, you’re not.

◧◩◪◨⬒⬓⬔⧯▣▦
52. trepri+A11[view] [source] [discussion] 2023-12-30 02:59:41
>>mark_u+s01
So basically I have no say about how my library is going to be used once I sell a license to a company, and if its use by a 3rd party leads to e.g. a mass-casualty event due to a bug in my code, I am liable?
◧◩◪
53. grumps+D11[view] [source] [discussion] 2023-12-30 03:01:30
>>moses-+1D
Because lawyers and courts become involved. They don't understand software or anything related to it.
◧◩◪◨⬒⬓
54. kragen+k51[view] [source] [discussion] 2023-12-30 04:07:04
>>mlinks+801
thank you very much!
◧◩◪◨⬒⬓⬔⧯
55. dqv+161[view] [source] [discussion] 2023-12-30 04:18:04
>>eggsbo+mF
Take OpenSSL. Their open source product would be free of liability. Their commercial support offering of that same product would not be.
◧◩◪◨
56. squigz+402[view] [source] [discussion] 2023-12-30 16:07:31
>>rebecc+jM
> 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.

replies(1): >>rebecc+Ix2
57. tesdin+F62[view] [source] 2023-12-30 16:57:08
>>sevagh+(OP)
You failed to read and understand the article. Not only commercial vendors but also authors of open source software aimed at consumers , could be held liable. The courts would decide.

> "whether “open source” is exempt from liability in a law designed to protect consumers. So far the answer is “probably not?” Exemption means consumers bear the cost – exactly what the law is trying to change. Perhaps if the open source in question remains an academic or research tool, versus reaching consumers, we’re okay? The proof may come when the first consumer demands compensation, and the courts step in.

◧◩◪◨⬒
58. tesdin+972[view] [source] [discussion] 2023-12-30 17:00:30
>>Mauran+I5
Most commenters here only read the first half it seems, I expected more of the hn audience.
◧◩◪◨⬒
59. rebecc+Ix2[view] [source] [discussion] 2023-12-30 19:46:28
>>squigz+402
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.

replies(1): >>squigz+Ui3
◧◩◪◨⬒⬓
60. squigz+Ui3[view] [source] [discussion] 2023-12-31 02:40:55
>>rebecc+Ix2
Thanks for the clarification :)
[go to top]