Do developers not see the irony of publishing AI generated code with a LICENSE?
at least this one does:
> Postscriptum: Yes, I did slap an Apache 2 license on it. Is that even valid when there's barely a human in the loop? A fascinating question but not one I'm not eager to figure out myself. It is however certainly something we'll all have to confront sooner or later.
The irony is even deeper than it appears. According to current US copyright doctrine, if Claude genuinely did all the work with minimal human creative input, the Salt Bae dash of ASL2.0 is essentially decorative - you can't license rights that don't exist.
The research shows the US Copyright Office hasn't caught up with `claude` code: they claim that prompting alone doesn't create authorship, regardless of complexity. Without "substantial" human modification and creative control over the final expression, the code lands in public domain by default. Not that it matters here, but anyone could theoretically use Ronacher's library while ignoring the Apache 2 terms entirely.
What makes this fascinating is that Ronacher knows this ("Is that even valid when there's barely a human in the loop?") but published anyway. It's a perfect microcosm of our current predicament - we're all slapping licenses on potentially unenforceable code because the alternative is.. what exactly?
> What makes this fascinating is that Ronacher knows this ("Is that even valid when there's barely a human in the loop?") but published anyway.
That has very pragmatic reasons. People should be able to use this library, in my jurisdiction I cannot place things in the public domain. So there are two outcomes: the Apache 2 license is valid and you can use it, or it was impossible to copyright it in the first place and it's in the public domain. Either way you are free to use it.
It makes it easier for users to enable permissions, accidentally too, and thus lower security and privacy. Google products are designed to exploit that. Google probably has data showing a large number of users have disabled such permissions globally, with no easy path to trick them into opting back in. That would be the cynical view!
edit: also one can never be too paranoid around Google.
> It makes it easier for users to enable permissions, accidentally too, and thus lower security and privacy. Google products are designed to exploit that.
I learned a while back that Google Maps was moved from maps.google.com to google.com/maps so that when people gave location permission to Maps, Google Search could also use that permission.
> I learned a while back that Google Maps was moved from maps.google.com to google.com/maps so that when people gave location permission to Maps, Google Search could also use that permission.
This does not appear to be the case, at least on iOS Safari. I went to Google Maps, gave it permission, then went to Google Search and searched for “delivery near me.” It again asked me for permission.
Seems like the code from the article will run as-is with either of the first two options. In any case, this is what I meant by Deno not being able run the code "unless one explicitly configures" it.
I guess we’ll see soon enough what Deploy will become since that's "imminent".
KV is dead if they've no desire to develop it out of beta and are working on something new. No reason to ever use it for a new project now.
Fresh is being refactored with an alpha in "late Q3 2025 (likely September)". It was a fairly basic framework to being with. The no compilation/build step was the only interesting idea and that's going away.
The runtime is actively developed but I find this statement amusing:
> We’re not chasing feature parity with other runtimes.
The release notes on Node/NPM compatibility would suggest otherwise.
Yeah this is a terrible move. Companies aren't relying on KV precisely because it's in beta not because it was a bad idea. I use Cloudflare Workers KV a lot and I'm not interested in durable objects. I was really interested in Deno KV until now.
Plus the optics of announcing a product and abandoning it are not good. Ryan is a great technical guy but these decisions don't look good from a strategic perspective.
I think that’s still a win for Deno. Even using all but one flag is better than carte blanche. That said I often —allow-all because Im lazy. Containerising stuff helps.
Node’s progress to modern stuff like ES modules has been glacial. Probably the primary reason Bun/Deno have any success. It is speeding up though, seems a fire was lit by competition.
It hardly matters on the enterprise space where projects live from LTS to LTS, and version upgrades only happen when someone allocates enough budget for a consultancy to come in and do some upgrade project.
These aren't the kind of folks rushing in to add Bun/Deno into their stacks.
Would such versions be much slimmer? Most of the binary is the V8 engine. The compatibility layers are largely thin wrappers around APIs.
Anyway, it does strike me as an odd pursuit regardless. Obviously they're seeing compatibility as opening the door for more potential customers. But as a dev, if I wanted Node compat I'd just use Node.
Dahl doesn't strike me as a business or product person. He's a genius when left to tinker. I get the impression Deno is floundering because of business/VC pressure. I see the original promise of Deno being compromised in an effort to increase users/customers. The project is no longer focused on just making a good JS runtime.
Deno's original positioning was as a second version of NodeJS without the learning cruft cluttering the environment. To that extent I think Dahl and his team was successful.
As is so often the case, once you introduce MBAs/VCs, the focus shifts to ROI and fast. I see Deno Deploy as being part of that attempt.
People still tend to forget that software development tools are not commercially viable. For a long time we have become spoilt for choice with ever more and improving tools.
at least this one does:
> Postscriptum: Yes, I did slap an Apache 2 license on it. Is that even valid when there's barely a human in the loop? A fascinating question but not one I'm not eager to figure out myself. It is however certainly something we'll all have to confront sooner or later.