Nagios Interoperability

[Thibault Genessay]

Dear list members

I have been following the discussion about "Nagios 3.0" with great 
interest as like many of us I am using Nagios together with other tools, 
some being GPL'd, some being proprietary. Until now, I had been using 
Nagios for itself, grabbing its checks through the NEB and putting them 
into a DB. But today I want to go further and make the NEB directly chat 
with our monitoring system.
The problem is that it implies that some module of our proprietary 
system include headers from Nagios, and even though this module does not 
link with Nagios libs, I think the GPL forces it to be also GPL'd. Then, 
to compile this module, one would need the headers from the rest of the 
sytem, making it GPL as a whole. Which is something we don't want.
However, I have thought of a workaround but I did not see (or 
understood) what the GPL states about it. It is binary compatibility. 
Rather than including our system headers, the NEB could send data in an 
apparently unordered manner and our system get this data and 
automagically build the structures back from it. This avoids the NEB and 
the system to share any header file. This is the agressive solution that 
nobody would like, but is kinda legally possible. (even if it needs to 
be reworked by a jurist).

I have thought of a more profitable way to solve the problem. Strictly 
speaking, there is not much difference between the two following systems:
Nagios --- checks ---> NEB -------> DB <---- queries ---- Frontend 
proprietary application
Nagios --- checks ---> NEB ---- TCP/IP -----> Frontend proprietary 
application
The first one is legal, the second is not because the NEB and the 
frontend app. should share headers, making both of them GPL'd. But when 
we think of it, the only difference is that the first one uses a DB 
which, just like Nagios-DB, somewhat reproduces the binary structures of 
Nagios (compare Nagios-DB's Service_Check table with Nagios' 
nebstruct_service_check). Ok, Nagios-DB is also under the GPL, but 
anybody could basically write a NEB that writes into a proprietary DB 
schema, and then use the data in a completely non-GPL manner.
But if we want the apps to talk directly rather than through the DB, we 
need them to be open source which is not compatible with our businesses 
(after all, we are selling stuff, aren't we ?). The possibility I have 
seen is to make a sub-part of Nagios LGPL'd so that a proprietary 
application could link with this library without any problem -- as 
Nagios could, hopefully.
This lib would include modified versions of the following headers:
objects.h
nebstructs.h
nebcallbacks.h
common.h
in which we would only keep the structure definitions. The rest of the 
defs could stay in the GPL part. Those headers, if properly written 
could be included from C++ or/and Windows applications, which is not 
something bad on the inter-operability point of view. The lib would as 
well include the serialization and unserialization functions.

I think this modification is strategic for the Nagios project because it 
would premit it to be shipped with important business applications that 
would otherwise use another basis. The community would benefit from a 
powerful way to externalize data from Nagios and it could eventually 
promote the way Nagios perform checks and report results to an 
industry-wide standard.

Thoughts , comments ?

-- 
Thibault GENESSAY
ALIADIS
www.aliadis.fr
Tel.  +(33) 870 723 724
Fax   +(33) 4 72 13 90 40



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf