You can make the opposite point with the same logic though: "the powerful, dangerous tobacco industry was given a loophole in the flavored cigarette ban allowing them to prey disproportionately on vulnerable Black populations."
You had to explain what “non-refundable” should be interpreted as. I think we can agree different people will have different interpretations.
I’d also expect any terms in the actual ToS defining “non-refundble” to get void in front of a judge in this specific cases if this was really pushed that far.
But from the OP it sounds like the cofounder might be continuing in the same line of business, but wants to "pivot" and jettison the now-dead weight of the technologist.
If this is the case it seems plausible that his contributions and R&D are still relevant, even if they're throwing out his code, and so perhaps he's entitled to whatever stake he vested over those first two years.
This makes sense to me. If it's entirely unrelated then yeah totally. But if they're doing a shopify store to sell these workshops then I think OP should get some points
I agree completely. My favorite podcasts are crowd-funded with no ads, but the least-bad approach to ad reads is when someone reads a script, verbatim, in a bored monotone. Especially when it's not one of the hosts reading, but a producer whose voice you don't recognize and implicitly trust. But this is really rare.
The big missing piece is roles. No service uses a root access key directly. Instead, there's a webserver role with access to a relevant secrets group but no access to data warehouse secrets, for example.
Access keys can be provisioned and downloaded straight onto the box from the service. Sure, a compromise is bad, but only exposes the secrets that would be available on the pwned box regardless.
OK, so "root" wasn't really the right term. I get an X credential so I can be an X, and nobody needs to worry that I also got enough to be any part of a Y. Thanks.
This sort of model also fits nicely with the AWS ecosystem. EC2 instances (virtual machines) can be given an IAM Role when they boot-up. An IAM Role is essentially an automatically generated access key which is unique to that EC2 instance, and has pre-determined permissions.
So in other words – a unique key is generated every time a virtual machine is created. It's fully automated, never shared between instances, and never needs to be handled manually. That key will give the virtual machine permission to access other AWS services, in this case the AWS Secrets Manager.
So as long as you're using EC2 instances, you won't need to worry about securely passing a 'master password' to your VMs in order for them to access secrets.