incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: OO/LO License
Date Sat, 04 Jun 2011 22:31:25 GMT
Dave Fisher <> wrote on 06/04/2011 05:35:32 PM:

> On Jun 4, 2011, at 1:17 PM, Sam Ruby wrote:
> > On Sat, Jun 4, 2011 at 4:02 PM, Dave Fisher <> 
> >> 
> >> Once licensing issues are understood then a way the two 
> communities might mutually cooperate becomes clear. And here it is 
> LO/TDF might contribute to Apache OO by providing portions of the LO
> codebase as MPL binary libraries.
> >> 
> >> Sam, is this the direction you are leading us?
> > 
> > While minor portions of a distribution which are unlikely to need to
> > be modified may be made available under the MPL, it is not the intent
> > of the ASF to produce distributions consisting substantially of
> > materials made available under other licenses.
> Agreed about substantial. My point was conceptual. Components and 
> extensions with difficult IP provenance OOo might not have a place 
> under the ASL. If LO/TDP were willing to package such components in,
> for example, an MPL licensed LO binary library, then the Apache OO 
> podling or project might use these as a part of OOo until it makes 
> the decision to replace it with other code.

My understanding is that TDF could do something like this, but only in a 
very limited way.  The issue is that they have the OOo code only under 
LGPLv3.  They then are dual licensing all of their new work (the delta 
since LO started) under LGPLv3/MPL.  So only the delta is under MPL.  It 
is not clear to what extent any of the LO enhancements can easily be 
bundled into a coherent module that would be interesting to reuse. 

But certainly, from a technical perspective, there are extension points in 
the OOo/LO code base that lend themselves to this approach, e.g., file 
filters, plugins, other extensions, etc.

My hope is that regardless of how OOo/LO collaborate in the future, it 
would make sense for us to maintain a directory (so not host the binaries 
at Apache, but more a catalog with external links) to such extensions, of 
any license.

And as I wrote earlier, I think in the new Apache OpenOffice project we 
should explore ways of enabling additional extension points as well.  For 
example, with Lotus Symphony we've added a mechanism to integrate web 



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

View raw message