Observium and GPL misconceptions


EDIT: As of 2013-10, I’ve started an Observium fork called LibreNMS.  This is just here for historical reference.

I recently started using Observium (a great network monitoring package which you should use), and found that I had some useful patches to contribute fairly soon afterwards.  I submitted a patch to enable bulk selection of checkboxes in JavaScript and it was initially rejected, in part because I included my own copyright header on a new file.

This started a discussion on the IRC channel during which numerous common misconceptions about the GNU GPL (the Free Software license under which Observium is released) were thrown around.  To summarise, these were the opinions given:

  1. Maintaining individual contributors’ copyright notices in a Free Software project is nonsense.
  2. The GPL is open source, but isn’t free.
  3. The GPL is not about the user, it’s about Richard Stallman wanting your code and not wanting anyone to use his.
  4. The GPL does not coexist with the LGPL.
  5. The GPL does not provide any benefits to the user of the software.
  6. The GPL is hypocritical; as it restricts the use of the free software it supposedly protects.
  7. The GPL is unclear and untested when it comes to linking restrictions.
  8. Free Software has more restrictions than commercial, closed source software.
  9. The GPLv3 and GPLv2 are incompatible and so cannot be used in the same software project.

Eventually the discussion degenerated into name-calling and personal insults.  (Unfortunately, I was denied permission to publish a copy of the relevant IRC logs so that the above summary could be independently verified.  I guess you’ll just have to take my word for it. 🙂

I will address some of the individual points above later, but I think most of them share a foundational assumption which drives most of the BSD-loving crowd’s fear of the GPL.  This assumption may be summed up as follows: the original author of a software package is the most important person or organisation in its existence.  (You may substitute “project leader”, “main copyright holder”, or similar in place of “original author” in the cases where a project is is active but no longer maintained by its original author.)

On this point there is no question: Adam Armstrong is much more important to Observium’s existence than I am.  But I think the question of licensing requires a little more nuance than simply assuming that the original author’s wishes trump everything.  One way of thinking about this is to compare the time investment by the original author and the other parties involved.  To do this, let’s think about some scenarios:


I don’t know how many hours Adam has spent on creating Observium, but I’m sure it was a substantial time investment.  Running a quick shell script over all the PHP, JavaScript, CSS, shell script, and SQL files in my copy of Observium (excluding the jpgraph, jquery, and overlib libraries) shows that there are over 45,000 lines of code in Observium r1957.  Assuming that the overall number of lines written since the beginning of the Observium project in 2006 is four times what is currently in the svn trunk (a total guess – if I cared to, I could get much closer to the real figure by processing the svn logs), this means that there were about 225,000 lines written over 4.5 years, or an average of over 136 lines per day.  Assuming those 136 lines took 2 hours to write (again, a total guess), this represents a total coding time investment of over 3200 hours over 4.5 years.  This figure does not include any time spent supporting the project, maintaining its infrastructure (e.g. web site, source code repository), or coordinating with other developers, but it does give a useful minimum figure.

Another major party with a significant time investment in Observium is its user base – the people who install it, configure it, and use it for monitoring real networks on a daily basis.  I have no way of knowing or even guessing how many such people there are, but let’s assume for the moment that my experience with Observium is roughly normal.  Over the past two months, I have installed it on an existing VM in my client’s ESX cluster, then created a new VM for it, migrated the RRD data from the original 32-bit VM to the new dedicated 64-bit VM, configured Observium to monitor the majority of my client’s Linux servers (both virtual and physical) and network equipment (mostly HP ProCurve switches).  I’ve made Observium the number one web page I visit when I arrive on site.  I’ve submitted a few patches, some of which have added useful functionality.  Overall, I would say that I’ve invested about 2 hours per week in Observium over the last 2 months, for a total of about 16 hours.

It should be obvious where I’m going with this: it would only take 200 users with similar experiences to mine a total of two months to roughly equal the time investment of the baseline coding of Observium.  My guess is that there are a lot more users than that (probably an order of magnitude more), and that most of them have been using the product for a lot longer than I have (probably an order of magnitude longer).

Other software

Observium is not a typical end-user product – it’s targeted at enterprise and service provider networks and requires some skill to implement (although not as much as some of its “competitors” in the network monitoring space).  Consider the CPU scheduler of a desktop or mobile operating system kernel such as Linux, Android, Microsoft Windows, or Apple iOS.  It would typically be roughly two orders of magnitude smaller than Observium (around 500 lines of code, let’s say).  The original developer(s) may have spent a significant length of time researching and testing it, but if a CPU scheduler doesn’t have workable functionality within a few months, it would likely be considered a failure.

Compare this with the number of users who depend upon that scheduler every day, and the difference is dramatic: the overall time invested by the users (in simply operating their devices and relying on them to perform at expected levels) vastly outweighs the time investment by the developer, probably within the first week of its release.

What does this have to do with the GPL?

What I’m getting at here is that for most software, the time investment on the part of the users is often roughly equal to (in the case of specialised software like Observium), and in many cases massively greater than (in the case of a generic CPU scheduler) the time investment on the part of the developers.  Software developers put their time into design, programming, testing, support, project infrastructure, etc.; users invest time in installation, testing, configuration, supporting other users, promoting, etc.  Both parties are major stakeholders in the software, and a good Free Software license should strike a balance between the rights of the different stakeholders.

What the GPL offers users

(In this post, I’ll assume use of version 3 of the GPL unless otherwise specified.)

The GPL’s preamble says that its purpose is “to make sure it remains free software for all its users”.   The primary benefit the GPL brings to users of GPL-licensed software is the guarantee that the software they have will remain free.  That is, no one can revoke their right to use the software, nor can anyone change the conditions under which they are allowed to copy and redistribute it.  (It doesn’t guarantee that future versions will be free, since the copyright holder might choose to relicense it, but it guarantees their access to the software they currently use.)

This offers adopters of GPL-licensed software a key advantage over proprietary software, since they know that time they invest in the software will not be wasted.  No vendor can come along (like Amazon did with one of their Kindle books) and decide that all customers need to delete their copy.  No copyright holder can demand additional license fees in order to maintain a customer’s right to run an existing installation of the software.  No party can sue them for using the software inappropriately, since the GPL explicitly excludes the executing of GPL-licensed software from its terms.  [See section 2 (“This License explicitly affirms your unlimited permission to run the unmodified Program.”) and section 9 (“You are not required to accept this License in order to receive or run a copy of the Program.”) for further details.  Incidentally, I believe this to mean that typical Windows-based installers of GPL software should NOT require the user to accept a copy of the GPL license in order to install the software.  However, I am not a lawyer.]

So the GPL offers conditions which are strong incentive for users to adopt the software.

What the GPL offers 3rd-party developers

Another stakeholder in the Free Software ecosystem is the 3rd-party developer.  Often these developers will be users of the software as well, and will make their own modifications, then pass on these modifications (or updated copies of the software) to others.  The GPL offers such developers essentially the same benefits which it provides to users, guaranteeing that their time investment in improving, distributing and supporting the software will not be wasted.  This is further enhanced if a distributed copyright model (such as that employed by the Linux kernel) is employed, because not only are currently-released copies of the software protected, but any licensing change to future versions must be approved by all copyright holders.

For me as a very part-time Free Software developer (among my other roles), this means that I’m much more likely to contribute towards a GPL-licensed project (or one using a similar license, such as the AGPL or LGPL), and also much less likely to be suspicious of the original developers’ motives if they do not ask me to waive copyright on my contributions.

Specific misconceptions

Now on to some of the specific issues raised in the Observium IRC channel.  I am not a lawyer, so these are just my opinion.  However, I hope that they are justified and well-documented opinions.

  1. Maintaining individual contributors’ copyright notices in a Free Software project is nonsense.  Because 3rd-party developers can be assured that their time investment in a piece of software is not wasted, using shared copyright on a GPL-licensed project is a way to gain developer mindshare and encourage further contributions.
  2. The GPL is open source, but isn’t free.  This seems to stem from an understanding of “free” which assumes that the original developer is the only major stakeholder in a software project.  When seen from the perspective of total time investment, the GPL’s restrictions on modification and redistribution (but not on use) are essential to maintain the freedoms of users, distributors, and 3rd-party developers alongside those of the original author.
  3. The GPL is not about the user, it’s about Richard Stallman wanting your code and not wanting anyone to use his.  The Free Software Foundation is mentioned in the GPLv3 only as
    1. the publisher of the GPL, and
    2. an example of an organisation which publishes GPL-licensed software.

    Nothing in the license requires any involvement of the FSF or Richard Stallman.  The fact that Red Hat have built an incredibly successful commercial enterprise on a codebase that is allegedly more than 50% GPL-licensed should be sufficient evidence that this is not the case.

  4. The GPL does not coexist with the LGPL.  The FSF has a detailed FAQ entry about this.  The kernel of truth behind this misrepresentation is that software licensed under GPLv2 only (as opposed to GPLv2 or later) is incompatible with the LGPLv3, which is unsurprising, since the provisions of the LGPLv3 could hardly be anticpated at the time of the GPLv2’s drafting.  The latest versions of GPL and LGPL are explicitly designed for compatibility.  Due to this design, if a project is licensed under GPLv2 or later (which most GPLv2 code is – the notable exception being the Linux kernel), then it is LGPLv3 compatible.
  5. The GPL does not provide any benefits to the user of the software. I hope that in this post I have justified the position that GPL offers great benefits to the user.
  6. The GPL is hypocritical; as it restricts the use of the free software it supposedly protects.  As it stands, this statement is factually false (see the references to sections 2 and 9 of the GPLv3 above).  However, I suspect that the thought behind this statement has re-use (presumably in a non-GPL-licensed project) by the author or a 3rd party developer in view rather than use by the end-user.  There is no question that the GPL has restrictions; however, they fall upon the parties modifying and distributing the software, not upon the user.Additionally, there is nothing to prevent a copyright holder from re-releasing the same code under a different license.  Licensing my code under GPL means that a large company can’t come along and commercialise my code without complying with the same conditions as everyone else.  To me, this is a great protection for my software and my time investment.
  7. The GPL is unclear and untested when it comes to linking restrictions.  I’m not a lawyer so I cannot comment on this with any authority.  I personally feel that the GPLv3 has cleared up a lot of ambiguities in this area and I’m much more comfortable with it in this respect than I was with the GPLv2.
  8. Free Software has more restrictions than commercial, closed source software.  All I can say in response to this is that this description doesn’t fit most of the closed source software licenses I’ve ever had the displeasure of reading.  Most of them specifically disclaim granting the recipient of the software any rights whatsoever over the software.
  9. The GPLv3 and GPLv2 are incompatible and so cannot be used in the same software project. This is true at the strict level, since if a project is licensed under GPLv2 only, it is not GPLv3 compatible.  However, the majority of GPLv2 software is licensed under GPLv2 or later (the Linux kernel is a notable exception), or dual-licensed (e.g. with the MIT license), so this shouldn’t be a major concern.

Where to next for me and Observium?

Where this leaves me with Observium is a little unclear.  I’ve tried to fit in with the original developers as best I can so far (including going back to Subversion for version control, despite its annoying limitations).  I’ve started small, but I was hoping to ramp up my contributions over the next few months.  Being required to assign copyright of contributions is an enthusiasm sapper for contributions, as is the suggestion that at the first chance Adam will relicense the project to BSD or MIT.

Observium is a great piece of software: it offers killer features for minimal configuration, saving me a lot of time and effort, and it’s fun and easy to hack on.  So while it remains GPL-licensed, I’ll probably swallow my pride and keep contributing.  My contributions are only a tiny fraction of the overall project, anyway.  If it all goes pear-shaped, I can always fork.  😉

Source: libertysys.com.au

What the world needs now is a better SMT

Novell’s SMT (Subscription Management Tool) is a software update tool for SUSE Linux Enterprise and openSUSE.  I’ve had the dubious honour of working with it over the last few months on a client site.  These notes were compiled as a result of installing SMT on three different servers, and interacting with various people in the Novell forums, especially the novell.support.sles.updates forum.

What’s wrong with SMT?

  • SMT is a mirrored repository, not a proxy.  That is, it has to download the entire distribution, even if you don’t use it.  Not only that, but as far as i can tell, SMT must successfully mirror a complete copy of the catalogue before any client systems can be updated.  I logged enhancement request 14093 to ask to have this fixed, and it has been rejected as having an “insufficient business case”.
  • SMT doesn’t work out which updates its clients need and mirror them automatically.  Instead, sysadmins must know which catalogues their systems need and manually configure these catalogues to be mirrored.  The biggest reason this is a problem is that it can result in some security updates not being applied to systems due to their catalogues not being available on the update server.  The catalogues are named rather obscurely, such that Novell released TID 7001199 to help customers determine which catalogues to mirror.  The TID itself is rather obscure and this suggests that there is a more fundamental issue: flawed design.  I logged enhancement request 14094 to ask for this to be fixed, and again, it was rejected, this time for the reason “Does not align to [sic] Novell strategy”.
  • SMT doesn’t coexist with the Novell Customer Center, so it is a single point of failure (SPOF) for software updates (unless it is clustered, and the SMT documentation doesn’t contain any information about whether this is possible or recommended).  I logged enhancement request 14095 to request this to be fixed, which was rejected, once again for “insufficient business case”.
  • SMT doesn’t have a web interface.  In the “Web 2.0” world, this is the most inexplicable drawback of all.  Novell works mostly in the Windows world, and if they want their customers to convert from NetWare to SUSE Linux Enterprise, they need to provide users working in a Windows environment (often with little Linux experience) with an easy interface which gives them confidence that their Linux systems are updating frequently and reliably.  I logged enhancement request 14096 asking for this to be added.  It is currently “under consideration”.

The bottom line with SMT from my perspective is that it is designed to solve Novell’s problems rather than their customers’.  The Achilles heel of SUSE Linux Enterprise is its update process, which is crippled by being tied to Novell’s licensing model.  This is a lose-lose proposition: the customer loses because the update process takes longer, needs registration (which is often flaky), and requires live HTTPS connections to the Novell Customer Center (which can’t be cached by a local squid proxy); Novell loses because their customers are less inclined to deploy a system which doesn’t update reliably.  I personally recommend to my clients that they deploy Debian GNU/Linux in all situations where they don’t need the NetWare integration which OES/Linux provides. (See this Novell forums thread for an example of the unreliability of Novell’s patching process.)

What’s right with SMT

All this said, there are some things that SMT does right:

  • It succeeds in making the update process considerably faster on both SLES 10 and SLES 11.  A faster Internet connection might mitigate this somewhat, but i expect Novell’s servers are part of the problem.)  The client on whose network i implemented SMT has a 4 Mbit synchronous wireless connection to the Internet, and updates were positively painful until SMT was implemented.
  • It removes the need for each system to be individually registered with a license key (at least for those customers licensed with SLAs), eliminating a pointless manual step in the setup of new servers.

What SMT needs

These are the features i think SMT needs (besides those already mentioned above) to have in order to make it a really compelling choice for sysadmins to install on their networks.  Many of these are unabashedly modeled on Microsoft WSUS – in my opinion it is a far superior product which makes managing updates on Windows much easier than using SMT to manage updates on SLES.

  • Administrator-defined grouping of hosts and releasing of updates to those groups.
  • Complete management of software repositories on all clients, so that, for example, an OES2 installation source can be added on a selected list of hosts without manual intervention on every client.
  • Space and bandwidth efficiency, so that older, obsoleted versions of current packages are cleaned up automatically, and not downloaded when a new catalogue is mirrored.  Of course, moving more towards a Debian-style update process or a proxy-based design rather than a mirroring-based one would remove the need for this.