util-linux/lib/parse-date.y license

[hfuse]

I found someone committed following files to the git repository

https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/lib/parse-date.y?id=7088bd88323fa9152ec9fbe4089fe76807445ed3

The lib/parse-date.y is created as GPLv3

Because the library in lib directory is used for creating some util-linux packages, I think that current util-linux license seems GPLv3

But COPYING in top directory said util-linux is GPLv2

https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/tree/COPYING

This confused me

I think that lib/parse-date.y should be LGPLv2.1

[hfuse]

As described the comment, lib/parse-date.y was imported from gnulib

And gnulib-tool was used for importing gnulib software
I also checked gnulib-tool and found --lgpl option

My understanding is that the developer can change gnulib software license to LGPL by using gnulib-tool --lgpl option

[karelzak]

No, we do not use parse_date() everywhere and do not link all tools with it. The util-linux license is not GPLv3 at all. We use many licenses and it's per-util, see README.licences.

I have moved parse-date.y to hwclock-parse-date.y to make it more obvious that we use the code only in hwclock and not everywhere. So, if we want to be strict and follow the licence headers that hwclock is GPLv3 now. It would be nice if we can re-introduce the file, but with LGPL to make it more usable for us.

[karelzak]

It seems you're right,
gnulib/modules/parse-datetime define License: LGPLv2+

althougth lib/parse-datetime.y uses GPLv3. I guess the code has been originally exported manually as copy rather than by gnulib-tool ;-(

Anyway not sure, how to export it as LGPL

   gnulib-tool --lgpl=3orGPLv2 --create-testdir --dir foo parse-datetime

generates all necessary stuff, but foo/gllib/parse-datetime.y is still with GPLv3, bug?

[karelzak]

Maybe I have a solution -- remove all parse-date.y and use parse_timestamp() from lib/timeutils.c.

The timeutils.c already covers many date-time formats, it's without problematic license, without dependence on bison, etc.

[hfuse]

I think that following option is correct gnulib-tool --lgpl=2 --create-testdir --dir foo parse-datetimeBR,

…

----- Original Message ----- From: Karel Zak <notifications@github.com> To: karelzak/util-linux <util-linux@noreply.github.com> Cc: hfuse <hfuse@yahoo.co.jp>; Author <author@noreply.github.com> Date: 2019/11/7, Thu 18:38 Subject: Re: [karelzak/util-linux] util-linux/lib/parse-date.y license (#891) It seems you're right, gnulib/modules/parse-datetime define License: LGPLv2+althougth lib/parse-datetime.y uses GPLv3. I guess the code has been originally exported manually as copy rather than by gnulib-tool ;-(Anyway not sure, how to export it as LGPL gnulib-tool --lgpl=3orGPLv2 --create-testdir --dir foo parse-datetime generates all necessary stuff, but foo/gllib/parse-datetime.y is still with GPLv3, bug?— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.  -- 布施　博明

[hfuse]

The util-linux license is not GPLv3 at all. We use many licenses and it's per-util, see README.licences.

I think that removing GPLv3 codes is best solution
Did you try "gnulib-tool --lgpl=2" command?

[karelzak]

$ /home/projects/gnulib/gnulib/gnulib-tool --lgpl=2 --create-testdir --dir foo parse-datetime
$ head foo/gllib/parse-datetime.y
%{
/* Parse a string into an internal timestamp.

   Copyright (C) 1999-2000, 2002-2019 Free Software Foundation, Inc.

   This program is free software: you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation; either version 3 of the License, or
   (at your option) any later version.

... so it works, but the file is still with GPLv3.

[hfuse]

I got same result
It seems that we can not get LGPLv2.1 version of parse-datetime.y

BTW, you proposed another solution

Maybe I have a solution -- remove all parse-date.y and use parse_timestamp() from lib/timeutils.c.
The timeutils.c already covers many date-time formats, it's without problematic license, without dependence on bison, etc.

Could you create hwclocl binary with about file?

Regards,

[karelzak]

Well, is hwclock with GPLv3 so big problem? :-)

We can use parse_timestamp() from lib/timeutils.c, but it implements only small subset of date-time formats and for some users it may be a regression...

We had exec() for date(1) in hwclock originally; this has been replaced by parse-date.y to avoid dependence on date(1) -- so date(1) like time formats are supported for pretty long time and I'm not sure if we want to change it.

[karelzak]

Closing for now. It seems we can alive with GPLv3 hwclock -- at least until someone send patch with better date-time parser ;-)