On Wed, Nov 01, 2000 at 11:54:15PM +0000, Sander Vesik wrote:
> On Fri, 27 Oct 2000, Martin Sevior wrote:
>
> >
> >
> > On Thu, 26 Oct 2000, John B Tunison wrote:
> >
> > > Dude, emails like this make me unhappy.
> > >
> >
> > I don't like discussing this on abiword-dev so this is just to you and the
> > gnome office list.
> >
> > > "Abi will not be a solely Gnome application until Gnome runs on at least
> > > Windows, BeOS, QNX and Mac. My personal opinion is that Abi should
> > > concentrate on core WP capabilities in its XP framework and pull in other
> > > components as needed via a component interface."
> > >
> > > True, Abi was always had XP as a goal. But so has StarOffice. Actually,
> > > in terms of design, StarOffice and AbiSuite are very similar, from the
> > > 50,000 foot view. C++ abstractions to cover portability.
> >
> > But then they have their own xp GUI rather than our more pragmatic
> > approach of native widget implementation. Just changing their GUI to gtk
> > will be a huge job. We have this and 4 other GUI's already.
> >
>
> umm... wrong. OpenOffice has a c++ abstraction layer (called vcl) what can
> in principle live on top of any toolkit/windowing system. No reason there
> could not be an OpenOffice/Athena, OpenOffice/gtk, OpenOffice/KDE,
> OpenOffice/motif, openoffice/xxxx
>
> The only part you should have to modify would be vcl - the rest of
> OpenOffice uses vcl.
This sounds lots like what we do in AbiWord.
Question: how much do you abstract?
In Abi, we have an abstraction layer for the toolkit (our XAP framework)
but we also have lots of platform specific code (not really lots, but
significant amounts). For example, every dialog for AbiWord has a cross-
platform component, but also a platform-specific component for each platform
it has been ported to.
There was a suggestion recently to add a more complete abstraction layer
but we decided against going in that direction, partly in view of the very
wide portability of GTK.
At what level do the vcl abstractions operate?
> >
> > I'll restate the major license problem. Abi is GPL'd and Open Office is
> > dual licensed. Open Office won't accept code that is not dual licensed.
> > AFAIU this second license (apart from the GPL) allows another company to
> > take Open Office code and incorporate it into their product without
> > releasing the source. If I'm correct in my understanding of this license
> > then it would take a VERY strong argument to convince just me to agree to
> > this, let alone the >100 contributers to Abi. Please correct me I'm wrong
> > someone.
> >
> > I'm personally not interested in writing anything other than GPL'd code.
> >
> > Ok so the question arises will Sun change its dual license policy? Without
> > such a change there cannot be a merger. We can take code from them but
> > they can't take code from us.
> >
>
> I am not qualified to talk for Sun on any such issues. I also *PERSONALY*
> find the present licence setup to be A Good Thing.
>
> > About "not being a sole gnome project" what I meant was that we should not
> > compromise our xp capabilities when with a bit of work we can develop a
> > full featured Gnome Office component and a powerful xp Wordprocessor.
> >
> > You should not under-estimate the value of being truely cross platform.
> > 99% of Computer users do not run Gnome. I see no reason why Abi should
> > limit itself to 1% of the Computer Population when with the present
> > framework we can reach >95% of the computer population.
> >
>
> Same here. At least as far as I am concerned.
>
> > I fully agree. We should ask Sun why we should dual license our code.
> >
>
> Why should the code not be dual licenced?
>
With regards to licensing, there are three problems:
1) Tracking all 115 contributors down.
2) Whether the SISSL is acceptable to any or all of them.
3) Copyright assignment. Personally, I am unwilling to assign copyright of
my code to Sun. I think they have good intentions with regard to this
project, and I respect them greatly for releasing this great body of code,
but I am not willing to trust that they will always be this enlightened.
sam th
sam uchicago edu
http://www.abisource.com/~sam/
GnuPG Key:
http://pgp5.ai.mit.edu:11371/pks/lookup?op=get&search=0xCABD33FC
Attachment:
pgpmsRKQTrKFi.pgp
Description: PGP signature