Hi all,
I have had a couple of discussions with a lot of folks in the past days.
During them, an idea was born that I would now like to present to the
broader audience here on the list:
We consider dual-licensing rsyslog, just like e.g. MySQL is dual
licensed. Nothing is yet finalized and I honestly request feedback on
that idea. Please let me explain...
What would it mean?
For open source users, nothing at all changes. Rsyslog would still be
licensed under GPL. However, the proposal would give us the option to
release certain parts under GPLv2 (remember rsyslog v3 and above are
licensed under GPLv3). While we did not yet consider this option, it has
been brought to our attention that libmysqlclient is licensed GPLv2 only
and as such cannot be linked to a GPLv3 program (the ommysql plugin). I
currently try to sort this out and have contacted MySQL, but
unfortunately did not yet receive a reply. Should that become a real
issue, we can either drop MySQL support or we can move the affected part
to GPLv2. Thanks to the plugin architecture, the main executable is not
affected, so it would be a matter of changing the license on the MySQL
plugin (which is in all respects a separate project just combined in the
main tarball for convenience - long term users know that it once was a
separate project ... and very inconvenient to handle ;)).
When it comes to commercial applications, there *is* a change.
Dual-licensing would enable us to provide rsyslog technology under a
commercial license and thus add to the funding of the project. The most
important use case for this ability is probably Adiscon itself.
Remember: Adiscon sponsors rsyslog development. Actually, the funding is
currently almost exclusively provided by Adiscon's commercial software
sales in the Windows environment. Rsyslog has much evolved and its
object model is becoming more and more appealing in itself.
I now have been granted permission to include Adiscon's proprietary BEEP
stack (based on, but superior to liblogging) into rsyslog. This would
free the formerly closed source and make it available to the open source
community at large (under GPLv3). However, permission is granted only
under the condition that code improvements (and there will be a lot) can
be contributed back to Adiscon's commercial software. One way to do that
would be, of course, to create a separate project for these sources and
dual-license that from the beginning on. However, that sounds unnatural
and overly complicated to me. I would like to concentrate on writing the
greatest syslog technology on earth and not on circumventing license
restrictions...
Than I was told that a number of open source project successfully use
dual licensing and this is probably the best route to take.
What would it NOT mean?
Dual licensing rsyslog is NOT intended as a step to build different
editions of rsyslog, where some of them will become closed source and
only be available for a fee. It is both my and Adiscon's firm believe
that such a movement is plainly wrong and severely impacts an open
source project. This will not happen to rsyslog.
The intension of dual licensing it is to use (parts of) its technology
in commercial context's, not to make rsyslog in itself a product.
So, why bother?
If nothing really changes for the user base, why am I writing this long
mail? Well, first of all I would like to avoid everything that badly
affects the rsyslog project. So I ask for feedback if you see any
problems with this move.
Secondly, and more importantly, code contributors *are* affected. This
is another reason why I post on this list, where I reach almost all
contributors.
In order to dual license a work, one must be copyright holder of the
whole work. Thankfully, I have written most parts of the technology that
are interesting for dual licensing. However, there were a number of much
appreciated contributions (once again a big thank you to all who
contribute!). Even though there was no explicit license applied to any
of the contributions, I think it is a fair to assume they were meant to
be licensed under the same license rsyslog is. So we in fact have
multiple copyright holders. In support for dual licensing, we would need
to set up a policy that patch authors transfer their copyright to
Adiscon and me. I believe that a contribution policy is well enough to
do the trick. Specifically, I am a strong opponent of any copyright
transfer documents that need to be signed before I can integrate a
patch. Instead, I would setup a contribution policy page that states
that copyright is automatically been transferred by sending in a patch.
If I can't get away without it, I may send a link to this page after I
received a patch, but that would all that happened. And, of course, we
need to have permission from past contributors to use their patches
under this model - so if you have contributed and don't like the policy,
please reply so that I know it.
Feedback, please...
I honestly think that the ability to dual-license rsyslog brings benefit
to the long-term goals of rsyslog. Seeing other (big) open source
projects like MySQL using such a policy and succeeding in the community
makes me feel good about it. But, again, I would not like to cause any
troubles to the rsyslog project. So please reply if you don't like the
thoughts outlined here or if you have any concerns. Nothing is fixed
yet, but I'd like to get over it as soon as possible...
Please reply by private mail if you'd like not to express yourself on
the list.
Thanks a lot,
Rainer
I have had a couple of discussions with a lot of folks in the past days.
During them, an idea was born that I would now like to present to the
broader audience here on the list:
We consider dual-licensing rsyslog, just like e.g. MySQL is dual
licensed. Nothing is yet finalized and I honestly request feedback on
that idea. Please let me explain...
What would it mean?
For open source users, nothing at all changes. Rsyslog would still be
licensed under GPL. However, the proposal would give us the option to
release certain parts under GPLv2 (remember rsyslog v3 and above are
licensed under GPLv3). While we did not yet consider this option, it has
been brought to our attention that libmysqlclient is licensed GPLv2 only
and as such cannot be linked to a GPLv3 program (the ommysql plugin). I
currently try to sort this out and have contacted MySQL, but
unfortunately did not yet receive a reply. Should that become a real
issue, we can either drop MySQL support or we can move the affected part
to GPLv2. Thanks to the plugin architecture, the main executable is not
affected, so it would be a matter of changing the license on the MySQL
plugin (which is in all respects a separate project just combined in the
main tarball for convenience - long term users know that it once was a
separate project ... and very inconvenient to handle ;)).
When it comes to commercial applications, there *is* a change.
Dual-licensing would enable us to provide rsyslog technology under a
commercial license and thus add to the funding of the project. The most
important use case for this ability is probably Adiscon itself.
Remember: Adiscon sponsors rsyslog development. Actually, the funding is
currently almost exclusively provided by Adiscon's commercial software
sales in the Windows environment. Rsyslog has much evolved and its
object model is becoming more and more appealing in itself.
I now have been granted permission to include Adiscon's proprietary BEEP
stack (based on, but superior to liblogging) into rsyslog. This would
free the formerly closed source and make it available to the open source
community at large (under GPLv3). However, permission is granted only
under the condition that code improvements (and there will be a lot) can
be contributed back to Adiscon's commercial software. One way to do that
would be, of course, to create a separate project for these sources and
dual-license that from the beginning on. However, that sounds unnatural
and overly complicated to me. I would like to concentrate on writing the
greatest syslog technology on earth and not on circumventing license
restrictions...
Than I was told that a number of open source project successfully use
dual licensing and this is probably the best route to take.
What would it NOT mean?
Dual licensing rsyslog is NOT intended as a step to build different
editions of rsyslog, where some of them will become closed source and
only be available for a fee. It is both my and Adiscon's firm believe
that such a movement is plainly wrong and severely impacts an open
source project. This will not happen to rsyslog.
The intension of dual licensing it is to use (parts of) its technology
in commercial context's, not to make rsyslog in itself a product.
So, why bother?
If nothing really changes for the user base, why am I writing this long
mail? Well, first of all I would like to avoid everything that badly
affects the rsyslog project. So I ask for feedback if you see any
problems with this move.
Secondly, and more importantly, code contributors *are* affected. This
is another reason why I post on this list, where I reach almost all
contributors.
In order to dual license a work, one must be copyright holder of the
whole work. Thankfully, I have written most parts of the technology that
are interesting for dual licensing. However, there were a number of much
appreciated contributions (once again a big thank you to all who
contribute!). Even though there was no explicit license applied to any
of the contributions, I think it is a fair to assume they were meant to
be licensed under the same license rsyslog is. So we in fact have
multiple copyright holders. In support for dual licensing, we would need
to set up a policy that patch authors transfer their copyright to
Adiscon and me. I believe that a contribution policy is well enough to
do the trick. Specifically, I am a strong opponent of any copyright
transfer documents that need to be signed before I can integrate a
patch. Instead, I would setup a contribution policy page that states
that copyright is automatically been transferred by sending in a patch.
If I can't get away without it, I may send a link to this page after I
received a patch, but that would all that happened. And, of course, we
need to have permission from past contributors to use their patches
under this model - so if you have contributed and don't like the policy,
please reply so that I know it.
Feedback, please...
I honestly think that the ability to dual-license rsyslog brings benefit
to the long-term goals of rsyslog. Seeing other (big) open source
projects like MySQL using such a policy and succeeding in the community
makes me feel good about it. But, again, I would not like to cause any
troubles to the rsyslog project. So please reply if you don't like the
thoughts outlined here or if you have any concerns. Nothing is fixed
yet, but I'd like to get over it as soon as possible...
Please reply by private mail if you'd like not to express yourself on
the list.
Thanks a lot,
Rainer