As regular readers know, there has been discussion on rsyslog‘s licensing model for quite some time, I guess much like the beginning of the project. Many things influence its licensing, community support and the ability to fund the project are among these. Over the years, we had several license changes, so things tend to evolve. The whole discussion was restarted in 2011 after the introduction of the systemd journal idea in November. A prime reason is that journald pushes rsyslog far more into the commercial-only space than we originally anticipated, as journald will probably push rsyslog out of many low-end systems (for details, see my original argument on rsyslog vs. journald, which I still support).
This lead to a lot of discussion with my peers at Adiscon. This resulted in a blog post on potential dual-licensing of rsyslog (to get the fine details, read that post, I don’t repeat them here; the post is still valid in regard to arguments and problems). That post, not unexpectedly, lead to a larger discussion on the rsyslog mailing list as well as quite some private conversations. In these discussions, some folks expressed they like an open core strategy more than dual licensing, while others expressed it right the other way around. Thankfully, some understanding for the need to fund the project was expressed as well ;-). Of course, no solution was reached and nothing was changed.
I have now taken the time to digest the discussion, Adiscon needs, and some overall trends. And I have briefly approached my peers at Adiscon as well as some contributors with a plan to go ahead in the most unintrusive way. So far, the idea was not killed (but also not discussed in-depth), so we may proceed with it. The core idea is that we must receive some funding for the work done. This is especially important in regard to the new environment that journald will create in the medium to long term. One thing that we learned during the past years is that commercial vendors are often hesitant to put GPLv3 code into their systems. Even larger key users slightly associated with software are hesitant (almost everyone falls into this category nowadays, think of embedded systems) for this reason. Ultimately, this somewhat blocks rsyslog’s use inside commercial entities. And by doing so, it also limits our funding opportunities because it is hard to sell support and services to someone who does not use the project.
To avoid this obstacle, the idea is to put a larger body of rsyslog under a more permissive license. Looking at current trends, the Apache Software License (ASL 2.0 to be precise) seems to be a good fit. Actually, one thing that Adiscon already decided is to put code written by Adiscon under this license. I have already converted some files after careful examination of contributors, original sources and development history (not a job I really like to spend time on, but…). We also hope to gain support by contributors to place all plugins under the ASL. In order to clean up licensing, it would also be useful (though somewhat optional) to put the rsyslog runtime, currently licensed under LGPLv3, under the ASL as well. We need to see how this works out with contributors, though (this is obviously the largest bunch of code). It is important to note that while LGPL is not “GPL-free” and may still cause some friction with our future primary user base, it is pretty similar to ASL in regard to what it permits. Having all runtime code under the ASL would probably help a bit with those “GPL-skeptic” enterprise customers.
Note that the ASL permits unlimited commercial use to anyone. I would still like to keep some leechers off the code (my original motivation to use GPLv3, among many others; my 2007 blog post on that is probably an interesting read in addition to this posting here – some things seem not to have worked out ;-)). My idea is to keep some files under GPLv3. This is not broadly discussed yet and details need to be worked out. Obviously, that would be counterproductive to what we intend to do with ASL 2.0. One could, however, optionally release these parts under a different license and thus somewhat “solve” the situation via relatively little modifications and different code. I agree, it boils down to some dual licensing, but in a smaller magnitude. Most importantly, everyone would be free to do his own implementation of the GPL parts and use the rest of rsyslog (the majority) with that freshly written code. [Please note that even though I changed some files to ASL, others are still under GPLv3, simply because I can not change licenses where Adiscon is not the sole copyright holder. So this is no indication that my idea is currently being implemented.]
In any case, if we mange to complete the re-licensing -with or without GPLv3 parts- everyone would be free to extend rsyslog with extra functionality. This obviously includes Adiscon as well. It would give us some extra funding opportunities, as we could create some plugins targeted at large commercial entities. One thing that immediately pops up my mind is a new queue subsystem (the queue driver is internally “plugin-ish”), which could integrate many of the improvements I have on my mind. While I would really love to write that beast, it is a considerable effort that Adiscon declines to fund and no other party has yet been willing to fund it either — but some expressed interest to provide limited financial support for it. If Adiscon could provide such a piece under a commercial license (at least for a while), I could probably persuade my peers to try this out and fund the effort. I honestly think this situation would be a win for everyone. With the current policies, it looks like this new subsystem will probably never materialize, so what is to lose? Highly specific input and output plugins also create similiar opportunity.
The ability to use commercial and non-commercial plugins is something that I always considered a valid use of rsyslog technology (see “writing rsyslog plugins” right at the bottom, under “licensing”). I just never cared to dig into the licensing implications, which make it somewhat hard to provide plugins under a GPL-incompatible license (contrary to what I originally intended). Note that in any case it would even be possible with a totally GPLv3 codebase (even if the rsyslog runtime would not be LGPL, what is is licensed under). The only difference is that with the current system, it would either require a creative interpretation of the GPL (something many open source software vendors have done before) or a somewhat technically inferior approach that avoids direct linking (using pipes, which is really not that bad, so it is a vital option and would probably be the one I’d choose). Again, with the intended re-licensing, we could remove some friction associated with “GPL-phobic” companies, thus increasing our funding abilities.
All in all, I think the proposal to re-license large parts of rsyslog under the Apache license is of benefit both the project as well as the community. It hopefully helps to provide the necessary funding for development and at the same time may even grow the community involvement as it becomes more attractive for other software vendors to participate in the rsyslog development (I found this article by Brian Proffitt a very interesting read in that regard; if you read it, be sure to follow its links for details). I would really appreciate if we could find support for this movement and, yes, I have to admit I consider it rather vital, especially with the new role rsyslog will play in the systemd dominated world. Let me conclude this posting with one more personal opinion: I think that any feature developed thanks to commercial licensing should immediately be available, for free, to non-commercial entities, like private parties, educational institutions and charities. For the same reasons, it should probably reside inside the public code repository and be free to explore by anyone.
PS: back in 2009, I wrote about my philosophy about the “free” in free and open source software. It may be worth a read in addition to this posting, as it probably explains some of the mindset behind my ideas.
UPDATE: This blog posting created some confusion if the rsyslog project will stay under GPLv3. In fact, it will! I wrote on new blog post clarifying the situation, please check it out.