[rrd-developers] Re: C API

[Peter Stamfest]

Hello Tobias,

On Fri, 10 Feb 2006, Tobias Oetiker wrote:

> Hi Peter,
>
> Granting an LGPL license to rrdtool would make it very simple to
> integrate rrdtool with many non GPL tools. My intent with
> publishing rrdtool under the GPL was

Don't get me wrong: I'm not advocating the LGPL! Not at all! Lee Thompson 
aksed about it. All I said is that everybody who contributed some code 
would have to agree with that move, and I think this obviously is unlikely 
for several reasons:

  * You don't want it
  * I don't want it
  * ...
  * ;-)

What I said in my last mail was that _I_ would be willing to release _my_ 
changes to the _update_ code (the initial multi-thread stuff) to a more 
liberal license, _but nothing else_ (unless I'm proven that it would be a 
GoodThing(tm)).

> a) Make sure that any modifications to rrdtool will be available
>   under the same liberal license as rrdtool as they are published.
>
> b) Promote free Software. Since the GPL gives people who want to
>   access rrdtool from closed-source applications some heavy
>   thinking (it can be done using the cli and also the scripting
>   apis and I would not even object to shared library access as
>   long as the tool itself does not do any graphing and logging
>   stuff itself.)

Ahh, this is exactly what I had in mind: let them update an RRD, but 
graphing and more elaborate stuff should be out of reach for closed 
source. And I'm not at all sure about fetch or info.

>
> I have no interest in preventing other free software from using
> rrdtool and if something like php has a license that gives people a
> headache over license incompatibility, then I see no gain in this
> hence I clarified the situation adding the FLOSS exception. I don't
> see it interfearing with the spirit of the GPL (as you can see from
> looking at the GPLv3 draft). As for the discussion, on the list
> that I missed and I am sorry for this (since most of the work on
> rrdtool seems to stay with me the 'developer-community' tends to slip
> my minde every now and then).

The problem I see with the undiscussed change is that I should now check 
if any of the "compatible" licenses really are compatible in my sense of 
how the GPL itself should work. I also always have problems with releases 
under the GPL "choose the version yourself" terms, as you never know what 
comes out of it. That said, maybe I get around to think about the 
implications of your changes.

One more thing: I do see _you_ as the Mr RRD, so your thoughts about the 
licensing matter the most, but such moves should really be discussed 
before they are made.

>
> As for the LGPLing rrdtool ...
>
> Intent a) would still be valid. Intent b) would be weakened, since
> LGPL is much easier on the 'consience' and I don't actualy think it
> is necessary to make it easy to use rrdtool in closed source
> software while I spend all that time on it giving it away for free.
> But feel free to make a case for LGPL ...
>
> The thought about the 'rrd' format is interesting, but I am not
> sure the current state is something we should promote all that much
> since it is platform dependent and quite rigid regarding
> extensibility.
>

True, but isn't the same true for many other file formats that are far 
more "successful"? (Waving hands here, as I'm not an expert on file 
formats...), also: I see most of the power in the consolidation feature, 
not the file format, and that is also something done during update time...

peter

--
Unsubscribe mailto:rrd-developers-request at list.ee.ethz.ch?subject=unsubscribe
Help        mailto:rrd-developers-request at list.ee.ethz.ch?subject=help
Archive     http://lists.ee.ethz.ch/rrd-developers
WebAdmin    http://lists.ee.ethz.ch/lsg2.cgi