>legally speaking.. if you're not sure of the risk- you don't document it.
Ah, so you kinda maybe sorta absolve yourself of culpability (but not really — "I didn't know this was copyrighted material" didn't grant you copyright), and simultaneously make fixing the potentially compromised codebase (someone else's job, hopefully) 100x harder because the history of which bits might've been copied was never kept.
Solid advice! As ethical as it is practical.
By the same measure, junkyards should avoid keeping receipts on the off chance that the catalytic converters some randos bring in after midnight are stolen property.
Better not document it.
One little trick the legal folks don't want you to know!
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
interesting post thanks for sharing! It does indeed complicate things if you want access control. For me personally I don't have a strong argument to provide sharing, a post can either be read by anyone or only by me, the middle ground doesn't really earn the level of complexity it adds for me personally.
I'm really not sure how I would solve it if I had to, git-crypt only makes sense because I only need access to the private posts locally and I would lose the added bonus of the encryption/decryption going on in the background and in a git-native way.
The thing I was trying to illustrate with the post was how amazingly some things just come together once you strip away all the extra functionality and what hidden bonuses can appear. Thinking about a possible solution that is still minimal though I would lose git-crypt and probably handle encryption/decryption manually, add a key for each of the people I wanted to give private access and have my email notifications automatically append their keys whenever i notify of new posts, but again the beauty/coherence gets lost.
(I agree with Filippo's post and it can also be applied to Renovate's security updates for Go modules - we don't have a way, right now, of ingesting better data sources like `govulncheck` when raising security PRs)
I think the confusion is also because it's a comparison of Community Self-Hosted (CE) vs the pure Open Source CLI - the latter is what works without license key
I'll see if I can help with clarifying this in the table!
Website: https://www.jvt.me (used for blog, but I also use as an IndieWeb site, so I i.e. reply to social media posts from my website, and they're syndicated out to the different platforms)
I've spent a bit of time thinking about this[0] - as a maintainer (oapi-codegen, Renovate, previously Jenkins Job DSL Plugin and Wiremock), as someone who used to work on "how can we better fund our company's dependencies", and building projects and products to better understand dependency usage
As others have noted, there are a few areas to watch out for, and:
- some ecosystems have more dependencies over fewer, and so we need to consider how to apply a careful weighting in line with that
- how do we handle forks? Does a % of the money go to the original maintainers who did 80% of the work?
- how can companies be clever to not need to pay this?
- some maintainers don't want financial support, and that's OK
- some project creators / maintainers don't get into the work for the money (... because there is often very little)
- there's a risk of funding requirements leading to "I'm not merging your PR without you paying me" which is /not problematic/ but may not be how some people (in particular companies) would like to operate
[0]: https://www.jvt.me/posts/2026/02/25/llm-attribute/
reply