Comment 45 for bug 1273484

(In reply to Kurt Seifried from comment #42)
> My concern is with regards to "but a rebase with new team members", how
> familiar is your team with all the existing code? Will this impact security
> response times (e.g. the original authors of the code whom are familiar with
> it vs. a new developer that has perhaps never seen the code before can have
> a huge impact on the time involved in a security response). If you can
> clarify this I would appreciate that greatly.


I lead the Shinken project. And in our community the answer is quite easy on this topic: we won't add nagios-plugins in our package and will switch to the "community one.

It's quite easy to understand: nagios inc forked the plugins, but as the trademark owner they for the other to rename. Ok seems legal, I got nothing against it. But what we trust are the guys that maintain the plugins since years, with a really great job.

I got nothing against the new team, but we do not know them, and as far as I know, they never commit nor help this project. So why give them a full access to all the monitoring users when the "known to work well" guys will be pushed away just for a name?

I don't know how packages names are impacted by trademark (don't play on this field with Nagios LLC, they know their job well on this legal part) and if it's a legal problem to keep "nagios" on the community name. But I think at least users should know that the package they are installing is a forked version and not the original team (I don't care about the name, the team matters, not the name). Maybe by setting this nagios-plugins package as virtual implemented by two new Conflicts ones?

If after some time we see that the new team is working well and patches are merged in the two packages why not allowing nagios-plugins to be back in the Shinken installations, but currently it will be "Conflict" in the Shinken EL package if the nagios-plugins is not following the original team behind it. I won't give root access to guys I don't trust.

I'm wondering, is such problem already occurs in Fedora history? Can RedHat legal team help there? (especially for the trademark issue).

Thanks a lot for your help, maintain a package in this moving monitoring world is really not an easy job :p