Re: Failsafe Licence LGPL / GPL confusion

On Fri, 2003-11-28 at 14:44, Lars Marowsky-Bree wrote:
> On 2003-11-28T12:20:49,
>    Kashif Shaikh <[email protected]> said:
> 
> > I'm not arguing if a library should be GPL or LGPL, I'm just saying the
> > license application should be made clearer, so people like me can
> > evaluate failsafe v.s. heartbeat(it's API is consistently LGPL). I can't
> > make the headers more clearer, because it depends on what the copyright
> > owners want to LGPL. So the balls in your court, I just need objective
> > information.
> 
> SGI owns most of the files and would have to reevaluate the copyright
> decisions.
Maybe someone from SGI can comment here? Otherwise someone(me?) could just
strip out GPL symbols from the LGPL header files.

> However, if you are comparing FailSafe to heartbeat, I can tell you that
> as of today, it's evaluating a space ship to a car ;-) FailSafe is much
> further advanced; it's not a reasonable comparison. The two benefits
> heartbeat has offer FailSafe is less complexity and tighter security.

Yes, FailSafe tries to be a space-ship, but ends up being the
kitchen-sink and too over-engineered. The nicest things Failsafe has is
the cms/gcs layer, and IMO the rest is crap; the cdb should be placed
over the cms/gcs layer, but it's pointless since cdb uses rpc for
communication and will be difficult to use gcs. FSD/SRM is hell -- both
trying to keep the same states and similar logic results in many bugs
due to 'assumptions' and what not. 

The scary part is Heartbeat's proposed CRM/CIB/SRM/CRS looks very
similar to FailSafe's CHOAS layer(no offense, I know you wrote the crm
docs)...and that's when complexity will shoot through the roof
again...only good for the 'enterprise' market. The reason why heartbeat
gets adopted in a 'heartbeat' because its easy to configure with
down-to-earth configuration and only a single daemon to manage. 

Kashif


> Sincerely,
>     Lars Marowsky-Brée <[email protected]>