openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan i <>
Subject Re: Background to Cooperation: ASF/AOO Principles, Policies, Practices
Date Sun, 28 Jun 2015 21:52:42 GMT
On 28 June 2015 at 19:49, Dennis E. Hamilton <> wrote:

> I want to be very clear about the narrowness of the exemplary Apache
> OpenOffice exception.  See the remark below.  And to see how one wends
> through the deliberations around obtaining an exception, <
>> is exemplary.  A general
> exploration of <> reveals
> more cases as well as how rare exceptions are.
>  - Dennis
> -----Original Message-----
> From: Dennis E. Hamilton []
> Sent: Saturday, June 27, 2015 16:56
> To:
> Subject: Background to Cooperation: ASF/AOO Principles, Policies, Practices
> [ ... ]
> There are many practices that support how the ASF pursues its mission.
> The use of mailing lists is one example.  The use of services supported on
> Apache infrastructure is another.
> There can be exceptions to policy and deviations among practices.
> Exceptions tend to be very specific and not generalized.  (I suspect a
> generalization would be a change/amendment of policy and a serious review
> of any conflicts with established principles.)
> An example of an exception that is specific to the Apache OpenOffice
> project is the distribution of convenience binaries that have writing-aid
> plug-ins bundled with them that are not themselves under a license that is
> acceptable for source-code releases.  There are a number of specific,
> delimited provisions under which this action is found consistent with
> Apache principles although it is an exception to a general policy.  This
> practice was only introduced after obtaining review and eventual
> concurrence via the list on which legal and license questions are discussed.
> <orcmid>
>     The narrowness of the exception for these plug-ins is that they
>     contain no code, they deliver data in a general format that can
>     be used in a well-defined technique, and that they are completely
>     replaceable.  Users can also install additional ones of their
>     choosing and remove/disable the ones that are provided in the
>     binary distributions as a convenience.  It is also the case that,
>     if one inspects the plug-in (using a form of Zip package), one
>     would encounter all applicable license information and there would
>     be no confusion over the license that is specific to them material
>     conveyed by a given plug-in.
> </orcmid>

I would be very careful about interpreting the above extract. The plugins
do contains quite a lot of code, and some of them like the dictionaries are
not really
optional. We actually deliver plugins as part of our own exe, so we do
distribute some of the plugins without a special license.

But legal has looked at what we deliver and accepted it, so no need to
detail that further.

You also use the word "narrowness", as if these exceptions are written in
stone, that is not the case, we can always ask for other exceptions if
needed (whether
we get them is a different matter).

jan i.

> [ ... ]
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message