I'm an MIT license software author. I frequently get people asking 'I mean to do X thing with your codebase, which is allowed under the license: is this okay wi

I'm an MIT license software author. I frequently get people asking 'I mean to do X thing with your codebase, which is allowed under the license: is this okay with you?' and my answer's typically, 'Of course, that's why I chose that license in the first place'. I'm also a white guy. Let's imagine what would happen if another white guy decided, "I want to make a DAW project that is only white guys' code, based on Chris's work as he seems white enough to me, and I will promote it through pointing to Chris and extolling his racial purity!" That's substantially more unpleasant (at least to my mind) than having an increased support burden, but it wouldn't change my use of the MIT license. Instead, what it would mean is this: if anybody asked, I'd tell 'em that the project was in compliance with the license but the people were absolute bozos and I didn't like them or the way they were behaving. Open source, especially as it leans more permissive, DOES NOT imply a support burden or endorsement deal. This is of course the BSD non-endorsement clause which is not present in the MIT license… It's a bit like this: my surname is Johnson. That's a pretty common name. I can imagine a person who learns this, and then goes, "Oh! I know a guy named Johnson. He is your brother! In fact I know five guys with the name Johnson. What a great family you have! I'll help you by gathering them all together for a reunion in your back yard." That would be dumb, but it would also be not my problem: I have a reasonable expectation that, in the context of normal society, I could say 'that's a very silly thing and not my doing' and people would acknowledge that it's the silly person's problem, NOT mine. By the same token, I feel confident that society would not tie me to a 'Only White Men DAW' using my MIT-licensed code, and lastly that the original package author is free to NOT take personal responsibility for handholding all possible users of their software, even if it's packaged in a large distribution that propagates their work farther than they expected. One possible workaround is what I effectively do with my codebase: if it's unwieldy or difficult in some way, and you're Free software, lean into that! Let it be known that you're too busy doing your part of the work to provide truly great support services, and suggest that third parties might step in and do their best to take up the slack. Odds are, they won't: but the suggestion is truly in the spirit of Free software, in that you are providing everything that YOU reasonably can, to anybody who would like to extend your work into a more fully developed software ecosystem. If there's a profound need for the type of support services you as the author don't feel able to extend to a giant audience, somebody WILL provide that support because it'll be much sought after and bring appreciation and popularity to the supporter. If that sort of popularization is truly important, the support-burden provider might end up seeing more in the way of donations/recompense than you as the original developer, because they'll be the ones directly dealing with the large audience and being 'the face' of the software. Think about what your expectations as a Free software developer are, and communicate those. That's all that's needed. Don't project onto the license, taking on things that aren't being asked of you, and the end result will evolve in a way that is strangely personalized to your needs. Right now I'm watching the evolution of three audio software projects: me with the Airwindows DSP codebase, Surge Synthesizer, and VCV Rack. Each one has developed a 'style' of interaction with society at large around use of the code, but in each case the 'style' is quite different. The expectations and 'style' WILL be communicated, regardless, and this is why I think it's a mistake to do things like request non-inclusion in a distro: that developer underestimates the ecosystem's ability to 'read' their wishes for how they interact with that system. I don't believe they'd get buried under support requests, unless they functionally behaved as if they were actually responsible for doing that. The ecosystem will 'read' what you do, not just what you say you'd like to do. Working in Free software requires that you're honest about what you are and are not offering. I could make my life incredibly harder, by putting forth the appearance that I am about coordinating and overseeing a whole world of pull requests and coordinated derivative projects… diving into stuff that's way beyond my ability to keep track of… but since I don't put across that appearance, my burden to maintain that is effectively zero. Because I'm rigorous about avoiding stuff that I'm ill-suited for, I'm not muddying the waters through pretending to be competent at it…