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 15:35:06 GMT
On Fri, Jan 6, 2012 at 10:08 AM, Ross Gardler
<> wrote:
> On 6 January 2012 14:07, Rob Weir <> wrote:
>> 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
>>>>> if we cannot keep the current repository as part of the project anyway,
>>>>> 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".
> Yes, that is what I meant by the word "single" damn the English
> language and it's subtleties.
>> At least I hope so, since we're currently allowing OSL to host.
> That's a different issue, that is a hosting provider. I was referring
> to brand association and profiteering as a result.
>>> 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.
> I already did in an earlier message:
> "If distributed it''s GPL since it's Drupal based. It could be argued
> that (assuming it's implemented as modules) that the modules are are
> not derivatives, but that is not the policy of the Drupal project [1]

I would argue, using the Drupal licensing FAQ's themselves, that this
analysis is encouraging, but not comprehensive:

"However, when distributing your own Drupal-based work, it is
important to keep in mind what the GPL applies to. The GPL on code
applies to code that interacts with that code, but not to data. That
is, Drupal's PHP code is under the GPL, and so all PHP code that
interacts with it must also be under the GPL or GPL compatible.
Images, JavaScript, and Flash files that PHP sends to the browser are
not affected by the GPL because they are data"


I assuming the website consists of more than just 100% PHP code that
calls Drupal?

> Note, I don't believe there is currently any license applied, Gav
> reported that he got permission from Oracle to just take it."

That should be adequate for hosting only by Infra and never making the
code available to others to use.  In other words, not allowing us to
encourage a larger ecosystem.  But we can probably do better, or at
least consider whether we might.

> ...
>>> 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.
> Agreed, but then that is more work again that someone has to do.

None if this is without work implications.   Even having Infra work on
stabilizing the current code has the implication that they then have
less time available to work on other things, including the Buildbots
that are probably even more critical for this project.

But the fact is SF is volunteering to help us with the extension
repository, but not offering to help us with Buildbots.  Knowing all
of these demands and constraints, what is the best solution?

>>> 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.
> As an IPMC member I would be concerned about a promise of breaking the
> Sourceforge stranglehold on the extensions site for the reasons I
> express above (ASF cannot benefit one organisation over another).
> However, I am only a single member of the IPMC and others may not have
> the same concerns.

"Stranglehold"?  I think that inflammatory term is not apt.   There
are other catalogs of OpenOffice extensions and templates.

For example, the FSF has one where they selected per their licensing

We could point to that.

The LibreOffice extensions repository should also be compatible:

We could point to that.

There are other template collections for OpenOffice.


We could point to them.

So I don't think we would have a reasonable worry about a "stranglehold".

> That being said, I had assumed that shipped AOO code would point to a
> single, or even default site. Although the financial gain is not the
> same I see this as being comparable to Firefox shipping with Google as
> the default search engine. Mozilla can do this because of their legal
> structure, the ASF cannot.

I believe we're talking about the website, not the product.

When we talked in the past about enabling the product to point to an
extension website, I think the thought was that we'd point to an
Apache catalog that contained only officially released extensions,
e.g., ALv2, QA'ed, voted on by PMC, etc.  That would be the safe thing
to do.  With a public, open extension repository we cannot really even
vouch for them being entirely free of malware.  It is really "as-is"
with a big disclaimer.  So it would probably not be appropriate for us
to point to them by default in the product.  (That was Dennis's
concern, as I understand it);.

> A proposal that addresses this concern would be good (and yes, I note
> your suggestion for dealing with this that might be sufficient, anyone
> else have ideas?)
> Ross
> --
> Ross Gardler (@rgardler)
> Programme Leader (Open Development)
> OpenDirective

View raw message