A backdoor in xz

Posted Mar 31, 2024 3:47 UTC (Sun) by rra (subscriber, #99804)
In reply to: A backdoor in xz by kleptog
Parent article: A backdoor in xz

I agree that working out the right way to do this would be hard. Nothing about this problem is easy; if it were easy, we would have done it already. But the cracks are showing in how we're doing this now. (If only this weren't true about dozens of other things about our modern world, several of which are significantly more important than free software.)

But, that said...

> Taxes are a very blunt instrument because they completely divorce the people who use the product from the people who pay for it.

This is exactly why I find the library model interesting: there's a feedback loop. Corporate products, services, and infrastructure that use free software vote with their choices. We figure out some way to count those choices (I know, I know, complexity of the software should be a factor, how to do this is very inobvious, insert vigorous hand-waving here), and an appropriate percentage of the revenues of those companies go to the maintainers of that software. If companies stop using their software, they stop getting money. If more companies use their software, they get more money.

I personally don't like that everything in society is denominated by money (this, ironically, is part of why I write free software; I like being motivated by community rather than money), but if I want free software developers to slow down, take a breath, be more methodical, and be able to take the time to do things properly, well, most of those things require money in some way. (Not *only* money, of course.) I think we need to find ways to derisk going part-time, or taking a year between jobs to work on free software, or making a living writing free software infrastructure, if we want to get ahead of our growing maintenance crisis.

A backdoor in xz

Posted Apr 1, 2024 15:30 UTC (Mon) by kleptog (subscriber, #1183) [Link]

> This is exactly why I find the library model interesting: there's a feedback loop. Corporate products, services, and infrastructure that use free software vote with their choices.

Ok, so that's a different model. That kind of thing exists as levies for other things. Like the "thuiskopieheffing" (home copy levy) which is basically an extra charge on writable CDs/DVDs and other media which is distributed to copyright holders as compensation for the fact the people copy stuff for own use. Or the charges on appliances that pay for the collection and recycling at end-of-life.

You could, in theory, add a 1% levy on all digital products/services and then via that hand-waving you were referring to, distribute to the developers/maintainers of open-source. The justification being that all digital products/services depend on open-source anyway, this is a way for finance it. I don't think this idea is completely ridiculous, if someone could actually work out the details it could actually happen.

The details however matter. Because it's not just a money problem. Even if tomorrow there was a fund available to pay for all the maintenance of open-source software, the social structures doesn't exist to make it happen. Are there enough people who actually want to do the required work, even if they were paid? How do we ensure the work is actually done? Figuring out which projects is the easy part. Can we trust the people who actually do it?

The financing of maintenance of open-source software is a long-standing problem and simply throwing money at it isn't going to solve it. You first need to figure out *how*, then you can discuss where to get the money from. I think the CRA is a step in the development of the business models that will improve the funding situation in the future but I don't think we yet know how this will work out.

A backdoor in xz

Posted Apr 2, 2024 16:12 UTC (Tue) by GNUtoo (guest, #61279) [Link] (1 responses)

> This is exactly why I find the library model interesting: there's a feedback loop. Corporate products, services, and infrastructure that use free software vote with their choices. We figure out some way to count those choices (I know, I know, complexity of the software should be a factor, how to do this is very inobvious, insert vigorous hand-waving here), and an appropriate percentage of the revenues of those companies go to the maintainers of that software. If companies stop using their software, they stop getting money. If more companies use their software, they get more money.

The issue here is the side effects. For instance what would prevent companies from writing extremely used software with poor security track record and try to get money to fix things after the fact when the design is bad, or that even bigger foundations than the design is bad (use cases impossible to secure, etc).

And if it somehow works it could also make very secure software that go in conflict with freedom or other things we care about (like inclusiveness, making old hardware continue to work, etc).

A slightly better approach would be to look at the NLnet approach and somehow adapt it for improving security maintenance.

Micro-grants for small period of time are probably not ideal to fund long term maintenance, so that could probably be adapted/changed, along with the metrics to decide when not to pay (it's probably easier to look if a specific task is done than assert the usefulness of maintenance tasks), but the fact that highly competent people decide what to fund and not to fund and have a strategic vision for FLOSS is probably something that we need.

This could avoid the most problematic perverse incentives, and the cost here would probably be the subjectivity of the people that decide what to fund or not to fund, and here having diverse people could help but probably won't fix everything.

But at least it would be better than the other models mentioned here before.

A backdoor in xz

Posted Apr 3, 2024 13:17 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

> The issue here is the side effects. For instance what would prevent companies from writing extremely used software with poor security track record and try to get money to fix things after the fact when the design is bad, or that even bigger foundations than the design is bad (use cases impossible to secure, etc).

First, to me, would be the interesting question of how a "poor security track record" ended up "extremely used" under the regulation threat looming. Besides that…if it is FOSS, who says the company gets the contract? Even if not, there could be some source escrow (something I would love to see for "critical" software). Either way, a bidding process can help with prices. Allow the "core maintainer" entity to usurp the lowest bid with, say, 10% overhead if they way to do it themselves and retain "power", but that can help curb gouging at least. Also allow bids to create a compatible replacement. Not that procurement doesn't have collusion, greased hands, and other situations, but it is at least something familiar.