Message ID | 20201229153556.22996-1-bage@linutronix.de |
---|---|
Headers | show |
Series | Build with libbsd for strlcpy | expand |
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(-) >
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.
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(-)