I wonder what the PGP signing concept does to thwart people who want to profit and don't care about the public good. It seems like anyone who attends a signing party can sell their key to the highest bidder, leading to bots and spammers all over again.
In the flat trust model we currently use most places, it's on each person to block each spammer, bot, etc. The cost of creating a new bot account is low so it's cheap to make them come back.
On a web of trust, if you have a negative interaction with a bot, you revoke trust in one of the humans in the chain of trust that caused you to come in contact with that bot. You've now effectively blocked all bots they've ever made or ever will make... At least until they recycle their identity and come to another key signing party.
Once you have the web in place though, a series of "this key belongs to a human" attestations, then you can layer metadata on top of it like "this human is a skilled biologist" or "this human is a security expert". So if you use those attestations to determine what content your exposed to then a malicious human doesn't merely need to show up at a key signing party to bootstrap a new identity, they also have to rebuild their reputation to a point where you or somebody you trust becomes interested in their content again.
Nothing can be done to prevent bad people from burning their identities for profit, but we can collectively make it not economical to do so by practicing some trust hygiene.
Key signing establishes a graph upon which more effective trust management becomes possible. It on its own is likely insufficient.
Also add a PR reviewer bot. Give it authority to reject the PR, but no authority to merge it. Let the AIs fight until the implementation AI and the reviewer AI come to an agreement. Also limit the number of rounds they're permitted to engage in, to avoid wasting resources. I haven't done this myself, but my naive brain thinks it's probably a good idea.
I believe the GP post is saying that if we react to the new AI-enabled environment by arbitrarily strengthening IP controls for IP owners, the greatest benefactors will almost certainly be lawyer-laden corporations, not communities, artists, or open source projects. That seems like a reasonable argument.
It seems like the answer is to adjust IP owner rights very carefully, if that's possible. It sounds very hard, though.
The article makes the same point; the quote was taken out of context.
The point the author was making was that the intent of GPL is to shift the balance of power from wealthy corporations to the commons, and that the spirit is to make contributing to the commons an activity where you feel safe in knowing that your contributions won't be exploited.
The corporations today have the resources to purchase AI compute to produce AI-laundered work, which wouldn't be possible without the commons the AI it got its training data from, and give nothing back to the commons.
This state of things disincentivizes contributing to the FOSS ecosystem, as your work will be taken advantage of while the commons gets nothing.
Share-alike clause of the GPL was the price that was set for benefitting from the commons.
Using LLMs trained on GPL code to x "reimplement" it creates a legal (but not a moral!) workaround to circumvent GPL and avoid paying the price for participation.
This means that the current iteration of GPL isn't doing its intended job.
GPL had to grow and evolve. The Internet services using GPL code to provide access to software without, technically, distributing it was a similar legal (but not moral) workaround which was addressed with an update in GPL.
The author argues that we have reached another such point. They don't argue what exactly needs to be updated, or how.
They bring up a suggestion to make copyrightable the input to the LLM which is sufficient to create a piece of software, because in the current legal landscape, creating the prompt is deemed equivalent to creating the output.
You can't have your cake and eat it too.
A vibe-coded API implementation created by an LLM trained on open source, GPL licensed code can only be considered one of two things:
— Derivative work, and therefore, subject to the requirement to be shared under the GPL license (something the legal system disagrees with)
— An original work of the person who entered the prompt into the LLM, which is a transformative fair use of the training set (the current position of the legal system).
In the later case, the input to the LLM (which must include a reference to the API) is effectively deemed to be equivalent to the output.
The vibe-coded app, the reasoning goes, isn't a photocopy of the training data, but a rendition of the prompt (even though the transformativeness came entirely from the machine and not the "author").
Personally, I don't see a difference between making a photocopy by scanning and printing, and by "reimplementing" API by vibe coding. A photocopy looks different under a microscope too, and is clearly distinguishable from the original. It can be made better by turning the contrast up, and by shuffling the colors around. It can be printed on glossy paper.
But the courts see it differently.
Consequently, the legal system currently decided that writing the prompt is where all the originality and creative value is.
Consequently, de facto, the API is the only part of an open source program that has can be protected by copyright.
The author argues that perhaps it should be — to start a conversation.
As for who the benefactors are from a change like that — that, too, is not clear-cut.
The entities that benefit the most from LLM use are the corporations which can afford the compute.
It isn't that cheap.
What has changed since the first days of GPL is precisely this: the cost of implementing an API has gone down asymmetrically.
The importance of having an open-source compiler was that it put corporations and contributors the commons on equal footing when it came to implementation.
It would take an engineer the same amount of time to implement an API whether they do it for their employer or themselves. And whether they write a piece of code for work or for an open-source project, the expenses are the same.
Without an open compiler, that's not possible. The engineer having access to the compiler at work would have an infinite advantage over an engineer who doesn't have it at home.
The LLM-driven AI today takes the same spot. It's become the tool that software engineers can and do use to produce work.
And the LLMs are neither open nor cheap. Both creating them as well as using them at scale is a privilege that only wealthy corporations can afford.
So we're back to the days before the GNU C compiler toolchain was written: the tools aren't free, and the corporations have effectively unlimited access to them compared to enthusiasts.
Consequently, locking down the implementation of public APIs will asymmetrically hurt the corporations more than it does the commons.
This asymmetry is at the core of GPL: being forced to share something for free doesn't at all hurt the developer who's doing it willingly in the first place.
Finally, looking back at the old days ignores the reality. Back in the day, the proprietary software established the APIs, and the commons grew by reimplementing them to produce viable substitutes.
The commons did not even have its own APIs worth talking about in the early 1990s. But the commons grew way, way past that point since then.
And the value of the open source software is currently not in the fact that you can hot-swap UNIX components with open source equivalents, but in the entire interoperable ecosystem existing.
The APIs of open source programs are where the design of this enormous ecosystem is encoded.
We can talk about possible negative outcomes from pricing it.
Meanwhile, the already happening outcome is that a large corporation like Microsoft can throw a billion dollars of compute on "creating" MSLinux and refabricating the entire FOSS ecosystem under a proprietary license, enacting the Embrace, Extend, Extinguish strategy they never quite abandoned.
It simply didn't make sense for a large corporation to do that earlier, because it's very hard to compete with free labor of open source contributors on cost. It would not be a justifiable expenditure.
What GPL had accomplished in the past was ensuring that Embracing the commons led to Extending it without Extinguishing, by a Midas touch clause. Once you embrace open source, you are it.
The author of the article asks us to think about how GPL needs to be modified so that today, embracing and extending open-source solutions wouldn't lead to commons being extinguished.
Which is exactly what happened in the case of the formerly-GPL library in question.
A lot of code is "useless" only in the sense that no one wants to buy it and it will never find its way into an end user product. On the other hand, that same code might have enormous value for education, research, planning, exploration, simulation, testing, and so on. Being able to generate reams of "useless" code is a highly desirable future.
Obviously "useful" doesn't just involve making money. Code that will be used for education and all of these things is clearly not useless.
But let's be honest to ourselves, the sort of useless code the GP meant will never ever be used for any of that. The code will never leave their personal storage. In that sense it's about as valuable for the society at large as the combined exabytes of GenAI smut that people have been filling their drives with by running their 4090s 24/7.
While Rust is excellent, you must acknowledge that Rust has issues with compilation time. It also has a steep learning curve (especially around lifetimes.) It's much too early to say Rust is the "final" language, especially since AI is driving a huge shift in thinking right now.
I used to think that I would never write C code again, but when I decided recently to build something that would run on ESP32 chips, I realized there wasn't any good reason for me to use Rust yet. ESP-IDF is built on C and I can write C code just fine. C compiles quickly, it's a very simple language on the surface, and as long as you minimize the use of dynamic memory allocation and other pitfalls, it's reliable.
If you're programming for ESP, then embassy is the way to go in most cases. You don't need to learn much about lifetimes in most of the application code. Steep learning curve people refer it is "thing blow up at compile time vs runtime." It's easy to write JS or C that passes all tests and compiles and then wonderful blows up when you start using it. It just forces you to learn things you need to know at IMO right now.
My biggest problem with rust right now is enormous target/ dirs.
> My biggest problem with rust right now is enormous target/ dirs.
We're working on that and it should get better soonish. We're working on shared caches, as well as pruning of old cached builds of dependencies that are unlikely to be reused in a future build.
Several months ago, just for fun, I asked Claude (the web site, not Claude Code) to build a web page with a little animated cannon that shoots at the mouse cursor with a ballistic trajectory. It built the page in seconds, but the aim was incorrect; it always shot too low. I told it the aim was off. It still got it wrong. I prompted it several times to try to correct it, but it never got it right. In fact, the web page started to break and Claude was introducing nasty bugs.
More recently, I tried the same experiment, again with Claude. I used the exact same prompt. This time, the aim was exactly correct. Instead of spending my time trying to correct it, I was able to ask it to add features. I've spent more time writing this comment on HN than I spent optimizing this toy. https://claude.ai/public/artifacts/d7f1c13c-2423-4f03-9fc4-8...
My point is that AI-assisted coding has improved dramatically in the past few months. I don't know whether it can reason deeply about things, but it can certainly imitate a human who reasons deeply. I've never seen any technology improve at this rate.
That sounds like the recommended approach. However, there's one more thing I often do: whenever Claude Code and I complete a task that didn't go well at first, I ask CC what it learned, and then I tell it to write down what it learned for the future. It's hard to believe how much better CC has become since I started doing that. I ask it to write dozens of unit tests and it just does. Nearly perfectly. It's insane.
Please help me understand better, because it feels like part of the problem has already been solved. Specifically, I've been told that the independent journalists that I watch on YouTube Premium receive a portion of my subscription fee. Is that not a form of micropayments? The system seems to work well enough for videos. Isn't there some way to adapt that kind of system to other media?
The solution is called centralization by a middle man that takes a massive cut - eg YouTube Premium. Only Google makes real money off that, and the content creators rely on sponsors instead for their own revenue. So does it really work? I would despise a future where we solve micro transactions by giving up control to yet-another unnecessary body. Especially not even at the level of Visa or Mastercard, despite how much I dislike crypto.
No, that is absolutely 100% not micropayments, as the consumer is not paying per view/article/video whatever. They're paying a fixed fee and are not metered.
Good to know. Now I think I know why micropayments for news media never took off: because people who want to read news media probably don't want to waste mental cycles on keeping track of a micropayments account. They want a set-and-forget solution with a predictable cost. If micropayments can't fit those expectations, then the market probably wants something other than the thing we're calling micropayments.
Goes like the following:
Google/YouTube have a userbase to track accounts for; they go to a bank (licensed money transmitter, with OFAC/KYC/AML programs implemented). Google gets paid by people looking to advertise, and that money goes into Google's master account. Google's finance system translates views/impressions to money movements to creator accounts hosted at other banks (same deal, OFAC/KYC/AML program in place). The main thing is, every party that actually moves around money, operates in such a way that the entire transaction chain is followable. It's not point to point, it's hub and spoke. The hubs keep track of everything to keep the Osama Bin Laden's or Russian Oligarch's, or Cuban nationals out of the U.S. financial system.
"Micropayments" have always been something different. We technologists just figured there would be a way we could whip up some accounting software, or a spec, and allow people a way to store and transact without relying on a custodial holder, with all the extra regulation burden. Point is though, government and law enforcement don't want that, because with that, it becomes a great deal more difficult to follow the money, or to get away with things like mandating everyone report money movements over some amount to the tax authority; something easy to do when it's tacked on to the condition of maintaining your license to do business. Every money transmitter being well behaved and integrated with the state maximizes the risk for anyone attempting to utilize the financial system for illegal activity.
Ergo... What you think of as already solved isn't "micropayments". It's traditional finance in the U.S. What we refer to when we say Micropayments, is a way to store value, maintain accounts, and run point to point transactions "blessed" or recognized by the world et al without an intermediary.
Nope! That's the fun part! All the misery from the downsides, none of the upside! But imagine how much worse it could be! /s
There's a reason I'm doing anything possible to avoid going back into finance. I never developed the knack to just sit back quietly doing stupid things that don't work for the purpose everyone says it's for.
I imagine other languages have similar libraries. I would say static typing in scripting languages has arrived and is here to stay. It's a huge benefit for large code bases.
That's for messages. The discussion was about email _addresses_. The former logically makes sense as an object, but the latter can easily be implemented as a raw string, hence the discussion.
Ha ha, well that's a relief. I thought the article was going to say that enabling TCP_NODELAY is causing problems in distributed systems. I am one of those people who just turn on TCP_NODELAY and never look back because it solves problems instantly and the downsides seem minimal. Fortunately, the article is on my side. Just enable TCP_NODELAY if you think it's a good idea. It apparently doesn't break anything in general.
reply