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
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
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
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
/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.
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.
to post comments)