Re: GNOME Office and OpenOffice (fwd)

[Sander Vesik <Sander Vesik ireland sun com>]

On Thu, 2 Nov 2000, Martin Sevior wrote:

> 
> Hi Sander,
> 	 I realize that my emails might have sounded combative. I will
> attempt to not become so in the future. 
> 

I should probably go home. 

> On Thu, 2 Nov 2000, Sander Vesik wrote:
> 
> > 
> > You mean unobstructed as long as everything is GPL licenced?
> > 
> 
> Gnome was founded over a Licensing dispute. I really like the GPL which is
> the reason I donate my time to the Abi project. My charge-out rate is
> $1000 a day. We have developers on Abi who are worth much more than that.

I know. Lot's of things get done over things like that. Sometimes they
turn out good (gnome for example), sometimes the equvalents of hundres of
personyears of highly qualified people 

> 
> > > If we are to have an open-source office suite that is as good as, or better
> > > than, the market leading office suite we need to use a) the best code from
> > > existing projects and b) the best developers working together.  Linux needs
> > > this.  It's a shame that licensing is an issue when we all want the same thing -
> > > the best office suite around to be open-source!
> > > 
> > 
> > The easiest way to achieve that is for everybody to leave the political
> > issue of licencing aside and just do it.
> >
> 
> This is a very hard thing to do in the abstract. I'm certainly not
> qualified. I've had enough trouble understanding precisely how Abi works
> and the best way to extend it. 
> 
> I do like the bonobo approach of isolated components communicating via a
> well defined protocol.
> 
> If as promised OO becomes a collection of bonobo components we can plug
> them into Abi with no trouble. OO could do the same with Abi, Gnumeric,
> Guppi etc.
>  

OO in a way does this - please look at the technical overview/ any other
relevant docs / source code. Not with bonobo right now, though.

> > The dual licence on OO code does not keep you from doing what you propose
> > - just write using the api. And shmae on everybody who reads that last
> > part as meaning "the api that OO uses". No reason the api can not be an
> > universally agreed upon thing that is abstractly specified (just so
> > everybody and their grandmother can implement it using their own favourite
> > licence). 
> >
> > All OO code (that I have seen) is available under GPL, LGPL and
> > SISSL. Everybody is welcome to take it and integrate it into their own
> > project or start a middle of (whatever) road one integrating it with
> > whatever other code they please. 
> 
> OK given that you are not talking for SUN can I take what you are saying

No, I am not talking for sun. You can be quite sure of that.

> to be, "We will write our OO applications to an agreed upon framework"

Yes.

In fact, I believe this is even really close to the offical standing
point. It's hard to be sure as nobody has (luckily) talked to me overly
much about that anyways.

OpenOffice is writen to a framework as it is right now. I believe the
framework to be very adaptable. The idl for the apis/framework of OO is
available now - you are welcome to take a look.

> and you happy that the resulting application will be better than OO by
> definition? We can use your code but you can't use ours?
> 

You can use our code but we (potentially) cannot use your code is
*BLINDLINGLY* obvious - our code is available under both LGPL and SISSL
(pick and choose) while "we" will use only code assigned to "us". Just so
the door is open to anybody who wants to use the code with the SISSL.

Now, one trick you may be overlooking is that OO is just a bunch of
components linked together with glue (think of corba). They can be written
in whatever language you please (just provide the bindings). Parts of it
can run in another address space. Parts of it could even be running on the
other side of the planet. It would of course introduce undue reliability
and overhead problems, so that is not the prefered way to do it. But I
believe the components written in java already do run in a separate
address space. Provides for a clean fallback should you not have a
supported java vm installed on the machine.

8-)

> Martin
> 

	Sander

OpenOffice Release Engineering / Dublin