Does anyone know how well sqlite handles forward compatibility and other cross application concerns? A KeePass sqlite file would need to be readable by a variety of clients, which each use different sqlite version. Could one client using a newer feature make a database unreadable on clients using an older format?
It is not guaranteed but breakage is rare, the only one the main site notes is that if you enable WAL mode then you need sqlite 3.7.0 (released 15 years ago).
Good find. I looked into a couple features, like JSON support, and those are built on top of BLOBs. So a newer client can add a column with JSONB data and the older client could read it as a BLOB, but the application will likely just ignore the unknown column.
If we board faster, do we spend more time sitting on the plane, waiting for refueling, checked luggage, and other process? It would be interesting to see how boarding interacts with other procedures happening in parallel.
I suppose the optimum is a fast board, but they delay boarding so you minimize time sitting in the plane before takeoff. In hot climates the plane can be very warm on the ground and you can't stretch like you can in the waiting area.
As the CGP Grey video already linked explains, we de-plane in the slowest order. De-planing faster has practical benefits, like getting you to your destination faster. But the airline seems to have the least control of that process.
I checked out Lecture 3: Development Environment and Tools, AI-powered development. About 20% of the class raised their hand when asked if they used "AI tools like auto-complete, inline chat, coding agents (not counting chatgpt)". Awesome to see that the AI hype hasn't derailed students from learning CS.
Presumably some may be fairly reluctant to admit this is in a classroom environment so the true numbers might be higher; however, even if it were actually 50% then that would still be good news.
Email's unread count means something specific: these are messages from real people
I don't know how this is for others, but as of a few years, this no longer holds for me; the vast majority is automated (unsollicited newsletters, spam, invoices, status updates, notifications).
I don't see much spam. I unsubscribe from anything I don't want and block anything I can't unsubscribe from. When I get an email it's a really strong signal that it's relevant to me.
FYI, Claude is one of the things that identifies itself, so if you have the means, you can configure your webserver/reverse proxy to abort the connection (or whatever else you wish to do) when the user agent has ClaudeBot or Claude-User in it. The latter is used when it reaches out to fetch the page for real.
It usually obeys /robots.txt aswell.
HOWEVER! Putting the magic string in visible places is useful nevertheless, in case the particular piece is mirrored or copied elsewhere.
NOPE. In the last 3 days, ClaudeBot has hit 1650 URLs on my server despite being globally disallowed in robots.txt (since 2025-06.) In the previous week, it did 11000 requests. The week before, similarly 11000 requests. etc. etc.
I stand corrected! When I checked my logs, looking for the user agent of the fetcher, and found Claude-User, I saw it fetch /robots.txt - but that's Claude-User, not ClaudeBot indeed.
Nevertheless, both identify themselves, so one can block them without robots.txt with a bit of user agent sniffing.
We shouldn't need to. But that's not something we can convince them of, so we don't have many other options, unfortunately.
(I personally serve them garbage, and poison their URL database with URLs I can later identify, even if they stop identifying themselves. Another thing we shouldn't need to do, but alas...)
Please explain how you come to that conclusion when I've got many hits a day from ClaudeBot, originating from an Anthropic net block, and ClaudeBot has been marked as "Disallow: /" in my robots.txt since last June.
Which one did you block? Because Anthropic uses the following bots: anthropic-ai, Claude-Web, ClaudeBot, Claude-SearchBot and Claude-User. I blocked all five in robots.txt and that's all Claude has retrieved so far.
I blocked ClaudeBot (7 months ago!) and yet today, hundreds of requests from (what seems to be, if I'm reading whois output correctly) an Anthropic net-block using Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com).
That is not how robots.txt works. If they're claiming that, e.g., "ClaudeBot" is ignoring the Disallow: / in my robots.txt because it's really "anthropic-ai" but just happens to be sending "ClaudeBot" as its user-agent instead of "anthropic-ai", how is that not anything but a deliberate skirting of robots.txt?
Which is what this whole bloody conversation is about!
That may not be how robots.txt is supposed to work, but that's how I block Anthropic's bots on my site. For now. Who knows? Maybe in 20 minutes they'll launch a new bot with a new name. At least for now, if you use all the current names, you'll block Claude.
IRC, Microsoft Kestrel servers normalize extra slashes in path names to a single slash and it’s been that way for many years. There are probably too many websites built on this assumption to start enforcing a different interpretation now.
I'm pretty sure flask does this by default. I've seen it in the wild a few times, and I even thought this was what's supposed to happen until I saw this article, so quite a few web server libraries must be doing this too.
You really need to normalize URLs on the server for one reason or another. The more important thing is that if you want composable anything and you want to pass paths around, instead of segments, you need to normalize %2f and / which upsets a lot of people. A server will also have to deal with . and ...
The WhatWG standard only prescribes what URL serializers/deserializes are doing, it explicitly permits servers to normalize it beyond that for empty slashes. At one point the spec even specifically called out the idea "of not holding data" in segments as being unintended.
The more important thing is that if you want composable anything
URLs should never be composed by the client: they are opaque strings. Cool URLs, of course, are pretty opaque strings to make life for humans better: http://site.example/articles/2026/01/28/ is much better than http://site.example/a46bcaee-fc3d-11f0-9390-af34fdb4192e. But no client should ever compose a URL: it should be configured with a base URL, retrieve that resource and receive a hypertext containing URLs to more resources, determine which of those to retrieve and so on.
Yes, I’m aware that OpenAPI-style systems expect clients to compose URLs. They are certainly able to do that, but I believe a resource-oriented HATEOAS style is preferable, providing operational flexibility and RESTful semantics.
URLs should never be composed by the client: they are opaque strings.
The main counterexample is relative URLs, which require clients to understand the structure of URLs and compose them from parts. There are many ways in which URLs are not opaque strings: you can’t even make an HTTP request without parsing and decomposing the URL. There are standards such as URL templates that allow more bespoke composition.
I agree, and I'll add that I've been very pleased that I can craft things like search URLs and dynamically deep-link into other websites. The URL structure is often part of the API spec.
I’m curious why you’d want to go out of your way to do this, rather than leaving the server to do whatever it does by default (whether that be 404, 200 of content or redirect to remove the slash), and blaming the users if it’s not right or ever stops working.
(I say this as someone who’s considering configuring his server to respond 400 to requests with query strings, as a petty reaction against sites that add ?ref=… and ?utm_… to links, when I don’t want to know where they’re coming from if their browser chose not to send a Referer header.)
There are a few feed fetchers that are requesting both "/index.atom" and "//index.atom". I was hoping that by sending a permanent redirect I could save both them and me some bandwidth by requesting the file only once instead of twice at each polling interval. I keep sending the permanent redirect, but they never take the hint. Sigh.
As for sending 400 due to query strings, I think 422 (Unprocessable Content) might be a better match, or even 418 (I'm a teapot) just to really jam the message home.
422 (Unprocessable Content) isn’t appropriate: “content” means the body, but this is about the URL. (This has been the designed semantics since WebDAV days; it was then named Unprocessable Enitity, but “entity” meant the body plus related headers like content-length.)
404 (Not Found): reasonable, but most likely to exhibit side effects positive or negative.
402 (Payment Required): minor abuse of spec since it’s reserved for future use; but funny: I’d let people pay me to make URLs work with specific query strings.
414 (URI Too Long): mildly dubious as it’s not actually about length but which character was used, but funny and perhaps fair enough.
I bet that's due to the feed fetcher being configured with both https://foo.example.com and https://foo.example.com/ and just blindly adding /index.atom. If you break the //index.atom URL you're probably breaking your feed for the users who subscribed with the trailing slash.
Oh, I know the probable cause of the issue, but I don't understand how I'm breaking //index.atom for subscribers? I get a request for a resource, it's actually under a different resource location, I send a permanent redirect. It's the same as when I get a request for https://example.com/path/path and because I know /path/path is a "directory", to get proper relative links to resolve, I send back a permanent redirect to https://example.com/path/path/. What is supposed to happen is the client is told "hey, that link you have? It should be this" but from my experience, almost none bother with updating the link.
Where are they? Where are the Yahoo style directories and RSS Reader type tools that bring it all together so I can use it as a user quickly and easily?
I feel like the number of people actually using IndieWeb concepts has been constant for 10-15 years - it doesn't grow or catch fire. It's a nice concept, it makes perfect sense, it facilitates an alternative to the social dysfunction of the current web, but it gets no traction.
It's another 'Linux on the desktop'. Next year will be its year.. next year
There's a ton happening in this space, but ad-driven social media steals so much attention. RSS readers like Feedly have millions of downloads and there's tons of other popular tools.
I've been working on an extension that collects feeds as you browse (https://github.com/robalexdev/blog-quest). There's a lot of active sites, especially if you're interested in tech.
I don't think the small web needs to grow to succeed, it seems quite successful and useful as is. But I think it will continue to grow because it provides a valuable alternative to the commercialized web.
At the same time, AT's design means that several features AP has like private posts and DMs just can't be implemented in AT (bsky DMs don't go through atproto at all; I'm not sure if there's even theoretically a mechanism for someone on Blacksky to DM someone on Bluesky).
You'll have to forgive me if that doesn't strike me as particularly heartening. The whole system is designed around entirely public repos, with all private state held by the centralized actors. My experience here is a great example; the protocol has a vulnerability - people acquiring domains referring to deleted did:webs and resurrecting them - and they resolved it by... breaking the experience of decentralized users in their centralized system.
People (not just me!) told them they would have issues with things like this from day one of the protocol being discussed openly. If they wanted to support private data, from DMs to posts, follows, and so forth, why not build in a mechanism for that from day one, rather than having to migrate to a protocol that supports it?
You'll have to forgive me if that doesn't strike me as particularly heartening.
I wasn't trying to 'hearten' anyone, I was just trying to answer the question the parent asked.
If they wanted to support private data, from DMs to posts, follows, and so forth, why not build in a mechanism for that from day one, rather than having to migrate to a protocol that supports it?
Because you don't always get to pick when you ship. Sometimes, you have to start somewhere and then build on to more things later. Bluesky's early history is fundamentally intertwined with Twitter/X's, and outside events shaped what has transpired just as much as decisions by the team have.
That said, that doesn't mean you have to like what they shipped. But that doesn't mean that there aren't reasons for choosing the things they've chosen and the order they've chosen to do them in, even if you personally disagree with those choices.
Apologies, I read your invocation of the roadmap as reassurance. "This feature doesn't exist, but it will soon!"
I understand they were under pressure to ship. What I don't understand is why they didn't work with any of the existing and actually decentralized social media projects out there.
The very first thing Jay (bluesky ceo) did that got her involved with the project (before it was even a company!) was making a colossal spreadsheet listing every single decentralized social media project they could find, including many obscure ones, and document in detail the specific pros and cons of each of them as a foundation for a Twitter replacement.
They did work with other decentralized projects extensively, and continue to do so.
What I don't understand is why they didn't work with any of the existing and actually decentralized social media projects out there.
I find it frustrating that you always presume bad faith.
They did extensive research on what was out there. Previous work did not meet their needs. It's as simple as that. I have never found the team to be hostile towards other projects. A bunch of folks had even worked on some of those other projects! They just have different design goals, and therefore, different systems get built because of it.
I, and others, have spent several years going "hey look this part of the system is centralized" and hearing, from you and others, "just wait, it'll be decentralized eventually!" or "it's decentralized in principle, even if not in practice!" or, worse, "no, I promise, it is decentralized" before finding out that it is not. (That was even on here!) I have been literally, actually, directly lied to by people about whether or not certain software components are available outside of the Bluesky platform. That's as bad faith as it gets!
But in this case... I don't really think I am assuming bad faith? I didn't say, "why didn't they evaluate other projects." I absolutely believe they did. You say those other projects didn't meet their needs, and I'm curious about how, specifically, they didn't.
A big way ActivityPub didn't meet their needs is that binding user identities to specific named server instances was a major UX regression compared to Twitter, and a founding philosphy of Bluesky was "no UX regressions compared to Twitter". Ordinary people don't want to have to figure out how to pick an instance and worry about the consequences of that. They want to be able to just go with whatever thing they heard of from their friend and have a way to deal with changing their mind about that later if they need to once they understand the app and ecosystem better.
Yeah, I absolutely agree. I think portable identity is really cool, and the work Bluesky and Spritely have done there is worthwhile and interesting.
What I don't understand is why they didn't do that work on top of existing server implementations that already did most of the rest of what they wanted, which would have then benefited the users of those servers!
Look, I agreed with you when I first heard about this project. But then it actually launched and I read through the specs and designs and built my own things on top of atproto.
There was no way to get the features they wanted on top of the existing decentralized social media protocols. User identity systems are really foundational, and it's extremely hard to work around their limitations if they don't fit your desired feature set. ActivityPub and the fediverse were okay with user identifiers being tied to specific DNS domains hosting them. Bluesky wasn't okay with that, for UX reasons. So there wasn't really an option of "just build on top of activitypub" - it would have required completely changing the fundamentals of how accounts work. It was discussed, and the existing ecosystem wasn't interested in that.
Fair enough! I'm still looking with interest at some of the proposals to build DID-like mechanisms into the Fediverse, and of course, as ATProto continues to become more decentralized, I'm becoming more interested in it, too :)
I don't really believe that you're having an honest conversation, and so I'm just going to bow out. I answered the question that was being asked, I'm not really interested in re-litigating all of this with you.
Steve, between this exchange and how I've seen you approach talking about LLMs I'm suspecting it isn't possible to have a "good faith" discussion that isn't just agreeing with you. Seems a little... bad faith!
I have plenty of disagreements with people about LLMs and about atproto! All the time! And they're good discussions.
They often don't happen on lobsters, because I find that posters on lobsters tend to be not particularly interested in having discussions. They're more interested in posturing about how they're right.
The parent has made it very clear over and over again that they're more interested in lecturing from their own opinions about things than engaging in a real way. I actually find what's in the post itself to be fairly decent, if you're willing to strip away the desire to cast atproto in as poor a light as possible. For example, pointing out that all of this is very undocumented? Yes, that's a great point, and it's also very true. But ultimately, that's not what this post is about. And that's why, you'll note, I didn't engage with the parent until they engaged with me.
I originally quit this site for six years because of friendlysock's repeated behaviors. I came back because I couldn't stand someone I respected being attacked publicly in bad faith, and decided to stick around again, because things had improved. But now, I see this site as mostly being a collection of friendlysocks, rather than just one. It's actually gotten worse.
So yeah, sure, I'm out again. Maybe I'll answer questions about jj from time to time, because it's a technology I truly care about enough to put up with all of this. But don't expect posts otherwise. Maybe I'll come back in a more real way in years again.
But now, I see this site as mostly being a collection of friendlysocks, rather than just one.
You know, I haven't seen anything particularly egregious in this thread (from you either) until this comment right here. That and your snarky comment to your Bluesky followers linked below does actually lead me to think that the parent comment might be correct. But I know we can't all be perfect on the internet 100% of the time. I just want to say that I was enjoying the conversation up until this point and I don't think lashing out at the lobste.rs community is really an appropriate reaction here.
Instead of assuming malice, maybe assume there are Lobsters users like myself who don't really care for the earlier discussion but agree with ~steveklabnik that the tone of the discussion was not in good faith. It was snarky and rude about developers who've clearly worked really hard on a protocol, and then disrespectful to Klabnik, by pretending not to know what he means. ATproto isn't perfect, but it's being worked on. "It'll be decentralized eventually" is a valid position for a project to hold on something they rushed to market to capitalise on an exodus of Twitter users.
Not specific to this topic - for promises of future functionality coming from the tech industry, I place very low weight on things that have yet to materialize after a generous grace period of several years. Call it hype fatigue. ActivityPub-based stuff isn't immune to this either. Cross-forge PRs have been in limbo for a while.
To be realistic, not a single decentralized social network in existence has Solved private communication. Every existing attempt either has critical security issues, UX problems, or there is an adoption/implementation gap. ActivityPub, ATProto, and Diaspora all currently lack any mechanism for actually private communication.
NoStr has, after many failed obsoleted extensions, most recently published extension support for MLS but it's contingent on your client's implementation and behavior, and is not exactly battle tested yet. There exists an extension to SSB called Private Box, but essentially all of the SSB GUI clients that support it have been discontinued for several years.
It absolutely should not be undersold as some oversight that devs forgot to hack together and ship overnight without issue. These two features are, I think, the most difficult to get right on a protocol level.
To me there is a difference between not having E2EE chat baked into the protocol and having no concept of any way to limit information from being available to anyone who asks for it. I agree that encrypted communication in a decentralized network is difficult. I don't agree that less public information is.
If you trust your operator and all the nodes they communicate with in the network to not read your private content, then yes it is not technically complicated to just arrange that an API not expose certain things to clients on their endpoints based on who should see it and shrug your shoulders at all the avenues where such an approach can easily be defeated.
However, I suspect that such half measures would end up more like a way to do security theater that makes users feel more secure in their use of a system than they actually are, which is incredibly dangerous. Taking such half measures would just erode any trust people have in a network the day that their supposedly private information is all leaked and people get dox'd and swatted.
If I were any of the reasonable people involved in the development of any of these protocols, I would also oppose such half measures being baked into their API's.
If you trust your operator and all the nodes they communicate with in the network to not read your private content
This is exactly how my longest-lived fedi account is: it's a locked account on a server run by a friend, connected to servers run by friends and friends-of-friends, and I post only followers-only.
This is not proof against all attack, but it's security commensurate with the threat model. I post emotionally vulnerable things, but nothing incriminating or unethical.
that has nothing to do with atproto then, that is centralized messaging, which bluesky the application has already implemented outside of atproto, minus the private posts part
Lobsters still require invites to get accounts and vote, though, so it seems less likely to be subject to brigading by random social media followers than most. As of a minute ago, Lobsters has 19,550 users.
What fraction of them 1) saw Klabnik's comment on BSky, 2) weren't already active on Lobsters, and 3) chose to login and start voting on this? (Only 2 users joined since this article was posted, so there's certainly no rush of signups to defend him.)
I think the upvote totals are more likely to reflect actual sentiment from regular users.
At the time of posting the replied-to message had accrued an anomalously high number of votes within ten minutes. It was pretty conspicuous for something buried like eight comments deep.
None of the absolute vote totals in the comments are high enough to make me bat an eyelash.
As for the depth, so what? It's easy to read all the comments of a post on Lobsters, because there's just not that many. If anything, deep comment threads indicate something of interest to people.
I think you're seeing nefarious activity where there's none.
For people like me who follow all comments via the /comments page, rank within a specific comment tree is irrelevant.
Even taken out of context, the comment (id 1ynvf2 to confirm what we're talking about) has enough info to invite a sympathetic member to upvote it, in my opinion.
I'm just stating this as a possible explanation to a sudden burst of upvotes, regardless of it receiving exposure on other sites.
This is not just embarrassing behavior, it is a violation of the Lobste.rs Guidelines:
Lobsters is more of a garden party than a debate club. We're learning things we didn't know to be curious about and sharing what we've made. Disagreements are normal but fights are not; it's OK to make your point, share a resource, and let someone be wrong. Abuse and bigotry are unwelcome.
This conspiratorial idea that the microscopic crossover of Bluesky users that also follow Steve and have an account here, are gaming the upvotes, a metric which nobody actually cares about anyways, is clearly just a way for you to continue to direct abuse at Steve for speaking out about a piece of technology you don't like!
It's not like I even have a dog in ATProto vs ActivityPub. They are just similar technologies made by different people that made different trade offs; ok, so what, it's honestly not that serious. But I upvoted Steve because he rightfully called the behavior in this thread as non-sequitur abuse, which in my opinion is doing no favors to anyone, including those who react to the standard of discourse on this website, and especially those who advocate for ActivityPub.
Yeah, I wasn't sure whether to flag it or not, since I have no prior experience with most of the people in this thread.
I don't yet know if it's an isolated mistake or a regular pattern, but I use a userscript called UTags to attach tags to usernames, which quickly surfaces repeat bad behavior.
I'm now on lobste.rs since 7 years and from my observation you do seem to end up in these heated discussions about things you really like and others don't for various reasons. I was once involved helping in one of these where things were simply factually wrong from my (and your) POV.
Honestly ? Simply staying out of these discussions or just stating some facts and logging out is the best. A submission with 93 upvotes, 112 comments (more than upvotes) and a title like this screams mud fight (or editor fight) to me. No way the comment section of lobsters is going to resolve long standing tradeoffs between decentralized-, centralized- and systems in the middle.
Hope you're staying here for the actually interesting topics (or rather topics for which it's not as much a question of priorities and preferences).
The purpose of commercial enterprises (like bluesky) is to make money for shareholders. Not to act in good faith (or bad). Nobody is claiming you are acting in bad faith, and nobody should expect any commercial enterprise to act in "good faith" because moral good and bad are meaningless concepts in a boardroom.
It's undeniable that there's a lot of money in being at the center, not so much in making tools to build a system with no center.
According to Wikipedia, Bluesky Social is something called public benefit corporation: „Benefit corporations explicitly specify that profit is not their only goal”.
Yes, Public Benefit corporations are in fact entirely performative. All it requires is that you specify that you can have pro-social goals other than profit; there is no requirement that you actually do anything positive. Any company whether decent or vile can claim to be a public benefit corporation just by amending their bylaws to say so.
Companies that do this often benefit from confusion between "Public Benefit Corporation" and B Corporation, which is a certification that actually does have qualifications that must be met beyond just saying "yeah trust us guys, we are good."
In the USA, a benefit corporation has two goals: profit, and passing a corporation-specific annual audit. The audit is arbitrary and advisory; benefit corporations get to have some non-profit goal but they do not have to pick a goal which benefits society.
I hope they can figure something out, but lately I've been at the point where I don't really put much stock in "they're working on a design" for technical projects (not just bsky here). I can't evaluate whether any of the technical proposals linked elsewhere in this thread are any good, but my default stance is that it won't happen any time soon, if ever.
There is probably a way to do private stuff on ATProto, which is how they solve everything else basically: by introducing a new "app" (i.e. a new server, with a custom backend/AppView) that deals with encrypted data and introduces yet another centralized point-of-failure that is impossibly hard to migrate out in practice, like Bluesky.
No, this is not how it will likely work out. The current proposals seem to be starting with introducing a protocol extension to the PDS to allow it to store records that don't get sent out of the firehose. Paul Frazee summarized some of the approaches being explored here: https://www.pfrazee.com/leaflets/3lzhui2zbxk2b
I enjoy emails so much that I made a new "reply" feature for the offpunk browser which is simply "sending an email to the author if I could find that email". After only two days of testing, I’m already sold to Gemini+Email as my social network of choice ;-)
Honestly, getting an email about my posts or things really makes my day. To me it's almost as good as getting a real letter in mail. It feels more personal, thought out, and gives me the warm fuzzies.
And it sometimes create meaningful exchanges. That’s why I wanted to make it easy for me to send a mail to reply to a blog post/gemlog I’m currently reading.
I don't think that's true. Email is very centralized to Google and Microsoft, but there are tons of other options available and they work perfectly fine.
Slightly off-topic, but does ATProto have something analogous to the FEP standardization / extension process where changes to the protocol are publically discussed?
Nothing that formal yet. They're currently in the process of turning ATproto into an IETF-owned spec with its own RFCs and such. Once that effort's done, the IETF RFC process will become the manner in which changes to the protocol are made and discussed. You can see the draft specs here: https://github.com/bluesky-social/ietf-drafts
And the messaging solution will offer the recipients mechanics to more or less automatically delete these emails (with their consent of course).
The UI they are going for seems to be that an email client can support a "show all expired email" view, then the user can choose to mass delete or pick and choose.
I'm unsure if even that could work if senders misuse expiricy for example billing or something like that. In any case it further reduces any potential effect it could have.
One reason I switched from this model to hugo (https://alexsci.com/blog/hugo-import/) was the challenge of keeping everything in sync. The title of the post exists in the HTML as both head title and body h1, the index, and the feed, for example. I found I'd forget to change one, so I wrote a manual deployment checklist to ensure they were all synchronized. When you write out every single step it's actually a lot.
I broke my RSS feed a couple times. I put the wrong date format, copy/pasted an RSS item but forgot to change the GUID, and made the images-as-relative-links error. I think you need a validation step, at the very least, as it's easy to break.
One of the reasons I'm considering going back to a plain HTML approach is that I want to archive old posts. I feel that a blog should use the header, footer, and style it used when it was posted. Hugo wants to make every page look the same.
I think there is a middle ground of writing posts in plain HTML while generating the feed and index (maybe sitemap too). If I write another SSG, that may be the concept.
Regarding Linux commit author dates, these are usually taken from when the patch email was sent. So you're actually measuring the email's Date header, which can be wildly inaccurate depending on the mail server (as you have noticed).
Agreed. There are more challenges too, if you're using a mail client like Thunderbird then I believe the Date header is set by the sending user's system, not the mail server (MUA vs MTA). So the system clock is being measured can vary.
I didn't write about it but I also did some light analysis of timestamp headers in the Linux mailing list archives. There's all sorts of "time travelling" happening there: messages with Received headers earlier than the Date header, replies earlier than the original message, etc. That data looked even noisier, so I didn't dig in to all the anomalies
The incident also reflects poorly on Microsoft for failing to proactively catch the mis-issued certificates and allowing Windows to trust them for such a long period of time. Certificate Transparency, a site that catalogues in real time the issuance of all browser-trusted certificates, can be searched automatically.
I don't understand how this reflects poorly on Microsoft? How is it Microsoft's responsibility to be monitoring CT logs for suspicious Cloudflare certificate issuance, and not, y'know, Cloudflare?
Microsoft couldn't have known if Cloudflare authorized the certificate or not, but they could have noticed that the certificate fails a bunch of lint checks: https://crt.sh/?id=14793030836&opt=pkimetal
All three other root stores (Chrome, Mozilla, Apple) proactively monitor CAs for lint failures and/or take third-party reports of lint failures (and other non-compliant behavior) seriously. I and others have tried reporting problems with Microsoft-trusted CAs to the Microsoft root store, only to be ignored.
I agree that it isn't Microsoft's role to detect misissued certificates but this incident does reflect poorly on Microsoft. Only Microsoft chose to trust this CA and this is not a little mistake for a CA to make. Microsoft has a very large trust store and it's not clear why they trust so many CAs. Google and Mozilla have a transparent inclusion process, complete with public audit reports from independent auditors, and when CAs make mistakes they explain what went wrong and how they are going to fix it. Microsoft is the odd one out here and should do better.
More to the point would you want them to? Would you want every change you make in your registrar be functionally blocked on MS reaching out to you when the pre-issue certificate was produced? Because you're essentially saying "MS should require CAs to confirm with MS, that MS has confirmed your intent to change CA".
It will be interesting to see if MS allows the CA to remain in their trust store given they've just demonstrated inadequate controls - unless of course a medical provider uses the CA for medically critical devices that have no reason to require anything PKI related to be involved and sues MS to force everyone to be exposed to a demonstrably untrustable CA because they are too incompetent to deal with an issue, despite signing a contract stating they understood they would need to be able to.
How does MS know which operations are bad? Should they require confirmation for every certificate that is issued?
You are misunderstanding who is responsible for what in the CT system.
The design of CT is to permit certificate recipients to detect issuance. They’re the only people who can identify such.
The fact that these certificates were issued, and were valid - so must have been submitted to multiple different logs - yet were apparently not detected is indicative of failure to monitor the logs by a service for whom such compromise is important.
If you ship a root store in your product you are trusting the CA roots you choose. If one of those CA's turns out to be untrustworthy you're responsible for finding out and removing it (in a revocation list or a software update).
Which you do via audit reports and similar. Not by manually verifying every operation they perform.
CT was specifically created to make detecting such issues possible, not to require root stores to verify every certificate issued themselves. The entire reason for root stores is because the alternative would be a single CA operated by the platform. The entire reason for CAs is to not do that, but once they are performing the task of verifying those operations there is no longer a reason for the CAs to exist.
I scored 20/21 on https://e-mail.wtf and all I got was this lousy text to share on social media.
The one I got wrong was consecutive periods.
The easy thing with email addresses (generally) is that the local part is “anything” and the domain part is, well, a domain. Comments are obsoleted (thank god) so you can safely wipe out anything between parenthesis, forward what remains to the server after the @ and you’re golden.
I even wrote a simple tool/service that took a http request and just asked the SMTP server if the local part was an actual mailbox.
No need for me to “parse” or validate at all myself.
User enumeration is not a real security risk. Ask Wikipedia what a phone book was.
"That's a valid email address!" So what? It's going to get spam and malware and phishing and half-assed spear-phishing attempts no matter what. And so will a thousand other addresses, most of which will be undeliverable.
"Now we know their login handle!" Security does not depend on the login handle. Security depends on the correspondence between a password and a particular login handle, and for anything serious, a second factor as well.
Not really. Enumeration allows me to try many firstname.lastname@example.com addresses. This tells me the names of the people working at a company. Names are PII.
I guess the argument can be made that less information is better, but this might become hair pulling at some point. Just rate limit VRFY and block people who miss a few hundred thousand times in a month.
There are a couple of features in SMTP that allow anyone to validate mail addresses:
the VRFY command, which became generally regarded as a bad idea in the 1990s because it allows user enumeration, and has been basically unused ever since;
and the RCPT TO command, which since the rise of spam around 2000 has generally rejected mail to invalid addresses because that’s one of the cheapest possible zero-false-positive anti-spam defences.
(Mail server implementations and local policies may differ, of course.)
It’s funny to me how these security best practices directly contradict each other, owing to the way threats evolved and drove our understanding of what defences actually have demonstrably useful effects.
I wish we could organize a service or chatroom where we match successful vibecoders up with "LLMs don't work for programming"ers and have them work on the same projects to see what's going wrong.
I made an entire useful website (https://bridgedays.github.io) with Sonnet 4 in like three hours a few days ago. "LLMs don't work for coding" is incomprehensible to me.
I don't want to overly critique a site that isn't a submission, but I'm seeing issues when Friday is a holiday. It looks like it suggests taking off Sunday to Wednesday, but not Thursday. But Sunday is listed as a weekend and Wednesday doesn't bridge to Friday. Unless I'm misunderstanding the concept or the UI, this doesn't appear to work.
It's great that this was quick to build, and it would take me more than three hours to replicate it by hand, but it doesn't seem usable yet.
Also some of the sources don't look entirely correct - Saxony in Germany, for example, definitely has more public holidays that fall midweek than are shown in the calendar.
I think it's a display issue, although maybe more a UX issue than a bug per se. If I look at November 2025 in the calendar, I can the 25th highlighted in bold, but also with a yellow background. I think the bold is because it's a public holiday, but the yellow background should be for days that I should take off, right? I would expect this to show with a red background, with the weekdays either side highlighted in yellow as potential bridge days.
The API returns the correct data, and I think the app is reading that data correctly (otherwise it wouldn't calculate bridge days there at all) but it's just displaying in a way that doesn't quite seem right.
Also, I'm looking at this all on mobile, which is very cut off and only shows the calendar and a very thin strip of something underneath that I can't read properly, so I might be missing something.
... November 2025 has the 25th highlighted in bold for Saxony 2025? That's a bug, can you post a screenshot please? (Also, what's your browser?) Nov 25 is not a holiday in Saxony, and it bolds Nov 19 here.
Also yeah the stuff underneath is kind of the entire site, ie. the list of bridge day holidays. :) Not sure how to fix that. When you click on a bridge day marker, it picks a time-off choice for that day from the list below, but it's not necessarily the longest one.
You're right, I meant the 19th. If that is the correct display (i.e. bold, yellow background), then you might want to highlight it a bit more somehow, because as it is I was struggling to see where any of the public holidays were.
For the section below, presumably the calendar is specified to be sticky in some way in the CSS (or the part below it is set to be scrollable). This makes the whole thing almost impossible to use on mobile, as you've only got access to the calendar. Maybe you can disable this stickiness, and just let the user scroll up and down between the calendar at the top and the calculations below? Maybe you could have the sticky effect only kick in if the window is tall enough, if you think it's useful enough to keep.
Alright, try now. I didn't consider phones at all. With smaller screens it should now disable the separate section and just show it as one flowing text. Also, tapping an opportunity should permanently select it (it uses mouseover on desktop). Then you can scroll back up to see it in the calendar.
Also, this is the total of my input:
Hi, can you change the site to not scroll the holidays panel but have it be part of normal page flow, on mobile only? On a desktop, the site is split into two halves, but on mobile the calendar dominates.
Alright, now to properly support mobile phones (no mouseover!) we also have to allow clicking on an opportunity and making the selection permanent (until another one is clicked). This should be the same mechanism as mouseover so that mouseover continues to work on desktop.
Nice! But now clicking out should deselect it again.
edit:
Woah! We seem to have added a bug when we added mobile and selection support- when we click on another opportunity, the calendar highlighting of the old opportunity is not removed.
I think it's a display issue, although maybe more a UX issue than a bug per se. If I look at November 2025 in the calendar, I can the 25th highlighted in bold, but also with a yellow background. I think the bold is because it's a public holiday, but the yellow background should be for days that I should take off, right? I would expect this to show with a red background, with the weekdays either side highlighted in yellow as potential bridge days.
The API returns the correct data, and I think the app is reading that data correctly (otherwise it wouldn't calculate bridge days there at all) but it's just displaying in a way that doesn't quite seem right.
Also, I'm looking at this all on mobile, which is very cut off and only shows the calendar and a very thin strip of something underneath that I can't read properly, so I might be missing something.
Thanks! No that's great, I love feedback. Could I bother you to file a bug report? There's a Github link on the top right.
There were definitely issues with the holidays, and it's very plausible that I haven't stamped them all out yet. I haven't seen something this blatant in my own use since I released it, but it's plausible I missed something.
I've done this with a few friends. For the most part, I've found that people just can't write specs very well. They'll ask the machine for something that can be interpreted in 50 different ways, or include long irrelevant parts of their thought process with relatively little detail about the desired solution. Having them practice writing specs that someone else could use has been really effective.
But a truly unambiguous spec would end up being code, right? Isn't it better to write that spec, that code, in a succinct language that's designed for that purpose, using a tool, a compiler or interpreter, that will handle it deterministically?
No, look at most RFCs and design documents. They detail what needs to happen, the edge cases, and sometimes rationale or test vectors. It can function as the source of truth for implementations without providing code.
I've written several RFCs that took weeks to make. I certainly would not recommend that level of detail for an LLM.
I'm more likely to use an LLM for prototyping. Another example: I was working on improving the performance of a data pipeline, where we were spending ~$10,000 in compute/month. I came up with several ideas, and asked the LLM to come up with more. There were something like 10 plausible ideas.
I ordered the ideas by how likely I thought they were to work, then tried implementing each one with the LLM, with shitty minimal code that was just enough to test the performance of the design. Each one took 30-90 minutes, and I would estimate that doing them myself would have taken me about 5 hours each, because that's how long two ideas took before I tried the LLM. My process for each was roughly "give me a plan for implementing design X", critiquing the plan back and forth and adding more detail, and then babysitting Claude Code while it actually implemented that plan, sometimes making corrections to the code it proposed.
Most of the ideas were a wash, but idea #8 was a 55% improvement in performance, which translated to a 40% improvement in cost. I definitely would not have even bothered to test it on my own.
After testing the ideas with the LLM, I created a new branch and implemented the best idea from scratch. I think this is generally a good way to work with them.
So here's an example of what I'm talking about. Initial prompt: "deduplicate this code." Revised prompt: "my codebase uses libraries Foo and Bar, which have very similar functionality. I would like to remove Foo and keep Bar. Search the web and compare the two libraries to see if I would lose any essential functionality this way. Then give me a plan for removing Foo."
"Give me a plan in a markdown file" is a secret weapon, because it lets you reset the context if something goes wrong and still keep going in the same approach.
This has been my experience too. It seems like the initial prompt matters more than any future prompts that attempt to keep it on track - it seems better to just /reset and adjust the initial prompt.
ok, can we all (competent programmers trying AI tools) at least agree that "I vibecoded X with Y in Z hours the other day" is completely uninformative, given the wide spread of outcomes we keep reading about ?
It would be far more instructive to show how it played out, how you interact with the tools, what you expect of them, etc.
"writing specs is hard and not fun to everyone" is certainly part of, as another comment covers (I'd rather write the project than the specs for sure). but it's worth adding that, since models rely on some randomness, there will always be cases where it just does badly on a question, because luck didn't favor you. if that was someone's "give it a chance", well...
Yep! As somebody who vibecodes a ton, it happens very frequently that I just have to go "well, it got it wrong, this context is ruined", /undo, /clear, reask question. It's easier to tell when the model has gone wrong than doing it right yourself, so this is still a speedup, but it is absolutely something you have to be ready for.
They just seem to be rating whether the org behind the project is individual, not-for-profit, or for-profit, and evaluating whether the org requires a CLA, DCO, or no agreement at all before accepting contributions.
Those with for-profit orgs and CLAs are deemed high risk for relicensing. Those with not-for-profit orgs and DCO are mid. Those with individuals and no agreement are low.
Maybe it's more subtle than that, but I've not been able to spot more nuance so far.
(Creator here) The mild rating reflects the use of the Apache 2 license, which isn't a copyleft license. It's pretty easy to take Apache 2 licensed software and build a non-open-source fork. The Apache Foundation would be fully compliant with the Apache 2 license if they released future versions of HTTPd under a non-open-source license.
The reason HTTPd feels like it's at lower risk is due to the reputation of the Apache Foundation. Reputation is hard to measure objectively, so I haven't been factoring it in to the ratings. I've considered reducing all risk ratings for non-profits, but there's examples of non-profits that have relicensed software, so that alone isn't a clear signal.
It also feels like it's at lower risk because it's been offered under the same license by the same not-for-profit since the 1990s.
I won't dispute that longevity is hard to measure/rate for the kind of ratings you're doing, but it certainly figures into my mental "risk math" when I'm deciding whether or not to contribute.
I strongly agree. It seems about as likely to be relicensed as ghostscript.
I didn't mean to suggest that I thought these ratings were correct; I was just saying what seems to be behind them as far as I can tell. The httpd one, specifically, made me think the ratings were not good as soon as I saw it.
After validation from the fellow comments, I now feel confident in asserting that this website is nothing more than an expression of the owner's bias against corporations (and the deluded fear of companies abusing permissive licenses, which doesn't happen anywhere near as often as FOSS advocates rave about). Now, having a bias against companies isn't the most taboo form of bias one can have, but it's still false information. This website is probably as reliable as your crazy uncle telling you they're putting nanobots in the water.
I appreciate the effort collating announcements, but the comparison to "rug pulls" is wrong and entitled.
Existing releases aren't suddenly being turned from open to restricted. If there was any forward-looking promise from the project stewards, it wasn't free lunch forever, but that users would be able to cook for themselves. I've yet to read about a project that changes its going-forward license policy and doesn't tell outside contributors, so as to keep drawing contributions.
IMO, when you accept outside contributions, a forward-looking promise is strongly implied. If you change the license so that people who've contributed to make the whole of the product better no longer have the same rights to the better whole that they had to the old versions, that feels very much like a rug pull to me.
You might argue that I could avoid that by refusing to consent to a CLA. I'd agree, and argue that these rug pulls are evidence that CLAs are not just things that "keep the lawyers happy" (as another commenter said) but are things that should actively inform contributors as to risks that might reduce the future value of their contributions.
If you change the license so that people who’ve contributed to make the whole of the product better no longer have the same rights to the better whole that they had to the old versions, that feels very much like a rug pull to me.
Contributors have the same rights to improve or even fork releases made under the prior license. The delta between the last release under the old license and the first release under the new license is a bunch of new work by the steward's contributors. There wasn't any promise that any further work would be licensed consistently, or even that there would be future work.
You might argue that I could avoid that by refusing to consent to a CLA.
I wouldn't, because use of a CLA isn't necessary or sufficient for the kinds of policy changes we're discussing. Any steward of a project under a permissive license without any particular terms for taking contributions by others can start releasing new work under different terms at any time, just as anyone else can fork under their own terms of choice.
No common license terms for source code shared and developed that I'm aware of—permissive, copyleft, or restricted—include any promise by anyone to do additional work in the future or license it a particular way. Certain uses of copyleft terms without special terms for licensing contributions from others can limit choice of license terms in practice, but still don't obligate anyone to keep contributing. Companies offering work under these licenses aren't any more obligated to perpetual user servitude than solo hackers putting out projects on their own.
Contributors have the same rights to improve or even fork releases made under the prior license. The delta between the last release under the old license and the first release under the new license is a bunch of new work by the steward’s contributors. There wasn’t any promise that any further work would be licensed consistently, or even that there would be future work.
Of course this is accurate, at least as far as the text of the license goes. But I would argue that it's far from the whole story, socially, which is a big part of the math for me when I decide whether and how much sweat-equity I'm willing to contribute to a project. And that's what I was getting at. When I write code for a project, my behavior is more than a simple transaction. I'm choosing to participate as a member of a community, and there are certain social norms that accompany that. I'm astute enough to read and understand the texts of licenses, so I often understand that there wasn't a promise in a legal sense. But there can be a social understanding that goes beyond the text of the license, and that can create expectations just as much as a license text can, even if those are (much!) less likely to be enforced by a court. They still convey how a party intends to behave even if they don't make that intent legally binding. And a party who conveys a misimpression based on these norms will eventually find itself wanting for collaborators if that becomes commonly recognized.
On those lines, when I choose to contribute to a project, I do generally understand that the project will continue to release future versions under terms that are very similar to the versions I gave code to. Project maintainers can, of course, violate that, if the license of the code I'm patching permits them to, but contributors and potential contributors will often notice this and react accordingly.
My point isn't legal. Two sides talking past each other, or making assumptions that don't turn out to be shared, happens all the time. They're communication problems, basic people business problems, long before and more often than they become legal problems.
You can't choose to unilaterally impose "community" on projects you don't steward, or a particular definition of what community means, just by showing up with patches. You can't impose your version of what goes without saying, by calling it "social norms" or "defaults" or anything else.
Nor can projects impose their "crowdsource" fantasies of infinite, competent, totally unpaid contribution on you. They decide what they offer, in the form of the projects they lead and their policies. You can take them or leave them, as you pointed out.
I've seen developers, especially idealistic Free Software people, decline to take up projects because of licensing policies. I've also seen developers consciously and energetically contribute to projects they know a for-profit company is actively dual licensing. I've seen developers assign IP in patches to proprietary software delivered in source form strictly under NDA, just to scratch a nagging itch in a tool their employer pays for.
I agree that many especially younger and more idealistic developers might feel a pang of loss when projects they contribute to announce going-forward license changes they don't like. Better if the party went on their way forever, on someone else's dime, as Linux, its distros, and a relatively tiny cohort of famous and important peer projects do. But outside those rarefied few, companies moving the work they fund to more restrictive terms has happened for a long time. Any disappointment based on informed expectations has to square with all that history.
I'd strongly encourage developers looking to contribute to projects to research the licensing policies and business models behind them before jumping in, especially if they're not going to be paid. I'd strongly support GitHub issues or other public calls to project stewards to clarify where they haven't, just as I'd encourage stewards to ask frank questions about motivation and funding of "outside" contributors appearing with unsolicited patches.
It's never worth hashing out everything that might go wrong, but it's also way too easy to self-deceive about alignment in silence, on either side. On major points, airing it out up front can be a whole lot better than retroactive recriminations about who knew or meant what where nothing was said. Many fewer lawyers would be needed in this world if more followed this free advice.
You can’t choose to unilaterally impose “community” on projects you don’t steward, or a particular definition of what community means, just by showing up with patches. You can’t impose your version of what goes without saying, by calling it “social norms” or “defaults” or anything else.
Absolutely not. But I need to make some assessment of what the community is like and what social norms are in place before investing time and labor in a non-trivial patch. For trivial patch-sets, I can't be bothered. I will totally drive by and send those. But for adding something major, where I need to invest real time learning the codebase and figuring out how to make my contribution fit well, it's not just technical and not just legal. There's a fit issue that extends past both dimensions. I don't believe a copyright license can be expressive enough to convey it.
For right or for wrong, when I contribute to an MIT-licensed project, I am expecting the future version that includes my contribution and is better because of my contribution to be licensed under similar terms. Same when I contribute to a GPL-licensed project. And I recognize that this is not an expectation that's enforced by license or by contract, generally, but the expectation is formed based on my assessment of the project owner's practices.
I’ve seen developers, especially idealistic Free Software people, decline to take up projects because of licensing policies. I’ve also seen developers consciously and energetically contribute to projects they know a for-profit company is actively dual licensing. I’ve seen developers assign IP in patches to proprietary software delivered in source form strictly under NDA, just to scratch a nagging itch in a tool their employer pays for.
I am not an especially idealistic Free Software person, but I have personally done all of these things.
I agree that many especially younger and more idealistic developers might feel a pang of loss when projects they contribute to announce going-forward license changes they don’t like. Better if the party went on their way forever, on someone else’s dime, as Linux, its distros, and a relatively tiny cohort of famous and important peer projects do. But outside those rarefied few, companies moving the work they fund to more restrictive terms has happened for a long time. Any disappointment based on informed expectations has to square with all that history.
I'm neither younger nor more idealistic, and I'm also not clairvoyant. We need to make educated guesses about where to apply efforts, particularly when the return on those efforts comes in the form of something social like free software. Sometimes those expectations get violated, and that's because I didn't inform myself properly up front. But it's not "entitled" to have made my best guess at those, be wrong, and express disappointment at being wrong.
Edit to add:
I’d strongly support GitHub issues or other public calls to project stewards to clarify where they haven’t
Of course. But a lot of these changes get made quite a bit above the pay grade of people who respond to GitHub issues, mailing list posts, etc., and opening an issue or posting to a mailing list to inquire about business model and plans for future license changes can be both perceived as off-topic in a technical forum and as an inquiry about business concerns that the employers of the people answering those issues/posts are unwilling to discuss in public.
You might argue that I could avoid that by refusing to consent to a CLA. I’d agree, and argue that these rug pulls are evidence that CLAs are not just things that “keep the lawyers happy” (as another commenter said) but are things that should actively inform contributors as to risks that might reduce the future value of their contributions.
I avoid making contributions to projects with CLAs for this reason. I want future contributors to have to "pay it backwards" as I have "paid it forward."
Creator here. This is great criticism; I don't think I've landed on the best terminology yet. I've tried to avoid the term "rug-pull" elsewhere on the site for these reasons, but kept it on the home page because the term is frequently used elsewhere. I'll keep working on terminology.
I think you're right about releases having licenses, not projects. But a project is more than just a release, especially from the contributor side. A project is also a point of collaboration and community. When a license change occurs, it can really disrupt the community of contributors. Writing code for an open-source project feels different from contributing to a non-open-source one.
Drew DeVault wrote a great piece about CLAs a couple years back and is now running redict as a fork of Redis.
The most descriptive, neutral name for this I've seen is "licensing policy change". But that's not widely used.
The neutral term I see used most is "relicensing", the one you picked up on. The problem with that term is ambiguity. I see a lot of posts on social media falling into that trap, confusing going-forward license changes as retroactive changes to past releases. I've also seen some people who know better encouraging confusion because they want to punish companies.
I've occasionally heard "license fork", which makes sense to me conceptually. I tend to avoid it only because I see it leaning into the various rhetorical battles along the lines of "We're not the fork. You are!" I think those battles are natural and healthy, so long as they're fought on who has contributed more and will have the better project going forward. I don't think it should be the case that any side—the steward, prior outside contributors, any new group pulled together to keep contributing under the old license—gets presumed to be the best. It should be about the software.
Drew's is a well known voice on CLAs, but I'd encourage you to read others, as well. You might not know, from his blog alone, that there are and have been CLAs that limit what licenses and kinds of licenses stewards can release contributed work under—putting into explicit legal terms the deal some activists wish were implied.
Personally, I'd add that very, very often, the relationship between "outside" contributor and project steward isn't equal, and justly should not be. Commercial project stewards tend to drive development. Many have had the experience of a highly opinionated guy with a patch showing up and demanding a fundamental licensing policy change for a PR, claiming it will unlock a deluge of "community" contributions that simply never materialize for the vast majority of even GPL-licensed, locked-open projects.
Maybe I should try to coin a new term. Rug-pull sounds too entitled and the others are lackluster.
CLAs that limit what licenses and kinds of licenses stewards can release contributed work under
I don't think I've come across one of those, but that would be very good to include. Do you remember off-hand which projects had those? I'm intentionally measuring CLAs that require copyright and/or patent grants, because those make it easier for a company to relicense external contributions. A CLA without those seems less risky. There's some really complicated stuff like Qt that have pretty novel approaches.
If I may suggest one more lens: Do project contributors have the same rights as the project originator?
It's much easier to swallow a license change from someone who is a peer with the same rights as you, but it's more painful if it comes from someone with a position of power over others.
I would argue that permissive licenses without a CLA create an environment where everyone is the most equal. Anyone can fork off with the same rights, even if they decide to use a different license moving forward. On the other hand, copyleft with CLA creates a strong imbalance where the source project owner has special rights to relicense that contributors do not share in.
I would argue that permissive licenses without a CLA create an environment where everyone is the most equal. Anyone can fork off with the same rights, even if they decide to use a different license moving forward. On the other hand, copyleft with CLA creates a strong imbalance where the source project owner has special rights to relicense that contributors do not share in.
This matches my analysis. As a general matter, I only contribute to a "copyleft with CLA" project if there's significant benefit to me getting to use the project with my patch included AND strong desire not to maintain a fork plus a distribution mechanism for that fork.
My bar for CLAs is high in general, though, and it'd be unusual for me to consider accepting one without being financially staked in to the project or otherwise associated with the business behind it.
I don't think requiring copyright and patent grant should be the only thing immediately elevating a project as "high relicensing risk", it's mostly just there to keep the lawyers happy. As far as I know, MS has never relicensed anything open to something more restrictive (if they have, it's obscure enough for me to have never heard of). You mostly see companies doing that because they sell one single software package and either want to be profitable or just to sell the whole company, which MS isn't going to do. It feels like a pretty naive way to gauge risk that hasn't taken actual real-world examples and reasoning for relicensing into account. In fact, I'd go as far as to argue a cloud company has the least possible incentive to relicense, especially because it would mean alienating their developer base, which would directly affect their cloud clientele. As an example, I think Amazon directly forked Redis to keep it open source, didn't they?
(Creator here) Part of the challenge of building a project like this is convincing others that the ratings are objective and don't represent personal bias. I've picked a couple measurable factors like "CLA requires copyright grant" which can be verified by linking to the relevant CLA. Drew DeVault's post has a great explanation of the problem. To me (in my subjective opinion) a company demanding developers grant them the ability to relicense your contributed code is a pretty big red flag that they may exercise that right.
I think the factors you mention (history of relicensing, dependence on a single product, alienation of developers) are more subjective and can change over time. A good counter-example may be CICERO. It was changed to a non-open-source license but its a project by a non-profit, it's not the sole product of the organization.
One of the main reasons I created the project was to promote developer discussion about open source licensing, so I'm happy that we're engaging in discussion here.
Indeed. The big risk for things like VS Code are the non-open bits of the open core model. All of the dev container infrastructure (which is one of the big advantages of VS Code) come from the remote extension and are not part of the open source release. There’s a much bigger risk that other important features will be developed as proprietary extensions than there is of MS relicensing the core.
With Linux distros now shipping (proprietary) NVIDIA drivers and (CDDL) OpenZFS, the same risk applies to Linux.
ProTip: avoid hosting based in military dictatorships.
But us-east-1 is mandatory for some services/functionality.
Warrant-less wiretaps?
The list is here, which includes core things like IAM:
https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/global-services.html
I wonder how well this advice is going to age in the US.
Does anyone know how well sqlite handles forward compatibility and other cross application concerns? A KeePass sqlite file would need to be readable by a variety of clients, which each use different sqlite version. Could one client using a newer feature make a database unreadable on clients using an older format?
It is not guaranteed but breakage is rare, the only one the main site notes is that if you enable WAL mode then you need sqlite 3.7.0 (released 15 years ago).
Good find. I looked into a couple features, like JSON support, and those are built on top of BLOBs. So a newer client can add a column with JSONB data and the older client could read it as a BLOB, but the application will likely just ignore the unknown column.
sqlite has a page endorsing the use of the database format in applications https://sqlite.org/appfileformat.html
If we board faster, do we spend more time sitting on the plane, waiting for refueling, checked luggage, and other process? It would be interesting to see how boarding interacts with other procedures happening in parallel.
I suppose the optimum is a fast board, but they delay boarding so you minimize time sitting in the plane before takeoff. In hot climates the plane can be very warm on the ground and you can't stretch like you can in the waiting area.
As the CGP Grey video already linked explains, we de-plane in the slowest order. De-planing faster has practical benefits, like getting you to your destination faster. But the airline seems to have the least control of that process.
I checked out Lecture 3: Development Environment and Tools, AI-powered development. About 20% of the class raised their hand when asked if they used "AI tools like auto-complete, inline chat, coding agents (not counting chatgpt)". Awesome to see that the AI hype hasn't derailed students from learning CS.
Presumably some may be fairly reluctant to admit this is in a classroom environment so the true numbers might be higher; however, even if it were actually 50% then that would still be good news.
I don't know how this is for others, but as of a few years, this no longer holds for me; the vast majority is automated (unsollicited newsletters, spam, invoices, status updates, notifications).
I don't see much spam. I unsubscribe from anything I don't want and block anything I can't unsubscribe from. When I get an email it's a really strong signal that it's relevant to me.
You get like 4 emails just from an online order. Mostly "to keep you posted".
Yeah, I don't see much spam, except for finely, artisanally crafted phishing emails, but I accumulate bacn faster than I can unsubscribe from it.
FYI, Claude is one of the things that identifies itself, so if you have the means, you can configure your webserver/reverse proxy to abort the connection (or whatever else you wish to do) when the user agent has
ClaudeBotorClaude-Userin it. The latter is used when it reaches out to fetch the page for real.It usually obeys
/robots.txtaswell.HOWEVER! Putting the magic string in visible places is useful nevertheless, in case the particular piece is mirrored or copied elsewhere.
NOPE. In the last 3 days, ClaudeBot has hit 1650 URLs on my server despite being globally disallowed in
robots.txt(since 2025-06.) In the previous week, it did 11000 requests. The week before, similarly 11000 requests. etc. etc.I stand corrected! When I checked my logs, looking for the user agent of the fetcher, and found
Claude-User, I saw it fetch/robots.txt- but that'sClaude-User, notClaudeBotindeed.Nevertheless, both identify themselves, so one can block them without robots.txt with a bit of user agent sniffing.
Right but why should we have to? Why can't/won't/don't they respect
robots.txt?We shouldn't need to. But that's not something we can convince them of, so we don't have many other options, unfortunately.
(I personally serve them garbage, and poison their URL database with URLs I can later identify, even if they stop identifying themselves. Another thing we shouldn't need to do, but alas...)
[Comment removed by author]
Claude-User is not a bot.
I specifically referenced ClaudeBot in my reply.
ClaudeBot respects robots txt.
Please explain how you come to that conclusion when I've got many hits a day from ClaudeBot, originating from an Anthropic net block, and ClaudeBot has been marked as "Disallow: /" in my
robots.txtsince last June.[Comment removed by author]
No it didn't in this case
Which one did you block? Because Anthropic uses the following bots:
anthropic-ai,Claude-Web,ClaudeBot,Claude-SearchBotandClaude-User. I blocked all five inrobots.txtand that's all Claude has retrieved so far.I blocked ClaudeBot (7 months ago!) and yet today, hundreds of requests from (what seems to be, if I'm reading
whoisoutput correctly) an Anthropic net-block usingMozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com).Does the IP range match as well? Anyone can use that user agent string.
Not doubting, just noting possible measurement error.
All but 2 out of the 2394 in the current log file come from 216.73.216.{217,86} which, if
whoisis to be believed, is:Out of curiosity, what is the URL to your robots.txt / your site? I wonder if someone could ask folks at Anthropic to look into this issue.
https://rjp.is/robots.txt
I've tested it with some online testers and it seems correct (in that they think AhrefsBot, ClaudeBot, et al are blocked whilst, e.g., CCBot isn't.)
You need to block all the Anthropic bots listed here, not just ClaudeBot.
That is not how
robots.txtworks. If they're claiming that, e.g., "ClaudeBot" is ignoring theDisallow: /in myrobots.txtbecause it's really "anthropic-ai" but just happens to be sending "ClaudeBot" as its user-agent instead of "anthropic-ai", how is that not anything but a deliberate skirting ofrobots.txt?Which is what this whole bloody conversation is about!
Also https://support.claude.com/en/articles/8896518-does-anthropic-crawl-data-from-the-web-and-how-can-site-owners-block-the-crawler specifically claims that
User-Agent: ClaudeBot\nDisallow: /is sufficient to block ClaudeBot (which it clearly isn't.)That may not be how
robots.txtis supposed to work, but that's how I block Anthropic's bots on my site. For now. Who knows? Maybe in 20 minutes they'll launch a new bot with a new name. At least for now, if you use all the current names, you'll block Claude.Sounds right… but why did this come up? What software did you find that performs this “normalization”?
IRC, Microsoft Kestrel servers normalize extra slashes in path names to a single slash and it’s been that way for many years. There are probably too many websites built on this assumption to start enforcing a different interpretation now.
The technology equivalent of "too big to fail" where a dominant vendor is given special dispensation to ignore the RFC.
I'm pretty sure flask does this by default. I've seen it in the wild a few times, and I even thought this was what's supposed to happen until I saw this article, so quite a few web server libraries must be doing this too.
That is correct, it is in fact a property of werkzeug which underlies flask (and other packages): https://werkzeug.palletsprojects.com/en/stable/routing/#werkzeug.routing.Map
You really need to normalize URLs on the server for one reason or another. The more important thing is that if you want composable anything and you want to pass paths around, instead of segments, you need to normalize
%2fand/which upsets a lot of people. A server will also have to deal with.and...The WhatWG standard only prescribes what URL serializers/deserializes are doing, it explicitly permits servers to normalize it beyond that for empty slashes. At one point the spec even specifically called out the idea "of not holding data" in segments as being unintended.
URLs should never be composed by the client: they are opaque strings. Cool URLs, of course, are pretty opaque strings to make life for humans better:
http://site.example/articles/2026/01/28/is much better thanhttp://site.example/a46bcaee-fc3d-11f0-9390-af34fdb4192e. But no client should ever compose a URL: it should be configured with a base URL, retrieve that resource and receive a hypertext containing URLs to more resources, determine which of those to retrieve and so on.Yes, I’m aware that OpenAPI-style systems expect clients to compose URLs. They are certainly able to do that, but I believe a resource-oriented HATEOAS style is preferable, providing operational flexibility and RESTful semantics.
The main counterexample is relative URLs, which require clients to understand the structure of URLs and compose them from parts. There are many ways in which URLs are not opaque strings: you can’t even make an HTTP request without parsing and decomposing the URL. There are standards such as URL templates that allow more bespoke composition.
I agree, and I'll add that I've been very pleased that I can craft things like search URLs and dynamically deep-link into other websites. The URL structure is often part of the API spec.
Composable on the server. As in: route /fußball/* to a different service.
Apache for one. It wasn't ... obvious, how to redirect "//index.atom" to what I consider the "canonical URL" of "/index.atom".
I’m curious why you’d want to go out of your way to do this, rather than leaving the server to do whatever it does by default (whether that be 404, 200 of content or redirect to remove the slash), and blaming the users if it’s not right or ever stops working.
(I say this as someone who’s considering configuring his server to respond 400 to requests with query strings, as a petty reaction against sites that add
?ref=…and?utm_…to links, when I don’t want to know where they’re coming from if their browser chose not to send aRefererheader.)There are a few feed fetchers that are requesting both "/index.atom" and "//index.atom". I was hoping that by sending a permanent redirect I could save both them and me some bandwidth by requesting the file only once instead of twice at each polling interval. I keep sending the permanent redirect, but they never take the hint. Sigh.
As for sending 400 due to query strings, I think 422 (Unprocessable Content) might be a better match, or even 418 (I'm a teapot) just to really jam the message home.
422 (Unprocessable Content) isn’t appropriate: “content” means the body, but this is about the URL. (This has been the designed semantics since WebDAV days; it was then named Unprocessable Enitity, but “entity” meant the body plus related headers like
content-length.)I reckon the reasonable candidates are:
Honestly I might go with 414.
I bet that's due to the feed fetcher being configured with both
https://foo.example.comandhttps://foo.example.com/and just blindly adding/index.atom. If you break the//index.atomURL you're probably breaking your feed for the users who subscribed with the trailing slash.Oh, I know the probable cause of the issue, but I don't understand how I'm breaking
//index.atomfor subscribers? I get a request for a resource, it's actually under a different resource location, I send a permanent redirect. It's the same as when I get a request forhttps://example.com/path/pathand because I know/path/pathis a "directory", to get proper relative links to resolve, I send back a permanent redirect tohttps://example.com/path/path/. What is supposed to happen is the client is told "hey, that link you have? It should be this" but from my experience, almost none bother with updating the link.There’s a list at the end of the article
Where are they? Where are the Yahoo style directories and RSS Reader type tools that bring it all together so I can use it as a user quickly and easily?
I feel like the number of people actually using IndieWeb concepts has been constant for 10-15 years - it doesn't grow or catch fire. It's a nice concept, it makes perfect sense, it facilitates an alternative to the social dysfunction of the current web, but it gets no traction.
It's another 'Linux on the desktop'. Next year will be its year.. next year
There's a ton happening in this space, but ad-driven social media steals so much attention. RSS readers like Feedly have millions of downloads and there's tons of other popular tools.
Some times it's hard to get started. Kagi Small Web (per the article) has a great list. I maintain a blogroll based version (https://alexsci.com/rss-blogroll-network/). But I think these can be overwhelming. There's also starter packs (https://www.youneedfeeds.com/starter-packs), if you have a theme in mind.
I've been working on an extension that collects feeds as you browse (https://github.com/robalexdev/blog-quest). There's a lot of active sites, especially if you're interested in tech.
I don't think the small web needs to grow to succeed, it seems quite successful and useful as is. But I think it will continue to grow because it provides a valuable alternative to the commercialized web.
For all its quirks and faults, ActivityPub remains the choice for Actually Existing Federation if you care about that.
At the same time, AT's design means that several features AP has like private posts and DMs just can't be implemented in AT (bsky DMs don't go through atproto at all; I'm not sure if there's even theoretically a mechanism for someone on Blacksky to DM someone on Bluesky).
Not yet, but private data has been an important priority of the team and they've been trying to work through a design.
You'll have to forgive me if that doesn't strike me as particularly heartening. The whole system is designed around entirely public repos, with all private state held by the centralized actors. My experience here is a great example; the protocol has a vulnerability - people acquiring domains referring to deleted did:webs and resurrecting them - and they resolved it by... breaking the experience of decentralized users in their centralized system.
People (not just me!) told them they would have issues with things like this from day one of the protocol being discussed openly. If they wanted to support private data, from DMs to posts, follows, and so forth, why not build in a mechanism for that from day one, rather than having to migrate to a protocol that supports it?
I wasn't trying to 'hearten' anyone, I was just trying to answer the question the parent asked.
Because you don't always get to pick when you ship. Sometimes, you have to start somewhere and then build on to more things later. Bluesky's early history is fundamentally intertwined with Twitter/X's, and outside events shaped what has transpired just as much as decisions by the team have.
That said, that doesn't mean you have to like what they shipped. But that doesn't mean that there aren't reasons for choosing the things they've chosen and the order they've chosen to do them in, even if you personally disagree with those choices.
Apologies, I read your invocation of the roadmap as reassurance. "This feature doesn't exist, but it will soon!"
I understand they were under pressure to ship. What I don't understand is why they didn't work with any of the existing and actually decentralized social media projects out there.
The very first thing Jay (bluesky ceo) did that got her involved with the project (before it was even a company!) was making a colossal spreadsheet listing every single decentralized social media project they could find, including many obscure ones, and document in detail the specific pros and cons of each of them as a foundation for a Twitter replacement.
They did work with other decentralized projects extensively, and continue to do so.
I find it frustrating that you always presume bad faith.
They did extensive research on what was out there. Previous work did not meet their needs. It's as simple as that. I have never found the team to be hostile towards other projects. A bunch of folks had even worked on some of those other projects! They just have different design goals, and therefore, different systems get built because of it.
I, and others, have spent several years going "hey look this part of the system is centralized" and hearing, from you and others, "just wait, it'll be decentralized eventually!" or "it's decentralized in principle, even if not in practice!" or, worse, "no, I promise, it is decentralized" before finding out that it is not. (That was even on here!) I have been literally, actually, directly lied to by people about whether or not certain software components are available outside of the Bluesky platform. That's as bad faith as it gets!
But in this case... I don't really think I am assuming bad faith? I didn't say, "why didn't they evaluate other projects." I absolutely believe they did. You say those other projects didn't meet their needs, and I'm curious about how, specifically, they didn't.
A big way ActivityPub didn't meet their needs is that binding user identities to specific named server instances was a major UX regression compared to Twitter, and a founding philosphy of Bluesky was "no UX regressions compared to Twitter". Ordinary people don't want to have to figure out how to pick an instance and worry about the consequences of that. They want to be able to just go with whatever thing they heard of from their friend and have a way to deal with changing their mind about that later if they need to once they understand the app and ecosystem better.
Yeah, I absolutely agree. I think portable identity is really cool, and the work Bluesky and Spritely have done there is worthwhile and interesting.
What I don't understand is why they didn't do that work on top of existing server implementations that already did most of the rest of what they wanted, which would have then benefited the users of those servers!
Look, I agreed with you when I first heard about this project. But then it actually launched and I read through the specs and designs and built my own things on top of atproto.
There was no way to get the features they wanted on top of the existing decentralized social media protocols. User identity systems are really foundational, and it's extremely hard to work around their limitations if they don't fit your desired feature set. ActivityPub and the fediverse were okay with user identifiers being tied to specific DNS domains hosting them. Bluesky wasn't okay with that, for UX reasons. So there wasn't really an option of "just build on top of activitypub" - it would have required completely changing the fundamentals of how accounts work. It was discussed, and the existing ecosystem wasn't interested in that.
Fair enough! I'm still looking with interest at some of the proposals to build DID-like mechanisms into the Fediverse, and of course, as ATProto continues to become more decentralized, I'm becoming more interested in it, too :)
I don't really believe that you're having an honest conversation, and so I'm just going to bow out. I answered the question that was being asked, I'm not really interested in re-litigating all of this with you.
Steve, between this exchange and how I've seen you approach talking about LLMs I'm suspecting it isn't possible to have a "good faith" discussion that isn't just agreeing with you. Seems a little... bad faith!
I have plenty of disagreements with people about LLMs and about atproto! All the time! And they're good discussions.
They often don't happen on lobsters, because I find that posters on lobsters tend to be not particularly interested in having discussions. They're more interested in posturing about how they're right.
The parent has made it very clear over and over again that they're more interested in lecturing from their own opinions about things than engaging in a real way. I actually find what's in the post itself to be fairly decent, if you're willing to strip away the desire to cast atproto in as poor a light as possible. For example, pointing out that all of this is very undocumented? Yes, that's a great point, and it's also very true. But ultimately, that's not what this post is about. And that's why, you'll note, I didn't engage with the parent until they engaged with me.
I originally quit this site for six years because of friendlysock's repeated behaviors. I came back because I couldn't stand someone I respected being attacked publicly in bad faith, and decided to stick around again, because things had improved. But now, I see this site as mostly being a collection of friendlysocks, rather than just one. It's actually gotten worse.
So yeah, sure, I'm out again. Maybe I'll answer questions about jj from time to time, because it's a technology I truly care about enough to put up with all of this. But don't expect posts otherwise. Maybe I'll come back in a more real way in years again.
You know, I haven't seen anything particularly egregious in this thread (from you either) until this comment right here. That and your snarky comment to your Bluesky followers linked below does actually lead me to think that the parent comment might be correct. But I know we can't all be perfect on the internet 100% of the time. I just want to say that I was enjoying the conversation up until this point and I don't think lashing out at the lobste.rs community is really an appropriate reaction here.
For those curious about intriguing upvote totals in this thread, it is being brigaded after being linked from the parents' large social media account https://bsky.app/profile/steveklabnik.com/post/3mdbpu2budk23
Instead of assuming malice, maybe assume there are Lobsters users like myself who don't really care for the earlier discussion but agree with ~steveklabnik that the tone of the discussion was not in good faith. It was snarky and rude about developers who've clearly worked really hard on a protocol, and then disrespectful to Klabnik, by pretending not to know what he means. ATproto isn't perfect, but it's being worked on. "It'll be decentralized eventually" is a valid position for a project to hold on something they rushed to market to capitalise on an exodus of Twitter users.
Not specific to this topic - for promises of future functionality coming from the tech industry, I place very low weight on things that have yet to materialize after a generous grace period of several years. Call it hype fatigue. ActivityPub-based stuff isn't immune to this either. Cross-forge PRs have been in limbo for a while.
Right, and it's not like DMs or private posts are some new feature people only just realized they wanted.
To be realistic, not a single decentralized social network in existence has Solved private communication. Every existing attempt either has critical security issues, UX problems, or there is an adoption/implementation gap. ActivityPub, ATProto, and Diaspora all currently lack any mechanism for actually private communication.
NoStr has, after many failed obsoleted extensions, most recently published extension support for MLS but it's contingent on your client's implementation and behavior, and is not exactly battle tested yet. There exists an extension to SSB called Private Box, but essentially all of the SSB GUI clients that support it have been discontinued for several years.
It absolutely should not be undersold as some oversight that devs forgot to hack together and ship overnight without issue. These two features are, I think, the most difficult to get right on a protocol level.
To me there is a difference between not having E2EE chat baked into the protocol and having no concept of any way to limit information from being available to anyone who asks for it. I agree that encrypted communication in a decentralized network is difficult. I don't agree that less public information is.
If you trust your operator and all the nodes they communicate with in the network to not read your private content, then yes it is not technically complicated to just arrange that an API not expose certain things to clients on their endpoints based on who should see it and shrug your shoulders at all the avenues where such an approach can easily be defeated.
However, I suspect that such half measures would end up more like a way to do security theater that makes users feel more secure in their use of a system than they actually are, which is incredibly dangerous. Taking such half measures would just erode any trust people have in a network the day that their supposedly private information is all leaked and people get dox'd and swatted.
If I were any of the reasonable people involved in the development of any of these protocols, I would also oppose such half measures being baked into their API's.
This is exactly how my longest-lived fedi account is: it's a locked account on a server run by a friend, connected to servers run by friends and friends-of-friends, and I post only followers-only.
This is not proof against all attack, but it's security commensurate with the threat model. I post emotionally vulnerable things, but nothing incriminating or unethical.
I'm not at all asking for E2EE, just "some way to send another user a message or make a post that isn't in the big atproto firehose".
that has nothing to do with atproto then, that is centralized messaging, which bluesky the application has already implemented outside of atproto, minus the private posts part
Lobsters still require invites to get accounts and vote, though, so it seems less likely to be subject to brigading by random social media followers than most. As of a minute ago, Lobsters has 19,550 users.
What fraction of them 1) saw Klabnik's comment on BSky, 2) weren't already active on Lobsters, and 3) chose to login and start voting on this? (Only 2 users joined since this article was posted, so there's certainly no rush of signups to defend him.)
I think the upvote totals are more likely to reflect actual sentiment from regular users.
At the time of posting the replied-to message had accrued an anomalously high number of votes within ten minutes. It was pretty conspicuous for something buried like eight comments deep.
None of the absolute vote totals in the comments are high enough to make me bat an eyelash.
As for the depth, so what? It's easy to read all the comments of a post on Lobsters, because there's just not that many. If anything, deep comment threads indicate something of interest to people.
I think you're seeing nefarious activity where there's none.
For people like me who follow all comments via the /comments page, rank within a specific comment tree is irrelevant.
Even taken out of context, the comment (id 1ynvf2 to confirm what we're talking about) has enough info to invite a sympathetic member to upvote it, in my opinion.
I'm just stating this as a possible explanation to a sudden burst of upvotes, regardless of it receiving exposure on other sites.
This is not just embarrassing behavior, it is a violation of the Lobste.rs Guidelines:
This conspiratorial idea that the microscopic crossover of Bluesky users that also follow Steve and have an account here, are gaming the upvotes, a metric which nobody actually cares about anyways, is clearly just a way for you to continue to direct abuse at Steve for speaking out about a piece of technology you don't like!
It's not like I even have a dog in ATProto vs ActivityPub. They are just similar technologies made by different people that made different trade offs; ok, so what, it's honestly not that serious. But I upvoted Steve because he rightfully called the behavior in this thread as non-sequitur abuse, which in my opinion is doing no favors to anyone, including those who react to the standard of discourse on this website, and especially those who advocate for ActivityPub.
Yeah, I wasn't sure whether to flag it or not, since I have no prior experience with most of the people in this thread.
I don't yet know if it's an isolated mistake or a regular pattern, but I use a userscript called UTags to attach tags to usernames, which quickly surfaces repeat bad behavior.
I'm now on lobste.rs since 7 years and from my observation you do seem to end up in these heated discussions about things you really like and others don't for various reasons. I was once involved helping in one of these where things were simply factually wrong from my (and your) POV.
Honestly ? Simply staying out of these discussions or just stating some facts and logging out is the best. A submission with 93 upvotes, 112 comments (more than upvotes) and a title like this screams mud fight (or editor fight) to me. No way the comment section of lobsters is going to resolve long standing tradeoffs between decentralized-, centralized- and systems in the middle.
Hope you're staying here for the actually interesting topics (or rather topics for which it's not as much a question of priorities and preferences).
The purpose of commercial enterprises (like bluesky) is to make money for shareholders. Not to act in good faith (or bad). Nobody is claiming you are acting in bad faith, and nobody should expect any commercial enterprise to act in "good faith" because moral good and bad are meaningless concepts in a boardroom.
It's undeniable that there's a lot of money in being at the center, not so much in making tools to build a system with no center.
According to Wikipedia, Bluesky Social is something called public benefit corporation: „Benefit corporations explicitly specify that profit is not their only goal”.
This seems performative to me. It's still a for-profit corporation, the people who stand to make that profit are still making the decisions.
Yes, Public Benefit corporations are in fact entirely performative. All it requires is that you specify that you can have pro-social goals other than profit; there is no requirement that you actually do anything positive. Any company whether decent or vile can claim to be a public benefit corporation just by amending their bylaws to say so.
Companies that do this often benefit from confusion between "Public Benefit Corporation" and B Corporation, which is a certification that actually does have qualifications that must be met beyond just saying "yeah trust us guys, we are good."
In the USA, a benefit corporation has two goals: profit, and passing a corporation-specific annual audit. The audit is arbitrary and advisory; benefit corporations get to have some non-profit goal but they do not have to pick a goal which benefits society.
Sadly, that seems to be just words on paper, and there's no actual laws to keep them on track. At least when you compare to EU non-profit laws.
[Comment removed by author]
I hope they can figure something out, but lately I've been at the point where I don't really put much stock in "they're working on a design" for technical projects (not just bsky here). I can't evaluate whether any of the technical proposals linked elsewhere in this thread are any good, but my default stance is that it won't happen any time soon, if ever.
There is probably a way to do private stuff on ATProto, which is how they solve everything else basically: by introducing a new "app" (i.e. a new server, with a custom backend/AppView) that deals with encrypted data and introduces yet another centralized point-of-failure that is impossibly hard to migrate out in practice, like Bluesky.
No, this is not how it will likely work out. The current proposals seem to be starting with introducing a protocol extension to the PDS to allow it to store records that don't get sent out of the firehose. Paul Frazee summarized some of the approaches being explored here: https://www.pfrazee.com/leaflets/3lzhui2zbxk2b
I think email is a fine choice, its the only one I can reliably reach all my friends and family.
Agreed. I have been putting a lot of effort towards moving my social connections to e-mail, and I really enjoy connecting with people that way.
Maybe we just all need to be on a big listserv.
I enjoy emails so much that I made a new "reply" feature for the offpunk browser which is simply "sending an email to the author if I could find that email". After only two days of testing, I’m already sold to Gemini+Email as my social network of choice ;-)
100% I thought about implementing comments for my blog/capsule, but then I just added a footer that says "send me an email". I occasionally get some!
Honestly, getting an email about my posts or things really makes my day. To me it's almost as good as getting a real letter in mail. It feels more personal, thought out, and gives me the warm fuzzies.
And it sometimes create meaningful exchanges. That’s why I wanted to make it easy for me to send a mail to reply to a blog post/gemlog I’m currently reading.
Oh, this is lovely. I should spin up Gemini again.
Only because you and all your friends and family use e-mail from the same 3 big companies :)
Actually Im in a minority: my partner uses protonmail, my parents use their work email (self hosted) and me I use fastmail.
I don't think that's true. Email is very centralized to Google and Microsoft, but there are tons of other options available and they work perfectly fine.
https://alexsci.com/blog/the-most-popular-email-providers/
Slightly off-topic, but does ATProto have something analogous to the FEP standardization / extension process where changes to the protocol are publically discussed?
Nothing that formal yet. They're currently in the process of turning ATproto into an IETF-owned spec with its own RFCs and such. Once that effort's done, the IETF RFC process will become the manner in which changes to the protocol are made and discussed. You can see the draft specs here: https://github.com/bluesky-social/ietf-drafts
Your email-related proposal will fail because:
... [x] it requires cooperation on the part of the malefactors ...
There is still some value in non-malicious senders giving their mail an expiration date.
Though I'm unsure if it should ever be used for deletion, I don't think anyone should be able to delete mail I receive.
I think this project agrees.
The UI they are going for seems to be that an email client can support a "show all expired email" view, then the user can choose to mass delete or pick and choose.
I'm unsure if even that could work if senders misuse expiricy for example billing or something like that. In any case it further reduces any potential effect it could have.
Perhaps we should crowd source email retention policies like do for ad blocking?
One reason I switched from this model to hugo (https://alexsci.com/blog/hugo-import/) was the challenge of keeping everything in sync. The title of the post exists in the HTML as both head title and body h1, the index, and the feed, for example. I found I'd forget to change one, so I wrote a manual deployment checklist to ensure they were all synchronized. When you write out every single step it's actually a lot.
I broke my RSS feed a couple times. I put the wrong date format, copy/pasted an RSS item but forgot to change the GUID, and made the images-as-relative-links error. I think you need a validation step, at the very least, as it's easy to break.
One of the reasons I'm considering going back to a plain HTML approach is that I want to archive old posts. I feel that a blog should use the header, footer, and style it used when it was posted. Hugo wants to make every page look the same.
I think there is a middle ground of writing posts in plain HTML while generating the feed and index (maybe sitemap too). If I write another SSG, that may be the concept.
Regarding Linux commit author dates, these are usually taken from when the patch email was sent. So you're actually measuring the email's Date header, which can be wildly inaccurate depending on the mail server (as you have noticed).
Agreed. There are more challenges too, if you're using a mail client like Thunderbird then I believe the Date header is set by the sending user's system, not the mail server (MUA vs MTA). So the system clock is being measured can vary.
I didn't write about it but I also did some light analysis of timestamp headers in the Linux mailing list archives. There's all sorts of "time travelling" happening there: messages with Received headers earlier than the Date header, replies earlier than the original message, etc. That data looked even noisier, so I didn't dig in to all the anomalies
I don't understand how this reflects poorly on Microsoft? How is it Microsoft's responsibility to be monitoring CT logs for suspicious Cloudflare certificate issuance, and not, y'know, Cloudflare?
Microsoft couldn't have known if Cloudflare authorized the certificate or not, but they could have noticed that the certificate fails a bunch of lint checks: https://crt.sh/?id=14793030836&opt=pkimetal
All three other root stores (Chrome, Mozilla, Apple) proactively monitor CAs for lint failures and/or take third-party reports of lint failures (and other non-compliant behavior) seriously. I and others have tried reporting problems with Microsoft-trusted CAs to the Microsoft root store, only to be ignored.
I agree that it isn't Microsoft's role to detect misissued certificates but this incident does reflect poorly on Microsoft. Only Microsoft chose to trust this CA and this is not a little mistake for a CA to make. Microsoft has a very large trust store and it's not clear why they trust so many CAs. Google and Mozilla have a transparent inclusion process, complete with public audit reports from independent auditors, and when CAs make mistakes they explain what went wrong and how they are going to fix it. Microsoft is the odd one out here and should do better.
I think the article blames Microsoft mostly because it is the only to trust this CA and it is unclear why.
Although I agree they aren’t the CA and cannot monitor ALL certificates issuance.
More to the point would you want them to? Would you want every change you make in your registrar be functionally blocked on MS reaching out to you when the pre-issue certificate was produced? Because you're essentially saying "MS should require CAs to confirm with MS, that MS has confirmed your intent to change CA".
It will be interesting to see if MS allows the CA to remain in their trust store given they've just demonstrated inadequate controls - unless of course a medical provider uses the CA for medically critical devices that have no reason to require anything PKI related to be involved and sues MS to force everyone to be exposed to a demonstrably untrustable CA because they are too incompetent to deal with an issue, despite signing a contract stating they understood they would need to be able to.
Microsoft seems to generally have low standards for what they consider trusted, whether 3rd parties, or themselves https://bugzilla.mozilla.org/show_bug.cgi?id=1965612
Microsoft is the one that trusted the CA. Cloudflare has no relationship with them as far as I know.
How does MS know which operations are bad? Should they require confirmation for every certificate that is issued?
You are misunderstanding who is responsible for what in the CT system.
The design of CT is to permit certificate recipients to detect issuance. They’re the only people who can identify such.
The fact that these certificates were issued, and were valid - so must have been submitted to multiple different logs - yet were apparently not detected is indicative of failure to monitor the logs by a service for whom such compromise is important.
If you ship a root store in your product you are trusting the CA roots you choose. If one of those CA's turns out to be untrustworthy you're responsible for finding out and removing it (in a revocation list or a software update).
Which you do via audit reports and similar. Not by manually verifying every operation they perform.
CT was specifically created to make detecting such issues possible, not to require root stores to verify every certificate issued themselves. The entire reason for root stores is because the alternative would be a single CA operated by the platform. The entire reason for CAs is to not do that, but once they are performing the task of verifying those operations there is no longer a reason for the CAs to exist.
The one I got wrong was consecutive periods.
The easy thing with email addresses (generally) is that the local part is “anything” and the domain part is, well, a domain. Comments are obsoleted (thank god) so you can safely wipe out anything between parenthesis, forward what remains to the server after the
@and you’re golden.I even wrote a simple tool/service that took a http request and just asked the SMTP server if the local part was an actual mailbox.
No need for me to “parse” or validate at all myself.
I got the space before @ wrong, because as it mentions it's ignored. It's not technically the email address then, is it? :D
Which mail servers support this?
This sounds like it would be a security risk due to user enumeration.
User enumeration is not a real security risk. Ask Wikipedia what a phone book was.
"That's a valid email address!" So what? It's going to get spam and malware and phishing and half-assed spear-phishing attempts no matter what. And so will a thousand other addresses, most of which will be undeliverable.
"Now we know their login handle!" Security does not depend on the login handle. Security depends on the correspondence between a password and a particular login handle, and for anything serious, a second factor as well.
It's certainly a privacy risk, though.
why? You have to know what you’re asking for.
Not really. Enumeration allows me to try many firstname.lastname@example.com addresses. This tells me the names of the people working at a company. Names are PII.
Names of employees are a matter of public record (as per: https://www.gsa.gov/reference/gsa-privacy-program/privacy-act-and-gsa-employees)
I guess the argument can be made that less information is better, but this might become hair pulling at some point. Just rate limit VRFY and block people who miss a few hundred thousand times in a month.
It also works for students at schools. And there are other jurisdictions than that link covers so it's still worth implementing or considering.
There are a couple of features in SMTP that allow anyone to validate mail addresses:
the VRFY command, which became generally regarded as a bad idea in the 1990s because it allows user enumeration, and has been basically unused ever since;
and the RCPT TO command, which since the rise of spam around 2000 has generally rejected mail to invalid addresses because that’s one of the cheapest possible zero-false-positive anti-spam defences.
(Mail server implementations and local policies may differ, of course.)
It’s funny to me how these security best practices directly contradict each other, owing to the way threats evolved and drove our understanding of what defences actually have demonstrably useful effects.
[Comment removed by author]
Mailboxes don't have to corrospond to users in any way
I wish we could organize a service or chatroom where we match successful vibecoders up with "LLMs don't work for programming"ers and have them work on the same projects to see what's going wrong.
I made an entire useful website (https://bridgedays.github.io) with Sonnet 4 in like three hours a few days ago. "LLMs don't work for coding" is incomprehensible to me.
I don't want to overly critique a site that isn't a submission, but I'm seeing issues when Friday is a holiday. It looks like it suggests taking off Sunday to Wednesday, but not Thursday. But Sunday is listed as a weekend and Wednesday doesn't bridge to Friday. Unless I'm misunderstanding the concept or the UI, this doesn't appear to work.
It's great that this was quick to build, and it would take me more than three hours to replicate it by hand, but it doesn't seem usable yet.
Also some of the sources don't look entirely correct - Saxony in Germany, for example, definitely has more public holidays that fall midweek than are shown in the calendar.
Unless it's a display issue, that would probably be a problem with the source, OpenHolidays API. Check https://openholidaysapi.org/PublicHolidays?countryIsoCode=DE&validFrom=2025-01-01&validTo=2025-12-31&languageIsoCode=DE&subdivisionCode=DE-SN please?
I think it's a display issue, although maybe more a UX issue than a bug per se. If I look at November 2025 in the calendar, I can the 25th highlighted in bold, but also with a yellow background. I think the bold is because it's a public holiday, but the yellow background should be for days that I should take off, right? I would expect this to show with a red background, with the weekdays either side highlighted in yellow as potential bridge days.
The API returns the correct data, and I think the app is reading that data correctly (otherwise it wouldn't calculate bridge days there at all) but it's just displaying in a way that doesn't quite seem right.
Also, I'm looking at this all on mobile, which is very cut off and only shows the calendar and a very thin strip of something underneath that I can't read properly, so I might be missing something.
... November 2025 has the 25th highlighted in bold for Saxony 2025? That's a bug, can you post a screenshot please? (Also, what's your browser?) Nov 25 is not a holiday in Saxony, and it bolds Nov 19 here.
Also yeah the stuff underneath is kind of the entire site, ie. the list of bridge day holidays. :) Not sure how to fix that. When you click on a bridge day marker, it picks a time-off choice for that day from the list below, but it's not necessarily the longest one.
You're right, I meant the 19th. If that is the correct display (i.e. bold, yellow background), then you might want to highlight it a bit more somehow, because as it is I was struggling to see where any of the public holidays were.
For the section below, presumably the calendar is specified to be sticky in some way in the CSS (or the part below it is set to be scrollable). This makes the whole thing almost impossible to use on mobile, as you've only got access to the calendar. Maybe you can disable this stickiness, and just let the user scroll up and down between the calendar at the top and the calculations below? Maybe you could have the sticky effect only kick in if the window is tall enough, if you think it's useful enough to keep.
Alright, try now. I didn't consider phones at all. With smaller screens it should now disable the separate section and just show it as one flowing text. Also, tapping an opportunity should permanently select it (it uses mouseover on desktop). Then you can scroll back up to see it in the calendar.
Also, this is the total of my input:
edit:
I think it's a display issue, although maybe more a UX issue than a bug per se. If I look at November 2025 in the calendar, I can the 25th highlighted in bold, but also with a yellow background. I think the bold is because it's a public holiday, but the yellow background should be for days that I should take off, right? I would expect this to show with a red background, with the weekdays either side highlighted in yellow as potential bridge days.
The API returns the correct data, and I think the app is reading that data correctly (otherwise it wouldn't calculate bridge days there at all) but it's just displaying in a way that doesn't quite seem right.
Also, I'm looking at this all on mobile, which is very cut off and only shows the calendar and a very thin strip of something underneath that I can't read properly, so I might be missing something.
Thanks! No that's great, I love feedback. Could I bother you to file a bug report? There's a Github link on the top right.
There were definitely issues with the holidays, and it's very plausible that I haven't stamped them all out yet. I haven't seen something this blatant in my own use since I released it, but it's plausible I missed something.
I've done this with a few friends. For the most part, I've found that people just can't write specs very well. They'll ask the machine for something that can be interpreted in 50 different ways, or include long irrelevant parts of their thought process with relatively little detail about the desired solution. Having them practice writing specs that someone else could use has been really effective.
But a truly unambiguous spec would end up being code, right? Isn't it better to write that spec, that code, in a succinct language that's designed for that purpose, using a tool, a compiler or interpreter, that will handle it deterministically?
No, look at most RFCs and design documents. They detail what needs to happen, the edge cases, and sometimes rationale or test vectors. It can function as the source of truth for implementations without providing code.
A good RFC takes longer to write than the implementation. Also, I usually write the RFC after writing a POC.
I've written several RFCs that took weeks to make. I certainly would not recommend that level of detail for an LLM.
I'm more likely to use an LLM for prototyping. Another example: I was working on improving the performance of a data pipeline, where we were spending ~$10,000 in compute/month. I came up with several ideas, and asked the LLM to come up with more. There were something like 10 plausible ideas.
I ordered the ideas by how likely I thought they were to work, then tried implementing each one with the LLM, with shitty minimal code that was just enough to test the performance of the design. Each one took 30-90 minutes, and I would estimate that doing them myself would have taken me about 5 hours each, because that's how long two ideas took before I tried the LLM. My process for each was roughly "give me a plan for implementing design X", critiquing the plan back and forth and adding more detail, and then babysitting Claude Code while it actually implemented that plan, sometimes making corrections to the code it proposed.
Most of the ideas were a wash, but idea #8 was a 55% improvement in performance, which translated to a 40% improvement in cost. I definitely would not have even bothered to test it on my own.
After testing the ideas with the LLM, I created a new branch and implemented the best idea from scratch. I think this is generally a good way to work with them.
So here's an example of what I'm talking about. Initial prompt: "deduplicate this code." Revised prompt: "my codebase uses libraries Foo and Bar, which have very similar functionality. I would like to remove Foo and keep Bar. Search the web and compare the two libraries to see if I would lose any essential functionality this way. Then give me a plan for removing Foo."
"Give me a plan in a markdown file" is a secret weapon, because it lets you reset the context if something goes wrong and still keep going in the same approach.
This has been my experience too. It seems like the initial prompt matters more than any future prompts that attempt to keep it on track - it seems better to just
/resetand adjust the initial prompt.+1, I vibe coded a pretty reasonable speed scrabble game (https://speedscrabble.netlify.app/) over parts of 3 days using Claude Code.
(That's not to say that I don't find it frustrating and maddening a lot of the time, but it really has changed the way I develop.)
ok, can we all (competent programmers trying AI tools) at least agree that "I vibecoded X with Y in Z hours the other day" is completely uninformative, given the wide spread of outcomes we keep reading about ?
It would be far more instructive to show how it played out, how you interact with the tools, what you expect of them, etc.
I played through your game. There were some minor UI annoyances, but that was quite fun and well executed.
"writing specs is hard and not fun to everyone" is certainly part of, as another comment covers (I'd rather write the project than the specs for sure). but it's worth adding that, since models rely on some randomness, there will always be cases where it just does badly on a question, because luck didn't favor you. if that was someone's "give it a chance", well...
Yep! As somebody who vibecodes a ton, it happens very frequently that I just have to go "well, it got it wrong, this context is ruined",
/undo,/clear, reask question. It's easier to tell when the model has gone wrong than doing it right yourself, so this is still a speedup, but it is absolutely something you have to be ready for.Is there any substance to these assessments?
They just seem to be rating whether the org behind the project is individual, not-for-profit, or for-profit, and evaluating whether the org requires a CLA, DCO, or no agreement at all before accepting contributions.
Those with for-profit orgs and CLAs are deemed high risk for relicensing. Those with not-for-profit orgs and DCO are mid. Those with individuals and no agreement are low.
Maybe it's more subtle than that, but I've not been able to spot more nuance so far.
Claiming that Apache HTTPd is mildly likely to be relicensed sounds just plain weird to me.
(Creator here) The mild rating reflects the use of the Apache 2 license, which isn't a copyleft license. It's pretty easy to take Apache 2 licensed software and build a non-open-source fork. The Apache Foundation would be fully compliant with the Apache 2 license if they released future versions of HTTPd under a non-open-source license.
The reason HTTPd feels like it's at lower risk is due to the reputation of the Apache Foundation. Reputation is hard to measure objectively, so I haven't been factoring it in to the ratings. I've considered reducing all risk ratings for non-profits, but there's examples of non-profits that have relicensed software, so that alone isn't a clear signal.
It also feels like it's at lower risk because it's been offered under the same license by the same not-for-profit since the 1990s.
I won't dispute that longevity is hard to measure/rate for the kind of ratings you're doing, but it certainly figures into my mental "risk math" when I'm deciding whether or not to contribute.
It's more likely that HTTPd is dead within 10 years than being relicensed (apart from a potential Apache-3.0).
I strongly agree. It seems about as likely to be relicensed as ghostscript.
I didn't mean to suggest that I thought these ratings were correct; I was just saying what seems to be behind them as far as I can tell. The httpd one, specifically, made me think the ratings were not good as soon as I saw it.
yeah that one stuck out as obviously wrong
It seems to be a consideration of :
A project with a CLA can be arbitrarily relicensed anytime.
A project with a permissive license can be switch to a non-open-source license (non retroactively).
Apparently all projects using the MIT license belong on this list? It's gonna be a big list...
The "high risk" category requires a "license agreement".
But yes, all permissives licenses (MIT, BSD, Apache) are "mild risk".
After validation from the fellow comments, I now feel confident in asserting that this website is nothing more than an expression of the owner's bias against corporations (and the deluded fear of companies abusing permissive licenses, which doesn't happen anywhere near as often as FOSS advocates rave about). Now, having a bias against companies isn't the most taboo form of bias one can have, but it's still false information. This website is probably as reliable as your crazy uncle telling you they're putting nanobots in the water.
(Creator) I think there's room to add many more projects, especially popular projects, but at some point there's diminishing returns.
I appreciate the effort collating announcements, but the comparison to "rug pulls" is wrong and entitled.
Existing releases aren't suddenly being turned from open to restricted. If there was any forward-looking promise from the project stewards, it wasn't free lunch forever, but that users would be able to cook for themselves. I've yet to read about a project that changes its going-forward license policy and doesn't tell outside contributors, so as to keep drawing contributions.
Projects don't have licenses. Releases do.
IMO, when you accept outside contributions, a forward-looking promise is strongly implied. If you change the license so that people who've contributed to make the whole of the product better no longer have the same rights to the better whole that they had to the old versions, that feels very much like a rug pull to me.
You might argue that I could avoid that by refusing to consent to a CLA. I'd agree, and argue that these rug pulls are evidence that CLAs are not just things that "keep the lawyers happy" (as another commenter said) but are things that should actively inform contributors as to risks that might reduce the future value of their contributions.
Contributors have the same rights to improve or even fork releases made under the prior license. The delta between the last release under the old license and the first release under the new license is a bunch of new work by the steward's contributors. There wasn't any promise that any further work would be licensed consistently, or even that there would be future work.
I wouldn't, because use of a CLA isn't necessary or sufficient for the kinds of policy changes we're discussing. Any steward of a project under a permissive license without any particular terms for taking contributions by others can start releasing new work under different terms at any time, just as anyone else can fork under their own terms of choice.
No common license terms for source code shared and developed that I'm aware of—permissive, copyleft, or restricted—include any promise by anyone to do additional work in the future or license it a particular way. Certain uses of copyleft terms without special terms for licensing contributions from others can limit choice of license terms in practice, but still don't obligate anyone to keep contributing. Companies offering work under these licenses aren't any more obligated to perpetual user servitude than solo hackers putting out projects on their own.
Of course this is accurate, at least as far as the text of the license goes. But I would argue that it's far from the whole story, socially, which is a big part of the math for me when I decide whether and how much sweat-equity I'm willing to contribute to a project. And that's what I was getting at. When I write code for a project, my behavior is more than a simple transaction. I'm choosing to participate as a member of a community, and there are certain social norms that accompany that. I'm astute enough to read and understand the texts of licenses, so I often understand that there wasn't a promise in a legal sense. But there can be a social understanding that goes beyond the text of the license, and that can create expectations just as much as a license text can, even if those are (much!) less likely to be enforced by a court. They still convey how a party intends to behave even if they don't make that intent legally binding. And a party who conveys a misimpression based on these norms will eventually find itself wanting for collaborators if that becomes commonly recognized.
On those lines, when I choose to contribute to a project, I do generally understand that the project will continue to release future versions under terms that are very similar to the versions I gave code to. Project maintainers can, of course, violate that, if the license of the code I'm patching permits them to, but contributors and potential contributors will often notice this and react accordingly.
My point isn't legal. Two sides talking past each other, or making assumptions that don't turn out to be shared, happens all the time. They're communication problems, basic people business problems, long before and more often than they become legal problems.
You can't choose to unilaterally impose "community" on projects you don't steward, or a particular definition of what community means, just by showing up with patches. You can't impose your version of what goes without saying, by calling it "social norms" or "defaults" or anything else.
Nor can projects impose their "crowdsource" fantasies of infinite, competent, totally unpaid contribution on you. They decide what they offer, in the form of the projects they lead and their policies. You can take them or leave them, as you pointed out.
I've seen developers, especially idealistic Free Software people, decline to take up projects because of licensing policies. I've also seen developers consciously and energetically contribute to projects they know a for-profit company is actively dual licensing. I've seen developers assign IP in patches to proprietary software delivered in source form strictly under NDA, just to scratch a nagging itch in a tool their employer pays for.
I agree that many especially younger and more idealistic developers might feel a pang of loss when projects they contribute to announce going-forward license changes they don't like. Better if the party went on their way forever, on someone else's dime, as Linux, its distros, and a relatively tiny cohort of famous and important peer projects do. But outside those rarefied few, companies moving the work they fund to more restrictive terms has happened for a long time. Any disappointment based on informed expectations has to square with all that history.
I'd strongly encourage developers looking to contribute to projects to research the licensing policies and business models behind them before jumping in, especially if they're not going to be paid. I'd strongly support GitHub issues or other public calls to project stewards to clarify where they haven't, just as I'd encourage stewards to ask frank questions about motivation and funding of "outside" contributors appearing with unsolicited patches.
It's never worth hashing out everything that might go wrong, but it's also way too easy to self-deceive about alignment in silence, on either side. On major points, airing it out up front can be a whole lot better than retroactive recriminations about who knew or meant what where nothing was said. Many fewer lawyers would be needed in this world if more followed this free advice.
Absolutely not. But I need to make some assessment of what the community is like and what social norms are in place before investing time and labor in a non-trivial patch. For trivial patch-sets, I can't be bothered. I will totally drive by and send those. But for adding something major, where I need to invest real time learning the codebase and figuring out how to make my contribution fit well, it's not just technical and not just legal. There's a fit issue that extends past both dimensions. I don't believe a copyright license can be expressive enough to convey it.
For right or for wrong, when I contribute to an MIT-licensed project, I am expecting the future version that includes my contribution and is better because of my contribution to be licensed under similar terms. Same when I contribute to a GPL-licensed project. And I recognize that this is not an expectation that's enforced by license or by contract, generally, but the expectation is formed based on my assessment of the project owner's practices.
I am not an especially idealistic Free Software person, but I have personally done all of these things.
I'm neither younger nor more idealistic, and I'm also not clairvoyant. We need to make educated guesses about where to apply efforts, particularly when the return on those efforts comes in the form of something social like free software. Sometimes those expectations get violated, and that's because I didn't inform myself properly up front. But it's not "entitled" to have made my best guess at those, be wrong, and express disappointment at being wrong.
Edit to add:
Of course. But a lot of these changes get made quite a bit above the pay grade of people who respond to GitHub issues, mailing list posts, etc., and opening an issue or posting to a mailing list to inquire about business model and plans for future license changes can be both perceived as off-topic in a technical forum and as an inquiry about business concerns that the employers of the people answering those issues/posts are unwilling to discuss in public.
I avoid making contributions to projects with CLAs for this reason. I want future contributors to have to "pay it backwards" as I have "paid it forward."
Creator here. This is great criticism; I don't think I've landed on the best terminology yet. I've tried to avoid the term "rug-pull" elsewhere on the site for these reasons, but kept it on the home page because the term is frequently used elsewhere. I'll keep working on terminology.
I think you're right about releases having licenses, not projects. But a project is more than just a release, especially from the contributor side. A project is also a point of collaboration and community. When a license change occurs, it can really disrupt the community of contributors. Writing code for an open-source project feels different from contributing to a non-open-source one.
Drew DeVault wrote a great piece about CLAs a couple years back and is now running redict as a fork of Redis.
The most descriptive, neutral name for this I've seen is "licensing policy change". But that's not widely used.
The neutral term I see used most is "relicensing", the one you picked up on. The problem with that term is ambiguity. I see a lot of posts on social media falling into that trap, confusing going-forward license changes as retroactive changes to past releases. I've also seen some people who know better encouraging confusion because they want to punish companies.
I've occasionally heard "license fork", which makes sense to me conceptually. I tend to avoid it only because I see it leaning into the various rhetorical battles along the lines of "We're not the fork. You are!" I think those battles are natural and healthy, so long as they're fought on who has contributed more and will have the better project going forward. I don't think it should be the case that any side—the steward, prior outside contributors, any new group pulled together to keep contributing under the old license—gets presumed to be the best. It should be about the software.
Drew's is a well known voice on CLAs, but I'd encourage you to read others, as well. You might not know, from his blog alone, that there are and have been CLAs that limit what licenses and kinds of licenses stewards can release contributed work under—putting into explicit legal terms the deal some activists wish were implied.
Personally, I'd add that very, very often, the relationship between "outside" contributor and project steward isn't equal, and justly should not be. Commercial project stewards tend to drive development. Many have had the experience of a highly opinionated guy with a patch showing up and demanding a fundamental licensing policy change for a PR, claiming it will unlock a deluge of "community" contributions that simply never materialize for the vast majority of even GPL-licensed, locked-open projects.
Maybe I should try to coin a new term. Rug-pull sounds too entitled and the others are lackluster.
I don't think I've come across one of those, but that would be very good to include. Do you remember off-hand which projects had those? I'm intentionally measuring CLAs that require copyright and/or patent grants, because those make it easier for a company to relicense external contributions. A CLA without those seems less risky. There's some really complicated stuff like Qt that have pretty novel approaches.
If I may suggest one more lens: Do project contributors have the same rights as the project originator?
It's much easier to swallow a license change from someone who is a peer with the same rights as you, but it's more painful if it comes from someone with a position of power over others.
I would argue that permissive licenses without a CLA create an environment where everyone is the most equal. Anyone can fork off with the same rights, even if they decide to use a different license moving forward. On the other hand, copyleft with CLA creates a strong imbalance where the source project owner has special rights to relicense that contributors do not share in.
This matches my analysis. As a general matter, I only contribute to a "copyleft with CLA" project if there's significant benefit to me getting to use the project with my patch included AND strong desire not to maintain a fork plus a distribution mechanism for that fork.
My bar for CLAs is high in general, though, and it'd be unusual for me to consider accepting one without being financially staked in to the project or otherwise associated with the business behind it.
I don't think requiring copyright and patent grant should be the only thing immediately elevating a project as "high relicensing risk", it's mostly just there to keep the lawyers happy. As far as I know, MS has never relicensed anything open to something more restrictive (if they have, it's obscure enough for me to have never heard of). You mostly see companies doing that because they sell one single software package and either want to be profitable or just to sell the whole company, which MS isn't going to do. It feels like a pretty naive way to gauge risk that hasn't taken actual real-world examples and reasoning for relicensing into account. In fact, I'd go as far as to argue a cloud company has the least possible incentive to relicense, especially because it would mean alienating their developer base, which would directly affect their cloud clientele. As an example, I think Amazon directly forked Redis to keep it open source, didn't they?
(Creator here) Part of the challenge of building a project like this is convincing others that the ratings are objective and don't represent personal bias. I've picked a couple measurable factors like "CLA requires copyright grant" which can be verified by linking to the relevant CLA. Drew DeVault's post has a great explanation of the problem. To me (in my subjective opinion) a company demanding developers grant them the ability to relicense your contributed code is a pretty big red flag that they may exercise that right.
I think the factors you mention (history of relicensing, dependence on a single product, alienation of developers) are more subjective and can change over time. A good counter-example may be CICERO. It was changed to a non-open-source license but its a project by a non-profit, it's not the sole product of the organization.
One of the main reasons I created the project was to promote developer discussion about open source licensing, so I'm happy that we're engaging in discussion here.
Indeed. The big risk for things like VS Code are the non-open bits of the open core model. All of the dev container infrastructure (which is one of the big advantages of VS Code) come from the remote extension and are not part of the open source release. There’s a much bigger risk that other important features will be developed as proprietary extensions than there is of MS relicensing the core.
With Linux distros now shipping (proprietary) NVIDIA drivers and (CDDL) OpenZFS, the same risk applies to Linux.