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