Well, Claude has the best personality in a field where the rest are in a race to make the most awful personality. That's kind of a moat. The models were smarter too though the others have largely caught up, especially Gemini.
Bubbles bursting aren't bad unless you were overinvested in the bubble. Consider that you'll be wiping your ass with DIMMs once this one bursts; I can always put more memory to good use.
> Bubbles bursting aren't bad unless you were overinvested in the bubble.
That's what I am trying to say: every big technology player, every industry, every government is all in on AI. That means you and I are along for the ride, whether we like it or not.
> Consider that you'll be wiping your ass with DIMMs once this one bursts; I can always put more memory to good use.
Except you can't, because DRAM makers have almost entirely pivoted from making (G)DDR chips to making HBM instead. HBM must be co-integrated at the interposer level and 3D-stacked, resulting in terrible yield. This makes it extremely pricy and impossible to package separately (no DIMMs).
So when I say the world is all in on this, I mean it. With every passing minute, there is less and less we can salvage once this is over; for consumer DRAM, it's already too late.
As far as I understand it, Richard Stallman has gotten his view about linking from FSF’s lawyers, who has advised the FSF about what does and does not count as a “derived work”, in the sense of US copyright law.
If you want to argue that the FSF’s lawyers are wrong, please provide more detailed, and hopefully referenced, arguments (as opposed to plain assertions).
FSF has opinions but not case law - anyone else's opinion is as valid, there's no citation because no court has ruled that dynamic linking is or isn't a derivative work.
You have to construct your own view based on existing statute and vaguely related cases.
Google LLC v. Oracle America, Inc., 593 U.S. 1 (2021) is not a pro-FSF opinion.
Whether linking (dynamic or not) is a derivative work is defined by things like incorporation, similarity, and creative expression.
I think the FSF view is unreasonably confident in its public opinions where the current law is that each potential infraction is going to be decided on a case by case basis. Read 17 USC 101 for yourself and square that with FSF/Stallman opinions.
There's too much nuance to have a stance about what happens when you link a program. "It depends" is the only thing you can say.
>Google LLC v. Oracle America, Inc., 593 U.S. 1 (2021)
does not apply to the linking of GPLed code. Google copied just the application programming interfaces and then supplied their own code that they wrote themselves.
if you link to a GPL library you are including their copyrighted code, even if the API that GNU uses did not originate with them but came from POSIX or similar.
I would point towards Oracle v. Rimini, where the Ninth Circuit has specifically ruled (inside a complex and yet-unresolved case) that a system built to interoperate with a copyrighted program does not constitute a derivative work of that program. (https://cdn.ca9.uscourts.gov/datastore/opinions/2024/12/16/2...)
They reference a less on point but better known case (https://en.wikipedia.org/wiki/Lewis_Galoob_Toys,_Inc._v._Nin...., for some reason you have to manually add the period at the end of the link) about whether NES cheat cartridges were copyright infringement. If a work that directly links to and interoperates with a program is a derivative work of that program, the Game Genie really was illegal after all. To me that doesn't seem right, and given the FSF's general opinion on console restrictions (https://www.fsf.org/bulletin/2025/winter/new-nintendo-drm-ba...) I kinda feel like they'd have to agree.
On some sites it's possible to work around this type of linkification bug by percent-encoding the last character (percent symbol followed by 2 hex digits representing the ASCII character):
i don't see how either of those cases applies to the FSF and GNU's attitude on library linking; in neither case were they creating a combined derivative work.
if I make an ai driven viewscreen that you can stick your paperback book into and it gives you a better reading experience of the book, your paperback book is still in there and you can take it out. My viewscreen may not work without the book, but it hasn't merged/modified the book with anything.
I guess I would say that you've illustrated the problem precisely. Dynamically linking to a GPL library in your program clearly does not combine your program with the library: the library's still there, you can see the .so/.ddl file sitting separately on your computer, it hasn't been merged with your program and your program didn't modify it. Yet the FSF still claims it's a combined derivative work.
Am I misunderstanding something about the analogy?
Ehh, I'm not sure it's fair to call the FSF dynamic linking absolutists. They only care about any of this because they've boxed themselves into a corner. They want to prevent people from writing proprietary wrappers around copyleft programs, but they don't want a license so restrictive that proprietary and copyleft programs are forbidden from interacting, and Freedom 0 means they can't explicitly prohibit a copyleft program from being used for suchandsuch purpose.
Not the kernel, but LGPL libraries do have relevant carveouts. And if you've ever heard RMS speak, he is extremely particular and does understand the nuances of all this.
reply