openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lawrence Rosen" <>
Subject RE: Concerns about the AOO community
Date Sat, 04 Oct 2014 18:31:23 GMT
FWIW, I want to share some of my own concerns. The problem here is not with Apache's willingness
to contribute to LO, but with Apache's willingness to accept contributions from LO under whatever
FOSS license LO settles on.

Does anyone here believe that even .001% of the users of either version of Open Office gives
a crap that we might turn this valuable software into a compendium of FOSS software components,
each component under its own FOSS license, some Apache and some something else? The entire
package will be FOSS as far as any end-user is concerned. 

This is something Apache can solve by accepting LO's contributions under LO's license. We
don't have to wait for LO to do that for us. I gather they made it even easier for us by transitioning
LO from GPL to MPL 2.0.

Only the antiquated Apache Third Party License Policy stands in the way and that's just a
document that can be changed. Stop letting FOSS licensing arguments among projects interfere
with technical solutions! The rest, as Dennis and Jan point out, is merely the easy stuff
of getting people on different FOSS projects to work well with each other. 

To quote Jan I:
> c) The people "in charge" should be told that this is
> what the communities want, and make it happen.


-----Original Message-----
From: Dennis E. Hamilton [] 
Sent: Saturday, October 4, 2014 10:13 AM
Subject: RE: Concerns about the AOO community

<orcnote>s below.

-----Original Message-----
From: jan i []
Sent: Saturday, October 4, 2014 07:58
To: dev
Subject: Re: Concerns about the AOO community

[ ... ]

In my opinion BOTH projects have made a lot of progress on their own (NOT by using code from
the other), and that should be acknowledged.

[ ... ]

In my humble opinion we could easily have a shared codebase of minimun 80% of the code. Put
it in a common git repository and allow LO as well as AOO committers to write code. The 2
projects would then have the last 20% in their own respective repositories.

Doing that would require only 3 changes:
a) all common code must be multi licensed, which is the case for most of code already.
b) AOO should grant LO committers committer status and visa versa.
c) The people "in charge" should be told that this is what the communities want, and make
it happen.

[ ... ]

jan I.

I think there are grounds for collaboration.  However, adding committers requires that the
Apache Software Foundation requirements for committers must be honored.  At least one TDF
Member has done so.  That participation is to be cherished.

There is already a common codebase but not via shared repository.  To create a shared repository
of common components that are collaboratively maintained probably requires different modularization
of the code base.  Having it be outside of the ASF infrastructure and also multi-licensed
raises all kinds of issues that appear to be far above the pay grade of the AOO Project. 

The AOO SVN trunk is already mirrored on GitHub. Is there any process for accepting pull requests
to it?

There is no problem with AOO code being relied upon by LibreOffice.  At the ASF, forking is
a feature.  I think we need to take that to heart.  That LibreOffice has relied on that is,
after all, that argument that was made in the podling days of AOO on why having
granted to the ASF was no problem, since everything AOO might do was readily available to
LibreOffice the same as to anyone.  There is no problem with LibO partaking of the Symphony-originated
contributions that have been merged into AOO.  It hurts that there is no acknowledgment of
that mutual benefit, especially for accessibility improvements.

The problem is the barrier presented by what could be common fixes not being able to travel
from LibO to AOO because of licensing conflicts (absent those developers becoming ASF committers).
 This is not so important for feature differences unrelated to interoperability via ODF as
it is for fixes and improvements to the common 80%.  Interoperability improvements that are
not sharable are an user-community issue though and I fear the consequences of the resulting
incompatibilities will be felt far beyond the preferences of the individual projects and their

Also, there would have to be some common refactoring in order for the different personalities
of releases to be separated and a common core being mutually maintained.  Better modularization
would be great anyhow, since it could radically improve build and testing time.  Yet that
is a big distraction from the main work of either project.  An approach involving smaller
steps is better.

I think these are simple matters of fact.  And licensing issues will still impact what AOO
can and cannot rely on and how dependencies are managed accordingly.

I suppose the best that can be done on the AOO side of this is to persist in being good neighbors
and being a good example of cooperative development wherever opportunities arise.

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message