Hi, Kamailio trunk version requires libcurl4-gnutls-dev Debian Lenny package while SIP-Router trunk version requires libcurl4-openssl-dev.
Both packages are not compatible (just one of them can be installed). This means that it's not possible to install both, Kamailio and SIP-Router, as Debian packages in the same host... :(
The fact is that both are the same but the first uses GnuTLS while the seconds uses OpenSSL.
This is a big issue for people wanting to have both projects installed as Deb packages.
Could it be modified? It there a real dependency on each package? or could any of them be valid for both projects?
Iñaki Baz Castillo writes:
Hi, Kamailio trunk version requires libcurl4-gnutls-dev Debian Lenny package while SIP-Router trunk version requires libcurl4-openssl-dev.
looks like both libcurl4-gnutls-dev and libcurl4-openssl-dev provide libcurl library. i think that my use of libcurl in k and sr modules could use either package.
-- juha
El Lunes, 22 de Junio de 2009, Juha Heinanen escribió:
Iñaki Baz Castillo writes:
Hi, Kamailio trunk version requires libcurl4-gnutls-dev Debian Lenny package while SIP-Router trunk version requires libcurl4-openssl-dev.
looks like both libcurl4-gnutls-dev and libcurl4-openssl-dev provide libcurl library. i think that my use of libcurl in k and sr modules could use either package.
I could try to compile Kamailio with libcurl4-openssl-dev (changing the debian control file). Any issue with it?
In case both packages are valid, which is supposed to be the "correct way"?
El Lunes, 22 de Junio de 2009, Iñaki Baz Castillo escribió:
El Lunes, 22 de Junio de 2009, Juha Heinanen escribió:
Iñaki Baz Castillo writes:
Hi, Kamailio trunk version requires libcurl4-gnutls-dev Debian Lenny package while SIP-Router trunk version requires libcurl4-openssl-dev.
looks like both libcurl4-gnutls-dev and libcurl4-openssl-dev provide libcurl library. i think that my use of libcurl in k and sr modules could use either package.
I could try to compile Kamailio with libcurl4-openssl-dev (changing the debian control file). Any issue with it?
I've done it and it compiles correctly but sinceI use nothing related to SSL/TL...
Iñaki Baz Castillo writes:
I could try to compile Kamailio with libcurl4-openssl-dev (changing the debian control file). Any issue with it?
there should not be any issues.
In case both packages are valid, which is supposed to be the "correct way"?
i would prefer gnutls version.
-- juha
Iñaki Baz Castillo schrieb:
El Lunes, 22 de Junio de 2009, Juha Heinanen escribió:
Iñaki Baz Castillo writes:
Hi, Kamailio trunk version requires libcurl4-gnutls-dev Debian Lenny package while SIP-Router trunk version requires libcurl4-openssl-dev.
looks like both libcurl4-gnutls-dev and libcurl4-openssl-dev provide libcurl library. i think that my use of libcurl in k and sr modules could use either package.
I could try to compile Kamailio with libcurl4-openssl-dev (changing the debian control file). Any issue with it?
I think there is no difference in functionality - just differences in licensing.
regards klaus
Klaus Darilion schrieb:
Iñaki Baz Castillo schrieb:
El Lunes, 22 de Junio de 2009, Juha Heinanen escribió:
Iñaki Baz Castillo writes:
Hi, Kamailio trunk version requires libcurl4-gnutls-dev Debian Lenny package while SIP-Router trunk version requires libcurl4-openssl-dev.
looks like both libcurl4-gnutls-dev and libcurl4-openssl-dev provide libcurl library. i think that my use of libcurl in k and sr modules could use either package.
I could try to compile Kamailio with libcurl4-openssl-dev (changing the debian control file). Any issue with it?
I think there is no difference in functionality - just differences in licensing.
Maybe there can be issues with libcurl4-openssl-dev as it is used also for other parts (TLS, libpq?, ...) and openssl is know to cause problems when it is initialized multiple times.
IIRC in ser the Identidy module uses static linking against openssl to avoid this issue.
regards klaus
On 23-06 10:02, Klaus Darilion wrote:
Iñaki Baz Castillo schrieb:
El Lunes, 22 de Junio de 2009, Juha Heinanen escribió:
Iñaki Baz Castillo writes:
Hi, Kamailio trunk version requires libcurl4-gnutls-dev Debian Lenny package while SIP-Router trunk version requires libcurl4-openssl-dev.
looks like both libcurl4-gnutls-dev and libcurl4-openssl-dev provide libcurl library. i think that my use of libcurl in k and sr modules could use either package.
I could try to compile Kamailio with libcurl4-openssl-dev (changing the debian control file). Any issue with it?
I think there is no difference in functionality - just differences in licensing.
From what I have seen there appears to be a big difference in performance, for example:
http://www.mail-archive.com/lftp-devel@uniyar.ac.ru/msg01486.html
and I have seen more such reports. Openssl received lots of speed optimizations over time, unlike gnutls.
Jan.
2009/6/23 Jan Janak jan@iptel.org:
and I have seen more such reports. Openssl received lots of speed optimizations over time, unlike gnutls.
So, is it ok if I change the dependencies in Kamailio to require libcurl4-openssl-dev instead of libcurl4-gnutls-dev?
On Dienstag, 23. Juni 2009, Iñaki Baz Castillo wrote:
2009/6/23 Jan Janak jan@iptel.org:
and I have seen more such reports. Openssl received lots of speed optimizations over time, unlike gnutls.
So, is it ok if I change the dependencies in Kamailio to require libcurl4-openssl-dev instead of libcurl4-gnutls-dev?
Hi Iñaki,
this would mean that the utils module can't be packaged with (official) debian anymore, as the licence of openssl don't allow it. This is basically the same problem as with the tls support, which is disabled in the debian package as well.
Henning
2009/6/23 Henning Westerholt henning.westerholt@1und1.de:
On Dienstag, 23. Juni 2009, Iñaki Baz Castillo wrote:
2009/6/23 Jan Janak jan@iptel.org:
and I have seen more such reports. Openssl received lots of speed optimizations over time, unlike gnutls.
So, is it ok if I change the dependencies in Kamailio to require libcurl4-openssl-dev instead of libcurl4-gnutls-dev?
Hi Iñaki,
this would mean that the utils module can't be packaged with (official) debian anymore, as the licence of openssl don't allow it. This is basically the same problem as with the tls support, which is disabled in the debian package as well.
So, what about SIP-Router and utils k-module? Note that SIP-Router requires libcurl4-openssl-dev.
On 06/23/2009 01:18 PM, Henning Westerholt wrote:
On Dienstag, 23. Juni 2009, Iñaki Baz Castillo wrote:
2009/6/23 Jan Janak jan@iptel.org:
and I have seen more such reports. Openssl received lots of speed optimizations over time, unlike gnutls.
So, is it ok if I change the dependencies in Kamailio to require libcurl4-openssl-dev instead of libcurl4-gnutls-dev?
Hi Iñaki,
this would mean that the utils module can't be packaged with (official) debian anymore, as the licence of openssl don't allow it. This is basically the same problem as with the tls support, which is disabled in the debian package as well.
is it inherited in this case? the tls implementation in core of kamailio is binding directly to openssl library and therefore need for the gpl disclaimer, but in this case utils binds to curl library.
In sip router this is fixed I guess and tls is shipped with debs -- anyhow, tls is a module in sr, the core is the same.
Cheers, Daniel
On 23-06 13:32, Daniel-Constantin Mierla wrote:
On 06/23/2009 01:18 PM, Henning Westerholt wrote:
On Dienstag, 23. Juni 2009, Iñaki Baz Castillo wrote:
2009/6/23 Jan Janak jan@iptel.org:
and I have seen more such reports. Openssl received lots of speed optimizations over time, unlike gnutls.
So, is it ok if I change the dependencies in Kamailio to require libcurl4-openssl-dev instead of libcurl4-gnutls-dev?
Hi Iñaki,
this would mean that the utils module can't be packaged with (official) debian anymore, as the licence of openssl don't allow it. This is basically the same problem as with the tls support, which is disabled in the debian package as well.
is it inherited in this case? the tls implementation in core of kamailio is binding directly to openssl library and therefore need for the gpl disclaimer, but in this case utils binds to curl library.
In sip router this is fixed I guess and tls is shipped with debs -- anyhow, tls is a module in sr, the core is the same.
If I understand it correctly, we are talking here about Debian control files that are being kept in the git repository, right? But aren't those files intended for people who want to build Debian packages themselves, rather than for official Debian developers? As far as I know official Debian developers maintain their control files elsewhere, and in fact it is recommended that upstream projects do not provide their own control files.
If this is the case, does it really matter if we keep libcurl4-openssl-dev in our control files? We know that all the stuff should work (at least was developed with) with openssl, so shouldn't this be the default for the people who attempt to build the packages themselves?
Also note that the -dev packages are only needed to actually build packages, they are not needed at runtime. They only contain files that are needed to compile applications that use libcurl. Corresponding runtime libraries are in libcurl3 (openssl version) and libcurl3-gnutls (gnutls version) and these can be installed at the same time. What this means is that it is not possible to *compile* applications for use with libcurl-openssl and libcurl-gnutls at the same time.
Jan.
2009/6/23 Jan Janak jan@iptel.org:
If I understand it correctly, we are talking here about Debian control files that are being kept in the git repository, right? But aren't those files intended for people who want to build Debian packages themselves, rather than for official Debian developers? As far as I know official Debian developers maintain their control files elsewhere, and in fact it is recommended that upstream projects do not provide their own control files.
I was thinking exactly the same. The debian files in SR repository are intended to build DEB packages, nothing related to Debian official repositories.
If Debian wants to provide official SR packages, them they could choose to use the GnuTLs version instead (by creating their own "control" file).
If this is the case, does it really matter if we keep libcurl4-openssl-dev in our control files? We know that all the stuff should work (at least was developed with) with openssl, so shouldn't this be the default for the people who attempt to build the packages themselves?
100% agree.
2009/6/23 Iñaki Baz Castillo ibc@aliax.net:
If Debian wants to provide official SR packages, them they could choose to use the GnuTLs version instead (by creating their own "control" file).
ops, my mistake. The *already* compiled DEB packages don't require de -dev packages, of course, but just the runtime libraries (libcurl3 or libcurl3-gnutls).
Some questions:
- If the deb package is compiled with libcurl4-openssl-dev, could the deb package itself require libcurl3-gnutls instead of libcurl3? Would it work?
- If there any licence issue if a DEB package requires libcurl3 (OpenSSL)?
- If there any licence issue if an *official* DEB package is compiled with libcurl4-openssl-dev instead of libcurl4-gnutls-dev?
On 23-06 14:54, Iñaki Baz Castillo wrote:
2009/6/23 Iñaki Baz Castillo ibc@aliax.net:
If Debian wants to provide official SR packages, them they could choose to use the GnuTLs version instead (by creating their own "control" file).
ops, my mistake. The *already* compiled DEB packages don't require de -dev packages, of course, but just the runtime libraries (libcurl3 or libcurl3-gnutls).
Some questions:
- If the deb package is compiled with libcurl4-openssl-dev, could the
deb package itself require libcurl3-gnutls instead of libcurl3? Would it work?
No, the binary package will depend on libcurl3-gnutls and libgnutls.
- If there any licence issue if a DEB package requires libcurl3 (OpenSSL)?
The OpenSSL license contains a clause which, according to the FSF, is incompatible with GPL. (The clause requires certain text to be present in all material). Thus GPL software, such as SER/Kamailio/sip-router, build with openssl is not GPL compatible anymore.
The solution suggested by the OpenSSL project is to add an exception to the license which explicitly permits to use the sofware with OpenSSL. This kind of change needs to be approved by all (c) holders. In our case we would need to get the approval from *all* contributors to both projects, which is probably not feasible. IANAL but this applies to the whole source tree, not just selected modules that use openssl.
To me this looks like a catch-22 situation more than a real licensing issue. The OpenSSL license requires that extra acknowledgement in all documents and according to FSF this make the license more restrictive than GPL itself.
So, a .deb package of ser/kamailio/sr build with OpenSSL is not GPL compatible anymore and this violates the license of the project if such package is distributed.
I seriously doubt that we could find a single (c)-owner in both projects who would be opposed to adding the exception to the license, so in my opinion the problem is purely procedural--it is difficult to make a list of all contributors and approach them individually.
- If there any licence issue if an *official* DEB package is compiled
with libcurl4-openssl-dev instead of libcurl4-gnutls-dev?
Opinions differ on this, but Debian people think so. By distributing binary packages of GPL software linked with openssl (and without the exception in the license) they are afraid that they would violate the terms of GPL. Debian probably wants to stay on the safe side, which is understandable given the sheer volume of software they distribute.
Jan.
PS: IANAL so do not trust a single word I just wrote.
On 23-06 15:40, Jan Janak wrote:
On 23-06 14:54, Iñaki Baz Castillo wrote:
2009/6/23 Iñaki Baz Castillo ibc@aliax.net:
If Debian wants to provide official SR packages, them they could choose to use the GnuTLs version instead (by creating their own "control" file).
ops, my mistake. The *already* compiled DEB packages don't require de -dev packages, of course, but just the runtime libraries (libcurl3 or libcurl3-gnutls).
Some questions:
- If the deb package is compiled with libcurl4-openssl-dev, could the
deb package itself require libcurl3-gnutls instead of libcurl3? Would it work?
No, the binary package will depend on libcurl3-gnutls and libgnutls.
Errata: The other way around (libcurl3 and libssl).
sorry, Jan.
El Martes, 23 de Junio de 2009, Jan Janak escribió:
So, a .deb package of ser/kamailio/sr build with OpenSSL is not GPL compatible anymore and this violates the license of the project if such package is distributed.
However, the deb packages generated by "make deb" are not necessarily those to be deitributed by Debian, rigth?
So we can use OpenSSL in our deb packages and Debian (or Alioth) could recompile the packages with GnuTLS in order to provide them in their public repositories.
2009/6/23 Juha Heinanen jh@tutpro.com:
Iñaki Baz Castillo writes:
> So, is it ok if I change the dependencies in Kamailio to require > libcurl4-openssl-dev instead of libcurl4-gnutls-dev?
fine with me,
I've changed the dependencies in kamailio trunk version (local copy) and it compiles fine. So, if there is no inconvenient I will commit it.
However, I've realized that the Debian control file says:
Maintainer: Debian VoIP Team pkg-voip-maintainers@lists.alioth.debian.org Uploaders: Kilian Krause kilian@debian.org
Perhaps we should change these values and use some "internal" name (as "Kamailio Developers Team")? And when the packages become Debian "official" packages (or those mantained by Alioth) they could rename de Mantainer and Uploaders, and could also change the dependencies not to use OpenSSL.
-
Daniel-Constantin Mierla -
Henning Westerholt -
Iñaki Baz Castillo -
Jan Janak -
jh＠tutpro.com -
Klaus Darilion