I know the author of this tool really wants to be able to make a living off this tool, and I fully support their pursuit of this, but I can't help but wonder if

I know the author of this tool really wants to be able to make a living off this tool, and I fully support their pursuit of this, but I can't help but wonder if doubling down on the strategy of making it harder to use to try out rather than easier is the wrong approach. The project I work on could potentially get a lot of benefit from switching over to mold, and I work at a company that potentially would be able to finance this project at the level they want due to the scale and potential amount of usage internally, but any attempts I've made to try to initiate discussion essentially isn't able to make progress due to the fact that I can't even attempt to make an estimate of how much it would cost (either in aggregate or per user/machine/team/etc.), and due to the fact that all of our builds happen in thoroughly scrutinized non-local environments and I can't just copy the code to a personal machine with mold installed to try out, I also can't offer any concrete numbers about how much time it would save to use it for our builds. It's unfortunate, because I think everyone basically agrees that this would 100% be worth pursuing if we knew for sure that it would be a significant improvement, as build times are a known pain point for our team, but no one with enough authority to actually try to contact and start discussing terms with the developer has enough time to justify spending bandwidth on this when I realistically don't have any concrete evidence that this would provide any benefit at all (and I don't really blame them for this, since I'm essentially just offering a hunch that this would be useful if we could use it). I understand that using the linker purely for trying it out internally and not actually distributing anything linked by it would not trigger the AGPL in the same way that using it in production would, but our general policy is to err on the side of safety when it comes to things like this; for example, despite longing for some of the unstable features of the nightly version of rustfmt like being able to auto-merge imports, we currently don't use it due to not wanting anything related to the nightly toolchain in the CI we use for release builds in order to be extra sure that we don't accidentally ship anything unstable (think of it sort of like a layer of "defense in depth" for the build processes due to our product being in a highly sensitive security domain). The bad reputation that larger companies have with regards to free software licenses (which in many cases is probably deserved) means that the managers and teams who genuinely want to respect licenses and be community members and therefore would be the ones who normally _would_ be ideal customers for products like this instead tend to be incredibly risk averse about GPL-related software precisely because we want to avoid being part of the problem. I'm not really sure what the long-term solution here is, but I feel like the only path out of this local minimum is for both potential developers and customers of free software to signal eagerness to engage with potential partners on the other side in good faith. Instead, my reading of most of the communications about mold's commercial potential seem to be proactively defensive with a tinge of resentment. I fully empathize with these feelings and probably would feel the similarly if not even stronger in the same situation, but ultimately that's why I have no personal interest in pursuing entrepreneurship myself; being in the right isn't always going to be sufficient for succeeding in business, and sometimes the best strategy will be to be to give the benefit of the doubt even if it hasn't yet been earned.