LWN: Comments on "The burden of knowledge: dealing with open-source risks"

Which bit about this only applies to open source?

taladar — Wed, 19 Mar 2025 09:31:47 +0000

I have certainly seen a lot of companies work with proprietary projects where the original creator had gone away and nobody else had any source code and so they are just ignoring the problem that the software does not get any updates and might stop working any day for a variety of reasons (e.g. compliance with changing laws, newly discovered security issues or critical bugs,...)

Which bit about this only applies to open source?

NAR — Tue, 18 Mar 2025 17:26:17 +0000

With commercial dependencies there are contracts (e.g. service level agreements, support, etc.) in place which might mitigate the problem (even if not technically, then legally and/or financially).

Red flag checker

paulj — Tue, 18 Mar 2025 15:04:20 +0000

Black flag probably is from motor racing. It indicates a specific participant must leave the race track, as they are disqualified.

Red flag checker

Wol — Tue, 18 Mar 2025 14:23:48 +0000

To me, a red flag is an indication of risk. Yes, often it's a warning to "don't do this", but ?the original? red flag was waved by a man in front of a motor car when they were new and considered dangerous. Then there's the red traffic light, which just means "stop".

As for the black flag, I have seen that for real in motor racing. It tells a driver to come off the track. I think this guy would have been in real trouble because he basically ignored it ...

Cheers,
Wol

Red flag checker

vicky@isc.org — Tue, 18 Mar 2025 12:52:50 +0000

I was thinking of the DCO requirement on the OpenSSF's 'Best Practices' Badge app. I didn't bother clarifying because I thought this thread had run its course. I don't expect the Best Practices badge to 'improve security' or 'guarantee security' but I do think it provides some useful information, for someone who is looking. From my little survey though, users do not seem to be looking at that badge or equivalent scorecards. Maybe this behavior will change over time....

Vicky

Red flag checker

pm215 — Tue, 18 Mar 2025 12:37:44 +0000

I think the more usual terminology for the flags analogy is that "indicators of potential risk" are *yellow* flags -- indicating "this might be fine, but it's something to investigate", and red flags are reserved for the more serious deal-breaker indicators, things that either mean "avoid" or "this must be addressed immediately". A bit of googling seems to indicate that some people have an extra higher tier of "black flag", but that's new to me.

Red flag checker

paulj — Tue, 18 Mar 2025 11:59:48 +0000

Not just English. In many, many contexts (motorsports, beaches, firing ranges), a red flag indicates imminent danger and a very strong discouragement, if not outright prohibition, on proceeding any further.

This isn't some abstract, vague symbol really. ;)

Red flag checker

farnz — Tue, 18 Mar 2025 11:05:38 +0000

But again, this is a red flag, not a no-no

In many dialects of English, "red flag" is nearly synonymous with "no-no"; the distinction is that a certain behaviour is a "no-no" if you are considering doing it, while it's a "red flag" if you observe someone else doing it. In both cases, it refers to a behaviour that should deter other people from interacting with you.

So, saying that something's a "red flag, not a no-no" is a bit weird - it can be read as "this is awful behaviour, not awful behaviour", which is nonsense.

Red flag checker

mxmehl — Tue, 18 Mar 2025 10:33:30 +0000

> A "red flag" is another word for a big no-go. It flags something that cannot be tolerated and must be fixed.
> That is the base for my reaction.

That's probably the main misunderstanding. For me, a red flag is an indicator for a potential risk. As written in an earlier comment above, CLAs are a good example. There are CLAs which I consider to be an immense risk, e.g. in the context of a single-vendor project lead by a company that a) is unwilling to cooperate with a community and b) is not specifically trustworthy. However, there may also be good CLAs, e.g. for trustworthy foundations that can use CLAs to secure and extend freedoms for the software users, and take effective measures to avoid any abuse of CLAs.

> I think this tool is dangerous, because if executed by the wrong people with the wrong understanding about what "single maintainer" actually means it can lead to very bad decisions. Both for the company and also for the project.

I am sorry to disappoint you but this "metric" is probably the most-used in all kinds of tools and has been implemented in methodologies and tools since at least 10 years. As with all metrics, it can be misinterpreted and stupid decisions can be made based on it -- which is one of the core reasons why I gave this presentation at FOSS Backstage. And hey, basically all of my own Open Source projects also turn out to score badly on these metrics, whatever that means ;)

And let's be honest: In some contexts, I might indeed come to the conclusion that a project lead by a single maintainer is a risk that I cannot accept without any countermeasures, for example in high-risk environments that need to stay stable for 20+ years. But again, a red flag is not a no-no. Nothing prevents such an organisation in this case to approach the project to offer contributions, co-maintainership, sponsorship, contracted work or even a permanent job. And again, outlining these possibilities, also within the context of upcoming legal requirements from the Cyber Resilience Act and similar legislation, was the main motivation for my talk.

That said, I am sorry you made such bad experiences with some individuals from companies. Unfortunately, the CRA might lead to an increase of such stupid requests and demands, but I do hope that in the long-term it will rather turn companies into good Open Source citizens who acknowledge their responsibilities towards the huge Open Source ecosystem they depend on and ultimately the customers of their products.

Red flag checker

mxmehl — Tue, 18 Mar 2025 10:11:33 +0000

Indeed, I also wonder why OpenSSF Scorecard with a security focus makes recommendations regarding licensing. They recommend either DCO or CLA. The former is a sane recommendation, although it's questionable whether it's legally helpful.

For me/us, a CLA is a red flag (so an indicator for a potential risk) because it poses the risk that an Open Source project becomes proprietary without any notice or debate amongst the contributors. Such a license change fundamentally changes our relationship to a certain piece of software, not only from a commercial/financial perspective but also in terms to our possibilities to engage actively or sponsor in order to contribute to the long-term stability of the project.

But again, this is a red flag, not a no-no. There are "good CLAs", e.g. for projects in trustworthy foundations such as Apache or GNU. In those contexts, a CLA may even be considered to be an advantage as it allows projects to improve the licensing situation, e.g. by dual-licensing, for the benefits of all users, so preserving and even extending freedoms, opposed to single-vendor projects where a CLA is rather used to restric freedoms.

Ultimately, this was the gist of my talk: metrics in whatever form are useless unless you interpret them within context. In Open Source, context can be the single projects, the ecosystem around it, and also my very own risk assessments as individual user or organisation.

Red flag checker

kleptog — Tue, 18 Mar 2025 08:43:14 +0000

> I think this tool is dangerous, because if executed by the wrong people with the wrong understanding about what "single maintainer" actually means it can lead to very bad decisions.

In other words, it's just like basing important decisions on any other single metric, because a single metric can never cover all the nuances needed for a good decision. See also GDP, GDP per capita, life expectancy, etc. If decision makers take all the human judgement out of a decision, they get what they deserve.

Red flag checker

pabs — Tue, 18 Mar 2025 05:38:20 +0000

What you experienced sounds pretty horrible...

Probably the tool needs to be reworked to point out correct solutions to the potential risks it uncovers.

For eg single maintainer working on a project in their spare time, with a donation form => donate money, offer to pay for work on the project and or assign employees to contribute back.

That of course won't deter bad actors but it should make most uses of the tool result in positive outcomes.

Red flag checker

mb — Mon, 17 Mar 2025 18:31:57 +0000

Thanks for your reply.

> I don't get where I insulted you or other maintainers in any way.

Well, I'll describe my perspective.

A "red flag" is another word for a big no-go. It flags something that cannot be tolerated and must be fixed.
That is the base for my reaction.

I maintain a couple of projects that many companies use for various purposes. They probably earn good money with them and that is perfectly fine.

For all of them I am the only maintainer.
I really don't see what is wrong with that (a.k.a. red flag) per se.
Almost all smaller Open Source projects are like that.
As long as the maintainer has the resources and can do the job properly then there is no problem at all.

I think this tool is dangerous, because if executed by the wrong people with the wrong understanding about what "single maintainer" actually means it can lead to very bad decisions. Both for the company and also for the project.
I can already see the new rule in the development process that mandates there being no red flags. Yes, I understood that there's no such rule at DB. I'm actually talking about other companies/people here which adopt such a tool. I see similar harmful metrics being enforced daily in my day job.

But it's also true that my reaction is based on my recent bad experience.
I'm not saying that all companies behave bad. In fact, most companies have a very good style of communication with the Open Source community.
But there also is the occasional company which uses Open Source software for bad purposes such as illegal fake products while also violating the license (of course) and then requesting support from the Open Source maintainer. This is what *actually* happened to me recently. Quote from their communication: "its actually working we will just rebrand it [...] Entitled Dick Dev". And this is not the worst part. I don't want to put the more harsh insults here.

This is not a good base for the next one to come along and flag the project as a "red flag".
So, yes. I was probably overreacting. However, I also wanted to make clear that I don't find such a tool acceptable.

monetization opportunity

Wol — Mon, 17 Mar 2025 16:12:50 +0000

> Surely if a FLOSS author has the funding and inclination, they should be able to get their project certified and release that info publicly? Why would that be banned?!

Because it doesn't work like that. Nobody can "get their project certified". It's all *self*-certification - with legal teeth.

Let's say I want to use your FLOSS in my product. It's FLOSS - I can do so no problem, I self certify my product, everything's fine ... until something goes wrong, and I'm legally on the hook for your product. I don't want that.

So I go to you, and say "here's this legal checklist, can you tick these boxes?". One of which is the bus factor! As a lone developer you simply can't tick the boxes end of. And bearing in mind the legal liability, would you even *want* to tick the boxes without being paid for it?

So you could set up "Pabs Software Consultancy LLC" with a few like-minded FLOSS developers, sign a support contract, and you can issue your CE and get paid to work on your product doing what you want.

Or, what I could do in these circumstances, is sign a retainer with you about consultancy rates, you're legally obligated to drop everything and fix it for me if I need you to, etc etc, and you still don't issue a CE (you can't), but I'm happy underwriting my CE because I know I've got you on the hook if there's a problem.

The (fraudulent) alternative, which is what pizza was worried about, is if I pretty much blackmail you into issuing a CE for nothing even if you're a lone developer. That won't happen, because most FLOSS guys have much more than two brain cells, and if I try that you'll keep the evidence. So when something *does* go wrong, and there's an investigation by the authorities, not only will I be on the hook for the liability I tried to dodge, but I'll be in very hot water for trying to dodge it.

At the end of the day, the legislation is about legal liability for fixing things, and the authorities are wise to people making promises they can't keep ...

Cheers,
Wol

Which bit about this only applies to open source?

mathstuf — Mon, 17 Mar 2025 15:28:14 +0000

I wonder if it falls into the same category of behavior as the "if we don't measure COVID infections, we can ignore the problem" behaviors witnessed during the pandemic.

Red flag checker

neverpanic — Mon, 17 Mar 2025 14:05:23 +0000

The OpenSSF best practices, and the OpenSSF Scorecard especially, are questionable.

Don't trust me on this, check what other say, too. Here's for example Daniel Stenberg on record at https://mastodon.social/@bagder/113673188062525753 or https://github.com/curl/curl/discussions/12609.

Or, see https://www.youtube.com/watch?v=J2X1yItdxvo&t=644.

Red flag checker

vicky@isc.org — Mon, 17 Mar 2025 13:48:34 +0000

It is funny that the CLA is a red flag in your system. We added a CLA to one of our projects because *not having one* was considered a negative security factor by the OpenSSF Best Practices badge.

I know some checkers - and again the Best Practices badge, penalize projects that have contributors from only one organization. This is also odd from a security perspective - I can see a concern for project longevity, but not code security - if commits are managed by a small, well-integrated team.

A colleague and I did an informal survey last summer asking users what they look at to determine the risk level of OSS. results are published here: https://ec.europa.eu/eusurvey/publication/RIPE88OpenSourc...

bottom line is, it depends.

monetization opportunity

farnz — Mon, 17 Mar 2025 10:40:04 +0000

AFAICT, the exact rule is that there has to be a contractual relationship of some form (a B2B sale is enough of a contract here, but acceptance of an open source licence is called out as not enough) to allow liability to pass along the chain. And the CRA "certification" is you saying that you accept liability for certain classes of faults in your software; open source gets a special exception, where you can offer the software to all interested parties without accepting liability for relevant faults (where commercial software providers, including those providing open source under a paid contract, can't escape liability in some cases).

There's also quite a bit of language in the CRA that prevents open source licensors from picking up liability without being very deliberate about who they're liable to, and what use that entity is making of the code; you can't just certify that you'll take on all liability for any use or misuse of the software (whereas a commercial entity can, and can even be required to take on liability for expected use of the software).

Which bit about this only applies to open source?

taladar — Mon, 17 Mar 2025 09:49:26 +0000

Most of those risks seem very real for commercial dependencies or software products too, not just open source ones. If anything you can judge the state of the proprietary software less than you can with open source projects.

Red flag checker

mxmehl — Mon, 17 Mar 2025 08:51:07 +0000

> It basically is a single-author project and it basically hasn't been changed in two years.
> Pretty red, eh? At least according to their own standards.
>
> This tool is dangerous.

Author of the talk here. Joe unfortunately did not mention that I called our Red Flag Checker a PoC. We don't even use it internally in a large scale, basically just to check whether a repo somehow required a Contributor License Agreement (CLA) which we consider to be a red flag.

The activity measurement came on top to explore how this tool could be further developed and whether it actually yields results which are useful to us. And as I said during the talk, I came to the conclusion that there mere activity of a project is not a strong indicator for potential risks.

I don't get where I insulted you or other maintainers in any way. I also don't understand where LtWolf sensed a sales pitch, as neither I nor DB Systel are selling anything to anyone in this room. If you're interested in my motivation and background, let's talk. If you're just here to bash anyone with any connection to a company in the broadest sense, have fun.

monetization opportunity

pabs — Mon, 17 Mar 2025 02:31:41 +0000

Surely if a FLOSS author has the funding and inclination, they should be able to get their project certified and release that info publicly? Why would that be banned?!

Red flag checker

ballombe — Sun, 16 Mar 2025 23:25:11 +0000

Also it is missing:

>* ⚠️⚠️ Software is funded by Google.

At this point the life expectancy of a software developed by an unpaid developer is higher than the life expectancy of a software receiving funding from Google.

Red flag checker

LtWorf — Sun, 16 Mar 2025 10:41:39 +0000

Yeah sales pitches at these conferences are sad.

In the end my workday's open sourced things are way more likely to be abandoned than many single contributor projects. Despite having funding and more contributors. Just because some VC might decide that is no longer something they want to see.

VCs consider LGPL licensed intellectual property owned by the company itself as way more risky than MIT licensed. Which is insane. But these rational actors do not really act rationally.

monetization opportunity

Wol — Sat, 15 Mar 2025 20:55:10 +0000

> if a vendor wants to delegate maintenance to the original open source developers then they need to be willing to pay for it.

Eggsackerly. Iirc, the legislation actually *bars* FLOSS authors from issuing CEs (unless, as you state, there are formal contracts in place).

Cheers,
Wol

monetization opportunity

raven667 — Sat, 15 Mar 2025 16:18:07 +0000

Isn't that effectively the EU response, commercial vendors need to take responsibility for whatever they ship including open source components, but open source developers don't have any particular burden unless they have a formal relationship to provide support, if a vendor wants to delegate maintenance to the original open source developers then they need to be willing to pay for it.

Red flag checker

mb — Sat, 15 Mar 2025 13:26:19 +0000

So, let's run it on itself then

>* ⚠️ Contributions: The top contributor has contributed more than 75% of the contributions of the next 10 contributors
>* ⚠️ Contributions: The last commit made by a human is more than 90 days old (192 days)

It basically is a single-author project and it basically hasn't been changed in two years.
Pretty red, eh? At least according to their own standards.

This tool is dangerous.

What I experience (personally) is that attacks from companies to Open Source projects are ever increasing.
I see that companies take stuff, violate my licenses, and then get angry if I don't support them in my free time.

And then, some guy comes and insults me that me being the only maintainer is a red flag.
Thanks.

monetization opportunity

roc — Fri, 14 Mar 2025 22:09:57 +0000

Surely there is an opportunity here to solve the open-source monetization problem: make the software open-source but charge for compliance. Require commercial software vendors to collect certificates that their dependencies are properly maintained, and let maintainers charge to provide those certificates.