You've been misled.

Irrelevant strawman, since you're not accusing the dnsmasq package in Debian stable of being straight-up broken.

They are not expected to deal with this. This is the responsibility of the Debian package maintainer.

If you (as an upstream) licensed your software in a manner that allows Debian to do what it does, and they do this to serve their users who actually want that, you are wrong to then complain about it.

If you don't want this, don't license your software like that, and Debian and their users will use some other software instead.

For what you want, there are other distributions for that. Debian also has stable-backports that does what you want.

No need to rage on distributions that also provide exactly what their users want.

Looking upthread, we seem to be talking about Claude. Claude is cloud-hosted inference but the harness is local if you're using Claude Code, and can be MITM'd there.

My theory is that lawyers tend to lean on the law to protect them more than others might. "I can ensure that it would be illegal for them to them to expose this data; therefore this method is safe" vs. "If they expose this data, is that a situation I want to deal with?".

I have been wondering if it's more geared at reducing resource usage, given that at the moment there's a known constraint on AI datacenter expansion capability. Perhaps they are struggling to meet demand?

If they all refuse, then they're leaving money on the table. One investor could invest in 10% production only, and that would be very lucrative. It would be exactly my low cost to produce potato scenario.

In practice, they don't all refuse, or all invest. The market finds a balance. In time, producers switch to the new method, because anybody who doesn't leaves an opportunity for someone else to take their business and make more money.

This takes time, though. If we want things to go quicker, then we need to guarantee return on investment for longer, which is exactly what the government does by guaranteeing prices to renewable energy producers.

No, because remember you are only able to meet 10% of market demand. The expensive producers will still get 90% of the business, and the market price for their product will remain basically the same. This is what we observe in the electricity markets today: the price to us is the cost of the most expensive product. The cheaper producers who cannot meet the full market demand still get to sell at the cost of the most expensive product.

This is how markets are supposed to work. It provides an economic incentive for production to increase, which is what we want.

Consider what happens if you develop a farming method to produce potatoes for a fraction of the usual cost, but you can only meet 10% of total demand at your local market. What price are you going to sell your potatoes for when you show up to the market? You (like any free market seller) want to maximise your return, so you'll be able to sell for a fraction under the previous market rate, undercutting everyone else. Your farming method would be extremely lucrative.

Sure, but Microsoft have to strike a balance, too. If they push too hard in this direction, they'll lose their users to Macs on one side (probably the majority) and Linux on the other (a minority in number, but perhaps significant in expertise and clout). Once an exodus begins, it's much harder to stop. So where we are in that balance, and the state of user mindshare migration, is still interesting to discuss.

Sure, you might neglect to add a file to your commit, or commit at all, but that's a problem whether you're pushing to a central public git forge or not.

We have Flatpaks to solve this problem too now, but AFAICT while Flatpaks do support sandboxing the UX for that is such that most Flatpak non-power-users aren't enforcing sandboxing on Flatpaks they install, so in practice the feature isn't present where it's most needed.

"District Court Finds That Using Copyrighted Works to Train Large Language Models Is Fair Use"

https://www.finnegan.com/en/insights/ip-updates/district-cou...