Agreed.

What made Linux the most widely used and successful OS was Android. But Linux and *BSD have fairly similar numbers of installations. You have 2.5 billion Apple devices (mac, iOS, etc.) versus 4 billion Android devices, you have more iOT devices on Linux, but a LOT more commercial routers and switches and other hardware on *BSD. It's really hard to calculate, but the numbers are probably within +/- 20% of being the same.

The problem is, none of those devices really qualify as Linux in any meaningful sense. Sure, they run the kernel, but that's about it. The user-space tools that GPL had such a big influence on are not there at all. Take all the iOT devices and Android devices and Chromebooks out of the picture, and Linux ends up actually being less popular than *BSD (because of macOS).

So whether Linux is or is not the most widely used OS depends on how you measure it.

I don't see any real evidence for what you're saying. Linux succeeded more because it had better support for PC graphics hardware early on, and the *BSDs didn't get a chance to really catch up. And the AT&T-Berkeley lawsuit stalled BSD development and adoption during the early 90s as well. And the *BSDs were fragmented into multiple camps (386BSD forked into FreeBSD and NetBSD, and then NetBSD further forked into OpenBSD), while the only forking on the Linux side was over distros. The lack of a strong, central leader likely made a far bigger difference than anything else.

All of these things led to Linux having more people working on it early on, and ultimately, the group with the most developers wins. Maybe GPL got them slightly more developers, or maybe it didn't. There's really no way to know. But my guess is that for every extra developer who joined because of the GPL, there were two corporate developers who didn't join because of the GPL, so I highly doubt you are correct in your assessment.

At best, GPL made it harder (but not impossible) for hardware developers to ship closed-source drivers, which made it easier to keep supporting old hardware, which probably resulted in a slight increase in the thickness of the long tail of the user base. Whether this is a meaningful benefit or not is unclear, because it also comes with the extra overhead of continuing to support that long tail. :-)

You don't have control over users. For my ancient Free projects, I've always hosted them on my own personal site. However because they are GPL, some people "helpfully" host a copy on GitHub. I don't particularly like it but they've done it. I don't update their copy or fix any bugs there.

Why not? Anything is possible in America!

No, statutory damages are per work. The minimum is $200 if the violator could show reasonable cause to have believed that the infringement was fair use, and the maximum is $150,000 in cases of willful infringement. The nominal range is $750 to $30,000.

To receive more than that requires showing actual damages. What this means is that even if there are a hundred GPLed projects whose licenses are being violated, short of proving willful infringement, apart from in injunction against further violations, the most they would likely get without showing actual damages is $3 million dollars, which is a slap on the wrist. And it's unclear how to show actual damages for something that you give away for free.

You *might* be able to make the claim that each new product line is a new infringement, but that's about the limit to what is realistic.

If you get proprietary software and then make a derivative work, you have violated copyright. It isn't just proprietary. It can't legally exist.

People use that term for licenses that meet a specific criterion — that using code under the license compels authoring other code under that license.

GPL and AGPL are viral, because when you use code under that license in larger projects, unless all integration occurs through a non-code interface (e.g. pipes), the larger project must be licensed under GPL or AGPL. In effect, code written under those licenses infects other code that you might want to link with them.

And it's even a problem in the open source world. There are open source licenses out there that are incompatible with GPL, such that you can't legally release a binary that combines the two. This is why, for example, unless something has changed recently, you cannot distribute a precompiled version of ffmpeg with all of the options turned on, because doing so with GPL bits turned on forces FFMPEG to be distributed as a whole under the GPL, and other open source components have non-reverse-engineering clauses that preclude their release under the GPL, which makes the resulting binary undistributable. Effectively, the GPL kills the patient at that point.

LGPL is not viral, because as long as you release any changes that you made to the LGPL code itself, you can link it with closed-source software. The same is true for *BSD and MIT and Apache licenses. These licenses don't infect unrelated code merely because of using the public APIs in those open source projects.

And I get that you don't think this is a problem, because you've drunk the whole Free Software Kool-Aid, but there's a reason I've been saying for more than two decades that using GPL for libraries is bad. Making it impossible to use a library in closed-source software does not harm closed-source software vendors, contrary to the FSF's beliefs. Rather, it causes those companies to cast aside the GPLed software and rewrite it.

And this is what almost always happens. If you write a library under GPL, someone will eventually need that library for a closed-source project, they will see the license, and decide to write a replacement. And after a while, it will become better than the GPL library that it replaced, because there will be a large number of people getting paid to do work on it, rather than it being someone's hobby project.

For an extreme example, we have only to look at compilers. For years, the FSF touted GCC as the crown jewel of GPL-licensed software. But a combination of being slow to upstream patches from commercial companies and an unwillingness to allow for integration of the core parser bits under a more permissive license eventually drove Apple to write their own compiler (clang) under a more permissive license. And now, clang-llvm outperforms GCC significantly, so much so that the latter is a legacy compiler outside of the Linux world, and is starting to gain real traction even in the Linux world.

Viral licenses really don't work. In theory, if it's a tool or application, GPL works great. It keeps people from creating a private fork, and keeps development out in the open. But it's also not meaningfully better than LGPL, though, because nobody links against an app. And the downside is that if somebody later comes up with an interesting use case for part of the app, but doesn't want to make that be open source for whatever reason, one of three things happens: they convince the original GPL code developers to relicense it (which is remarkably hard except for largely-single-contributor code), they rewrite it from scratch under a different license, or the idea dies as infeasible. See also GCC.

So I would argue that even for applications, it makes a lot of sense to use LGPL for everything except for the user interface code. License anything that could even potentially be used as a library under LGPL to maximize the potential for reuse while still keeping changes out in the open.

But I digress.

Ok... you have me questioning the details now, but the AI overview I just checked says:

"Yes, Apple's M-series chips integrate the RAM directly onto the processor package. Because the memory is built-in as "Unified Memory," it cannot be upgraded or replaced after your Mac or iPad is purchased."

Yep... back as far as 2006, several execs were indicted for price-fixing RAM:

https://www.justice.gov/archiv...

There was a class action lawsuit in 2018 over the same issue.

I assume Apple, at least, feels they've taken steps to control RAM availability with their transition to the M series ARM processors, because they integrate the memory and the video memory into the CPU itself?

I had to look "G Suite" up because I had no idea what it was, it turns out that the only component I've ever used is gmail and that became necessary when I bought my first Android device after the "Email of death" killed Nokia's Symbian. I don't actually use gmail, it's the hook used for Android App updates.
Charging for Gmail is unthinkable, that would have so many knock-on effects.

They're not gambling if you have a real-world stake in an outcome addressed by one of these markets.

That definition is bonkers. If I gamble in a casino, I have a real-world stake in an outcome. If I turn to my neighbour and make a side bet about the outcome of my primary bet, it doesn't become insurance, it's just another bet.

Secondly, calling them markets seriously is also bonkers. They are full of insider traders and professional quants who take most of the money from stupid college kids who are desperately worried about their future employment prospects. These are markets in name only, and you're falling for it.

Thirdly, Kalshi and Polymarket both make side deals with the large finance companies for billion dollar investments. The product is you. Well, your money, they don't care about you. Jane Street is the top performer in this space and has repeatedly been found guilty of insider trading and market shenanigans all over the world. Good luck hedging your "real-world stakes" against those guys.

They still have those? I would have thought that everything was sent electronically by now, and nobody hand-entered anything except for bank tellers and other people who are dealing face-to-face with customers.

Then again, I remember how hard it was to do an international wire transfer a few months back, and how my bank faxed paperwork back and forth to their back office, so I guess that's plausible.

The unfortunate thing, though, is that for the most part, any use of AI to do that stuff is a mistake, because you should be shifting the burden of data entry (and thus the burden of correctness) to the customer by doing everything electronically to the maximum extent possible. The fact that banks use paper forms in the first place is the flaw, and replacing the person who types the contents of the form with AI is just replacing one error-prone, bank-at-fault process with another, when they should be shifting the liability for error to the customer. This also has the advantage of reducing the likelihood of error, because the customer had to fill all that info in on the form in the first place, so you have one opportunity for error instead of two. This also has the advantage of usually making it easier for the customer, because the customer doesn't have to do stuff in person. And so on.

Show me this software that you consider usable enough to replace more than about 5% of what a software engineer does.

Depends on what you mean by AI. If you mean specialized trained models that do very specific things (e.g. optimizing just-in-time component purchases or using computer vision to make robots work more effectively, making stock picks, spotting tumors on scans, and optimizing ad spend to get the best results), then yes. If you mean LLMs, I think you missed the mark with your list (except maybe ad creation; that's plausible).

LLMs are great for automating trivial work as long as there's no high financial cost for mistakes. Chat bots to help you search for products on a website better are a great example. Or LLMs to help you write the skeleton for new code or help you write unit tests (as long as you check the results). Or LLMs to help you look for bugs in code or review code before submission. Or LLMs to help you create prototypes of new software while deciding what approach you want to take. Or LLMs to quickly create artwork for fun, where you don't care if there are extra fingers.

LLMs are not great when there is high risk. Chat bots for airline customer service are a great example. Turning LLMs loose writing code without a competent programmer looking over its shoulder is another good example.

In between are the use cases where it functions adequately, but may not save much time, because the overhead of reviewing its work adequately is a sizable percentage of the time required to do the work by hand. Writing real-world production code is a great example.

Presumably it will get better over time. But whether it will ever reach a level of trust where we can turn it loose to write code and not carefully scrutinize that work, I couldn't say. Right now, there's too much risk of it saying that tests pass when they actually haven't been run, or worse, when the AI has decided to delete the tests so that they won't fail. There's too much risk of gaslighting across the board. There's too much risk of AI subtly misinterpreting prompts in extremely creative ways to give you results that look like they are correct but are actually wrong. And so on.

I'm going to assume for the moment that the C-suite at Meta are not complete and utter morons. So from this, we can conclude that Meta is firing people not because they actually believe AI will do their jobs, but rather because they don't have enough revenue to pay for their AI hardware costs, and they're hoping that they can get away with counting on their near-monopoly on social media to let them safely unstaff large parts of Facebook, Instagram, and other services in the short term so that they can build their data centers.

And while that might be true (because the DOJ let Facebook get way, way too big), that's a stock price disaster waiting to happen. It's risking throwing away the whole company to spend more money on Facebook's LLM technology, which might still never be good enough for them to actually make money at it. It made sense to do that work up to a point, because they could benefit from it internally for things like abuse detection. But trying to productize it without adequate rounds of funding is a mistake. If they truly think their tech is up to snuff, they should spin it off into a separate subsidiary and do rounds of financing to pay for the cost, with separate stock offerings.

After that, you should tell them to also build a Thunderdome so that all the AIs can fight each other in leather rags, while playing the new tune on loudspeakers. There's only one rule: Two AI enter, one AI leaves.

That's a well known side effect of mathematics! May I suggest using an LLM to count them for you?

There's a lamb! That makes one!
Look,another lamb! That makes two!
Another lamb! That makes four!
And one more crocodile! That makes five!
There's another lamb! That's six!
...