Could /Documentation/technical/commit-graph.txt be relicensed under a permissive license?

Hello. https://github.com/git/git/blob/master/Documentation/technical/commit-graph.txt documents a file format for exporting commit graphs for consumption by third-party tools. But the license of this file is not permissive, and the license of git itself is GPL, so I am not allowed to use these 2 files to create an own permissive-licensed tool reading this file. This probably defeats the purpose of exporting these info and then reading it with another applications.

Could the doc file be relicensed under a permissive license?

KOLANICH <kolan_n@mail.ru> writes:

It is a wrong conclusion, isn't it?

GPL copyright protects the expression of the document, but the copyright protects only the expression, and does not protect the underlying format itself and the idea behind it. So I do not see a need to relicense the documentation text at all.

On 12/10/2019 3:10 PM, Junio C Hamano wrote:

I don't appear to have the original message? Perhaps it was directly addressed to Junio?

(Insert "I am not a lawyer" warning.)

I think this is the correct interpretation. One can interact with binary files as you want. In fact, there are likely privately licensed products that interact with Git's pack-files even though their format documentation is under GPL.

What _could_ be problematic is repeating the documentation directly in another permissive-licensed repository.

Thanks, -Stolee

On Tue, Dec 10, 2019 at 03:38:35PM -0500, Derrick Stolee wrote:

It made it to me via the list, too.

That's my understanding as well. That said, I would not be opposed to some kind of statement in the documentation making our view explicit.

-Peff

On 12/10/2019 3:50 PM, Jeff King wrote:

Hm... I have had messages from the list be delayed somehow by Gmail.

A similar statement could apply to the following files:

Documentation/technical/bitmap-format.txt Documentation/technical/commit-graph-format.txt Documentation/technical/http-protocol.txt Documentation/technical/index-format.txt Documentation/technical/long-running-process-protocol.txt Documentation/technical/pack-format.txt Documentation/technical/pack-protocol.txt Documentation/technical/protocol-capabilities.txt Documentation/technical/protocol-common.txt Documentation/technical/protocol-v2.txt

and perhaps others, including future additions.

Would it be better to have a new file in Documentation/technical/ that describes this view?

-Stolee

On Tue, 10 Dec 2019 at 15:51, Jeff King <peff@peff.net> wrote:

As someone with a vested interest in permissively licensed tools that can perform some basic git-compatible operations, such a statement would be appreciated.

Jeff King <peff@peff.net> writes:

In principle, I do not mind that either.

But quite honestly, I cannot say that I am (or "want to be") all that sympathetic.

It takes me some effort to convince myself that it is worth for us to spend extra brain cycles even thinking about making such statements, when those who would benefit the most from such an effort are the ones who call the software we work on "contamination" and proclaim that they cannot be bothered to spend the necessary effort to comply with the license as a waste of time.

I'd be more receptive to those who are more friendly and respectful---these things tend to be mutual.

Necessity to treat so called free software with a technique invented to deal with closed-source proprietary software by companies enjoying their walled gardens and vigorously protecting their walls integrity in courts is a clear sign that there is something wrong with the software. I don't beleive that free open-source software should to work this way.

Hi,

On Wed, 11 Dec 2019, KOLANICH wrote:

Seeing as the obvious effect of such a hostile statement can only be less cooperation, in particular when replying directly to a mail where the Git maintainer pointed out that there is hardly any benefit to the Git project in addressing complaints raised in a combative manner, I have to wonder whether you realize that you just sabotaged the process where quite a few people were ready to help you to get what you desire?

Puzzled, Johannes

On 2019-12-10 at 20:50:56, Jeff King wrote:

This is consistent with my interpretation as well. I view the documentation as a specification, and implementers are free to license their software as they see fit. They need only comply with the GPL if they wish to copy, modify, or distribute the documentation itself (or other parts of Git).

I see this exactly as the situation with RFCs (e.g., TCP): they are documentation licensed under non-free terms, but there are multiple independent implementations of those RFCs under different terms (Linux, FreeBSD, and Windows, for example). The license terms of the RFCs apply only to those documents, not the implementations.

Derrick Stolee <stolee@gmail.com> writes:

[...]

Sidenote: I wonder if JGit, which is permissively-licensed (EDL,
i.e. new-style BSD) pure-Java implementation of Git, makes use of commit
graph.

I remember that pack bitmaps came to Git from JGit, where that feature was first implemented.

Best, -- Jakub Narębski