Mailing List Archive

Feedback Requested: Dual-Licensing rsyslog
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
Feedback Requested: Dual-Licensing rsyslog [ In reply to ]
2008/2/20, Rainer Gerhards <rgerhards at hq.adiscon.com>:
> Hi all,

>
> Feedback, please...

Tbh, I have mixed feelings about that.
First of all, I have to say, that I'm not a lawyer, do don't take my
words for granted.
But as the original source code is licensed under the GPL (at least
parts of it like klogd and pidfile.c), and is copyright of the
original authors, you can't just relicense it.
You'd have to ask the original authors for permission.
Second, I don't think that simply providing a wiki page, stating that
for all contributions the copyright is automatically transferred to
adiscon is legally effective. You definitely have to ask a lawyer for
clarification here.
For dual-licensed projects I know, like e.g. Qt, I know that they
don't/can't accept contributions (afaik even simple bug fixes) without
such a waiver. That's a major pain.
As a result (at least from my experience), many people avoid to
contribute to such dual-licensed projects.
If you take Qt or MySQL again, you'll see that they are almost 100%
developed by the company itself. The flow of external contributions is
very little.
If you remember the latest discussion on the debian-devel mailing
list, you will remember that the current license of rsyslog was
mentioned as a definite advantage over syslog-ng.

Imho the acceptance and the participation in the community will be
higher if rsyslog stayed a gpl only project. Again, this is only my
personal opinion and I very much understand your urge to generate
revenue for your company.

An idea, which I would prefer over dual-licensing the complete rsyslog
project, is to provide enterprise level plugins under a commercial or
dual-license only and generate revenue from those plugins.
Evolution (mail and pim application) is such an example, where the
project itself is GPL, but the exchange connector (realised via
plugins) is commercial.

HTH,
Michael

--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Feedback Requested: Dual-Licensing rsyslog [ In reply to ]
Hi Michael and all,

thanks for the feedback, much appreciated. At first, please let me
re-iterate that I honestly seek such feedback and nobody (at least over
here) has made up his mind ;)

So...
> > Feedback, please...
>
> Tbh, I have mixed feelings about that.
> First of all, I have to say, that I'm not a lawyer, do don't take my
> words for granted.
> But as the original source code is licensed under the GPL (at least
> parts of it like klogd and pidfile.c), and is copyright of the
> original authors, you can't just relicense it.
> You'd have to ask the original authors for permission.

I missed to explain this: of course, the original source can not be
relicensed. What I am most concerned about is new code and especially
code that I intend to pull from Adiscon's closed source projects. Things
like the queue w/ worker pool and the upcoming RFC 3195 part.

> Second, I don't think that simply providing a wiki page, stating that
> for all contributions the copyright is automatically transferred to
> adiscon is legally effective. You definitely have to ask a lawyer for
> clarification here.
> For dual-licensed projects I know, like e.g. Qt, I know that they
> don't/can't accept contributions (afaik even simple bug fixes) without
> such a waiver. That's a major pain.

I fully agree. I'll try to get a clarification. If we need a written
waiver, that's a no-go.

> As a result (at least from my experience), many people avoid to
> contribute to such dual-licensed projects.
> If you take Qt or MySQL again, you'll see that they are almost 100%
> developed by the company itself. The flow of external contributions is
> very little.
> If you remember the latest discussion on the debian-devel mailing
> list, you will remember that the current license of rsyslog was
> mentioned as a definite advantage over syslog-ng.

Yes, and that's one of the reasons I would like to discuss it *in depth*
before any move is made :)

> Imho the acceptance and the participation in the community will be
> higher if rsyslog stayed a gpl only project. Again, this is only my
> personal opinion and I very much understand your urge to generate
> revenue for your company.
>
> An idea, which I would prefer over dual-licensing the complete rsyslog
> project, is to provide enterprise level plugins under a commercial or
> dual-license only and generate revenue from those plugins.
> Evolution (mail and pim application) is such an example, where the
> project itself is GPL, but the exchange connector (realised via
> plugins) is commercial.

This idea is interesting. Thank to the design, we are quite modular. And
will become even more modular. Actually, *every* object will soon be
(automatically, relax ;)) be loadable. When I am done with basic
expressions, I'll take a deep look at this as part of loadable function
support. I already have a lot of pieces on my mind, just need to pull
them together.

So I could take e.g. the RFC 3195 code and offer *just it*
dual-licensed. Then, we need the painful waiver only for these parts.
Doable. But I have to admit I don't like it. I agree it is probably the
best approach to circumvent problems. But on first look it stinks ;) If
dual-licensing causes grief to the project, it doesn't feel right to let
it cause grief to some parts of the project. And the sample is a
well-chosen one: the BEEP (3195) support will probably become *the*
cornerstone in rsyslog protocol support (that's the reason I go for it).
So does it sound good to make it a second-class citizen? Mmmmhhh... Of
course, I also need to discuss internally. But I'd prefer to keep
rsyslog components under a single license - even if that means we need
to put everything under GPLv3 only. Or am I going overboard here? Please
comment.

>
> HTH

Indeed, it does. :)

Rainer