incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <>
Subject RE: Extensions hosting
Date Fri, 06 Jan 2012 20:16:57 GMT
At some point it would be good to return to the use cases that are of concern and what they

 1. There are extensions that are bundled in the setup that is delivered as part of the install
process for a binary release.  These extensions are installed in a specific place while the
installer is running under elevated privileges.  (On Windows this is a place that is normally
not writeable by running applications.)

 2. There are extensions (in .oxt files) and templates in whatever files they are in that
the application (OO.o and LO) will install when "opened" (i.e., the extension manager is fired
up on them).  These will be installed by the application, but, on Windows at least, in a special
cache that is separated from (1) and that does not require elevated privileges to create.
 It does require special knowledge to locate.  The .oxt is the more-useful artifact.

 3. There are potentially (though I have not seen it done) additional extension or their updates
that the application will find and download on behalf of users.  I assume these are handled
as in (2), if at all.

There are different levels of concern, and the considerations may vary depending on what the
path (1-3) is:

 A. The licenses that apply to the extensions and how the users are made aware of them (preferably
with a way to acknowledge and also to opt-out).

 B. The way that the material is not easily separable from its license information and that
users will be aware of the license if the material is accessed in its installed locations
without the application as an intermediary.  (This is not unlike the situation with fonts
as well.)

 C. Security issues related to the threat surface of the application and the prospect of exploits
being achieved by crafting of malicious extensions/templates or subverting the download process
itself or the cached extension locations.  This leads to consideration of authentication and
reliance on existing procedures for secure delivery, detection of counterfeit/trojan materials,

 - Dennis

-----Original Message-----
From: Dave Fisher [] 
Sent: Friday, January 06, 2012 10:21
Subject: Re: Extensions hosting

On Jan 6, 2012, at 10:17 AM, Dave Fisher wrote:

> On Jan 6, 2012, at 9:56 AM, Rob Weir wrote:
>> On Fri, Jan 6, 2012 at 12:39 PM, Ross Gardler
>> <> wrote:
>>> On 6 January 2012 16:31, Rob Weir <> wrote:
>>>> On Fri, Jan 6, 2012 at 11:20 AM, Ross Gardler
>>>> <> wrote:
>>>>> On 6 January 2012 15:49, Rob Weir <> wrote:
>>>>>> On Fri, Jan 6, 2012 at 10:24 AM, Ross Gardler
>>>>>> <> wrote:
>>>>>>> On 6 January 2012 15:03, Rob Weir <>
>>>>>>> ...
>>>>>>>>> I'm not saying you *will* be allowed to host them, I'm
saying you
>>>>>>>>> *may* be allowed to. Similarly, I'm asking you, and others,
to stop
>>>>>>>>> saying you *won't* be able to host them.
>>>>> ...
>>>>>>> Lets continue to focus on what the AOO *wants* not what some
of us
>>>>>>> perceive is *allowed*. Once we know what is wanted we can explore
>>>>>>> is possible.
>>>>>> OK.  So if we want to host the extensions site, as is, and have it
>>>>>> conform to some revised ASF policy, then we would need to be able
>>>>>> do things like:
>>>>>> 1) Host GPL extensions on Apache servers, using websites associated
>>>>>> with Apache products, using Apache trademarks.  In other words,
>>>>>> without the distance the Board has encouraged the use of Apache-Extras
>>>>>> for in the past.
>>>>> That is not a correct summary of the ASFs position. We do not
>>>>> *develop* software that is under any licence other than ALv2 (go to
>>>>> apache-extras). As far as I understand it the extensions site does not
>>>>> provide development support.
>>>>> We do not distribute incompatibly licensed code that might restrict
>>>>> the rights of our downstream users to *modify* the source of our
>>>>> projects. Since none of the extensions will be bundled with AOO
>>>>> releases this is not relevant.
>>>> You seem to be saying that anything not forbidden may be allowed.
>>> No, I'm saying that as a mentor of the AOO podling, as a long standing Member
of The Apache Software Foundation and as a current VP of the foundation I believe that I have
a pretty good feel for why things are the way they are. This allows me to, with reasonable
confidence, guess at what would be allowed and what would not.
>> As always, thanks Ross for your mentor's wise words of advise.  But I
>> personally am having difficulties determining sometimes whether you
>> are merely giving mentorly advice versus actively advocating, like a
>> PMC member, for one particular outcome over another.   If your intent
>> really is to argue against the SF proposal (which is how it looks to
>> me) then maybe we can just get a clean, unadorned argument for that
>> position, one with fewer hats.  So far I've seen no one else but you
>> argue that position, so it would be good for the overall discussion to
>> hear it, from you personally.  I think that would be allowed,  right?
> I'm reading this thread. The message is that ASF policy is flexible to a certain extent.
It is not like a corporation's policy which is likely to be bureaucratically inflexible. Rob,
would you please try to get used to that ;-)
> The proposal is now somewhat buried in this long thread.
> There are issues to decide.
> (1) What is the AOO vision of extensions, templates in the longer term (or even AOO 3.4)?
> (2) How do we get Extensions and Templates stable?
> (3) How do we disconnect E and T from using Oracle infrastructure for userids and passwords?

One more point - extensions are critical for Native Language support and some language packs
are only available with an incompatible license.

>>> At the very least, I know the boundaries of my knowledge and I know who to ask
once I know what to ask. Hence this thread.
> Thank you!
> Regards,
> Dave
>>> Ross

View raw message