incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: Extensions hosting
Date Fri, 06 Jan 2012 14:07:15 GMT
On Fri, Jan 6, 2012 at 7:38 AM, Ross Gardler <> wrote:
> On 6 January 2012 11:52, Ross Gardler <> wrote:
>> On 6 January 2012 09:32, Andrea Pescetti <> wrote:
>>> On 04/01/2012 Roberto Galoppini wrote:
>>>> 2012/1/4 Jürgen Schmidt:
>> ...
>>> Sounds good. The stabilization phase can be done anywhere, but as Rob wrote
>>> if we cannot keep the current repository as part of the project anyway, it
>>> makes sense to do it as part of a larger effort.
>> Can we please put a stop to this meme. Nobody has said that it *can't*
>> be kept as part of the project. I have no idea why this keeps getting
>> repeated. There are issues to be addressed, but nobody has said we
>> can't address them. That's what this thread is about, creating a
>> proposal for the board to consider and give us an indication as to
>> whether it would be acceptable or not.
> Furthermore, please remember that to allow a single third party to
> host a required service for an Apache project is also against ASF
> policy. In fact it is quite possibly against the law (I'm no lawyer so
> this is speculation).

I think you meant to say to "exclusively allow a single third party".
At least I hope so, since we're currently allowing OSL to host.

> The ASF is a charity, as such we cannot do anything that benefits one
> organisation more than another. Allowing SF to host the *only*
> extensions site would mean that only SF could make a profit from doing
> so and thus the ASF would be benefiting SF more than anyone else. We
> can't slam one organisation (TOO, for example) whilst actively
> supporting another.

True, but no one has suggested giving SF any exclusive rights.  In
fact we've been talking about quite the opposite, of opening it up so
that even Apache does not have exclusive control and ability to host

> So far this thread has made it clear (at least to me) that there are
> two phases to this:
> - short-medium term stabilise the extensions code and hosting
> - long term move to a federated approach
> Stabilisation needs to happen before the 3.3 release
> Federation can't happen before the 3.4 release and may not happen until later
> Rob has suggested we consider accepting the SF offer and asking infra
> to help with the longer term goal of federation (which was originally
> suggested by Gav).
> In this proposal I would like to require that SF  open source their
> work on stabilising the platform (which is their intention, as I
> understand it). The federation code would be managed here in the
> foundation.

It would be good to clarify exactly what license the original site us
under as well.

> This means that the ASF remains in control of the "level playing
> field" since we control the point of entry to the federated platform.
> Others can start up catalogue sites if they want by using the existing
> Drupal code or by building something else that plugs into the
> federation site, which could simply be an FTP site and an meta-data
> file.
> The downside of this plan is that we lose control over the existing
> extensions platform, although we can take it back for internal hosting
> at any point since it is open source.
> On the other hand if the ASF maintains the Drupal extensions platform
> we cannot distribute it since it is GPL. We could put it on
> apache-extras, but that is no different to it being in SF without the
> SF offered resources.
> However, infra is not proposing, as I understand it, to distribute the
> platform. The infra proposal is for the ASF to host a federation
> platform and for individuals to provide a download location for their
> extensions (which could be their own website, SF, Google Code or
> whatever they want).
> There is very little difference, in my opinion, between these two
> proposals. The only significant different that I can see is who does
> the work in the short term. Am I missing something?

The longer-term federated approach does not need to be based on the
current Drupal solution.  It might share a similar data model to ease
migration.  But I don't see any reason why we could not make the
federated solution be based on ALv2 code.

> The middle ground is to have SF do the stabilisation and for the ASF
> to accelerate the move to a federated site. In my opinion (and it is
> only my opinion), this model risks slowing down graduation since the
> federation site would need to be active in order to ensure a level
> playing field for all.

I don't see federation as being a graduation requirement.  Remember,
federation is not needed for having a level playing field.  It merely
helps allow the different hosts to coordinate in an easier way to
benefit the users.

We could just as well enable fairness like this:

Take the current extensions URL: and have it be a static
page that says something like:

"As a service to our users we provide the following list of external
extensions and templates sites that work with Apache OpenOffice.
Since these are not official Apache OpenOffice releases, we do not
vouch for their quality or functionality.  They come in a variety of
licenses.  But many of our users find extensions to be a useful way to
enhance their use of Apache OpenOffice"

Then we give an alphabetic listing of links to anyone 1) who wants to
host extensions and 2) is not abusing our trademarks.

As you see, this is no different than how Apache projects deal with
3rd party ports and similar non-Apache releases.  We can do it fairly.

> From my point of view the decision hinges on how high up the priority
> list does the AOO community have a federated extensions site? If it's
> high and there will be plenty of work on the federation code then the
> "middle ground" option is a good one. If it is not high then we need
> to get feedback from the board as to whether my concerns about level
> playing fields are valid or not. We also need feedback from the IPMC
> (since legal@ has delegated to them) on whether we can resolve the IP
> issues relating to distributing non-apache licensed code via an ASF
> hosted extensions site (my personal opinion is that this will not be a
> significant problem as long as branding is managed correctly).
> Is this a fair (high level) summary of the position so far? If so
> which is the preferred route for AOO?

Maybe check with the board on whether disclaimer language, as I
outlined above, would be sufficient?

> Ross

View raw message