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
