I personally prefer Free Software (FSF-approved) or Open Source (OSI-approved) licenses, but I also agree that there is a place for other licenses. It's better that there's space for kinda-open, rather than it being open vs completely closed repositories.
I've previously worked at a company using an "open source" license (Elastic, with the ELv2) and have enjoyed having to explain the difference to folks between what it meant to be "open source" vs "Open Source", and the fact that a lot of folks generally don't understand the difference and some of the nuance. Mentioning the BuSL was because it's something a lot more folks may be aware of, i.e. given Hashicorp's recent relicense (as with other companies in recent years)
Sustainability is hard, and having different ways to describe this is good! But it's a lot harder when people don't understand why something calling itself "open source" when it's "but you can't run it if you're a company" is bad
I must say, I'm honoured this commenter is so angry about this post, they've read through many of my blog posts, and gone through microsites like my Manual of Me[0], to pull this quote to attempt to criticise me
If you've not read up on the background between the two - I'd very much recommend it (and sorry if I'm re-explaining something you understand)
With Free Software, it's "free as in freedom", not "free as in gratis". Free Software is generally a bit more strongly biased towards the users of a piece of software, but as businesses started to use it they were a bit unhappy with that, so Open Source came to reduce that a little bit, making it easier for companies to use it, without as many strong protections for a user
I think using `open source`, and clarifying that it includes non-OSI-approved licenses could work.
Alternatively, "source available" is a term that's been used to imply the source is there, but it's not "open source" (which led to the Fair Source folks working on their own naming for it, so as some folks have negative views of "source available")
As I've written elsewhere in the thread, having worked at a large Enterprise in collaboration with Legal, if there isn't tracking of what AI contributions you have, it's harder to be protected legally by ie Microsoft's indemnity clause if you're sued
IMO (and I am biased because I have written about this before in https://news.ycombinator.com/item?id=47164481) but I believe it's to make sure they're legally covering their users, and making sure users of AI tools do at least have some attribution for AI-derived contributions
Glad to hear you're enjoying Renovate - I'm biased, but I agree that the SHA pinning PR updates are a very nice feature
We recently found (in Renovate) some edge cases with how tags work in GitHub Actions which was fun (https://news.ycombinator.com/item?id=47892740) and there's a few things in there Dependabot doesn't seem to support too
Very much looking forward to getting this on Renovate - we require squash-merge via Merge Queue (with no per-PR override available in GitHub, despite asking) and so when I've got multiple changes, it's a lot of wrangling and rebasing
If this works as smoothly as it sounds, that'll significantly reduce the overhead!
Yep, we had to do this recently with Renovate, where we had too many releases, and new publishing hit a size limit on the registry, so we needed support to help us unpublish a load of old releases