git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Brandon Casey <drafnel@gmail.com>
To: Philippe Joyez <philippe.joyez@cea.fr>
Cc: Joris van der Hoeven <vdhoeven@lix.polytechnique.fr>,
	git-for-windows@googlegroups.com,
	"git@vger.kernel.org" <git@vger.kernel.org>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: requesting permission to use some Git for Windows code
Date: Thu, 27 Jul 2017 22:31:32 -0700	[thread overview]
Message-ID: <CA+sFfMcAtStAfoc6Zaq7zW3cmYLu1QMX9_mmrRWe=M_GJYDeyw@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.21.1.1706281259170.84669@virtualbox>

Hi Philippe,

Please feel free to use my portions of the mentioned works under the GPLv3.

-Brandon

On Tue, Jul 25, 2017 at 6:53 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi Philippe,
>
> I am not quite certain whether I have replied to this earlier or not.
> Under the assumption that I did not, I'll send this mail; Cc:ed to the
> mailing lists as discussed privately.
>
> On Fri, 23 Jun 2017, Philippe Joyez wrote:
>
>> This message is to request the permission to use code chunks from Git
>> for Windows in GNU TeXmacs <http://texmacs.org/>, to which I contribute.
>> The main developer of TeXmacs is Joris van der Hoeven (in cc).
>>
>> Context:
>>
>> Just like Git, TeXmacs originated on *nix platforms and was subsequently
>> ported to windows using MinGW. Naturally, some issues we have in that
>> port are the very same Git for Windows has faced.
>>
>> One specific problem you have solved and that TeXmacs still hasn't, is
>> dealing with unicode filenames. By taking relevant pieces of code in Git
>> for windows, I could easily come up with a patch that enables TeXmacs to
>> handle unicode filenames in windows.
>>
>> Now, the problem is that Git code is GPL V2, while TeXmacs is GPL V3:
>> Incorporating my patch in TeXmacs' trunk would be a violation of GPL
>> V2... /unless/ we are granted the permission to do so by the authors of
>> the code. This is precisely the reason for this message.
>
> It is great that you can make use of the code!
>
> As to the licensing problem, I agree it is a hassle. The biggest obstacle
> is that you have to have the consent of all the authors.
>
> You hereby have mine.
>
>> The chunks of code we would like to reuse are from these Git for Windows
>> files:
>> git-compat-util.h
>
> This file is quite large, maybe you can cut down on the authors to contact
> by restricting the `git annotate`/`git log`/`git shortlog` calls to
> specific parts, using the `-L <start-line-no>,<end-line-no>` option?
>
>> ctype.c
>
> $ git shortlog -nse ctype.c
>      5  Junio C Hamano <gitster@pobox.com>
>      4  René Scharfe <l.s.r@web.de>
>      2  Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
>      1  Ben Walton <bdwalton@gmail.com>
>      1  Brandon Casey <drafnel@gmail.com>
>      1  Gary V. Vaughan <git@mlists.thewrittenword.com>
>      1  Linus Torvalds <torvalds@linux-foundation.org>
>      1  Namhyung Kim <namhyung@gmail.com>
>
> I *think* Ben Walton's change (189c860c9ec (kwset: use unsigned char to
> store values with high-bit set, 2015-03-02)) is not copyright-able, as it
> only changes the type from signed to unsigned. But I am not a lawyer ;-)
>
> Likewise, Namhyung Kim's change (1a191a22959 (ctype.c only wants
> git-compat-util.h, 2012-02-10)) only changes which header is included.
> That seems to be a too-obvious/too-trivial change to me.
>
> Also, it looks as if removing a comma as was done in 4b05548fc05 (enums:
> omit trailing comma for portability, 2010-05-14) by Gary V. Vaughan would
> not merit any copyright.
>
> If in doubt, you could simply take the version of ctype.c with those
> changes reverted as basis of your work.
>
> You still have to get the consent of Junio, René, Duy, Brandon and Linus
> to relicense the file's contents.
>
>> compat ¬
>>    mingw.c
>
> I count 35 authors other than myself for that file... Maybe you can narrow
> down what you need?
>
>>    mingw.h
>
> Still 29 authors other than me...
>
>>    win32.h
>
> This is more manageable, as it only saw three authors. But then, you could
> simply reimplement the functionality, it's just two functions, and I do
> not think that get_file_attr() is implemented in the best way: we have a
> function called err_win_to_posix() in compat/mingw.c which is much more
> complete.
>
> Having said that, err_win_to_posix() is still not implemented in the best
> way. The best way is to abuse Windows' own (undocumented) _doserrmap()
> function along with the information in the header files winerror.h and
> errno.h to generate the mapping. Those two files, as per mingw-w64's
> headers, have the very nice preamble:
>
>         /**
>          * This file has no copyright assigned and is placed in the Public Domain.
>          * This file is part of the mingw-w64 runtime package.
>          * No warranty is given; refer to the file DISCLAIMER.PD within this
>          * package.
>          */
>
> Therefore, the result has no copyright assigned and is placed in the
> Public Domain and we can do the very same, too.
>
> As I wanted to have a Windows error -> errno mapping that I could
> relicense as I see fit, anyway, I took this as an excellent opportunity to
> generate exactly that.
>
> Please find the header attached. Here is how I generated that header file:
>
> -- snip --
> cat >/tmp/generrmap.c <<EOF &&
> #include <windows.h>
> #include <stdio.h>
>
> static void map_code(unsigned long code, const char *id);
>
> int _main(int argc, char **argv)
> {
>         printf("/* This file has no copyright assigned and is placed in the "
>                 "Public Domain. */\\n"
>                 "\\n"
>                 "#ifndef WINERR2ERRNO_H\\n"
>                 "#define WINERR2ERRNO_H\\n"
>                 "\\n"
>                 "static int winerror2errno(long code)\\n"
>                 "{\\n");
> $(sed -n 's/^#define \([^ ]*\) __MSABI_LONG([1-9].*/\tmap_code(\1, "\1");/p' \
>         </mingw64/x86_64-w64-mingw32/include/winerror.h)
>         printf("\\tdefault: errno = EINVAL;\\n"
>                 "\\t}\\n"
>                 "\\n"
>                 "\\treturn -1; /* Typical return value when errno was set */\\n"
>                 "}\\n"
>                 "\\n"
>                 "#endif /* WINERR2ERRNO_H */\\n");
>         fflush(stdout);
>         return 0;
> }
>
> /* Undocumented function in the MSVCRT */
> extern void _dosmaperr(unsigned long code);
>
> static const char *errno2constant(int err, const char *id)
> {
>         switch (err) {
> $(sed -n 's/^#define \([^ ]*\) \([0-9]*\)$/\tcase \2: return "\1";/p' \
>         </mingw64/x86_64-w64-mingw32/include/errno.h)
>         default:
>                 fprintf(stderr, "Unhandled err: %d (for %s)\\n", err, id);
>                 exit(1);
>         }
> }
>
> static void map_code(unsigned long code, const char *id)
> {
>         errno = 0;
>         _dosmaperr(code);
>         if (!errno) {
>                 fprintf(stderr, "Unhandled id: '%s' (%ld)\\n", id, code);
>                 exit(1);
>         }
>         if (errno != EINVAL)
>                 printf("\\tcase %s: errno = %s;\\n",
>                         id, errno2constant(errno, id));
> }
> EOF
> gcc -g -nostdlib -o /tmp/generrmap.exe /tmp/generrmap.c -lmsvcr120 &&
> /tmp/generrmap
> -- snap --
>
>>    win32 ¬
>>         dirent.c
>>         dirent.h
>
> I encourage you to have a look whether you really need that full-fledged
> functionality.
>
> For vaguely related work, I recently reimplemented this differently, for
> use in BusyBox-w32, where we really only need to have the file names. The
> implementation is a lot cleaner, and I am happy to relicense this to
> whatever license you see fit (even BSD):
>
>         https://github.com/git-for-windows/busybox-w32/commit/b76eee3aca
>
>>         lazyload.h
>
> This one was authored by me, and I am happy to relicense it to GPLv3. Or
> whatever license, really.
>
> Ciao,
> Johannes

  parent reply	other threads:[~2017-07-28  5:31 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <a730cebb-1782-f32b-0b7c-253bd61475d6@cea.fr>
2017-07-25 13:53 ` requesting permission to use some Git for Windows code Johannes Schindelin
     [not found]   ` <83bce6b8-a5eb-4914-a2d3-edd57050bfaa@googlegroups.com>
2017-07-27  8:31     ` Philippe Joyez
2017-07-28  5:31   ` Brandon Casey [this message]
2017-07-28 15:26     ` Marius Storm-Olsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CA+sFfMcAtStAfoc6Zaq7zW3cmYLu1QMX9_mmrRWe=M_GJYDeyw@mail.gmail.com' \
    --to=drafnel@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git-for-windows@googlegroups.com \
    --cc=git@vger.kernel.org \
    --cc=philippe.joyez@cea.fr \
    --cc=vdhoeven@lix.polytechnique.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).