On Sat, 25 Jan 2020, Karel Zak wrote:
On Fri, Jan 24, 2020 at 04:16:47PM -0300, Carlos Santos wrote:
That's a problem. It makes hwclock hard to include in embedded systems
due to the GPLv3 restrictions.
I noticed that it comes due to sys-utils/hwclock-parse-date.y, which
was taken from gnulib. Would it be possible to take the file from an
previous version of gnulib that was still under GPLv2?
An alternative approach would be porting a similar code using a more
liberal license, e.g. BSD.
What do you think?
I have tried to export it from gnulib with v2, but it was impossible
by official gnulib tools. Maybe do it manually from some old
tarball. I'll accept a patch for this if you have time do it.
You do realize that I had to heavily modify that file to remove its
gnulib dependencies (because you said no to gnulib). If I recall
correctly I had newer and older versions to chose from and picked that
one due to it having the most bugs fixed while still being practical to
strip its gnulib dependence.
The reasons for making the change were:
* remove hwclock's dependence on date(1)
* remove an insecure call to date(1)
* I thought there would be to many complaints if the accepted input
date formats were changed
As to the last bullet point; personally I think having the --date option
accept every date syntax know to history is nonsense. A fixed format
would be fine with me. Since we switched hwclock's output to ISO 8601
that seems like a good choice for its input. Or you could just use the
existing utillinux date parser.
The question is, do you want to deal with any pushback for
changing the long established accepted --date formats?
I'll like to release 2.35.1 ASAP (due to bug in sfdisk --move-data),
so we can add this license change too.
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
http://karelzak.blogspot.com
