I've got the Richard Stallman's answer (and the right to post it of
course, that's why I didn't post it yesterday).
First mail :
Richard Stallman <rms@...>
to nap <naparuba@...>
date Wed, Jun 23, 2010 at 11:23 PM
subject Re: AGPL software reimplementation of a GPLv2 one is allowed?
I am not a lawyer, but I know the answer is not so simple.
You can use the algorithms you learn from reading their code, but
translating the code into another language would surely infringe
copyright. For intermediate possibilities, the answer may not be
clear, so you would need to talk with a lawyer for advice.
And another mail to precise what "inspiration" was :
Thanks for the answer. The exact case is that I look at the code to
look at how some parameters are done (I look at the regexp), but The
algorithm to find and parse them is my own.
Richard Stallman :
In that case, you are probably ok; but I am not a lawyer.
You should check with a lawyer if you want real legal advice.
APRIL could help you find a French lawyer.
So "inspiration" (looking at another algorithm but make your own) is
allowed to Richard Stallman (and to all people I talk about this in
fact in forums or websites).
So get back in our case : I look at regexp of daterange in Nagios
code, but I didn't copy/paste/translate them. I use it to look at all
formats they can have, so look at the algorithm that "match" patterns.
Then I write my own regexp and my own algorithm. And prove it is quite
easy : my code is far longer than Nagios one in this algorithm, I use
far more regexp than Nagios code (I'm very bad in regexp). So we can't
talk about translation.
There is one part of Nagios code I copy/translate : the parent
circular checks for hosts and I've got the right to do this : it's my
patch in Nagios code.
So looking at this, I won't change the Shinken license. The users will
have the better license for them.
If you find a copy/translate code, let me know it so we can re-wrote it. Thanks,
Like you should already see, we remove "reimplementation" and "fork"
from all places we can. Now Shinken is "compatible with". This should
be better for both projects to do not think our codes are inherited.
Now I will be back with my loving emacs and Shinken code, but my
proposal for patches is still available of course. And this place will
still be open for anyone you ant to talk about improvement like realms
or other cool things for monitoring users.
On Wed, Jun 23, 2010 at 9:35 AM, nap <naparuba@...> wrote:
> On Tue, Jun 22, 2010 at 5:11 PM, Ethan Galstad <egalstad@...> wrote:
>> I'm just joinging the list, so I can't reply to previous messages as
>> normal, so I'll quote one of the recent replies regarding licensing...
>>> LOL, so funny, make me nearly fall from my chair :)
>>> You do not really know what Shinken is isn't it? When I say it's a
>>> fork, I do not mean I take Nagios code, change the licence (and I'm
>>> totally agree that's not possible to change Nagios license, hopefully
>>> ;) ) and say : "Hey, I'm totally something totally different". I did
>>> not "steal" code (even if I do not like the "steal" usage in a open
>>> source context).
>>> It's a TOTAL reimplementation of the code! I do not take a SINGLE line
>>> of the Nagios code. Only the documentation (in fact the doc from
>>> monitoring-fr, you know, the ex nagios-fr...) and this part got a
>>> LICENSE file of GPLV2. (you should look at this docbook documentation,
>>> very good docbook format by the way).
>> There is no "documentation" that references in detail how to
>> programmatically process timeperiod logic for Nagios Core, yet somehow
>> this managed to be magically "re-implemented" in the Shinken Python
>> code. Pixie dust must be flying on someone's network to have made that
> Yes, there is no documentation about how datetimes (inside
> timeperiods) are defined, but the way timeperiods works is quite
> obvious : get the next date, that's all. I look at the Nagios code for
> the datetime part so see all the was we can defined them. But not for
> the algorithms in it (like find the next date for example, and it ask
> me quite a lot of papers to find the good algorithm...).
> So if you are right about the "inspiration" part, and the fact I do
> not use the http://en.wikipedia.org/wiki/Clean_room_design technique,
> I will put the function asides of the rest of the code and AGPL
> licence, and make the documentation, then someone else can wrote them
> We are talking about the comments in the timeperiod.py file, and the
> function resolve_daterange function (quite long, was quite not
> pythonic after all). All others functions were coded without looking
> at how Nagios does in the code (and If I'm not wrong, it's better
> because exclusion is not working isn't it?).
>> "Re-implementation" when referencing pre-existing code is still covered
>> under copyright laws and protects the original copyright holders. There
>> is code all around Shinken that could not have been developed without
>> having looked at the C code for Nagios Core as the reference. Downtime,
>> macros, timeperiod logic, and other Shinken Python code makes it clear
>> that the C code from Nagios Core was used as a reference when
>> "re-implementing" Nagios Core.
> The only part that take inspiration from the code and not the
> documentation is datetime format because like you said it's not
> documented. That's all. Timeperiod is not affected by it : I wrote my
> own algorithm to find a new date because it was a good challenge for
> my algorithm skill.
> For downtime and macros, the documentation was enough. Downtime are
> just a check of a timeperiod, and macro are just a reverse hash table
> after all.
> For the rest of the Shinken code (the distributed way) I do not see
> how it can be inspired by Nagios : one is distributed with graph
> management, the other is a daemon with all in it.
>> This type of "re-implementation" to a different language with a license
>> switch would clearly be considered copyright infringement and you could
>> find yourself in deep trouble. Since Nagios Core is GPL, you have
>> rights to modify it, but you're required to release those changes/mods
>> under the same license. The GPL doesn't grant you rights to
>> re-implement under a different license when you use the original GPL
>> code as a reference.
>> Since Shinken was "re-implemented" using the Nagios Core code as a
>> reference, it cannot be release under the AGPL - it must be released
>> under the GPL license.
>> You don't have rights to change the GPL license associated with Nagios
>> Core without getting permission from every person who has contributed to
>> the Nagios Core code over the past decade. Neither do I. Those are
>> the rules - plain and simple.
>> If you're going to live in the world of intellectual property, you need
>> to understand the rules that you have to abide by. Just because you're
>> an "Open Source" guy doesn't mean you have any right to violate licenses
>> as you see fit or make the rules up as you go.
> Yes, I will follow the rules, that why I ask help fro the FSF and to
> Richard Stallman about this "inspiration" (not using the clean room
> design) between two projects. If I must put this part of code in
> GPLv2, it's not a problem. Even if it's in a "gray zone", we will
> redone the part of code for the datetime function and class names.
> If you find some other portions of code that cannot be wrote without
> the nagios code (so with only the documentation) let me know it.
> By the way I choose the AGPL license because I wanted the maximum of
> freedom for the users : if they are monitored by some box, they should
> be able to get the code that are monitoring them. I though fully new
> code was a opportunity to make a upgrade of the license for the users.
> It was really not to offense other developers.
> If you do not want the Shinken project to be a proprietary software, I
> also do not want it, believe me. If you fear that Shinken become a new
> business challenger : it's not the case, I'm a sysadmin, and a happy
> sysadmin. With family things, I can't afford to be a business man and
> move every where.
> I see that the term "fork" about Shinken can cause problem to both or
> ours projects. I'll take "compatibility with" because that better
> shows what it is, and people will not think this is based on the same
> code (and so is tested from 10 years because that's no true for
> So finally : let wait for a FSF answer, I think they are better than
> every one to say if code inspiration need to keep the same license. If
> we need to change it, we will do it (then go to GPL, than rewrote the
> part into AGPL with documentation based informations for datetime).
> The "fork" term will be remove from all places where Shinken is (where
> I can edit of course) to put "compatible with" or something similar.
> Believe me, I do not want a war between our two projects because
> everyone will lose in this game, and Zabbix/Zenoss will just have more
> users. If we can cooperate about improvement about configuration or
> documentation, I will be happy to to it. There is no chance I stopped
> Shinken project, I'm not related to the Nagios consultant world, and I
> still want to be a sysadmin (this is the best way to understand the
> users : be one of them :) ). There still a hope in my mind so theses
> two projects will merge one day.
> Jean Gabès
>> Ethan Galstad
>> Nagios Enterprises, LLC
>> Office: (888)NAGIOS-1 x701
>> Fax: (651)204-9103
>> Mobile: (651)278-1477
>> Email: egalstad@...
>> Web: www.nagios.com
>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>> lucky parental unit. See the prize list and enter to win:
>> Shinken-devel mailing list