git is a good example. It's GPLv2, but that hasn't prevented it from being used to form a near-monopoly (github) for F/OSS, now bought by MS. Linux: used in the world's largest spynet (Android). Your joy and enthusiasm being taken advantage of for nefarious purposes.

>git is a good example. It's GPLv2

Is it a good example? I'm not very firm with licensing. As far as I understand it git is not a library or a programming language, which means that even if you use it commercially you're not really modifying or repackaging it in your software, so there's really no duties arising out of it even if you use it on your servers. Your software is just communicating with git.

Please correct me if I'm wrong.

You probably have the term linking in mind to draw the conclusion that if you're merely exec'ing an external binary, this exempts you from GPL restrictions. But that term is used in the L(!)GPL to state an ok method of bundling your code along with the licensed lib. AFAIK, that GPL code is ok to bundle with proprietary software whenever GPL-ed code is invoked in a separate process, though heard frequently, has yet to stand in court, especially when said proprietary software is just a wrapper or web interface.

Edit: IANAL

It's a separate program though, so you're not repackaging, modifying or redistributing.

Let's take for example TortoiseGit, should they decide to sell TortoiseGit now, they wouldn't have a problem with the GPL because they're not redistributing git. They just say, download git and our program will connect to it. Git does not become part of TortoiseGit at any point. You could replace the git client with one that has the same interface and it would still work.

Whether TortoiseGit is a derivative work of Git is ultimately a legal question. Certainly just being a separate binary doesn't automatically make it not one. "You could replace the git client with one that has the same interface and it would still work." - that's true of any library used in any program.

It seems like the point has been lost.

Unless you're building (as your company's product) a Git client based on Git, then the license of Git is irrelevant. It does not enter into the question of how you must license your product when you publish it.

Most people who have chosen to include Git in their development stack don't suffer any consequence from the fact that it is licensed as GPLv2. TortoiseGit is another matter altogether – ~in fact it must be licensed as GPLv2, because it links to libgit2. If it was changed to wrap the Git binary instead, then what you say is probably true.~ (this is false, [1] libgit2 is licensed as GPLv2 with the Linking Exception. So clients that link to it need not be licensed as GPLv2.)

But most of us Git users are not actually building Git clients.

[1]: https://github.com/libgit2/libgit2/issues/3046

Describing git as a DSL stretches the term quite a bit.

('DSL' can be a valuable lens to view a program though. Just like viewing things as eg file systems or databases can sometimes give you deeper insight.)

How can you say “We’re all in this together” when youre donating your time and they use the fruits of that labor to profit off you

OP increases the sum in the non-zero-sum sense. Sure, gots back directly nothing, but the chance that gets more eventually increases.

Key differentiation here is that the person is not donating time so that a company necessarily profits off that labor. OP is getting what they (OP) are expecting out of it (joy by being a part of larger collection of people that have given them so much free stuff)