<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 6 May 2009, at 15:34, <a href="mailto:Sascha.Runschke@gfkl.com">Sascha.Runschke@gfkl.com</a> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><blockquote type="cite">Our policy has nothing to do with "GPL fanatism" or the like. Having a<br></blockquote><blockquote type="cite">single copyright holder can simplify things, that's all.<br></blockquote><br>I agree to a certain extend.<br>Though the _need_ to give away the copyright to the team can make<br>things harder, too. Especially for all of us who work for companies<br>using nagios and writing code/extensions/plugins for it. I cannot<br>give away something which doesn't belong to me. Code I produce<br>during my work is owned by my company. And it's not like I'm<br>alone in that boat - lots of people are in the same position.<br>By ruling out any submission without relinquishing the copyright<br>you also miss on a lot of submissions at all. I considered submitting<br>some plugins for a long time and have even been doing some work on<br>refurbishing them so they are usable by the public without the need<br>to hack things inside the plugins - but I can stop that work now.<br><br>Big question is:<br><br>Does the "benefit" of that restriction beat the "disadvantage" of<br>missing a lot of possibilities for new code submission?<br><br>I sincerely doubt that...</div></blockquote><div><br></div>There's lot of good discussion on this thread, but I just want to home in on the issue re "code is owned by my company so I cannot contribute".</div><div><br></div><div>Let's assume the Nagios Plugin team does accept dual copyrights, and your company, Company A, has a non-trivial (less than 10%, but greater than 5 lines) change made and want to retain copyright. Let's say the change gets into the core code with those copyrights intact. </div><div><br></div><div>Then let's say Company X takes Nagios Plugin code, rips out all copyright statements, and then proceeds to call the code their own (by the way, this actually happened a few years back). Legally, its much more difficult for the Nagios Plugin team to pursue infringement - we have to contact all copyright owners and get agreement before any action is taken. This is why we want the simplicity.</div><div><br></div><div>But let's concentrate on Company A - what's happened to their "intellectual property"? Can they now have a say in how the Nagios Plugin team responds to this? I guess they could, but they have more important things to do, like running their company. What's happened to the code they've released? Well, now everyone can see it, it can get incorporated anywhere that there is a fork of the plugins code. The only difference with the Nagios Plugin team is our integrity of allowing the dual copyright in the first place - anyone ripping code is not working to the same standards.</div><div><br></div><div>The fact of the matter is that Company A is not going to get any additional benefit from contributing their code upstream to a project. Their "ownership" of their changes will not get them a seat at the table. </div><div><br></div><div>(If you do want a seat at the table, you can - join the team and contribute. I am more than happy to take on new members that will devote their time to the project. I listen to a lot of opinions, but I value the opinions of the people doing the work a lot more.)</div><div><br></div><div>So what does Company A get out of contributing? They get their changes evaluated by our team. They get their changes tested by a wider audience. They get their code running against our test servers. They get reduced support overhead as they no longer need to continue patching their version (which may break in future). None of these have anything to do with copyright.</div><div><br></div><div>As an example, my company, Opsera, make changes to Nagios. As required by GPL, we publish the changes we do to Nagios (<a href="http://trac.opsview.org/browser/trunk/opsview-base/Makefile#L256)">http://trac.opsview.org/browser/trunk/opsview-base/Makefile#L256)</a>. We list all the patches we make against a virgin Nagios tarball. Some of our patches do say "Copyright Opsera", but with the caveat that if it gets into the core distribution, then we give the copyright to Ethan (<a href="http://trac.opsview.org/browser/trunk/opsview-base/patches/nsca_alternate.t#L6)">http://trac.opsview.org/browser/trunk/opsview-base/patches/nsca_alternate.t#L6)</a>. The benefit to Opsera is that we are perceived as (1) experts, (2) good citizens. And if it gets into core code - great! That's one less thing to patch and worry about. There's no way Opsera would claim to be "authors of Nagios".</div><div><br></div><div>If your company doesn't want to contribute, that's their prerogative and the licence permits that. But I'm willing to bet that a change in policy to dual copyrights will not make a difference. </div><div><br></div><div>If you want permission from your company to contribute, you need to make the argument with them.</div><div><br></div><div>Ton</div><div><br></div></body></html>