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. | --------------------------------------------------------------------------