On Friday 07 September 2007 16:03, Dan Shearer wrote: > On Fri, Sep 07, 2007 at 03:47:53PM +0200, Kern Sibbald wrote: > > On Friday 07 September 2007 15:04, Dan Shearer wrote: > > > On Fri, Sep 07, 2007 at 02:24:34PM +0200, Kern Sibbald wrote: > > > > From what you write, I'm not sure that you really understand the > > > > problem -- it > > > > > > I think (I hope) I understood the problem enough to focus on the one > > > bit > > > > > > that concerns me: > > > > Now, I am not immediately considering switching either to GPL (2 or > > > > later) or to v3 because I find it too hard to understand v3, and it > > > > does not resolve the problem with OpenSSL. My solution for Bacula > > > > will probably be: keep GPLv2, but add an exception, which I can do > > > > because it is all our own code -- no 3rd party GPL copyrights. The > > > > exception will be something like the following: > > > > > > Yes, this all makes sense. What I am suggesting is that you move to: > > > > > > GPLv2(or greater) plus an exception > > > > > > rather than > > > > > > GPLv2(only) plus an exception > > > > Well, I am not opposed to doing the above, but don't see any advantage. > > It doesn't allow us to use any more software than we currently do, and no > > one objects to GPLv2. > > If you do this you are offering your users the maximum amount of > futureproofing that you can. The reason is that GPLv2-only is > incompatible with GPLv3 code. I can't pretend to guess why that might be > important to Bacula in the future, but if you have the ability to give > your users extra leverage you might as well do so. When there is a good > reason to give away leverage, then of course do that as well. But since > you say "I am not opposed to doing the above" it seems you don't have a > reason. > > Make sense?
Well, as long as we have no 3rd party GPLed code in Bacula, which is what I am currently planning, we can always modify the license later. Currently there is zero downside that I can see to maintaining the license GPLv2. It doesn't restrict users from using GPLv3 code. There is no restriction on mixing any kind of software licenses, the restriction comes in distributing the code, and normally users are not going to distribute Bacula code with their own GPLv3 additions. > > > If you are using a bunch of code copyrighted by Samba, you are pretty > > much restricted to their licensing, and I don't see things any > > differently than you do. > > Right. So we'll continue to watch each other's projects > > > license to GPLv3. Note, even if our license were GPLv3 we could not use > > your code since the GPLed Samba code cannot be used with OpenSSL. Really > > sad. > > Well yes, except that as Simo pointed out OpenSSL is probably not what > your users want in terms of security, and the alternatives don't come > with clashing licenses. Other than speed issues, no user has complained about OpenSSL or asked to use some other code. We will look at using NSS though. Ignoring any possible license problems, like you with Samba code, the real problem is the time to implement NSS (I'll take a careful look at their compatibility interface). Basically, it is a BIG project that adds no new functionality for the user. For the current time, we need to focus on getting enterprise features into Bacula not changing encryption libraries. We started on the OpenSSL code before I understood the restrictive consequences of using GPL. Had I know at the time what I know now, things might have been different. > > > > As a minor technical point, it seems to me as a non-backup person that > > > having a plugin interface to call scripts for backup purposes is a good > > > idea? I can think of commandline tools on Windows, Unix, VMS and > > > several other operating systems where everything you want to do certain > > > operations already exists in a command (eg, dump permissions for all > > > files on a volume.) > > > > Yes, I think plugin capability is quite important, but it has not been > > voted very high by our users compared to other projects. We do have the > > ability to invoke a script at the beginning of a backup and at the end, > > which partially resolves the problem, but what we don't have is the > > ability to invoke a script on a file by file basis and to read from that > > script for backup or write to the script for a restore. > > Please give us a ping when you get around to implementing this. Yes, of course. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
