Re: A few contributor's questions
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. 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 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. -- Andreas Ericsson andreas.erics...@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- 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
Re: A few contributor's questions
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 €1. 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
Re: A few contributor's questions
Hi, David Kastrup wrote: builtin/blame.c merely states /* * Blame * * Copyright (c) 2006, Junio C Hamano */ I think you planned to make substantial changes, so /* * Blame * * Copyright (c) 2006--2014, Junio C Hamano and others * Licensed under GPLv2. See Git's COPYING file for details. */ towards the end of the series (or squashed into some patch that makes significant changes) looks fine to me. Also keep in mind that you don't need a copyright notice to own copyright, that it would be crazy for someone to claim you've assigned copyright on your changes without an explicit reassignment, and that libgit2's git.git-authors file that keeps coming up includes a comment with a heuristic for delving into the history to find the authors of some code. [...] Permissable-Licenses: GPL Version 2 or later Wouldn't a signed message on your website or some other public place (e.g., the mailing list) do the trick? Or a sentence in a commit message saying I'd be happy to have these changes relicensed under the GPL version 2 or later. sounds fine to me, at least. Thanks and hope that helps, Jonathan -- 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
Re: A few contributor's questions
Jonathan Nieder jrnie...@gmail.com writes: Also keep in mind that you don't need a copyright notice to own copyright, that it would be crazy for someone to claim you've assigned copyright on your changes without an explicit reassignment, Not at all crazy: Documentation/SubmittingPatches states that adding a Signed-off-by: footer to a commit among other things constitutes agreement to Developer's Certificate of Origin 1.1 By making a contribution to this project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or The only relevant notice to licensing indicated in the file currently is Copyright (c) 2006 by Junio Hamano. Also whether or not this implies an assignment of copyright, it is a reasonable assumption for people working with a copy of Git distributed by tar file or otherwise that a file with such a copyright notice only contains material copyrighted by Junio Hamano. So if I want to assert my copyright in the case of licensing breaches, the party in breach may claim estoppel by me hiding material copyrighted by myself in a file with such a notice. and that libgit2's git.git-authors file that keeps coming up includes a comment with a heuristic for delving into the history to find the authors of some code. Sure. But that does not mean that this is the only means to reasonably infer the authorship of a file. [...] Permissable-Licenses: GPL Version 2 or later Wouldn't a signed message on your website or some other public place (e.g., the mailing list) do the trick? Legally? Sure. The whole point of such a notice in the commit message (or in some central file in the Git repository) is to save people the hassle of second-guessing or sleuthing for every single contribution. Or a sentence in a commit message saying I'd be happy to have these changes relicensed under the GPL version 2 or later. sounds fine to me, at least. It's verbose and cumbersome enough that I would not have been surprised if there'd be an established way of getting this information on record, preferably per-project rather than per-commit. If it's going to be per-commit, a footer line would be less obtrusive than a whole sentence. But it would seem that there's no rule/standard here. Thanks -- 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
Re: A few contributor's questions
Hi, David Kastrup wrote: Also whether or not this implies an assignment of copyright, it is a reasonable assumption for [...] Since I think we've completely gone off the rails: I assume the problem you're trying to solve is that files don't have clear enough notices of their licensing. That could be a real problem for people using the code, since if you no one gave you a license then you don't have a license at all. It's also a problem in that it makes it harder to interpret the phrase under the same open source license (though I have no idea how that could be read as I give up my copyright completely). The way git currently works in that area is the same as the Linux kernel: * the code is copyright by the authors and we try not to waste fuss on maintaining a comprehensive list in notices. If you want to find the authors to negotiate special licensing, you get to do the work. * license is GPLv2-only where not otherwise specified * relicensing, when needed, happens by contacting all the copyright holders and getting their consent I don't see anything weird about that. But people using the code might like clearer notices, so I personally would not mind an extra line in most files stating the license. (More than that and it becomes absurd.) That's all just my opinion --- Junio might think differently, etc. [...] It's verbose and cumbersome enough that I would not have been surprised if there'd be an established way of getting this information on record, preferably per-project rather than per-commit. For relicensing the existing practice is to just contact people. That has the advantage that I can make a decision about whether to allow relicensing code I've written in the context of how I expect it to be used. I expect that if you had a stance on GPLv2+ licensing of contributions to git published in some place easily found by search engines (for example a message on the mailing list), interested people would not have too much trouble finding it when the time comes. Hope that helps, Jonathan -- 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
Re: A few contributor's questions
Jonathan Nieder jrnie...@gmail.com writes: I assume the problem you're trying to solve is that files don't have clear enough notices of their licensing. No, just the file that I'm contributing to. It has a single copyright attribution that arguably is already less than accurate _unless_ the respective authors can be considered to have been acting with the intent of letting Junio do whatever he wants to do with their contribution. That could be a real problem for people using the code, since if you no one gave you a license then you don't have a license at all. In that case, it is reasonably to revert to the general license. It's also a problem in that it makes it harder to interpret the phrase under the same open source license (though I have no idea how that could be read as I give up my copyright completely). If the existing notice is (c) Junio Hamano that means that Junio is fully able to license at his will. And in the case of his work on Git, this includes his expressive permission to relicense under the conditions of libgit2, including a no-modification binary-only licensing option. So my problem is not as much that people might get the idea they might not use/copy my work at all (which would be silly), but rather that they have reasonable expectation to use it under the licensing scheme of libgit2 without getting back to me. * the code is copyright by the authors and we try not to waste fuss on maintaining a comprehensive list in notices. That's fine, but we are talking not about a list but a single named copyright holder. I was proposing adding and others to clarify that the list is not exhaustive. * relicensing, when needed, happens by contacting all the copyright holders and getting their consent I don't see anything weird about that. Neither do I. But people using the code might like clearer notices, so I personally would not mind an extra line in most files stating the license. I was more concerned about amending the copyright attribution, though a single line pointing out GPLv2 and referring the reader to the general COPYING file does not seem excessive, either. It's verbose and cumbersome enough that I would not have been surprised if there'd be an established way of getting this information on record, preferably per-project rather than per-commit. For relicensing the existing practice is to just contact people. Well, that stops working once they are dead. And it's probably rather tricky to locate their heirs even in case they have placed instructions concerning their copyrights into their last will. While I am not in a rush here, I am still likely to turn decomposing into a fulltime occupation earlier than most other contributors: I started working with computers at a time when the single most imminent danger to long-term data archival were mice. That has the advantage that I can make a decision about whether to allow relicensing code I've written in the context of how I expect it to be used. I expect that if you had a stance on GPLv2+ licensing of contributions to git published in some place easily found by search engines (for example a message on the mailing list), interested people would not have too much trouble finding it when the time comes. Maybe, maybe not. There is a big hole in the indexing of the Google News history that was taken over from what once was Dejanews. Putting the information regarding prospective licensing close to the actual source seems like a smart move. At any rate, if there is no stock procedure for that, that's it. -- 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
Re: A few contributor's questions
when relicensing, people use git blame, not header copyright notices to track down the authors. if you are bothered by the copyright notice at the top, modify it as part of your patchset, it's very unlikely that anyone will care enough to object. But copyright assignment has very strict requirements, it can't just be implicit or in e-mail, it requires a signed document, so unless you sign a document stating that you are transferring copyright, you don't have to worry about that. David Lang On Fri, 31 Jan 2014, David Kastrup wrote: Date: Fri, 31 Jan 2014 22:06:16 +0100 From: David Kastrup d...@gnu.org To: Jonathan Nieder jrnie...@gmail.com Cc: git@vger.kernel.org Subject: Re: A few contributor's questions Jonathan Nieder jrnie...@gmail.com writes: I assume the problem you're trying to solve is that files don't have clear enough notices of their licensing. No, just the file that I'm contributing to. It has a single copyright attribution that arguably is already less than accurate _unless_ the respective authors can be considered to have been acting with the intent of letting Junio do whatever he wants to do with their contribution. That could be a real problem for people using the code, since if you no one gave you a license then you don't have a license at all. In that case, it is reasonably to revert to the general license. It's also a problem in that it makes it harder to interpret the phrase under the same open source license (though I have no idea how that could be read as I give up my copyright completely). If the existing notice is (c) Junio Hamano that means that Junio is fully able to license at his will. And in the case of his work on Git, this includes his expressive permission to relicense under the conditions of libgit2, including a no-modification binary-only licensing option. So my problem is not as much that people might get the idea they might not use/copy my work at all (which would be silly), but rather that they have reasonable expectation to use it under the licensing scheme of libgit2 without getting back to me. * the code is copyright by the authors and we try not to waste fuss on maintaining a comprehensive list in notices. That's fine, but we are talking not about a list but a single named copyright holder. I was proposing adding and others to clarify that the list is not exhaustive. * relicensing, when needed, happens by contacting all the copyright holders and getting their consent I don't see anything weird about that. Neither do I. But people using the code might like clearer notices, so I personally would not mind an extra line in most files stating the license. I was more concerned about amending the copyright attribution, though a single line pointing out GPLv2 and referring the reader to the general COPYING file does not seem excessive, either. It's verbose and cumbersome enough that I would not have been surprised if there'd be an established way of getting this information on record, preferably per-project rather than per-commit. For relicensing the existing practice is to just contact people. Well, that stops working once they are dead. And it's probably rather tricky to locate their heirs even in case they have placed instructions concerning their copyrights into their last will. While I am not in a rush here, I am still likely to turn decomposing into a fulltime occupation earlier than most other contributors: I started working with computers at a time when the single most imminent danger to long-term data archival were mice. That has the advantage that I can make a decision about whether to allow relicensing code I've written in the context of how I expect it to be used. I expect that if you had a stance on GPLv2+ licensing of contributions to git published in some place easily found by search engines (for example a message on the mailing list), interested people would not have too much trouble finding it when the time comes. Maybe, maybe not. There is a big hole in the indexing of the Google News history that was taken over from what once was Dejanews. Putting the information regarding prospective licensing close to the actual source seems like a smart move. At any rate, if there is no stock procedure for that, that's it.
