Comment 57 for bug 1273484

(In reply to Sam Kottler from comment #24)
>
> I agree that it's too early to decide on the issue. These are the packages
> in EPEL that depend on nagios-plugins and what do we want to do about them?
> Create community-plugins-* alternatives?
>

I think that will be absolutely necessary sooner or later, as Nagios Enterprises have made it pretty clear that they will bring in lawyers for pretty much everything using the Nagios name without being directly affiliated with Nagios Enterprises.

Most, if not all, of the plugins in the list fall into that category, and there's no way to protect against a forced rename later. Then there's the problem with the original authors. Most of them won't want their work flying under the nagios banner anymore, since they're mostly community enthusiasts who wrote something useful once upon a time, but have since been shafted by Nagios Enterprises one way or another. I know I have, and I've been directly involved in creating or maintaining several of the plugins in the list in comment #24.

Personally, I'd do a "monitoring" or "network-monitoring" meta-package which provides the paths. The nagios package can depend on that, as can other solutions that in some way or other benefit from the various plugin suites (such as Shinken, Naemon, Icinga, Zenoss etc).

For legal reasons, I'd then rename everything nagiosy except nagios-core and nagios-gui to something neutral, such as "monitoring-" and keep packages from being named "nagios-X" unless Nagios Enterprises themselves add a package review request for a package with their trademark-protected name. The current "nagios-plugins-dhcp" etc should be dropped and "monitoring-plugins-dhcp" should "Provides: nagios-plugins-dhcp" during a transitional period.

I'm more than willing to write the specfiles to make that happen, but I'm unfamiliar with RedHat's procedures in this area.