4 ms·

git is a both domain specific programming language and library of software routines that enable version control. Curious why you don't see it this way.

carlmr 8y ago
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.
- lmm 8y ago
  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.
  - yebyen 8y ago
    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 https://github.com/libgit2/libgit2/issues/3046
eru 8y ago
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.)

carlmr 8y ago

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.

lmm 8y ago
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.
- yebyen 8y ago
  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 https://github.com/libgit2/libgit2/issues/3046

eru 8y ago

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.)