mbox series

[0/3] Build with libbsd for strlcpy

Message ID 20201229153556.22996-1-bage@linutronix.de
Headers show
Series Build with libbsd for strlcpy | expand

Message

Bastian Germann Dec. 29, 2020, 3:35 p.m. UTC
From: Bastian Germann <bage@linutronix.de>

Besides the missing copyright and license information for OpenBSD's
strlcpy implementation, there is another problem with it.

Building with a libbsd-configured zeromq can trigger a linking error.
This series intends to fix that by using libbsd for SWUpdate as well.

Bastian Germann (3):
  Revert "Replace own implementation of strlcpy with FreeBSD"
  Revert "Introduce strlcpy() as string copy replacement"
  Build with libbsd for strlcpy

 Makefile.flags          |  3 +++
 core/util.c             | 33 ---------------------------------
 doc/source/swupdate.rst |  1 +
 include/util.h          |  6 +-----
 4 files changed, 5 insertions(+), 38 deletions(-)

Comments

Stefano Babic Dec. 29, 2020, 4 p.m. UTC | #1
Hi Bastian,

On 29.12.20 16:35, bage@linutronix.de wrote:
> From: Bastian Germann <bage@linutronix.de>
> 
> Besides the missing copyright and license information for OpenBSD's
> strlcpy implementation, there is another problem with it.
> 
> Building with a libbsd-configured zeromq can trigger a linking error.
> This series intends to fix that by using libbsd for SWUpdate as well.
> 

I am quite prudent to add further libraries and dependencies to the
project if they are not really needed. In this case, we are talking
about a single function that consists of just a bunch of code. Sure, it
should be added to the function that code is coming from BSD or from
libsd itself. But I tend to prefer the own implementation in SWUpdate if
no other functions from libsd are used.

Regarding zeroMQ, I am hitting another bigger issue. zeroMQ is released
under LGPL, but LGPLv3.

This is then incompatible with GPLv2. I am to remove the remote handler
(and zeroMQ) completely from SWUpdate. Are you using the remote handler
or is there anybody out there complaining abot its removal ?

Best regards,
Stefano Babic

> Bastian Germann (3):
>   Revert "Replace own implementation of strlcpy with FreeBSD"
>   Revert "Introduce strlcpy() as string copy replacement"
>   Build with libbsd for strlcpy
> 
>  Makefile.flags          |  3 +++
>  core/util.c             | 33 ---------------------------------
>  doc/source/swupdate.rst |  1 +
>  include/util.h          |  6 +-----
>  4 files changed, 5 insertions(+), 38 deletions(-)
>
Bastian Germann Dec. 29, 2020, 4:11 p.m. UTC | #2
Am 29.12.20 um 17:00 schrieb Stefano Babic:
> Hi Bastian,
> 
>> Besides the missing copyright and license information for OpenBSD's
>> strlcpy implementation, there is another problem with it.
>>
>> Building with a libbsd-configured zeromq can trigger a linking error.
>> This series intends to fix that by using libbsd for SWUpdate as well.
>>
> 
> I am quite prudent to add further libraries and dependencies to the
> project if they are not really needed. In this case, we are talking
> about a single function that consists of just a bunch of code. Sure, it
> should be added to the function that code is coming from BSD or from
> libsd itself. But I tend to prefer the own implementation in SWUpdate if
> no other functions from libsd are used.

Please add the copyright/license information then.

> 
> Regarding zeroMQ, I am hitting another bigger issue. zeroMQ is released
> under LGPL, but LGPLv3.
> 
> This is then incompatible with GPLv2. I am to remove the remote handler
> (and zeroMQ) completely from SWUpdate. Are you using the remote handler
> or is there anybody out there complaining abot its removal ?

I do not use the remote handler.

According to http://wiki.zeromq.org/area:licensing, zeroMQ has a linking 
exception which intends to heal this license issue. They also want to 
relicense under MPLv2 in the future.