Hello,
Why are you calling me Mr. Radoslaw?
2015-02-12 12:46 GMT+01:00 Heitor Faria <hei...@bacula.com.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
rados...@korzeniewski.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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
