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. > > which is what I understood you to have written. > > > Bacula may be linked with any libraries permitted under the GPL, > > or with any non-GPLed libraries, including OpenSSL, that are > > required for its proper functioning, providing the license for said > > libraries is OpenSource as defined by OSI (i.e. the source code is > > freely available and can be modified). > > I understand this exception, I think it addresses the complicated nexus > of licenses you face very well. > > In our situation at OpenChange, we link very extensively to GPL (not > LGPL) Samba libraries. Samba has been GPLv2 or later, and recently > became GPLv3 or later. Samba has a very different set of constraints and > competitive environment to Bacula, and GPLv3 is what the Samba team have > chosen. That has nothing to do with OpenChange: we can't replace Samba > even if we wanted to, right now we're peddling hard just to solve > Exchange. > > However with OpenChange it is not impossible that one day another > provider of the underlying SMB services might come along to deliver what > we need client-side. We are very unlikely to stop linking to Samba (why > would we?) but it is feasible that we might start offering the option to > link to something else instead. An example project that, with some work, > might be able to do this is jCIFS. jCIFS is LGPLv2+, and potentially we > could start licensing OpenChange under both the GPLv3(or later) and the > LGPLv3(or later), or even something wildly different. > > My point is that *regardless* of anything we do with dual licensing and > exceptions, it is all moot until a replacement for Samba GPL libraries > appears. There is no chance of persuading the Samba team to adopt a > GPL-with-exceptions license, nor do I think in the particular case of > Samba that would be a wise move. > > > Were you to add something similar, it would probably solve the problem. > > It > > So, I hope I have been clear, I'm afraid there is no solution like this > that will solve the problem unless it also comes with man-years worth of > coding to replace Samba libraries. > > > might be a bit harder to write since in your case, you have libraries > > that would be included in other programs, and you probably don't want > > your code to > > ... and then as you rightly say, there is the downstream case. And how. > > > If you are interested in working on something, let me know, and I can > > probably come up with something that would allow Bacula an OpenChange > > to work together. In any case whatever clause I add to Bacula will be > > reviewed by FSFE (Free Software Foundation Europe) before it is > > included to ensure there is no loop hole in what I want to accomplish. > > I am very interested. Given the extra explanations above, do you now see > it any differently to me? 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. It looks like you are "screwed" by the GPL license as Bacula was. I spent several weeks rewriting the some 10 files copyrighted by others, and so now we have regained control of our license. However, it will take at *least* a month of testing to make sure it is stable again. It is sad to have first hand experience that Steve Palmer of Microsoft might have been right when he said that the "GPL is like a cancer". I don't really think it is that bad, but it makes me laugh when I think about it. In any case, the GPL has turned out to be far more restrictive of my rights than I ever imagined when I adopted it almost 6 years ago. I fear that GPLv3 will prove to be even more restrictive, which is why I hesitate to open our 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. Too bad Stallman didn't spend as much time worrying about Open Source developers rights as he did with Microsoft/SuSE and Tivo. Oh well. > > 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. Best regards, Kern ------------------------------------------------------------------------- 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
