It's not at all about "labels" though (who cares), but about the very pragmatic and practical consequences, such as: * in my comment above, the necessity of be

It's not at all about "labels" though (who cares), but about the very pragmatic and practical consequences, such as: * in my comment above, the necessity of being able to evaluate whether a product is even fit for the job (which requires access to the code) BEFORE shelling out mucho money on it. Your licensing scheme is fundamentally incompatible with that pragmatic requirement, whereas open source is not. That's not a "label" issue. * other such very practical consequences that I didn't even mention in my last comment include the following classic: when you make your product and business dependent on another (external) product, it is crucial to have some sound risk assessment: what about the bus factor of that external provider? What if they close? What if they suddenly change their licensing terms to the worse? What mess do I risk to find my business in and how hard is it to get out of that situation? With a permissive open source license, the maintained collective development can go on, whatever happens to the original developers and however they decide to change their course. With a closed license, the users and/or their businesses are doomed. So the one part where I agree is that merely "getting the job done" for its technical part is not the ONLY thing that matters and not the ONLY relevant selection criterion. There are other very relevant and very pragmatic make-or-break criteria/issues, such as legal and business-critical questions like those that come in consequence of the license… not of their "label", but of their actual content.