I think that is a fair concern, but personally I'd much rather give my users unrestricted abilities to use my code, because I believe that any proprietary-tech built on my code will not be able to compete in the end game with any also OSS-tech built on my code. I also see the same that any OSS-version would outcompete (a)GPL-version, though I'm sure you disagree?
> I believe that any proprietary-tech built on my code will not be able to compete in the end game with any also OSS-tech built on my code
I'm worried that you face a forever-uphill climb. Whenever a proprietary group pulls ahead by developing some killer feature or improvement, your OSS group has to duplicate all of their work. Whereas if your OSS group pulls ahead, they can just fork you and put all their energy into pulling ahead again.
I think this analysis is a good argument for why you might want to put restrictions on those who would take advantage of your community's work. (Of course, it's important that the restrictions actually work and aren't burdensome to those who don't want to take advantage of you. Whether the GPL or any other license succeeds at that is debatable.)
This also assumes that the software must constantly evolve and `pull ahead'. In reality, a lot of the software in use usually evolves to a point of being useful and does not need anything but routine incremental adjustments (I did not say improvements because one man's improvement is another man's useless feature), like compilers being retargeted, or typesetting software using new image formats, or a new language.
Software becoming free (as in everything, beer and speech) is a natural progression because our patterns of using software are not that flexible so when a new use case appears, in a few years the free software catches up and it is no longer possible to abuse the customers as before (like Autodesk is doing now), just as it should be. Not that this model is bullet proof, unfortunately.
When you own the entire vertical, all the way to end user, it makes sense.
In practice, the final steps that are necessary to deliver something useful to the user are often considered the most boring and tedious (UI, documentation etc), so many F/OSS projects either don't bother at all, or provide something half-baked. But if the underlying libraries allow for a proprietary derivative, then that might motivate some businesses to come and do all that tedious stuff for $$$. Such businesses might not contribute back much, but they are also unlikely to fork - less code to maintain that way.
When that happens, I don't think it's a loss for anybody, really. The open code stays open and can be improved further, and it also gets used by more people in better ways. Some would argue that library developers aren't properly compensated, but the act of voluntarily releasing something under a non-copyleft license is explicit consent to that.
In the hypothetical "suffering an annoying bug" scenario, I would, of course, prefer to have the source so that I can fix it. But if the real choice is between having a product with an annoying unfixable bug (but plenty of other added value), and not having one at all, because nobody wants to build my extremely useful GPL'd library into a polished product, the obvious pragmatic choice is the bug.
Yes, and that is achieved by keeping the part that makes it all sellable to consumers proprietary. But there's not much point in doing that with the backing open source libraries, especially if they're popular and in active development - maintaining a constantly diverging in-house fork is very time-consuming and expensive, so it must have some really big value-add to justify them.
How many closed-source projects use, say, SQLite? How many of them fork it?
I think that is a fair concern, but personally I'd much rather give my users unrestricted abilities to use my code, because I believe that any proprietary-tech built on my code will not be able to compete in the end game with any also OSS-tech built on my code. I also see the same that any OSS-version would outcompete (a)GPL-version, though I'm sure you disagree?