freeradius and openssl exception
Hello all, I'm sorry in advance if this is something that has already been discussed to death. I have been googling around, and I do see some discussion about an openssl exception that took place in 2005, but I don't see any resolution, nor do I see any actual exception in COPYING. Is this something, first of all, that people are either interested in or amenable to? If so, has any progress been made? I ask all this because I recently took over comaintenance of the package for Debian, and there are several modules that we can't ship precompiled right now, as I understand it (eap being the most common, but for some reason postgres is also currently disabled - that needs seperate investigation). If no progress has been made, I would be willing to do some of the leg work sending around a sort of form email to contributors asking for an exception, or whatever you all thought was the best way of handling this. Of course, if you're not agreeable, I guess we just stop here - no hard feelings, but it means back to the drawing board for a gnutls solution or some shim layer. Take care, -- -------------------------------------------------------------------------- | Stephen Gran | Just because you're paranoid doesn't | | steve@lobefin.net | mean they AREN'T after you. | | http://www.lobefin.net/~steve | | --------------------------------------------------------------------------
Stephen Gran wrote:
I'm sorry in advance if this is something that has already been discussed to death.
Indeed, it was discussed many times. The OpenSSL advertising clause was also discussed a few months ago on the openssl-users mailing list, and it seems unlikely they'll ever change their licence. http://marc.theaimsgroup.com/?l=openssl-users&m=114460613316150&w=2
I have been googling around, and I do see some discussion about an openssl exception that took place in 2005, but I don't see any resolution, nor do I see any actual exception in COPYING. Is this something, first of all, that people are either interested in or amenable to? If so, has any progress been made?
In short: nothing has been done yet, but there's no strong objection to the exception. Speaking personally, I'd prefer a GnuTLS solution but I won't go against everybody else.
I ask all this because I recently took over comaintenance of the package for Debian, and there are several modules that we can't ship precompiled right now, as I understand it (eap being the most common, but for some reason postgres is also currently disabled - that needs seperate investigation).
The problem with the module rlm_sql_postgresql is the Debian package libpq4 depends on libssl. A user installing freeradius-postgresql also installs libssl through apt-get mechanism. $ apt-cache show libpq4 | grep Depends Depends: libc6 (>= 2.3.6-6), libcomerr2 (>= 1.33-3), libkrb53 (>= 1.4.2), libssl0.9.8 (>= 0.9.8b-1)
If no progress has been made, I would be willing to do some of the leg work sending around a sort of form email to contributors asking for an exception, or whatever you all thought was the best way of handling this.
The PostgreSQL project has a pending patch for GnuTLS support, but I don't know the status of this patch. (there is a problem with psqlODBC) http://archives.postgresql.org/pgsql-general/2006-04/msg00977.php When PostgreSQL completes their GnuTLS patch, it could be added as a dpatch in the postgresql source package, so the PostgreSQL client library doesn't depend on libssl anymore, and the freeradius-postgresql package can enter the Debian archive. -- Nicolas Baradakis
On Wed, Jul 26, 2006 at 03:55:55PM +0200, Nicolas Baradakis said:
Stephen Gran wrote:
I'm sorry in advance if this is something that has already been discussed to death.
Indeed, it was discussed many times.
The OpenSSL advertising clause was also discussed a few months ago on the openssl-users mailing list, and it seems unlikely they'll ever change their licence.
http://marc.theaimsgroup.com/?l=openssl-users&m=114460613316150&w=2
Thanks for the pointer. Sadly, apart from a fair amount of heat, that didn't seem to produce very much in the end.
I have been googling around, and I do see some discussion about an openssl exception that took place in 2005, but I don't see any resolution, nor do I see any actual exception in COPYING. Is this something, first of all, that people are either interested in or amenable to? If so, has any progress been made?
In short: nothing has been done yet, but there's no strong objection to the exception.
Speaking personally, I'd prefer a GnuTLS solution but I won't go against everybody else.
Agreed. I do think that GnuTLS is weaker in some areas (slower, etc) but the licensing issues are easier.
I ask all this because I recently took over comaintenance of the package for Debian, and there are several modules that we can't ship precompiled right now, as I understand it (eap being the most common, but for some reason postgres is also currently disabled - that needs seperate investigation).
The problem with the module rlm_sql_postgresql is the Debian package libpq4 depends on libssl. A user installing freeradius-postgresql also installs libssl through apt-get mechanism.
Oh yes, I understand that - I just am not clear on why this instance of transitive linking is actually a problem. But that's not really an issue for discussion on freeradius-dev, I don't think.
When PostgreSQL completes their GnuTLS patch, it could be added as a dpatch in the postgresql source package, so the PostgreSQL client library doesn't depend on libssl anymore, and the freeradius-postgresql package can enter the Debian archive.
That would be nice. That still leaves us with the eap submodules that expect to use openssl directly, though. They are the ones that represent clear problems for binary redistribution, and can only really be solved within the freeradius project (well, or within the openssl community, but as you pointed out, that seems unlikely). So, what can I start on? Should I mail everyone who is listed as a contributor to a file that uses openssl directly? Should I do something else? I don't mind doing the work to make this happen, but as it's not a small task, I would appreciate a clear statement that the development group as a whole is in favor of something like this before spending a lot of time on it. Thanks all, -- -------------------------------------------------------------------------- | Stephen Gran | Coming together is a beginning; | | steve@lobefin.net | keeping together is progress; working | | http://www.lobefin.net/~steve | together is success. | --------------------------------------------------------------------------
Stephen Gran <steve@lobefin.net> wrote:
That would be nice. That still leaves us with the eap submodules that expect to use openssl directly, though. They are the ones that represent clear problems for binary redistribution, and can only really be solved within the freeradius project (well, or within the openssl community, but as you pointed out, that seems unlikely).
The copyright holders can do pretty much what they want with their software, including distributing binaries that others cannot. I suggest a debian apt repository on freeradius.org, containing nothing more than the modules in FreeRADIUS that link to OpenSSL. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Wed, Jul 26, 2006 at 12:36:00PM -0400, Alan DeKok said:
Stephen Gran <steve@lobefin.net> wrote:
That would be nice. That still leaves us with the eap submodules that expect to use openssl directly, though. They are the ones that represent clear problems for binary redistribution, and can only really be solved within the freeradius project (well, or within the openssl community, but as you pointed out, that seems unlikely).
The copyright holders can do pretty much what they want with their software, including distributing binaries that others cannot.
I suggest a debian apt repository on freeradius.org, containing nothing more than the modules in FreeRADIUS that link to OpenSSL.
If that seems like less work to maintain over time than getting an openssl exception granted, I'm sure I can automate something to do that. I think I would prefer a license exception in general, but I am not going to create a fuss over it if you are opposed or feel that it's too much overhead for some reason. Take care, -- -------------------------------------------------------------------------- | Stephen Gran | The mome rath isn't born that could | | steve@lobefin.net | outgrabe me. -- Nicol Williamson | | http://www.lobefin.net/~steve | | --------------------------------------------------------------------------
Stephen Gran wrote:
The problem with the module rlm_sql_postgresql is the Debian package libpq4 depends on libssl. A user installing freeradius-postgresql also installs libssl through apt-get mechanism.
Oh yes, I understand that - I just am not clear on why this instance of transitive linking is actually a problem. But that's not really an issue for discussion on freeradius-dev, I don't think.
It's an issue for debian-legal. http://lists.debian.org/debian-legal/2002/11/msg00253.html
When PostgreSQL completes their GnuTLS patch, it could be added as a dpatch in the postgresql source package, so the PostgreSQL client library doesn't depend on libssl anymore, and the freeradius-postgresql package can enter the Debian archive.
That would be nice. That still leaves us with the eap submodules that expect to use openssl directly, though. They are the ones that represent clear problems for binary redistribution, and can only really be solved within the freeradius project (well, or within the openssl community, but as you pointed out, that seems unlikely).
Concerning the eap submodules, I'm all for Alan's idea of an apt repository on freeradius.org. We are already maintaining the files under the debian directory between each releases, therefore there isn't much additional work. While we are at it, we can also provide the latest version of FreeRADIUS for the users running Debian Sarge. -- Nicolas Baradakis
On Wed, Jul 26, 2006 at 09:15:21PM +0200, Nicolas Baradakis said:
Stephen Gran wrote:
The problem with the module rlm_sql_postgresql is the Debian package libpq4 depends on libssl. A user installing freeradius-postgresql also installs libssl through apt-get mechanism.
Oh yes, I understand that - I just am not clear on why this instance of transitive linking is actually a problem. But that's not really an issue for discussion on freeradius-dev, I don't think.
It's an issue for debian-legal. http://lists.debian.org/debian-legal/2002/11/msg00253.html
Oh yes, I am aware of the arguments, thank you. I'm just not sure I agree with them. As I said, though, I don't really think this has anything to do with freeradius development. If you really want to have the conversation about why I think what about about transitive linking, we can have it via private mail or some list dedicated to tedious legalities. I don't think this is the place for it, though.
When PostgreSQL completes their GnuTLS patch, it could be added as a dpatch in the postgresql source package, so the PostgreSQL client library doesn't depend on libssl anymore, and the freeradius-postgresql package can enter the Debian archive.
That would be nice. That still leaves us with the eap submodules that expect to use openssl directly, though. They are the ones that represent clear problems for binary redistribution, and can only really be solved within the freeradius project (well, or within the openssl community, but as you pointed out, that seems unlikely).
Concerning the eap submodules, I'm all for Alan's idea of an apt repository on freeradius.org. We are already maintaining the files under the debian directory between each releases, therefore there isn't much additional work. While we are at it, we can also provide the latest version of FreeRADIUS for the users running Debian Sarge.
OK, just a quick question, though: is the core freeradius team the sole copyright holders? If so, binary redistribution is no problem, and it seems reasonable. It would also probably be reasonably trivial to just grant an excemption if that was the case, however. If you're not the sole copyright holders, of course, you'll need to ask for permission from the others, in which case we're in roughly the same place, aren't we? -- -------------------------------------------------------------------------- | Stephen Gran | Men of quality are not afraid of women | | steve@lobefin.net | for equality. | | http://www.lobefin.net/~steve | | --------------------------------------------------------------------------
Stephen Gran wrote:
OK, just a quick question, though: is the core freeradius team the sole copyright holders?
I think the answer is no because the FreeRADIUS source tree includes many patches from different people/organizations.
If you're not the sole copyright holders, of course, you'll need to ask for permission from the others, in which case we're in roughly the same place, aren't we?
I'm not qualified for legal questions, but it looks different to me. While the possibility is very low that someone will sue Debian for redistributing binary versions of the eap submodules, it just doesn't make sense that someone will contribute something to FreeRADIUS and afterwards prevent the distribution by the FreeRADIUS project itself. -- Nicolas Baradakis
participants (3)
-
Alan DeKok -
Nicolas Baradakis -
Stephen Gran