8

Is there any version control software with the functionality of Git, but which is not under a viral license? - A "viral license" being, by my definition, one which requires derived software to be under the same or an equally-restrictive license.

I'm not interested in an argument on or discussion about the GPL; it's outside the scope of this question and website.

Thanks.

Narf the Mouse
  • 1,491
  • 5
  • 17
  • 26
  • have you considered using SVN? Is your issue with version control software, or integrating a version control software with your program, or are you talking about a host for the data? – Dr.J Apr 22 '11 at 21:36
  • 8
    Why is a "viral" license a problem? Using Git for your software *does not* require you to put your software under the GPL. –  Apr 22 '11 at 21:39
  • Even the Apache Software Foundation itself encourages the *use* of git. – bmargulies Apr 22 '11 at 21:55
  • 2
    @Delnan: It's a philosophical objection. I know it's not applicable to me, but I don't want to encourage the GPL to spread in any way, in somewhat of the same way I wouldn't walk around carrying an infectious virus I'm immune to. – Narf the Mouse Apr 22 '11 at 23:37
  • 2
    I'm not enough of a religious warrior either to encourage the "let's give our buddies a headstart by disallowing everyone else to use out stuff" stance that those licenses basically are. However, there are lots of great applications under the GPL (do you use `gcc`? I bet you did, *at least* indirectly if you ever used a unix-ish enviroment) that I want to use despite and philosophical disagreements, partly because quite often, there's about no useful code that can be derived from them as they're standalone applications (and in many cases, e.g. Codelite plugins, there's an exception for them). –  Apr 23 '11 at 00:05
  • I am using Git; I'd just rather not if I can find a good replacement. – Narf the Mouse Apr 23 '11 at 02:54
  • 2
    Anti-Git-Jihad because of the GPL? You should mention the projects you are involved in somewhere so I can stay away from them as far as possible. – ThiefMaster Sep 23 '12 at 12:07
  • 2
    If you didn't want discussion probably should have just asked for version control that isn't under GPL, instead of the additional adjectives. – eric Mar 31 '14 at 18:36
  • 1
    Thank you for this question, I was afraid to ask. – Todd Partridge Sep 23 '17 at 14:38
  • @NarftheMouse: thanks for this question. I'm also in the same boat looking for a non-GPL `git` replacement, although in my case it's not a purely philosophical issue, but also a practical one: If at some time in the future I need to have the freedom of packaging the SCM I use under permissive license terms, the choice of a GPLed one will be an obstacle. I choose all the tools I use trying to maximize my freedom at any future scenario. However, as of today, I still don't know of any `git` "clone" which is non-GPLed. – cesss Jul 24 '18 at 09:31
  • I use: https://gitlab.com/es20490446e/gitu – Alberto Salvia Novella Jun 17 '20 at 20:53

3 Answers3

11

Fossil is (and Codeville was) a BSD-licensed distributed revision control system.

Note that unless you're actually modifying the version control software itself, the license doesn't affect you; you're free to develop non-GPL'ed software using a GPL'ed tool to manage revisions.

0xC0000022L
  • 18,189
  • 7
  • 69
  • 131
Wooble
  • 80,189
  • 12
  • 97
  • 124
3

The other options are :

  1. Perforce
  2. Bazaar
  3. SVN
  4. CVS
Guvante
  • 17,681
  • 1
  • 28
  • 64
Dinesh Arora
  • 1,652
  • 2
  • 20
  • 27
0

UPDATE:

Since 2 years passed since started professionally working with git (after 20 years of not-git...) I can say this:

  1. GIT has it's advantages when it comes to merging code bases between branches and multiple users. Once you master it, and learn to ignore its - sometimes utterly confusing command line UI - can be easy to work with.

  2. On the downside, GIT IS complex to understand and LEARN. There is a long steep learning phase, especially if you work from the command line in multiply branched repository (the common and the recommended approach). Working with UI tools like InteliJ IDE's can hide some of the details, but these require their learning attention and time too + some not so basic GIT knowledge. And this knowledge is required by ALL members of your team.

OLD AND (not so) BELOVED ANSWER:

Forget the license... You want to NOT use GIT for so many other reasons...

If you want things to work faster for your team - stay away from GIT. Why not use SVN? It is supported by any service that supports GIT, and is the most popular alternative to GIT (as far as I know).

To commit/merge/manage a team in GIT it'll take you exponentially more time than other SVN/Fossil/... All in the name of advance "distributed" design, and a rich set of methods to kill your code, merge it wrongly, give you so many options to do horrible mistakes (that happen to pro's and newbies alike), and do simple things the HARD HARD way. Were in reality it only serves the ritual hungry souls of geeky programmers, who would otherwise have to go home late and face the empty walls of their houses... (poetic answer too).

REALLY - It would actually be funny if it wasn't the number one pain-in-the-arse time killer in the office. And once you go GIT you can never go back, so my advice, don't let the geeks have it. Keep it out or pay the price.

And, yeah, I know the crowd here, and I am more than willing to loose a few points. It's not like it means anything real.

rubmz
  • 1,618
  • 2
  • 19
  • 38
  • 2
    Downvoting due to complete inaccuracy. I switched from SVN to Git about 10 years ago and have been much happier and more productive as a result. – Marnen Laibow-Koser Sep 13 '18 at 19:31
  • 2
    So, you did something 10 years ago and say I am completely inaccurate. Genius. I stand behind every word. Working with git is a nightmare. Hard to learn. Hard to work with. Sorry for not playing "follow the leader" on this one... I worked with a number of version control systems, and GIT is... not easy to work with. Without justification. Anyway, have fun down voting this answer, if it gets you happy :) – rubmz Sep 16 '18 at 14:11
  • It’s not that I “did something 10 years ago”, but rather that I have considerable experience (Git for the last 10 years, other VCSs before that) that contradicts your claims. Git is different from SVN and CVS, sure, and it takes a bit of learning. But I enjoy using it and would never willingly go back to what I had before—and it makes teams so much more productive than SVN. – Marnen Laibow-Koser Sep 18 '18 at 15:59
  • 4
    You didn't use any other CVS for the last 10 years, hence my comment. But regardless of this futile discussion. GIT requires too many steps to be "productive". It takes too long to learn. Many of my expert team-mates have little clue on how to manage different situations driven to by GIT's 7 layer scheme... All this while other VCS's provide similar features without the hassle. Very simple. It's a pain in the arse... that's all. But it's so complex to deal with, that everybody want to say that they master the beast, hence, they are genius... NOT. – rubmz Sep 19 '18 at 06:04
  • I actually have used SVN a few times since I switched to Git, which has convinced me that I never want to use SVN again if I have a choice—SVN actually makes things that are easy in Git much *harder*. And no, Git doesn’t have to take long to learn. I’ve trained co-workers in it quite quickly. • “everybody want to say that they master the beast, hence, they are genius” No, quite the reverse. I’m saying that it’s *not* hard to master Git, and you don’t have to be a genius to do it. I’m not claiming any special ability here; you’re the one saying that. – Marnen Laibow-Koser Sep 19 '18 at 14:04
  • 1
    Lets agree we disagree. Each and his own experience... – rubmz Sep 20 '18 at 08:58
  • When you make claims in an insulting tone that are pretty clearly false, and don’t provide any evidence for them, I’m not sure that you then have any standing to “agree to disagree”. – Marnen Laibow-Koser Sep 20 '18 at 20:02
  • Well don't get insulted, but I really don't mind if you think I have a stand or a sit, or well anything else... – rubmz Sep 20 '18 at 21:19
  • 5
    Agreed. Git is a pain. Nobody wants to change history: why is that option even there? Why dozens of commands with as many options? Why distributed repositories? Why staging? Nobody needs that. – Perdi Estaquel Dec 11 '18 at 02:57
  • @PerdiEstaquel I hope you’re being sarcastic. :) Staging and embracing the distributed nature of Git are fundamental parts of my workflow, at least. I miss both when I have to use something like SVN. I agree that changing history is evil, though. – Marnen Laibow-Koser Mar 13 '19 at 14:46
  • 1
    @MarnenLaibow-Koser Now that I'm a git expert in a number of different workflows, I can say that GIT MAY have some extra functionality over other VCS's. However, the need to learn a whole new, highly opinionated language just to save/merge the team's code is not the way I would go. Yet, everybody do so, and I have to go with the flow on that one. My experience with SVN was that it was way more fluent and easy to work with. And best: I didn't have to keep an open CMD/BASH window just so I can use the command line... GIT has brought me back to DOS times, which I wanted to forget... – rubmz Mar 14 '19 at 11:20
  • @rubmz SVN is perhaps a bit simpler than Git, at least if you started with it (although I’ve heard people who started on Git say they can’t understand SVN!), but it’s missing many features that make life easier. You *can* use Git without the command line through a client such as SourceTree; however some features work better from the command line (and that’s true of SVN too!). I find that I usually have a command line window open for other reasons anyway, so that’s no big deal for me. – Marnen Laibow-Koser Mar 14 '19 at 12:51
  • 1
    It's not just the window. It's understanding the 3 stages of committing code that can get you really frustrated as a newbie, especially if you come from SVN/Fossil, where committing is one stage... Still didn't find why it is needed. Probably meant for IDE's and Code management tools like JetBrain's and SourceTree. SVN works as a simple windows explorer extensions, without the need to use the command line EVER, which is way cooler in my opinion. Yet, some people find VI convenient. Go figure people :) – rubmz Mar 14 '19 at 13:19
  • @rubmz The fact that you speak of the “3 stages of committing code” makes me think that someone taught you Git in a way that encouraged you to develop a poor mental model of how it works. I assume you’re referring to staging, committing, and pushing, which are different operations with different purposes. Each one is individually useful, but if you just think of it as “3 stages of committing”, then it’s probably harder to see that than if you’d been taught to understand each operation on its own. (I can explain the latter if you want, but it seems like excessive detail here.) – Marnen Laibow-Koser Mar 14 '19 at 14:28
  • @rubmz And no, SVN doesn’t work as a Windows Explorer extension. You’re thinking of TortoiseSVN, which is a particular client just as SourceTree is (and BTW, TortoiseGit also exists). – Marnen Laibow-Koser Mar 14 '19 at 14:30
  • Somebody has flagged this comment [for review](https://stackoverflow.com/review/low-quality-posts/22470555) incorrectly - it [**is an answer**](https://meta.stackoverflow.com/q/287563/1364007). It is saying "use SVN" - which answers the question. – Wai Ha Lee Mar 15 '19 at 05:59
  • This discussion has become long (no I don't flag as inapropriate anyone's commment... not that bored :) and yes, the "staging" stage is redundent in my opinion. Would live without it... – rubmz Mar 16 '19 at 15:19
  • @rubmz You’re not the first person I’ve heard say that they don’t understand staging, and in fact there are some UIs for Git (such as Gitless) that make the staging area vanish. For myself, though, I really *love* the staging area. I like being able to build up a changeset incrementally, and only commit it when I’m ready to do so. – Marnen Laibow-Koser Mar 18 '19 at 21:18
  • Downvoted as the answer is just a rant without arguments/examples/explanations why git is bad, touching the question from OP just slightly – leberknecht Jun 13 '19 at 13:57
  • @rubmz one criticism of your answer: you _can_ go back once you went with Git. In fact the format defined by [`git-fast-import`](https://www.git-scm.com/docs/git-fast-import) is _the_ way to go that route. Personally I consider it the only aspect of "core Git" (going by `gitglossary`) - other than some abstract ideas - which would be worth having around even if Git ever went the way of the dodo. [Reposurgeon](https://gitlab.com/esr/reposurgeon), originally written in Python now Go, is the tool to do it, unless you want to put up with the rough edges of auto-converted repos. – 0xC0000022L Feb 19 '20 at 12:01