-----Original Message-----
From: Pavel Machek <pavel@denx.de>
Sent: Tuesday, April 7, 2020 6:52 AM
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Pavel Machek <pavel@denx.de>; Kento Yoshida
<kento.yoshida.wz@renesas.com>; cip-security@lists.cip-project.org;
cip-dev@lists.cip-project.org
Subject: Re: [cip-dev] Python 3.x vs 2.7

On Mon 2020-04-06 12:15:16, Jan Kiszka wrote:

On 03.04.20 23:47, Pavel Machek wrote:

Hi!

FYI, unfortunately we couldn't find the alternative package for

system backup. The duplicity is the best package for us from the license and num
of dependencies point of view.

See the following.

<duplicity>
Encryption: Yes
Schedule backup: No
Incremental backup: Yes
License: GPL v2
Dependencies count (aprox): 80
Reference: http://duplicity.nongnu.org/features.ht

I'm not sure what your exact requirements are, but have you

considered

"tar"? It should be possible to pipe its output to aespipe (and
possibly other tools) to get encryption, and it should be able to

do

incremental backups...

I suppose there is that concern about GPLv3 again (as with broadly

used

rsync) - which is generally overrated. There exists legal views that

already

GPLv2 requires to keep such licensed components replaceable on the

target.

What then effectively remains with v3 is its, well, wording

complexity.

Does "tar" match the requirements?

And I agree that best option would be to accept GPLv3.

Some of the security members didn't accept GPLv3, so currently we dropped GPLv3 packages from the candidates.

BTW, I'm not sure but is the CIP policy on accepting GPLv3 still to be decided?

If that's out of question, I'm pretty sure we can get GPLv2 tar implementation
somewhere. busybox has implementation, and I'm pretty sure there's GPLv2 fork
of busybox. Old version of tar should be GPLv2. Still better than porting duplicity
to different python version...

Thank you for introduction about "tar".
I will investigate whether it meets the requirements.
And also I'll search GPLv2 implementation if it meets the requirements.
If it's not decided yet about the CIP policy on accepting GPLv3, we cannot adopt GPLv3 packages.

Anyway, I agreed it is difficult to support python 2 for a super long term. And everyone agreed on this point.
So, we cannot support each libraries using python 2, at least.

Best regards, Kent

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany