incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niall Pemberton <>
Subject Re: A little OOo history
Date Tue, 07 Jun 2011 16:11:08 GMT
On Tue, Jun 7, 2011 at 4:52 PM, William A. Rowe Jr. <> wrote:
> On 6/7/2011 10:23 AM, Phillip Rhodes wrote:
>> One question about the comment above though:  Are you advocating that Apache
>> OOo stick to source-only releases, and avoid
>> building and delivering binaries altogether?  Or is your idea that Apache
>> OOo would deliver builds, but that they be "Vanilla OOo" , ala the "vanilla
>> kernel" from, with a presumption that (some|most|all) end-users
>> will choose to use a distribution provided by somebody else... where
>> somebody else could be IBM, Novell, LibreOffice, Red Hat, etc.?
> Just to clarify, only source code is "released" by the ASF.  Yes, there may

I don't believe this is true - we have to release the source, but
anything we distribute is considered released and needs to be
checked/approved - and the release FAQ seems to agree with that


> be binary artifacts built on that code (esp in the case of .jars), and some
> of the reviewers may choose to verify available binaries, and some may also
> verify their own binary builds, before voting on the release.
> Some|most|all end-users (by which I mean administrators and even developers
> using tools such as eclipse) obtain most Apache software as you describe
> above, from another party.  In fact, RedHat might pick up the entire
> LibreOffice stack which in turn is derived from much shared OOo code, while
> a BSD distribution might pick up only the AL OOo base, and an entirely
> unrelated office productivity suite might pick only document manipulation
> classes from an AL OOo code base.
> As an observer to the CoApp project at OuterCurve, I'm particularly
> excited by what that project could accomplish with a Windows package,
> starting from the AL base, including the LibreOffice work in GPL/CC that
> the ASF would be unwilling to host.  As an .msi based distribution which
> shakes out at the library/component level, upgrades from release to release
> might consume far less bandwidth.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message