Just so you know, Tailscale tech has always impressed me, but your responsiveness here has cemented my appreciation of your org and I look forward to bringing yall in as our company hits the growth phase.
Random idea: When a recommendation is not being followed for a customer because of some deliberate or idiosyncratic reason, a notes field could:
1. Help them remember why, so that they aren't confused the next time they re-run the checkup. ("Oh yeah, we wanted to do X but we can't until we retire Y because it's not compatible.")
2. If it's clearly labeled as info also shared with Tailscale, product managers could use it to help generate theories about why certain customers don't do X.
For any software or tooling with a complex config, my ideal would be to have a superset of this feature, to provide "intelligent diffs" between full or local configuration states. Whether active or saved. So I could compare not just my current active config and your current recommended config(s), but also between your prior-version recommended config(s) and current recommended config(s). Or between my current config and a prospective new config I'm working up. Or between my last-year active config and current active config.
I've always found tailscale's json config a bit intimidating. I greatly appreciate the new UI that makes it easier to define rules, alas, both going to relevant docs straight from it and determining 'is this rule just lazy/bad/unsafe' is hard and frustrating most of the time.
That's where I'd like to see this sort of checkup.
Yell at me please if i just said anyone can ssh as root from any node!
There’s a lot wrong here, but the fact the author is upset there’s no confirmation for an API call makes me question if they should have any credentials, never mind staging
It's always been relatively shocking to me that this is still relevant 4 years after I wrote it. Helm is as Ubiquitous as ever, despite attempts to replace it with Jsonnet, Cue and programming languages.
I've personally moved on from Jsonnet and would recommend Pulumi to anyone experiencing this problem.
For them to get accepted into the CNCF would require relicensing a large amount of MPL work. What's always been confusing to me about Hashicorp's change and any subsequent relicense of OpenTF is that I know for a fact not everyone who contributed code to Terraform signed the CLA and allowed permission to relicense.
I suspect if OpenTF tries to relicense to a more permissive license like Apache 2 (rather than less in the case of BSL) license we might see some fireworks.
The CNCF has made exceptions on their license policy before, specifically for MPL based software. It'll probably be easier for OpenTF to go through that process than to relicense (which is likely not even possible for anyone other than Hashicorp).
Disclosure: I'm on the CNCF legal committee, which mainly makes recommendations to the CNCF board on things like exceptions to CNCF's fairly strict licensing policy.
This is correct, but I believe MPL has never been approved as a main project license for a CNCF project before, as opposed to a license of a third party dependency (the default rule is that such projects must be under the Apache License 2.0). FWIW I would not hesitate to support such a request for a policy exception.
That's great to hear. We at Oxide are huge fans of the MPLv2 and it's our default license for everything; I think it's reasonable that the default expectation for CNCF is Apache 2.0, but would love for MPLv2 to also be considered a first-class license!
In my personal opinion, there's no good reason to have a license policy at the CNCF, or any Linux Foundation directed fund, that makes using copyleft licenses so burdensome, especially when they are as "weak" as MPL 2.0 is.
I know that there are Reasons. I just don't think they are good ones.
