Christian Hammers | 1 May 23:03 2005
Picon

[quagga-dev 3374] Licence issues due to linking against openssl via libsnmp?

Hello

I recently received a bug report saying that Quagga was linking against
OpenSSL which is not allowed as Quagga is GPL and OpenSSL not compatible
according to many people [1].

Now, even with removing the (useless?) "-lcrypto" options from
./configure, the resulting binary still links against libcrypto.so
as libnetsnmp links against it (and therefore, according to the FSF
point of view quagga indirectly also uses OpenSSL code).

The suggested solutions are:
 - remove/replace Net-SNMP support
 - change the licence to let it say that Quagga is GPL but with the
   exception that it may be link against OpenSSL.
   (not as easy as it sounds if you think about who may have the right
   to change the licence of a GPLed code..)

Has this been discussed before?

bye,

-christian-

[1] http://www.gnome.org/~markmc/openssl-and-the-gpl.html
    http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs
Paul Jakma | 2 May 00:58 2005
Picon

[quagga-dev 3375] Re: Licence issues due to linking against openssl via libsnmp?

On Sun, 1 May 2005, Christian Hammers wrote:

> Hello
>
> I recently received a bug report saying that Quagga was linking 
> against OpenSSL which is not allowed as Quagga is GPL and OpenSSL 
> not compatible according to many people [1].

What's the state of GNUtls?

> Now, even with removing the (useless?) "-lcrypto" options from
> ./configure,

Ah, good idea.

> the resulting binary still links against libcrypto.so as libnetsnmp 
> links against it (and therefore, according to the FSF point of view 
> quagga indirectly also uses OpenSSL code).

> The suggested solutions are:
> - remove/replace Net-SNMP support

It's already optional though. If the licence issue bothers one 
sufficiently you can build without net-snmp. Some further thoughts:

- We do not directly care about openssl or use it directly in any
   way.

- We just link to net-snmp, in most cases at run-time via the dynamic
   linker (and it's dependencies). Further, net-snmp is optional.
(Continue reading)

Christian Hammers | 2 May 01:16 2005
Picon

[quagga-dev 3376] Re: Licence issues due to linking against openssl via libsnmp?

Hello

On 2005-05-01 Paul Jakma wrote:
> > I recently received a bug report saying that Quagga was linking 
> > against OpenSSL which is not allowed as Quagga is GPL and OpenSSL 
> > not compatible according to many people [1].
> 
> What's the state of GNUtls?
It's recommended from all parties so probably stable but I don't know
why the NetSNMP maintainers do not use it (they don't have to as they
use a BSD style licence).

> Note that an end-user who builds Quagga linked to GPL-incompatible 
> libraries is not "breaking" the GPL, for they are not bound by the 
> GPL as long as they do not distribute outside their organisation. 
> Hence I don't see anything wrong in providing the option and no 
> reason to remove it.
Good point, but was more for the "replace" instead of the "remove"
anyway. Too bad though that I can't propose an alternative SNMP library
although it probably exists.

> I wonder if perhaps it would be more fruitful to make net-snmp 
> support GNUtls, as this must surely affect other net-snmp using GPLed 
> applications. And till then, Debian can just build Quagga without 
> net-snmp support, or alternatively build net-snmp without OpenSSL 
> linkage (not sure if thats possible).
I try to convince them...

> What is net-snmp using openssl for? asn.1 type stuff or for 
> non-critical TLS protected SNMP (if that exists - i dont know) or for 
(Continue reading)

Paul Jakma | 2 May 01:28 2005
Picon

[quagga-dev 3377] Re: Licence issues due to linking against openssl via libsnmp?

On Mon, 2 May 2005, Christian Hammers wrote:

> It's recommended from all parties so probably stable but I don't 
> know why the NetSNMP maintainers do not use it (they don't have to 
> as they use a BSD style licence).

Right.

>> Note that an end-user who builds Quagga linked to GPL-incompatible
>> libraries is not "breaking" the GPL, for they are not bound by the
>> GPL as long as they do not distribute outside their organisation.
>> Hence I don't see anything wrong in providing the option and no
>> reason to remove it.

> Good point, but was more for the "replace" instead of the "remove" 
> anyway.

Well, as an immediate solution, Debian can simply not build in 
net-snmp support in Debian Quagga packages.

> Too bad though that I can't propose an alternative SNMP 
> library although it probably exists.

Well, actually all we need is the snmp-smux protocol really.. we dont 
need anything but that.

> I try to convince them...

Excellent.

(Continue reading)

Christian Hammers | 2 May 01:33 2005
Picon

[quagga-dev 3378] BGP-MD5 and Quagga 0.99.1: LIST_LOOP renamed?

Hello

Hasso's BGP MD5 patch for 0.98 does no longer compile:
  bgpd.c: In function `peer_password_set':
  bgpd.c:3334: warning: implicit declaration of function `LIST_LOOP'

I assume that this LIST_LOOP has been renamed to ALL_LIST_ELEMENTS_RO
but as the content of the macro looks a bit different I think I better
ask.

BTW, as nobody answered [quagga-dev 3204] :) Why not incorporating it into
the main branch? I assume most distros will have to apply it anyway because
they have users whose peers force them to use it.

bye,

-christian-
Paul Jakma | 2 May 02:37 2005
Picon

[quagga-dev 3379] Re: BGP-MD5 and Quagga 0.99.1: LIST_LOOP renamed?

On Mon, 2 May 2005, Christian Hammers wrote:

> Hello
>
> Hasso's BGP MD5 patch for 0.98 does no longer compile:
>  bgpd.c: In function `peer_password_set':
>  bgpd.c:3334: warning: implicit declaration of function `LIST_LOOP'
>
> I assume that this LIST_LOOP has been renamed to 
> ALL_LIST_ELEMENTS_RO but as the content of the macro looks a bit 
> different I think I better ask.

s/LIST_LOOP ((.*),(.*),(.*)/for (ALL_LIST_ELEMENTS (\1,\2,\3,nnode))/

And add a '*nnode' to the existing 'struct listnode *X;' definition.

> BTW, as nobody answered [quagga-dev 3204] :) Why not incorporating 
> it into the main branch? I assume most distros will have to apply 
> it anyway because they have users whose peers force them to use it.

That'd depend on whether the kernel the distro or OS uses supports 
TCP-MD5 I guess.

regards,
--

-- 
Paul Jakma	paul <at> clubi.ie	paul <at> jakma.org	Key ID: 64A2FF6A
Fortune:
Practical people would be more practical if they would take a little
more time for dreaming.
 		-- J. P. McEvoy
(Continue reading)

Paul Jakma | 2 May 02:39 2005
Picon

[quagga-dev 3380] Re: Licence issues due to linking against openssl via libsnmp?

On Sun, 1 May 2005, Paul Jakma wrote:

> What is net-snmp using openssl for? asn.1 type stuff or for non-critical TLS 
> protected SNMP (if that exists - i dont know) or for algorithms for secure 
> passwords?

ASN.1 parsing it seems.

Anyone know of a GPL compatible ASN.1 helper library? (The rest of 
the stuff we likely can do ourselves..)

regards,
--

-- 
Paul Jakma	paul <at> clubi.ie	paul <at> jakma.org	Key ID: 64A2FF6A
Fortune:
Push where it gives and scratch where it itches.
Christian Hammers | 2 May 09:41 2005
Picon

[quagga-dev 3381] Re: Licence issues due to linking against openssl via libsnmp?

Hello

On 2005-05-02 Paul Jakma wrote:
> On Sun, 1 May 2005, Paul Jakma wrote:
> 
> > What is net-snmp using openssl for? asn.1 type stuff or for non-critical TLS 
> > protected SNMP (if that exists - i dont know) or for algorithms for secure 
> > passwords?
> 
> ASN.1 parsing it seems.
The NEWS.gz from libsnmp5 also mentioned SHA1+MD5, PKCS#11 handling and DES
encryption in SNMPv3...

> Anyone know of a GPL compatible ASN.1 helper library? (The rest of 
> the stuff we likely can do ourselves..)
There's libtasn, the ASN.1 library used in GnuTLS.

bye,

-christian-
_______________________________________________
Quagga-dev mailing list
Quagga-dev <at> lists.quagga.net
http://lists.quagga.net/mailman/listinfo/quagga-dev
Renato Machado de Sousa | 2 May 13:40 2005
Picon

[quagga-dev 3382] Re: Licence issues due to linking against openssl via libsnmp?

Comments below...

> It's already optional though. If the licence issue bothers one
> sufficiently you can build without net-snmp. Some further thoughts:
>
> - We do not directly care about openssl or use it directly in any
>    way.
>
> - We just link to net-snmp, in most cases at run-time via the dynamic
>    linker (and it's dependencies). Further, net-snmp is optional.
>
> Hence, I'm not particularly sure this is a Quagga problem, rather any
> potential problem is upon those who might build and distribute Quagga
> binaries linked to net-snmp.
>
> Note that an end-user who builds Quagga linked to GPL-incompatible
> libraries is not "breaking" the GPL, for they are not bound by the
> GPL as long as they do not distribute outside their organisation.
> Hence I don't see anything wrong in providing the option and no
> reason to remove it.

Obligatory disclaimer: I am not a lawyer, blah, blah, blah...

I concur with this view. Net-SNMP's license is MIT and BSD (without 
advertisement clause). As such, Quagga can legally link with it, as long as 
SNMP isn't compiled with OpenSSL (didn't try it, but gentoo has a ssl useflag 
for net-snmp, so it must be optional), and Quagga doesn't assume SSL is 
available (that is, doesn't call SSL APIs, if they are any different from 
standard). As said before, this isn't a problem to Quagga at all: it is 
prepared for linking and based in a library that it CAN link to, and the fact 
(Continue reading)

Paul Jakma | 2 May 18:36 2005
Picon

[quagga-dev 3383] Re: Licence issues due to linking against openssl via libsnmp?

On Mon, 2 May 2005, Renato Machado de Sousa wrote:

> Just to be clean, we can add a configure.ac macro that tests if 
> net-snmp is linked against SSL, and if so, issues a warning saying 
> the binaries it build will be illegal to distribute.

Note that some systems appear not to link netsnmp to SSL. It's left 
to the application to link in all the dependent libraries.

> AFAIK, Zebra also links against net-snmp, so it has the same 
> issues. Unless he wants to leave zebra in a legal limbo, if any 
> change needs to be made in quagga he will need to make it in zebra 
> too.

I'm not even sure there is a legal problem. From POV of Quagga this 
amounts to nothing more than an entry in the ELF header. We don't 
need OpenSSL to compile, we dont use any data structures it provides, 
we dont care of its existence at all. The only way OpenSSL happens to 
be in the picture is that netsnmp typically wants -lcrypto.

If you look at the dynamic symbol table for a Quagga binary built 
with netsnmp support you wont find /any/ OpenSSL/libcrypto symbols 
(afaict). If someone implemented a netsnmp that used something else 
for crypto, the same Quagga binary could make use of it (all you'd 
need to do is provide a dummy crypto ELF shared object - it wouldn't 
even need to be binary compatible with OpenSSL libcrypto, it wouldn't 
even need to implement /anything/).

IOW, Quagga binaries with netsnmp are quite isolated from libcrypto, 
other than that single ELF entry.. (which can easily be made resolve 
(Continue reading)


Gmane