Re: Failsafe Licence LGPL / GPL confusion

Hello,
Sorry for being somehow off-topic. We might move this discussion in the
linux-ha mailing list instead.

----- Original Message ----- 
From: "Kashif Shaikh"

>
> Yes, FailSafe tries to be a space-ship, but ends up being the
> kitchen-sink and too over-engineered.
>
> ...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.
>
I am interested in what you are doing to position different opensource
solutions. I've never read anything on this.
As you invoke the trend towards complexity, I would be interested in getting
your opinion on WDX too (www.wdx.shaman-x.org) Design choices for WDX were
simplicity and robustness. WDX capabilities are frozen now (118kB binary).
There is no plan to make it more complex in the future. I don't know if it
matters, but WDX is fully GPL since it has no published API.
I'd like to understand if it is correct to position WDX functionality in the
low end and heartbeat capabilities in the high end, provided the future of
failsafe is uncertain. If we do so, what would be the benefits of complexity
of futur Heartbeat, in your opinion ?

Regards
Dominique

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]>

_______________________________________________
LinuxFailSafe mailing list
[email protected]
http://lists.community.tummy.com/mailman/listinfo/linuxfailsafe