This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Holger Freyther holger at freyther.de> On 19 Feb 2016, at 19:54, Ruben Undheim <ruben.undheim at gmail.com> wrote: > > Hi, Dear Ruben, > > When running lintian on openbsc, I get the following error: > > E: osmocom-bsc-nat: possible-gpl-code-linked-with-openssl > E: osmocom-nitb: possible-gpl-code-linked-with-openssl > > It seems like openbsc is being linked with libcrypto from OpenSSL, but I cannot > find any statement of OpenSSL exception for the AGPL. Debian policy requires > this. > > Can you look into this? You can have a look at wget if you need an example. if you are debian developer maybe you know someone working on lintian. What always triggers me is that it (and specially lintian.debian.org) say what is wrong but they don't point to a solution, e.g. they also link to other broken packages but never to an example how this specific program has fixed the issue. It is a bit like writing E: blub. When picking libcrypto I considered it a system library (FreeBSD, OSX, etc. ship it in the base system). I think instead of changing the license it is easier to change the calls. From my point of view there are several options: 1.) You link against libgnutls-openssl-dev which provides a wrapper for RAND_bytes. 2.) We move to GNUtls (or gcrypt?) to call the function that RAND_bytes is wrapped around (after reading the documentation) 3.) We use GNU nettle and their yarrow-256 implementation (assuming that is a smart move)? I think from a packaging point of view 1st might be the easiest and just means patching one line in configure.ac? holger