Allow linking against OpenSSL? (Was Re: [GENERAL] Debian package for freeradius_postgresql module)
Greetings FreeRadius people, This discussion started on the postgresql's "pgsql-general" mailing list. The problem here is that the freeradius-postgresql package needs to link against libpgsql, which means that it may be indirectly linked against openssl. There is a conflict between OpenSSL's BSD license and the GPL which means that it's not legal to distribute a copy of GPL code that is linked in this way. It appears that several other GPL apps have added a special clause to their license that allows them to be linked against OpenSSL. Could this be done for freeradius/freeradius-postgresql as well? This could pave the way towards enhanced freeradius support in Debian, specifically the addition of freeradius-postgresql to Debian's mainline. For your reference, here is the start of the thread on the pgsql-general list that got us to this point: http://archives.postgresql.org/pgsql-general/2006-04/msg00247.php Thanks, Tyler Tom Lane <tgl@sss.pgh.pa.us> wrote:
I don't think so. I got curious and looked at what's on my Ubuntu system: Courier IMAP is GPL with an additional clause that explicitly allows linking with OpenSSL; Postfix has an Apache-ish license; Exim is GPL and also explicitly allows linking with OpenSSL; Cyrus IMAP is BSDish; Apache is non-GPL... I can't think offhand of anything that is GPL and links with OpenSSL without an explicit clause permitting same. Hm. So can we lobby freeradius to tweak their license similarly?
Tyler MacDonald <tyler@yi.org> wrote:
It appears that several other GPL apps have added a special clause to their license that allows them to be linked against OpenSSL.
Could this be done for freeradius/freeradius-postgresql as well?
I have no objection to that. Debian should at least be able to distribute their version of source packages, that will build binaries against the distributed binary packages. Alan DeKok.
Alan DeKok <aland@nitros9.org> wrote:
It appears that several other GPL apps have added a special clause to their license that allows them to be linked against OpenSSL.
Could this be done for freeradius/freeradius-postgresql as well?
I have no objection to that.
Debian should at least be able to distribute their version of source packages, that will build binaries against the distributed binary packages.
Alan DeKok.
Thanks Alan!!! Can we look forward to this clause in the next version of FreeRadius? Is the next version due to come out anytime soon? Thanks, Tyler
Tyler MacDonald <tyler@yi.org> wrote:
Thanks Alan!!! Can we look forward to this clause in the next version of FreeRadius? Is the next version due to come out anytime soon?
The developers have to discuss this, and we have to get buy-in from people, but I don't expect there's too much of a problem. As for the next release, it may be a month or so. Alan DeKok.
Tyler MacDonald wrote:
It appears that several other GPL apps have added a special clause to their license that allows them to be linked against OpenSSL.
Could this be done for freeradius/freeradius-postgresql as well?
Personally I really dislike the idea: FreeRADIUS code is released under the GPL and there is nothing wrong with that. I note there are many other ways to get a freeradius-postgresql package in Debian. - Ask Debian to provide a SSL-free package of the PostgreSQL libraries, so our freeradius-postgresql package can depend on that. - Add GnuTLS support to PostgreSQL (someone suggested to work on that in the "pgsql-general" mailing list) http://archives.postgresql.org/pgsql-general/2006-04/msg00367.php - Ask OpenSSL to remove the advertising clause from their license. I also note the current situation is really a minor problem for our users, because we're maintaining the necessary files to build the Debian packages in our CVS. Anybody can easily build a Debian package of the freeradius-postgresql module from a sources tarball with a single command line. (dpkg-buildpackage) -- Nicolas Baradakis
Nicolas Baradakis <nbk@sitadelle.com> wrote:
- Ask OpenSSL to remove the advertising clause from their license.
This is the most compelling alternative on your list, since this clause is the reason why all these other software packages have had to add special clauses to their own licenses. Has this been attempted before, I wonder...
I also note the current situation is really a minor problem for our users, because we're maintaining the necessary files to build the Debian packages in our CVS. Anybody can easily build a Debian package of the freeradius-postgresql module from a sources tarball with a single command line. (dpkg-buildpackage)
I agree that it's still trivial to get freeradius-postgresql *onto* a server, but I don't think that makes the problem minor. It requires that the user has development tools installed on their server, which is not the most secure thing to do. Either that, or they have to roll their own package on one system and upload it to their server and maintain that separately from the rest of their installation. This can have security implications too, since the end user will have to manually keep an eye out for security updates instead of just upgrading against security.debian.org. So you provide a way of debianizing freeradius packages easily, even ones that aren't included with debian. Given that, another alternative (admittedly with it's own set of problems) would be an official freeradius apt repository. Cheers, Tyler
Tyler MacDonald wrote:
This can have security implications too, since the end user will have to manually keep an eye out for security updates instead of just upgrading against security.debian.org.
In theory, you're right. In reality, FreeRADIUS has disclosed a security problem on 20 March and there's still no official Debian package available yet :( So finally if you really care about security you'd better build packages from sources anyway.
So you provide a way of debianizing freeradius packages easily, even ones that aren't included with debian. Given that, another alternative (admittedly with it's own set of problems) would be an official freeradius apt repository.
This doesn't solve anything. The problem is that such packages aren't distributable in binary form. If someone provides a repository, he becomes an outlaw. (exaggeratedly) -- Nicolas Baradakis
Nicolas Baradakis <nbk@sitadelle.com> wrote:
So you provide a way of debianizing freeradius packages easily, even ones that aren't included with debian. Given that, another alternative (admittedly with it's own set of problems) would be an official freeradius apt repository. This doesn't solve anything. The problem is that such packages aren't distributable in binary form. If someone provides a repository, he becomes an outlaw. (exaggeratedly)
*sigh* You're right. And I wouldn't want to suggest an "illegal" apt repo either (although I've used ones in the past, like one that provides a nice .deb full of win32 codec dlls for use with mplayer). It's rediculous that this is so simple to achieve technically, and all products involved are being provided for free, yet there's still all this beaurocratic red tape involved in getting them to play nice together... - Tyler
Tyler MacDonald wrote:
It's rediculous that this is so simple to achieve technically, and all products involved are being provided for free, yet there's still all this beaurocratic red tape involved in getting them to play nice together...
I understand very well, and I'd like to help Debian to achieve world domination, too. But I'm really wary of a license change. Alternatively, is it possible to leave the LICENSE file intact, and to write an OpenSSL exception as a side note in a different file? I think I'll have to do some research whether this is valid or not. (if someone knows of such an example, it'd help) -- Nicolas Baradakis
Nicolas Baradakis <nbk@sitadelle.com> wrote:
Personally I really dislike the idea: FreeRADIUS code is released under the GPL and there is nothing wrong with that.
You are right, there is nothing wrong with that. But is there anything wrong with the FreeRADIUS code released under the GPL with an additional clause allowing linking against OpenSSL, even as a temporary measure until either OpenSSL fixes it's license or PostgreSQL supports gnu TLS? I can't think of anybody or anything that would hurt, and it would have the immediate practical benefit of allowing the freeradius-postgresql package into the official debian repo. - Tyler
On 4/8/06, Tyler MacDonald <tyler@yi.org> wrote:
I can't think of anybody or anything that would hurt, and it would have the immediate practical benefit of allowing the freeradius-postgresql package into the official debian repo.
Beside the postgresql support, this also opens the door to peap/eap-tls enabled Debian FreeRadius packages. All those 802.1x Debian users currently have to build their own packages for this support (although that's really easy with Debian ready upstream source, as Nicolas mentioned earlier)
Jorgen Rosink wrote:
Beside the postgresql support, this also opens the door to peap/eap-tls enabled Debian FreeRadius packages. All those 802.1x Debian users currently have to build their own packages for this support (although that's really easy with Debian ready upstream source, as Nicolas mentioned earlier)
Indeed, these modules are a problem in Debian as well, for legal and technical reasons too: until version 1.1.1 I didn't manage to build rlm_eap_peap and rlm_eap_ttls properly. After the technical problems have been solved, we discussed the legal issues on the developpement mailing list a few weeks ago, and we planed to add support for GnuTLS, which is released under the LGPL. It will take more time to write source code than to edit the license, but I believe it's a better solution in the long term. -- Nicolas Baradakis
Tyler MacDonald wrote:
Personally I really dislike the idea: FreeRADIUS code is released under the GPL and there is nothing wrong with that.
You are right, there is nothing wrong with that. But is there anything wrong with the FreeRADIUS code released under the GPL with an additional clause allowing linking against OpenSSL, even as a temporary measure until either OpenSSL fixes it's license or PostgreSQL supports gnu TLS?
Well, I'm not in position to decide for a FreeRADIUS license change or not, I'm just manifesting my personal opinion. If the other developpers agree, I won't go against them, of course. However I believe it's better for FreeRADIUS to keep a plain GPL license (without any modification) because it simplifies any legal issue: - license violation with our code in another non-GPL software (it has already happened in the past) - adding contribution from an external company (they have questions concerning the license of the submitted material) Even if it's based on the GPL, a "FreeRADIUS license" is more confusing.
I can't think of anybody or anything that would hurt, and it would have the immediate practical benefit of allowing the freeradius-postgresql package into the official debian repo.
Altering the FreeRADIUS license will make only *one* package enter in the Debian repository. I'm not inclined to choose this solution while other solutions could solve the problem for *all* GPL programs depending on the PostgreSQL libraries. -- Nicolas Baradakis
Nicolas Baradakis <nbk@sitadelle.com> wrote:
I also note the current situation is really a minor problem for our users, because we're maintaining the necessary files to build the Debian packages in our CVS. Anybody can easily build a Debian package of the freeradius-postgresql module from a sources tarball with a single command line. (dpkg-buildpackage)
That does mitigate a lot of the problems. How about an additional idea: I don't think it's a problem for copyright owners to distribute binaries, so if we set up a mini apt system (say apt.freeradius.org), we could put problematic debian packages there. Alan DeKok.
Alan DeKok <aland@nitros9.org> wrote:
I also note the current situation is really a minor problem for our users, because we're maintaining the necessary files to build the Debian packages in our CVS. Anybody can easily build a Debian package of the freeradius-postgresql module from a sources tarball with a single command line. (dpkg-buildpackage) How about an additional idea: I don't think it's a problem for copyright owners to distribute binaries, so if we set up a mini apt system (say apt.freeradius.org), we could put problematic debian packages there.
According to a previous email from nick, you'd have to still put te license exemption in there to make that happen. Seems kinda odd that somebody could be liable for violating their own license... - Tyler
Tyler MacDonald <tyler@yi.org> wrote:
How about an additional idea: I don't think it's a problem for copyright owners to distribute binaries, so if we set up a mini apt system (say apt.freeradius.org), we could put problematic debian packages there.
According to a previous email from nick, you'd have to still put te license exemption in there to make that happen. Seems kinda odd that somebody could be liable for violating their own license...
Martijn van Oosterhout posted this topical URL to the PostgreSQL mailing list: http://www.gnome.org/~markmc/openssl-and-the-gpl.html Cheers, Tyler
Alan DeKok wrote:
How about an additional idea: I don't think it's a problem for copyright owners to distribute binaries, so if we set up a mini apt system (say apt.freeradius.org), we could put problematic debian packages there.
Perhaps it's fine if the copyright owners distribute the binaries themselves, I don't know. Aside the legal problem, I believe it's a great idea: we could provide an apt repository with the latest version of FreeRADIUS for Debian stable, testing and unstable. Indeed I think more people are installing Debian stable (Sarge) on a production server, but they get an old version of FreeRADIUS. (unless they compile it manually) Such a repository would help the Debian users to easily upgrade FreeRADIUS on their servers with the apt-get utility. -- Nicolas Baradakis
Nicolas Baradakis <nbk@sitadelle.com> wrote:
Perhaps it's fine if the copyright owners distribute the binaries themselves, I don't know.
Copyright owners can do whatever they want with their copyrighted material, including changing the copyright, or distributing the material in ways that are denied to others.
Aside the legal problem, I believe it's a great idea: we could provide an apt repository with the latest version of FreeRADIUS for Debian stable, testing and unstable.
Ok. Let's get it set up. If we go down that route, though, I'd like to make RPM's available, Solaris PKG's, etc. That involves some additional resources which might not be readily available. Alan DeKok.
Alan DeKok <aland@nitros9.org> wrote:
Nicolas Baradakis <nbk@sitadelle.com> wrote:
Perhaps it's fine if the copyright owners distribute the binaries themselves, I don't know.
Copyright owners can do whatever they want with their copyrighted material, including changing the copyright, or distributing the material in ways that are denied to others.
Aside the legal problem, I believe it's a great idea: we could provide an apt repository with the latest version of FreeRADIUS for Debian stable, testing and unstable.
Ok. Let's get it set up.
If we go down that route, though, I'd like to make RPM's available, Solaris PKG's, etc. That involves some additional resources which might not be readily available.
I've had my eye on this package, it may help: http://www.autobuild.org/ I think even if we do this, I'd like to see the FreeRadius license change to allow linking against OpenSSL, the OpenSSL license to change to allow linking against GPL, and the GPL license to change to allow linking against whatever. - Tyler
On Tue 11 Apr 2006 20:20, Alan DeKok wrote:
Nicolas Baradakis <nbk@sitadelle.com> wrote:
Perhaps it's fine if the copyright owners distribute the binaries themselves, I don't know.
Copyright owners can do whatever they want with their copyrighted material, including changing the copyright, or distributing the material in ways that are denied to others.
Aside the legal problem, I believe it's a great idea: we could provide an apt repository with the latest version of FreeRADIUS for Debian stable, testing and unstable.
Ok. Let's get it set up.
If we go down that route, though, I'd like to make RPM's available, Solaris PKG's, etc. That involves some additional resources which might not be readily available.
I already make RPMs available on a sporadic basic for SUSE. I had a red carpet repo setup also, but havent maintained it recently... -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
participants (5)
-
Alan DeKok -
Jorgen Rosink -
Nicolas Baradakis -
Peter Nixon -
Tyler MacDonald