Re: [Bacula-users] Request for help

Hello,

Why are you calling me Mr. Radoslaw?

2015-02-12 12:46 GMT+01:00 Heitor Faria <heitor AT bacula.com DOT br>:

However, MOST of the code developed by Bacula Enterprise are in the form of Plugins (Vmware, Databases, etc.) (...) that CAN'T be considered derivations / modifications of the original Bacula Source code.

Bacula plugins are derived work of Bacula code. Please read my discussion with Kern about 2010 when I start developing a PostgreSQL plugin for Bacula:

Kern Sibbald:
"(...)
There are varying opinions on whether or not a plugin is a derived work or
not, but it is and has always been the opinion of the FSFE that a shared
object (as is the case for Bacula plugins) is a derived work, which means
that it must have the same license (or at least one that is compatible).
Hello Mr. Radoslaw: This is more a political / philosofical opinion from FSFE, but its not law technically right.

There was a huge discussion on the LKML if kernel modules could be licensed other then GPLv2 (the main Linux kernel license). The conclusion was they could take a different license only when modules do not use exported GPL licensed symbols (EXPORT_SYMBOL_GPL). Kernel modules from technical point of view are the same as Bacula plugins.

The most important is a linking which connects a GPL licensed code with another one. To compile a plugin you need a few include header files which define plugin API. Without it you are unable to make a plugin. It is not a law it is a technical issue.

If you are unsure, just ask Kern as I did in the 2010. Then I've got an answer quoted above.

I personally am probably a bit more open to different possibilities, but I
firmly believe that if you are extending Bacula with a plugin, you should
give back to the community by providing it with your source code.
(...)"
This was probably an option from a Bacula community developer.

Quoted above are opinion of the main Bacula author and developer - Kern Sibbald.

So, I extended a Bacula with a plugin and released it with AGPLv3 license. Releasing a plugin with a different license is a bit complicated because Bacula allow plugins with a specific licenses only:

fd_plugins.c:1160:

if (strcmp(info->plugin_license, "Bacula AGPLv3") != 0 &&
strcmp(info->plugin_license, "AGPLv3") != 0) {
Jmsg(NULL, M_ERROR, 0, _("Plugin license incompatible. Plugin=%s license=%s\n"),
plugin->file, info->plugin_license);

I'm not talking here about Bacula Enterprise because it has a different license.

best regards
--
Radosław Korzeniewski
What is the definition of derived work? They are *transformations* from a original work, like rearrangements, instrumentation, presentation, translation etc.

No! I disagree! To make a derived work you do not need to transform/change/rearrange/etc. the original. I can use 100% the original code in my application which become a derived work.

We can't say that plugins are derived work, since there is a division between Bacula core original code and the plugin code.

No! There is not! The glue code are at least a header files and linking. Bacula uses a lot of own implementation of a dozen of standard library functions like malloc, snprintf, etc. When you make a plugin you are forced to use a Bacula implementation of these functions. Without it you will be in trouble to make things work. I know what I'm talking about.

In fact there is not even GPL plugins (that I know) similar to the ones Bacula Enterprise provide, so we could no even argue that they are not original code.

I do not understand what do you mean. Sorry.

A question for every one: if plugins needed to hold the same license that the core application code, what about the RunBefore / After job scripts? Aren't they original work? Are they code?

Are you kidding me? Any application/program/script executed with RunBefore/After job parameter are in every bit different from plugin. First thing plugin require linking to the Bacula binary code but external applications in RunBefore/After job parameters are not - they are run with exec() system call. Plugins share an application memory space with Bacula binary code, exec()'uted applications own a separate address space.

IMHO the license is the *law* for the application, and this law can't embrace every of its accessories (3rd party libraries, plugins, scripts etc.),because we would be going into a rights deadlock / inferno / rights instability. Of course, there is a limit.

The law is a license - GPL do not allow to make a derived work which is not GPL licensed. This feature make any library usage very limited. This is a reason LGPL comes from. LGPL in opposite to GPL allow to link and use of the library in the same address space of non-GPL application securing any modifications to the library itself LGPL licensed.

And finally I do agree with you that plugins should be available with any license and current policy is very restrictive. But you are wrong, current Bacula code and license do not allow to use non AGPLv3 licensed plugins.

best regards

Radosław Korzeniewski
radoslaw AT korzeniewski DOT net

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/

_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users