A licensing change for syslog-ng

Many have criticized syslog-ng, a replacement for the syslog logging daemon with many additional features, for not being open enough. Syslog-ng has a closed-source commercial version and keeps the entire code base under a single copyright by requiring copyright transfer for contributions, which has been a sore spot in the eyes of many people. This may be part of the cause for syslog-ng failing to become the default system-logging daemon of modern Linux distributions. Now the project seeks to relieve these concerns and attract a wider contributor base with a new licensing model.

Over ten years ago, the development of syslog-ng started out as a purely GPL project, but required copyright transfer for contributed patches. Similar to other projects, for example MySQL, this aimed to keep the codebase under a single copyright, leaving the possibility open for future relicensing and proprietary versions.

For about eight years, syslog-ng was virtually a one-man show, maintained by its core developer Balázs Scheidler. This changed in 2006 when BalaBit — the company founded by Balázs originally for developing application-layer firewalls — decided to back the project and release a commercial version, syslog-ng Premium Edition. The model was to develop both versions in parallel and release additional features in the Premium Edition, which over time get released in the Open Source Edition as well.

Some of the original features of the commercial version, like logging to SQL databases or TLS-encrypted log transport have already been shifted to the open-source version. For others — like storing messages in encrypted and timestamped files, buffering messages on the client's hard disk during network outages, or the eventlog to syslog forwarding agent for Microsoft Windows platforms — that day has yet to come. Certain features like support for the new syslog protocol (RFC5424-28) appeared in both versions at the same time, while others were released in the Open Source Edition first.

With version 3.2 of syslog-ng Open Source Edition the project introduces significant changes in its licensing and its core framework. The monolithic codebase has been restructured into a core and a set of plugins, moving most of the functionality into plugins, with the core being the glue that keeps everything working. The core is licensed under the GNU Lesser General Public License (LGPL), while the plugins remain under the GNU General Public License (GPL) version 2.

Reasons and motives for the changes

The reasons for changing to a plugin-based architecture are both technical and administrative. For one, plugins make it easier to extend the functionality of syslog-ng, much easier than hacking the monolithic codebase of earlier versions, thus simplifying the life of contributors. Since copyright transfer is not required any longer, the project hopes to become more accessible to new developers.

In addition, distributions have differing requirements and policies on how system daemons access external libraries. For example, in openSUSE it is a much-debated problem that the system logging daemon — which is started early in the boot process — should not need access to the SSL libraries which only become available much later when the /usr partition is mounted. In syslog-ng 3.2 it is possible to start syslog-ng with limited functionality, and then reload it with additional plugins (like encrypted network destinations) at a later point.

Because of the dual licensing (and at the beginning to keep that possibility open), the syslog-ng project required contributors to transfer the copyright of their patches to BalaBit. That allowed the patches to be incorporated in both the open source and the commercial versions to keep the codebase of the two branches as close as possible to simplify the development process of both. Many would-be contributors did not like this idea, or simply found it overly bureaucratic. It even raised issues if the contributor created the patch as part of their work, as many companies do not have a policy to handle such situations, or simply refuse to sign contributory agreements. All of that discouraged many potential contributors from sending their patches upstream.

Also, the dual licensing of syslog-ng caused much controversy in open-source communities, and was one of the main reasons why Fedora — and subsequently most major Linux distributions — chose rsyslog when replacing syslogd. On the other hand, a significant portion of BalaBit's revenues comes from the commercial syslog-ng Premium Edition, landing BalaBit on Deloitte's regional lists of fastest-growing technology companies. Offering commercial support for the GPL version for many years did not produce the income that the commercial version generated in a year.

What all this means

The modularity of the new, plugin-based architecture and the license change boils down to the following consequences:

• The contributors retain the copyright of their patches, decreasing overall bureaucracy and making contribution easier.

• Anyone can develop and distribute open or proprietary plugins. Formerly BalaBit had exclusivity to develop a commercial version. Obviously proprietary plugins can link only to the LGPL syslog-ng core, and not to plugins licensed under the GPL.

Switching the license of the syslog-ng core to LGPL allows the project to use exactly the same core for the open source and commercial versions, and transfer the features of the Premium Edition to proprietary plugins, making the development and maintenance of both versions simpler and more reliable. Also, compared to many other mixed licensing models dealing with open-source and proprietary versions, BalaBit's approach is more open in the sense that it drops the exclusivity for proprietary plugins, now anyone is free to create such plugins.

Naturally, the license change does not fully address the concerns about whether the upstream syslog-ng project would accept patches for the open-source version that replicate the functionality of an existing proprietary plugin. However, the switch to the plugin-based architecture mitigates this problem as it makes it easy to develop and distribute plugins independently of the upstream version. For example, a Linux distribution could create plugins specifically tailored to its needs, and include them in its stock syslog-ng package — or a separate package if needed.

Other new features

Apart from the license change, syslog-ng Open Source Edition 3.2 introduces some other new features:

• To make configuring syslog-ng easier and more customizable, configuration snippets describing how to process the log messages of specific applications can be created and easily reused. For example, the syslog-ng configuration needed to read the logs of an application (e.g. Apache, Tomcat) can be stored in a central configuration library, and reused as needed.

• The syslog-ng application can automatically recognize the platform it is running on, and configure itself to collect platform-specific log messages. For example, it will read the default door file on Solaris, /dev/log on Linux and BSD, and so on. Potentially, this makes configuration management of syslog-ng easier, especially in environments that use many different operating systems.

• The new version of syslog-ng adds support for reading BSD-style process-accounting (pacct) log messages. Process accounting logs are stored in a binary file; this feature is an initial step to extend syslog-ng to read various non-syslog messages from binary files.

For a more detailed list, refer to this developer blog posting.

Conclusion

The syslog-ng project continues to grow as new features appear on a regular basis, making log collection and processing easier and more flexible. The new licensing model and the plugin-based architecture provide a range of opportunities for developers and contributors alike, and also increases the competition between system logging solutions, whether open-source or proprietary. As we have seen countless times, competition is good for users because it increases the range of possibilities to choose from.