User: Password:
Subscribe / Log in / New account


A licensing change for syslog-ng

August 31, 2010

This article was contributed by Robert Fekete

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.


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.

Comments (17 posted)

Brief items

Chromium Graphics Overhaul (The Chromium Blog)

The Chromium blog reports on some developments in graphics handling in the free Google Chrome-based browser. The intent is to speed up graphics rendering by taking advantage of the GPU. "At its core, this graphics work relies on a new process (yes, another one) called the GPU process. The GPU process accepts graphics commands from the renderer process and pushes them to OpenGL or Direct3D (via ANGLE). Normally, renderer processes wouldn’t be able to access these APIs, so the GPU process runs in a modified sandbox. Creating a specialized process like this allows Chromium’s sandbox to continue to contain as much as possbile: the renderer process is still unable to access the system’s graphics APIs, and the GPU process contains less logic."

Comments (10 posted)

An overdue update from the Diaspora team

The Diaspora team has put out an update on their progress in creating a "privacy aware, personally controlled, do-it-all, open source social network". The project raised a fairly large sum of money to fund its efforts, and now it is reporting back. "We are spending a good chunk of time concentrating on building clear, contextual sharing. That means an intuitive way for users to decide, and not notice deciding, what content goes to their coworkers and what goes to their drinking buddies. We know that’s a hard UI problem and we take it seriously. The publicity and money that you have given us has let us work with great designers like Janice Frasier, through her new program LUXr, whose constant reminders that we are not the user have kept us honest and focused. Pivotal Labs has also helped us prioritize, and we have pushed back more technical features like plugins and APIs in favor of simple and high value features."

Comments (41 posted)

KDE SC 4.5.1 Released

KDE has updated the Applications, Platform and Plasma Workspaces to 4.5.1. "This release will make 4.5 users life more pleasant by adding a number of important bugfixes, bringing more stability and better functionality to the Plasma Desktop, and many applications and utilities."

Full Story (comments: none)

Nanny 2.30.0 released

The first stable version (2.30.0) of the Nanny filter for parents who wish to restrict their children's access to the computer has been released. "Nanny is an easy way to control what your kids are doing in the computer. You can limit how much time a day each one of them is browsing the web, chatting or doing email. You can also decide at which times of the day [they] can do this things."

Full Story (comments: none)

NumPy 1.5.0 release

Version 1.5.0 of NumPy, a package for scientific computing in Python, has been released. This is the first release that is Python 3 compatible, though the testing framework relies on nose, which does not yet have a Python 3 compatible release (though there is a development branch).

Full Story (comments: none)

PostgreSQL 9.0 Release Candidate 1

The first release candidate for PostgreSQL 9.0 is available for testing. "No changes in commands, interfaces or APIs are expected between this release candidate and the final version. Applications which will deploy on 9.0 can and should test against 9.0rc1. Depending on bug reports, there may or may not be more release candidates before the final release."

Full Story (comments: 15)

Newsletters and articles

Development newsletters from the last week

Comments (none posted)

GNOME Journal Issue 21 released

Issue 21 of the GNOME Journal is out; topics covered include simple real-time games, Grilo, and an interview with Bradley Kuhn.

Full Story (comments: 1)

Callaway: The long, sordid tale of Sun RPC, abbreviated somewhat, to protect the [guilty] and the irresponsible

Fedora engineering manager Tom "spot" Callaway closes the book on a multi-year effort to relicense Sun's RPC code. The license, which was originally released with the code in 1984—before there were free software licenses—had distribution restrictions that made it clearly non-free. Debian noticed it first in 2002 and Fedora started working on the problem in 2005. "So, we restarted the effort with Oracle, and on August 18, 2010, Wim Coekaerts, on behalf of Oracle America, gave permission for the remaining files that we knew about under the Sun RPC license (netkit-rusers, krb5, and glibc) to be relicensed under the 3 clause BSD license."

Comments (24 posted)

Kügler: Demystifying Akonadi

KDE hacker Sebastian Kügler writes about Akonadi on his blog. In the article, he describes Akonadi, looks at its current status, and its future. "Akonadi is a groupware cache that runs on the local machine, a shared data store for all your personal [information]. Akonadi offers a unified API to receive and synchronise data with groupware, email servers or other online services. Agents called "resources" are responsible for communicating with the remote service, say your email server. These resources run out-of-process and communicate via separate control and data channels with the mothership (your local Akonadi). Resources are easy to implement and can interface any data source with Akonadi, be it your local calendar file, your companies groupware, email servers or address directories, or anything else you can come up with. More on that specifically later."

Comments (2 posted)

Page editor: Jonathan Corbet
Next page: Announcements>>

Copyright © 2010, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds