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? > 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. > > 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. -- Dan Shearer [EMAIL PROTECTED] _______________________________________________ devel mailing list [email protected] http://mailman.openchange.org/listinfo/devel
