I haven't tried this yet, but poking around the site, I'm wondering what mitigations you have for potential abuse? I'm concerned specifically about transparency

I haven't tried this yet, but poking around the site, I'm wondering what mitigations you have for potential abuse? I'm concerned specifically about transparency to the end user about the costs of the packages that they've installed. Thinking aloud: * My user chooses to install my package with scarf, either because I force them to (by not making it easily available elsewhere) or because they want to support me (yay!) * I make money from their install, and/or their use of the package (is this correct?) In that case, as Mallory, as a bad actor, I: * Want to make a package that looks affordable but pulls in dependencies * I want to make those dependencies cheap at first, but then I'm going to make them expensive later, when you are, well, dependent (ahem) * I want those deps to be, as much as possible, me and my friends I'm not even going to get into the abuse potential I can imagine would obtain by preying on naive good actors; e.g. convincing some well-intentioned dev to use my dep and then effectively taking rents from all of their downstream users. I haven't had a chance to play with Scarf yet but I'd love to hear about how you handle scenarios like this on its website. Because I'm pretty sure these scenarios are why something like scarf hasn't shown up before. (Personal belief/stance informing this worry: FOSS got big by providing easily-reasoned-about costing structure in an industry that had hitherto been beholden to things like on-site auditors, per-seat licensing, hidden costs, submarine patents, etc; our value prop was "you always know your cost is gonna be $0, plus installer and maintainer salaries", which is much better than "We decided this now costs double". We didn't so much cost less as cost predictably.)