git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 0/2] Two janitorial patches for builtin/blame.c

From
David Kastrup <dak@gnu.org>
Date
Jan 21, 2014, 17:40 UTC
Message-ID
<874n4xqlly.fsf@fencepost.gnu.org>
In-Reply-To
<20140121165546.GE18964@google.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
Show 10 quoted lines
> David Kastrup wrote:
>
>> Now I might have sent at an unopportune time: blame.c is mostly
>> attributed to Junio who seems to have been a few days absent now.
>>
>> I also have seen quite a few mails and patch submissions on the list go
>> basically unanswered in the last few days.
>
> In the U.S., yesterday was a federal holiday (Martin Luther King, Jr.
> day) and the two days before were the weekend.
I see.
>> Now the file involved (builtin/blame.c) itself does not state _any_
>> license.
>
> Most of git is GPLv2-only.
Does that include builtin/blame.c?
> Yeah, since these patches aren't adding a large new chunk of code

Well, _significant_ chunks of code are in the works already (and my question was really more about them).

> there's no need for a new copyright notice and so no place to put that
> kind of thing unless Junio wants to relicense blame (which would be
> orthogonal to these patches).

So my understanding is that when we are talking about _significant_ additions to builtin/blame.c (the current patches don't qualify as such really) that

a) builtin/blame.c is licensed under GPLv2 b) significant contributions to it will not be relicensed under different licenses without the respective contributors' explicit consent.

This question is not academical to me. I don't have any source of income apart from people paying me to write free software (mainly LilyPond users), so if I'm writing significant pieces of code, I don't want to see them distributed as proprietary software (for example, by traveling through the very unrestrictively licensed libgit2) without being in the situation of negotiating recompensation for that.

The combination of the SubmittingPatches text with the file notices in builtin/blame.c is not really painting a full picture of the situation.

-- 
David Kastrup
Previous: Jonathan NiederNext: Jonathan Nieder
Message 8 of 17 in “Two janitorial patches for builtin/blame.c”
  1. 0/2 Two janitorial patches for builtin/blame.cDavid Kastrup, Jan 19, 2014
  2. 1/2 builtin/blame.c: struct blame_entry does not need a prev linkDavid Kastrup, Jan 19, 2014
  3. Junio C HamanoJan 21, 2014
  4. David KastrupJan 21, 2014
  5. 2/2 Eliminate same_suspect function in builtin/blame.cDavid Kastrup, Jan 19, 2014
  6. David KastrupJan 21, 2014
  7. Jonathan NiederJan 21, 2014
  8. David KastrupJan 21, 2014
  9. Jonathan NiederJan 21, 2014
  10. David KastrupJan 21, 2014
  11. Jonathan NiederJan 21, 2014
  12. David KastrupJan 21, 2014
  13. Jonathan NiederJan 21, 2014
  14. David KastrupJan 21, 2014
  15. Junio C HamanoJan 21, 2014
  16. David KastrupJan 21, 2014
  17. Jonathan NiederJan 21, 2014

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.