Andreas Ericsson <a...@op5.se> writes: > On 2014-01-31 14:04, David Kastrup wrote: >> >> I'm still in the process of finishing the rewrite of the builtin/blame.c >> internals. Now there are various questions regarding the final patch >> proposals and commit messages. >> >> Point 1) signing off implies that I'm fine with the licensing of the >> file. builtin/blame.c merely states >> >> /* >> * Blame >> * >> * Copyright (c) 2006, Junio C Hamano >> */ >> >> which obviously will not match the authorship of my contributions. >> Since Junio has given blanket permission to reuse his Git contributions >> under other licenses (see >> <URL:https://github.com/libgit2/libgit2/blob/development/git.git-authors#L58>) >> that I am not going to license my work under, the first commit in the >> respective series would replace this header with > > It's a long time since I wrote that document. > > Does this mean you're not willing to relicense your contributions with > the license used by libgit2? That's what the document is supposed to > mean and it's what I asked on the mailing list when requesting > permission.
I make a living from writing Free Software. It should hardly come as a surprise that I will not hand libgit2 users like Microsoft or GitHub software for unrestricted use in proprietary products without getting recompensated. They make money from their products without sharing their code back. So I'm not going to relicense my work under the libgit2 license _without_ _recompensation_, for use by companies that don't license their work without recompensation. It would be grossly unfair towards those people who actually pay me for writing GPLed software (mostly GNU LilyPond). Of course I regularly report what I worked on, and I expect a temporary drop in my funding corresponding to the lack of LilyPond-related activities. So there is an actual cost for me to bear, and I will not bear it myself in order to support proprietary derivatives. So the price tag for letting the finished git-blame work (I've found a few more optimizations making it more worthwhile) get relicensed under the libgit2 licensing scheme would be in the order of €10000. It would take a rather good salaried programmer to reproduce what I'm doing right now for the same price tag, and since my work will be available in Git proper under the GPLv2 before anybody has to make any decision, there is no uncertainty about exactly what people will be getting. If there is going to be significant use of the git-blame functionality by libgit2, I claim that the gain in efficiency (and programming time) would more than offset the cost. And if there isn't going to be significant use of that functionality, it's not important whether it's in libgit2 or not. > The libgit2 license used as of today is still the license that people > agreed to relicense their contributions under. It can be found here: > https://github.com/libgit2/libgit2/blob/development/.HEADER That's actually the license on some files. The overall license statement in <URL:https://github.com/libgit2/libgit2/blob/development/COPYING> suggests that the libgit2 code base encompasses quite more components. Some of those are mentioned as being licensed under the Apache 2.0 license, incompatible to GPLv2 according to <URL:https://www.apache.org/licenses/GPL-compatibility.html>. Since the GPL requires licensing of a work _as_ _a_ _whole_, it's not really all too obvious to me whether any part but the linking/unmodified-binary exception will actually be effective. But that's pure speculation on my part (I am obviously not a lawyer) and no skin off my nose if somebody wants to invest the price for releasing under whatever licensing scheme libgit2 happens to use. If libgit2 or a variant of it reverts to unmodified GPLv2 (or later) at any point of time, they are free to just take what is there without having to negotiate with me (or anybody else), anyway. And of course, calling the git executable and letting it do the work will also remain an option. That's likely what the simple git web services do anyway. "git blame" is usually disabled in web interfaces for performance reasons, and I'm afraid that even a factor of 3--4 in speed (which is what I'm getting with uglier real-world cases) is not going to change that. > I'm mostly adding it here for the sake of clarity in case people find > this in the future and wonder what all the fuzz was about. It's probably easy to notice that I can make a lot of fuzz about small things. It's probably less annoying when I do it in code rather than in prose... -- David Kastrup -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
