Re: [Nagios-devel] Re: AW: Re: [Nagios-users] Nagios 3.0,natively

Support forum for Nagios Core, Nagios Plugins, NCPA, NRPE, NSCA, NDOUtils and more. Engage with the community of users including those using the open source solutions.
Locked
Guest

Re: [Nagios-devel] Re: AW: Re: [Nagios-users] Nagios 3.0,natively

Post by Guest »

sean finney wrote:
> On Sat, Aug 27, 2005 at 09:57:28AM +0200, Andreas Ericsson wrote:
>
>>That's because we don't sell a modified copy. We package the unmodified
>>copy with proprietary addons, like a webgui for configuration, a little
>>something for traphandling and syslog handling, a "clever" skin-based
>>notification script (I've been meaning to make that one public, but
>>haven't gotten around to asking yet). Those addons use none of the GPL'd
>>code so it's quite alright to have other licenses for them.
>
>
> the difference is basically whether the "add-ons" are "derived works" or
> "additional software". i'm guessing that it is the latter, in which
> case the GPL explicitly allows for you to distribute GPL'd software
> alongside non-free software on the same "medium". if the software
> links against the GPL'd software, that's another story (which brings
> us to the nebs)
>
>
>>We're having a lawyer investigate if nebmodules must be GPL right now.
>>If they do, I'll release a couple of good ones later on.
>
>
> i'd put my money on them needing to be so. if i understand the
> architecture (which i might not of course) correctly, this would
> be very analagous to proprietary loadable kernel modules for linux,
> which would not be legal except for the fact that linus made a special
> exception in his licensing to allow them.
>
> of course, this largely depends on whether or not you need to compile
> them against nagios source/headers, whether or not the modules
> are useful in their own right apart from nagios, and other factors
> which could determine their status as "derived works" or not.

Yes. This is actually pretty tricky. One of the modules I'm writing now
uses a spooling mechanism for binary data to be distributed to several
hosts. This spooling mechanism was originally proprietary, but if we
have to make it GPL, then so be it. It's possible though that GPL'd code
can be linked to proprietary code (rather than vice versa) which would
be the case. This is what the lawyers are looking in to.

>
>>>>Besides that, I've submitted some 30-odd patches back to nagios (core
>>>>project, don't get me started on the plugins) for bugfixes, new
>
>
> but you get yourself started, later on :)
>

Sadly, yes.

>
>>We've had lawyers look at it. Since we don't modify the nagios source,
>>we have no obligation to provide it for download. We DO modify the
>>plugins. Our modified plugins are available for download from
>>http://oss.op5.se/nagios which is where we post everything that has to
>>do with Nagios and is touched by us one way or another.
>
>
> this is true, under the circumstance that you provide source code
> along with the binary GPL'd software, or have otherwise provided
> the information they need to locate the original source code (or
> give an offer to provide said code). sections 1 and 2 only address how
> you can handle the source code--section 3 clarifies for what you can do
> with binary-only distribution.
>

The stuff at oss.op5.se is source-code only, so that's ok then.

>
>>I've tried numerous times to get our patches through to the nagiosplug
>>project but it has taken too long to get them applied. In the end the
>>amount of patches became overwhelming, so now I won't merge them with
>>the official distro unless I get commit-access to the cvs. It's simply
>>too much work to provide the patches, and it's worth absolutely nothing
>>to me.
>
>
>>and I get a free peer review (from competent coders, I might add. The
>>plugins aren't exactly stellar in quality).
>
>
> don't you think your periodic comments of such nature are part of the
> reason why so many of the nagiosplug team are hesitant to spend time
> working with you, in spite of your proficiency?
>

Most likely so, but since Karl stopped doing anything (2 years ago) and
before you joined every change submitted (the few there were)
implemented, without exception, something that made the code less
efficient (throwing away calculated values just to calculate them
again), harder to maintain (spurious dependencies and just plain weird
use of distributed

...[email truncated]...


This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]
Locked