On Thu, Mar 23, 2006 at 12:14:16PM -0500, Matthew Carpenter wrote: > On Thursday 23 March 2006 02:52, Paul TBBle Hampson wrote: >> The short answer is OpenSSL/GPL incompatibility, local build with a >> couple of small changes to the source (see the top of debian/rules) will >> solve it. > I'm afraid I don't understand why the OpenSSL and GPL licenses are an issue in > this case. FreeRadius is "based on" OpenSSL. OpenSSL is a BSD license, much > less restrictive than GPL. That's why BSD code ended up in Windows. So why > is the license and issue? OpenSSL's not under the BSD license, it's under the OpenSSL license, which is very similar to the problematic BSD four-clause license, which is known to be incompatible with the GPL, for example. You're thinking of the three-clause (no advertising clause) BSD license, which pretty much exists to allow interaction with the GPL. In short, the GPL forbids extra restrictions on distribution of GPL'd code beyond what the GPL contains. The BSD four-clause license adds an extra restriction, that you must include certain text in any advertising or feature-listing of the product. Anyway, how do you know BSD code ended up in Windows? Because the BSD four-clause license it was under (this is WinSock, right?) required that Microsoft advertise that they use it. On the other hand, there's no GPL'd code in Windows, or they'd be required to distribute the source code with it. ^_^ And of course Windows is considered an operating system, so you can use GPL'd code on Windows even though it depends on operating-system components not compatibly licensed, as long as the GPL'd code isn't part of the OS. (MS's licenses mean that this forbids Internet Explorer or Windows Media Player from containing GPL'd code, as they are part of the OS. But addon modules that depend on either (ie. using iBrower or iMediaPlayer controls) in GPL'd code is fine. You might find if you want to research further, "GPL considered harmful" may be enlightening. Also, the GPL vs OpenSSL license FAQ is specifically relevant. (or in fact FAQs, the FSF has one, the OpenSSL Project has one, and Debian uses another one [2]. Obviously in Debian we follow the Debian one's conclusions.) Of course, you've got to take everyone's conclusions with a grain or two of salt. The only thing that's actually reliable is the license itself, and clarifying public statements by the parties that don't conflict with the license itself. ie If you agree to a license that states the moon is made of cheese, (see clause 17 of the GPL) statements by the FSF that the moon is actually a hole in the sky through which one can see heaven have no legal standing. >> Now I look at it, I completely forgot the idea of doing a -src package >> for people to build... I'll throw that back in my TODO pile. > Thank you! I appreciate it! > Could you even put together an add-on package? Perhaps I'm just not grasping > the issue. I mean if Ubuntu can package up NVidia's 3d graphics driver, I'm > interested to hear what the issue is between two OSS licenses and Ubuntu > inclusion. (Then again, I guess I should ask if you even have anything to do > with the Ubuntu folks) I've nothing to do with the Ubuntu folks. I have a stack of 05.10 CDs on my desk to give to anyone who shows a vauge interest in Linux, but beyond that I've not done more than look around. (Never booted it myself. ^_^) Debian includes a copy in the non-free repository, in both binary and source forms. The copyright text in the Debian package (which I presume is replicated into the Ubuntu package) indicates that this is something nVidia want. So I'm not sure what issue you're getting at exactly. Either way, any issue with the nVidia drivers is different to this, since that's one, largely self-contained, piece of software. The kernel developers have specifically said that using their defined module interface doesn't require GPL-compatibility. Using other symbols from the kernel does, and those symbols aren't available to modules that do not declare themselves to be GPL'd. The issue here is that two licenses that affect the whole package have terms that are impossible to simultaneously fufill. This means that you have to pick one to fufill. With FreeRADIUS, if we don't fufill the OpenSSL license, we can't have EAP-TLS, EAP-PEAP, EAP-TTLS, SNMP agent support, or postgresql support. If we dont' fufill the GPL, we can't have the /usr/sbin/freeradius or any of the rlm_modules. (ie libradius itself is LGPL, if you want to use _it_ with OpenSSL of some kind... Mind you, I don't recall if the LGPL conflicts with OpenSSL, but I expect it does not.) The reason I can put together an add-on package is that the GPL (at least) applies all its restrictions to binary distributions. So I can distribute the GPL'd source, even though a binary produced from it will depend on OpenSSL and therefore be itself undistributable. The GPL's FAQ and clarifications points out that within one organisation it's not really "distribution", so you can use the source package once, publish the resulting .deb onto the internal-use packages repository, and you're golden. Or at least, that's the idea. ^_^ >> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=266229 > Thank you again. :) I'm CC'ing this to the bugreport for reference. I hope that's not a problem? Ideally, we'll have gnuTLS as an option sooner or later, anyway. ^_^ [2] http://www.gnome.org/~markmc/openssl-and-the-gpl.html -- ----------------------------------------------------------- Paul "TBBle" Hampson, BSc, MCSE On-hiatus Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)