Oh, yeah. GPL V3 is spectacularly unfriendly to commercial development of anything — enough so that Apple created Clang, which has cut GCC's market share almost in half, massively damaging the long-term viability of the FSF's golden goose. And since the release of V3, GPL development has declined massively to maybe a third of what it was before GPL v3.

GPL v3 was widely regarded by almost everyone in the tech industry as a boneheaded move. It still is.

The reality is, if you're a BSD distro, folks kind of expect the whole thing to be BSD-licensed, or else what's the point. So having GPL-licensed bits is the sort of thing that they try to avoid. They held their noses and put up with gcc until clang got good enough. There are probably other examples. But there are really good reasons from a "we want you to be able to drop our stuff into any commercial situation and use it without worrying about licensing" perspective why they would want to avoid bringing in additional GPL if at all possible. :-)

A lot of us who do understand it very well also shirk away from GPL, and V3 in particular. It's messy when you're shipping a boot loader that gets loaded onto hardware. This is not to say that having the source available isn't a good thing, but there's no guarantee that users will be able to update it even if they have the source, thanks to code signing requirements, etc.

Besides, consider how many ARM board manufacturers don't bother to contribute their patches to mainline Linux and end up with hardware that is borderline unsupported after a couple of years, rather than contribute back. They comply with the GPL fully, making their code available, but the notion that the GPL somehow magically forces them to contribute back in a meaningful way is just wishful thinking. In reality, it's a giant pile of forks.

It may surprise you that most bigger developers do share it back. A sizable percentage of the development work done on *BSD comes from commercial contributors who are hired by companies that use the software. Turns out it's really beneficial to have your code merged in so that you're not constantly chasing a moving target or re-fixing bugs that other people have fixed because you decided to close things off and fork.

They can, but those "plenty of examples" tend to get rewritten eventually, because GPL code in *BSD has a bit of a stench.

Either way, they probably won't use it at all. Realistically speaking, here's what you can expect: The OpenBSD folks will fork at the last version that was licensed under MIT. They'll continue doing development on their fork, independently fixing bugs that affect them, and not contributing them upstream to the GPL-contaminated fork. After all, it's not like the OpenBSD folks are strangers to forking things. L8-)

Not really. MIT licenses might not give an incentive to contribute back, but most larger companies that use MIT-licensed code do, in fact, contribute back. By contrast, GPL v3 is so toxic that with the sole exception of my first tech employer (which was a Linux distro), no company I've ever worked at will touch it with a ten-meter pole.

Moreover, the GPL does not force you to give back, either. You can GPL something, and someone can use it indefinitely in a modified state without ever giving you the changes back. Someone can even create their own fork on GitHub and commit millions of changes and never send you a pull request or tell you that they did it. They have to give the source to their users, not yours. And this problem exists even in V3, and indeed, even in Affero V3.

So the notion that GPL somehow makes a project less stagnant is seriously wishful thinking. All the GPL does is eliminate most corporate contributors. The problem of getting people who change your code to actually give the code back to you in a usable form is exactly the same regardless of license.

It may have been generated in 2025, but the copyright on the man page itself says OpenWall 2017.

Realistically, I don't care what language Claude runs commands in when working on a project. That doesn't have to match the language of the project. My preferences for what commands the tool is allowed to run have basically nothing to do with the project, with the exception of me expecting it to not access files outside a per-project sandbox, which should be just a list of directories that are part of the project.

Either way, the fact that a project can encompass multiple directories means that metadata about the project shouldn't live in that directory.

But even if we assume that for some reason, I care whether it tries to use the wrong git repo and the wrong password (which wouldn't make a lot of sense, given that the .git file should tell what repo to use), the list of allowed commands still does not belong as part of the project data, because what I as a developer am willing to tolerate is not necessarily the same as what someone else as a developer on that same project is wiling to tolerate. It is inherently a per-user choice, not a per-project choice, which means it doesn't belong within ten thousand miles of the project directory.

There are exactly two valid places to store it: the app's preferences or a separate per-project configuration file that lives outside the data container (e.g. $HOME/.claude/projects/project_name). And in an ideal world, you'd have multiple configurations that you can choose from, e.g. one permission set that grants it more access than others, depending on what you're working on. And when you create a new project, you'd choose which permission set to use, e.g. "Project directory only", "Team Drive and project", "YOLO", etc.

But either way, no matter where it lives, it should not there.

Just because other questionably designed systems made the same mistake, that doesn't mean it isn't a mistake. For one thing, it's a security red flag the size of a planet in this context. If that file lives in the project directory, that means it's presumptively inside the writable part of the sandbox, which means nothing prevents Claude from rewriting that file to grant itself additional permissions. Compared with that, the potential for leaks is just the icing on the cake.

This isn't a grey area. That data has security implications at multiple levels, and it *absolutely* should *never* be anywhere *near* the project directory, period.

Next to is not inside. If it were up one level, right next to the git root, we wouldn't be having this discussion. It wouldn't end up in the repository, it wouldn't be inside Claude's sandbox, and it wouldn't be a security hole from h**l.

But I'd prefer it to be in the app's preferences, so that it gets nuked when the app settings get nuked.

There’s a trivial fix: Sue Anthropic for storing this in the project directory instead of in a centralized preferences file like any remotely competent software developer would have done. The only reason this is a problem is because they deliberately mixed public data and private metadata in the same directory.

I'm not saying that the mode doesn't exist, and I'm not saying Tesla isn't saying that they will disclaim warranty coverage if you wash your car without using it. I'm just saying that none of the things that it does should reasonably cause the car to be seriously damaged, and if that happens, something was wrong with the car to begin with.

More to the point, I'd be willing to bet that a court would laugh at them and find them liable anyway because of the sheer unreasonableness of expecting someone to put a car in a mode just to wash it, not to mention that they would have to prove that the car wash mode somehow would have prevented whatever the damage was, which just seems really unlikely given what it does, and also prove that a reasonable person would not consider whatever design decision made that unnecessary to be a defect in design or workmanship.

In other words, my words to Tesla are "Good luck with that."

There's no such thing as clean natural gas. Even if you have no methane leaks, you're still producing CO2.

And no, the solar farm to power a gigawatt data center would be only about 10 square miles or so. It's big, but it's not "small state" big.

I mean, there were multiple Toyota cars recalled for the same thing, so at least they're in good company.

Yeah, that's a bad design flaw.

That's rather exaggerated. If that were the case, they'd be dying every time it rained. The car wash mode just puts the car in neutral and keeps it that way after you get out of the car. It's needed only for the sorts of car washes that roll your car through.

This is why I said that it is not necessarily done on-site. The point is that the bigger companies tend to spend money on grid capacity to offset their usage, with a strong preference towards green energy, because that tends to be cheaper than burning natural gas.

You have those backwards. The 2017 man page says that there is an option for returning a string starting with "*", depending on how the library was configured. The 2018 man page says that it returns NULL on failure... because they realized eight years ago that a non-NULL return on failure was a mistake.

The problem with the Cybertruck isn't its design. The problem is its cost. It costs almost twice as much as an F350, with half to two-thirds of the bed capacity, half the towing capacity, and as little as half the range.

If CyberTruck sold for $35,000, people would buy it, because it would be competing head-to-head with the F150.

If Elon had shipped the battery extender that was originally promised, had made long bed versions so that you'd still have actual bed capacity remaining after installing it, and had doubled the towing capacity, people would buy it.

But instead, he delivered something that was a fraction of what was promised, at a quarter of the value per dollar of the competition, and then wondered why his little "I'm a far-right winger" stunts failed to attract sales from the rural South. It was never about his politics. It was always about value for the money. All his stunts really did was cost the company sales in California.

Bear in mind that the jet engines were Elon Musk's data centers, not Anthropic's, nor those of any other even remotely competent tech company. You have a company run by someone who things anthropogenic climate change is a myth choosing a high-pollution power solution that costs more per kWh just to piss off the environmentalists. The problem isn't the data center. The problem is the person building it.

Most data centers aren't going to use a jet engine. They're going to use a solar farm during the day and grid at night, or they're going to put in massive battery banks and go off-grid entirely. It's cheaper and better for the environment. Maybe the power production will be off-site and connected over the grid, or maybe it will be on-site, depending on location, or maybe they'll pay to build solar production and power storage to offset their consumption, but either way, that's the way things are mostly trending.

Same is true for water use. The big companies try to reduce their water use, because that's an ongoing cost, and they'd rather spend more up front than pay for their mistakes forever. And they can do that, because they have the money to spend up front. It's mostly the little fly-by-night startups that produce eco-disasters, because their main concern is avoiding spending unnecessary capital costs on construction that they don't have, and hoping that the higher ongoing costs won't bankrupt them before they become cash-flow-positive and can start building better data centers that are less awful.

Funny, the Linux man page for crypt says it returns NULL on error. Same with the Mac man page.

Anybody who thought that returning a string on error was a good idea just because some badly written piece of code might crash should never be allowed to write software. Let it crash. Fix the bug in the other software. Working around one bug by creating a second bug is pretty much always a mistake unless it is targeted sufficiently to prevent the bug from causing further harm.