Extensions hosting

[Ross Gardler <rg...@opendirective.com>]

As the community know Gav, in his role at infrastructure@ has
undertaken to stabilise and migrate the AOO extensions code to ASF
infrastructure. His work has been progressing and he remains committed
to completing this.

However, as some know Sourceforge made an offer to help via our
private list. At the time they did not want to discuss this topic in
public for a number of reasons. I've had a couple of chats with
Roberto Gallopini and Jeff Drobick in order to help them understand
why the ASF prefers to host all services for its projects. In response
SF have tailored their offer of support.

I relayed the outline of our conversations to the infrastructure team
who have asked me to have the AOO project provide some feedback, via a
board report, on what problems the AOO project forsee for the
extensions site and what options are available, if possible a
recommendation for an optimal solution should also be made. Note that
we can submit something out of cycle if we want, the next full report
is not due till March.

The reason infra@ have escalated to board@ is probably that we need to
figure out a long term solution for the AOO project and that solution
is heavily influenced by ASF policy. Any solution that we are
currently considering will have an impact on the AOO extensions site
and/or on ASF policy.

The current situation, as I understand it, is that the board have
given permission for the extensions site to be managed by infra during
incubation. The problem of distributing content under licences other
than Apache is not seen to be a problem during the incubation process.
Beyond incubation the board has delegated responsibility to the
Incubator PMC. I don't believe that particular discussion has been
started yet.

Gav tells us that he has been thinking about making the extensions
site an index site, thus allowing the extensions to be housed
elsewhere (apache-extras, sourceforge, google code, github, FooBar
corporation or wherever). This would neatly bypass the licence
problem. Open source extensions needing hosting could go to
apache-extras while commercially licensed extensions would need to
provide their own hosting.

An alternative is to work with a third party willing to help. I've
copied below the text of a mail outlining the SF proposal. You will
note that they are keen to ensure that we don't get locked into the SF
services. Nevertheless, one of the reasons the ASF hosts its own
services is to avoid exposing us to unmanageable risk.

I have no reason to believe SourceForge have anything other than good
intentions in making this offer. SF has been supporting open source
for a very long time. It is backed at the highest level (Jeff is
President and CEO) and I believe Roberto is known within the
OpenOffce.org community. However, many aspects of this will be outside
of the control of the AOO project, despite SFs real attempts to
mitigate our concerns relating to this.

Please note that the timescales Jeff outlines are unrealistic given
that we need to seek board input before being able to ensure the AOO
project makes the right decision.  SF want to move quickly, but I
don't think we need to be rushed into making a decision.

Once you've digested and debated the offer from Sourceforge the
community needs to come up with a couple of paragraphs indicating a
desired route forwards and reasons for it. I will try and attend the
appropriate board meeting in order to answer any questions that arise.

Please be imaginative in your planning for the future. The optimal
solution might be some combination of ASF and SF offerings.

Note Roberto Gallopini has joined this list and is ready to make any
clarifications necessary. I've also made Gav aware of this post so
that he can answer any questions we have about what infra@ are able to
do.

Thanks,
Ross

--- COPIED PROPOSAL ---

I'm glad we had a chance to talk last week - exciting times for Open
Office as the product and community transition into the ASF.

For over a decade, SourceForge has been committed to advancing the
open source software community.  We host over 300,000 projects and are
visited by over 40 MM users per month for free, secure, and fast
downloads of open source software.  Trusted and reliable download
delivery is an important part of our service, with over 4 million
downloads per day and 2 PB from our mirror network each month.  We are
committed to helping OSS projects scale and grow.

Based on our discussions, we understand there are a few things you are
solving for as part of the Open Office Incubation effort:
Supporting a diverse licensing terms for Open Office extensions, that
may not all comply with the Apache OSS policy;
Stabilizing your Drupal OO Extensions site and ensuring high
availability and download bandwidth without cost
Expanding both the developer base who will move into working on the
Apache framework as well as adoption of the Open Office product and
extensions.
We think we can help and that there would be mutual benefit.  To that
end, we propose the following for your consideration:

1.) Stabilize the your OO Extensions Drupal instance by moving the it
and all services to SourceForge.  Our Site Operations team will do teh
work and oversee the operations for you as we do other services.  To
your community the directory will look the same and extension and
template files will move to SourceForge's globally-distributed
download mirror network where we can ensure reliable, scalable
delivery.  Drupal will be hosted on our project web service, serving
your existing domain via a VHOST.  Standard infrastructure
(monitoring, backups, etc.) and service levels (99.9% availability
target) apply.

These SourceForge services will be provided gratis, and without
lock-in -- you are open to change your mind later.  We anticipate this
migration would involve a week of planning and preparation, followed
by a week of migration and pre/post-migration communications.  We're
prepared to commence this work the next week if provided your approval
and support.

2.) Once stabilized, we will work with you on a timeline to evaluate
and execute a migration from Drupal 5 to Drupal 7.

Allowing us to host the Extensions community will solve the license
challenges - or at least give you time to work through a longer term
solution.  We would also be able to cross promote the software titles
to the development community as well - so perhaps expand not only your
user base but developers.

Roberto (our Sr. Director of Business Development) has been involved
in the OpenOffice.org community for many years -- he will continue to
be your point-of-contact.  If we secure the go-ahead this week, we
will start on Tuesday next week and expect to be complete by 1/15 with
step 1.  I have asked our head of Site Ops to oversee the
implementation and he'll partner up with your technical folks to
ensure the hosting transition goes well.

Our motivation here is quite simple, it is all part of our mission to
help Open Source Software initiatives succeed.  To that end,
SourceForge and Geeknet Media are able to fund these services and make
them free to the community through advertising largely on the download
and directory pages.  So there won't ever be a charge back to your
community and we are able to reinvest in R&D on our developer tools as
well.

We look forward to hearing back from you this week if possible.  Feel
free to forward this on to whomever you would like in terms of getting
to an aligned decision.

I wish you a happy new year!

-- 
Thank you,
Jeff

--- End of copied text ---
-- 
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com

Re: Extensions hosting

[Andrea Pescetti <pe...@apache.org>]

On 03/01/2012 17:25, Rob Weir wrote:
> On Tue, Jan 3, 2012 at 10:51 AM, Ross Gardler wrote:
>> making the extensions
>> site an index site, thus allowing the extensions to be housed
>> elsewhere (apache-extras, sourceforge, google code, github, FooBar
>> corporation or wherever). This would neatly bypass the licence
>> problem. ...
> That was my recommendation as well, in the previous thread referenced
> above.  It is more work up front

To make it clear once again: this is possible with the current 
Extensions website and it has always been possible. Some extensions 
listed on extensions.services.openoffice.org are hosted on SourceForge 
and downloaded from there, for example.

Regards,
   Andrea.

Re: Extensions hosting

[Ross Gardler <rg...@opendirective.com>]

On 3 January 2012 16:25, Rob Weir <ro...@apache.org> wrote:
> On Tue, Jan 3, 2012 at 10:51 AM, Ross Gardler
> <rg...@opendirective.com> wrote:
>> As the community know Gav, in his role at infrastructure@ has
>> undertaken to stabilise and migrate the AOO extensions code to ASF
>> infrastructure. His work has been progressing and he remains committed
>> to completing this.
>>
>> However, as some know Sourceforge made an offer to help via our
>> private list. At the time they did not want to discuss this topic in
>> public for a number of reasons. I've had a couple of chats with
>> Roberto Gallopini and Jeff Drobick in order to help them understand
>> why the ASF prefers to host all services for its projects. In response
>> SF have tailored their offer of support.
>>
>
> Thanks for the wonderful job of reaching out to SourceForge and
> connecting us to this offer, Ross.

Well they chased me down, all I did was agree to talk. They are
serious about this and wouldn't let me say "no" ;-) (well, I guess
they wouldn't have). Thanks anyway.

>> I relayed the outline of our conversations to the infrastructure team
>> who have asked me to have the AOO project provide some feedback, via a
>> board report, on what problems the AOO project forsee for the
>> extensions site and what options are available, if possible a
>> recommendation for an optimal solution should also be made. Note that
>> we can submit something out of cycle if we want, the next full report
>> is not due till March.
>>
>
> This has already been discussed, in detail in a previous thread:
>
> http://markmail.org/message/sm57zvd5gnblxpo6
>
> I believe that discussion is what prompted Gavin to action.  If
> someone wants to copy and paste that into a Board report, then they
> are welcome to do so.

Thanks for the pointer, always good not to duplicate effort. I'm not
sure that thread ever came to a conclusion though. It is certainly
what prompted Gav into action, but the solution Gav is currently
working on is a short term one for incubation. Longer term Gav is
committed to providing the meta-data repository. What happens to the
extensions after that? Do we host them at the ASF or do we work
something out with others, such as SF (and you are right to point out
this is not an either or, nor do we have to limit ourselves to SF
providing an extensions community environment).

I leave the rest of your post uncommented to allow others time to
speak up (and me time to re-read that thread to make sure I didn't
miss anything important). In general I agree with your observations
and would like to see the options you present (and others that come to
mind) explored.

Ross

Re: Extensions hosting

[Rob Weir <ro...@apache.org>]

On Wed, Jan 4, 2012 at 12:26 PM, Ariel Constenla-Haile
<ar...@apache.org> wrote:
>
> Hi *,
>
> On Wed, Jan 04, 2012 at 09:18:07AM +0100, Jürgen Schmidt wrote:
>> We should keep in mind that for many extension developers it's
>> probably ok to create a SF, GoogleCode or whatever project to host
>> the extension code and the binary. But i believe that there are also
>> many developers who simply want to put there macro collection in an
>> extension container with the necessary meta data and want share it
>> with others. Means they simply want to upload it for broader
>> availability without creating their own project or the necessity to
>> have their own webspace for hosting the binary extension.
>>
>> And i think this is even more important for templates. People create
>> a nice template and would ideally be able to upload it directly from
>> the office. Ok for upload we would need some kind of registration
>> and authentication to do that. But that would be very convenient for
>> users.
>
> not only templates, there is a whole set of NON-CODE extensions, that is
> you do not need to be a developer nor write any code to build very
> useful extensions!
> http://wiki.services.openoffice.org/wiki/Non-code_extensions
>
> You can not expect those "extension creators" (new term, as they are not
> developers in the sense of developing source code) to create a SF
> project or the like.
>

This is all true, but really orthogonal to the point.  I agree that we
need a simplified interface for providing templates, etc.  These are
users, maybe power uses, but they are not going to use SVN/Hg/git or
be patient with complicated procedures to upload a template. It should
be easy, like uploading a photo to your Facebook page.

But that is just user interface.  From the data perspective, you can
still have -- and I think we still should have -- a clean separation
between a repository of extensions or templates, a catalog of
extensions or templates, and an interface for doing a federated search
of multiple catalogs of extensions or templates.  It is not an
either/or situation.

-Rob

>
> Regards
> --
> Ariel Constenla-Haile
> La Plata, Argentina

Re: Extensions hosting

[Ariel Constenla-Haile <ar...@apache.org>]

Hi *,

On Wed, Jan 04, 2012 at 09:18:07AM +0100, Jürgen Schmidt wrote:
> We should keep in mind that for many extension developers it's
> probably ok to create a SF, GoogleCode or whatever project to host
> the extension code and the binary. But i believe that there are also
> many developers who simply want to put there macro collection in an
> extension container with the necessary meta data and want share it
> with others. Means they simply want to upload it for broader
> availability without creating their own project or the necessity to
> have their own webspace for hosting the binary extension.
> 
> And i think this is even more important for templates. People create
> a nice template and would ideally be able to upload it directly from
> the office. Ok for upload we would need some kind of registration
> and authentication to do that. But that would be very convenient for
> users.

not only templates, there is a whole set of NON-CODE extensions, that is
you do not need to be a developer nor write any code to build very
useful extensions!
http://wiki.services.openoffice.org/wiki/Non-code_extensions

You can not expect those "extension creators" (new term, as they are not
developers in the sense of developing source code) to create a SF
project or the like.


Regards
-- 
Ariel Constenla-Haile
La Plata, Argentina

Re: Extensions hosting

[Roberto Galoppini <rg...@geek.net>]

On Fri, Jan 6, 2012 at 10:32 AM, Andrea Pescetti <pe...@apache.org> wrote:
> On 04/01/2012 Roberto Galoppini wrote:
>>
>> 2012/1/4 Jürgen Schmidt:
>>
>>> We should keep in mind that for many extension developers it's probably
>>> ok
>>> to create a SF, GoogleCode or whatever project to host the extension code
>>> and the binary. But i believe that there are also many developers who
>>> simply
>>> want to put there macro collection in an extension container with the
>>> necessary meta data and want share it with others. Means they simply want
>>> to
>>> upload it for broader availability without creating their own project or
>>> the
>>> necessity to have their own webspace for hosting the binary extension.
>>
>>
>> The SourceForge proposed solution would support this in exactly the
>> way the current system does
>
>
> Perfect, and this addresses one of my few concerns with the (otherwise good,
> in my opinion) proposal from SourceForge. So it would possible to just
> upload an extension/template without turning it into a SF project.
>
>
>> First, what we're proposing in the short term is to migrate and
>> stabilize the current drupal instance using the sourceforge.net Secure
>> Project Web infrastructure.   This would give selected members of the
>> team SSH access to the server space where it's hosted, and full access
>> to both the code and database content.
>
>
> 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.
>
>
>> Middle term we would love to work with you to have this site become
>> the center of a federated extensions community.
>
>
> Again nice, but here I have a few issues:
>
> 1) The proposed Drupal 5 to Drupal 7 migration would indeed yield, if done
> properly, a "template site" that can be installed anywhere with the same
> capabilities. Would it be possible to design it so that as a result we have
> a ready-to-deploy "extension repository" website, under a proper free
> license, that can be installed in several places? This has partly been
> covered in other parts of the thread, but the key point here is to design
> the site to be flexible from the beginning: for example, the current
> Templates sites was developed this way (i.e., you can reinstall it and get a
> new Templates site) but the current Extensions site wasn't (i.e., to
> reinstall it you need to copy over the whole extensions database too and
> then try and clean it up properly).

This design can certainly done, and SF.net will assist in the process,
but our imediate goal is to stabilize the infrastructure and restore
service to users.

We are by no means tied to Drupal, and would support whatever "second
generation platform" the community chooses.   In fact we have some
relevant federation code  in python, based on feeds with DOAP payloads
that we might be able to donate to the process.

>
> 2) For those preferring to use other tools than Drupal, the protocol should
> still allow others to build their repositories/catalogs with tools of their
> choice, but it would be good and helpful to provide the Drupal 7 site as
> "reference implementation" and document it properly.

This is an important point, and we totally agree.

> 3) The community would need free access to statistics. It is very important
> for us to know how extensions are downloaded and updated. The current
> statistics are not very reliable due to caching and the multiple attempts
> needed to download an extension. Would SourceForge be available to share
> download figures and other statistics with the community?

We have a solid Hadoop based, download statistics system for downloads
from the mirror network, and we always make those totals public. We
can also work with the AOO community to get customized statistics if
that's required.

Roberto

> Regards,
>  Andrea.
====
This e- mail message is intended only for the named recipient(s) above. It may contain confidential and privileged information. If you are not the intended recipient you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and delete the message and any attachment(s) from your system. Thank you.

Re: Extensions hosting

[Joe Schaefer <jo...@yahoo.com>]

+1.



----- Original Message -----
> From: Ross Gardler <rg...@opendirective.com>
> To: ooo-dev@incubator.apache.org
> Cc: 
> Sent: Friday, January 6, 2012 9:39 AM
> Subject: Re: Extensions hosting
> 
> On 6 January 2012 13:53, Rob Weir <ro...@apache.org> wrote:
>>  On Fri, Jan 6, 2012 at 6:52 AM, Ross Gardler 
> <rg...@opendirective.com> wrote:
>>>  On 6 January 2012 09:32, Andrea Pescetti <pe...@apache.org> 
> 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.
>>> 
>> 
>>  If by "repository" you mean merely the software that hosts the
>>  repository, then you are correct.  If by "repository" you mean 
> also
>>  all of the extensions and templates that are hosted in the repository,
>>  including GPL, trialware, demoware and other commercial, non OSS
>>  extensions, then I think Juergen is correct.
> 
> I mean distributing the extensions from ASF hardware, including the
> licence incompatible ones.
> 
> To my knowledge nobody has said that this cannot be done at the ASF in
> the long term. What has been said is that current policy does not
> allow for it. Permission is granted to serve them here during
> incubation and the resolution of the policy issue has been delegated
> to the IPMC.
> 
> Nobody has said what the conclusion of the IPMC will be longer term
> and, to my knowledge, nobody has asked either.
> 
>>  In fact we've been told
>>  that this would be an issue for graduation.
> 
> One of us is mistaken. Please point me to a mail that says anything
> other than the *policy* issues need to be resolved.
> 
> 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.
> 
> Ross
> 

Re: Extensions hosting

[Rob Weir <ro...@apache.org>]

On Fri, Jan 6, 2012 at 1:54 PM, Dave Fisher <da...@comcast.net> wrote:
>
> On Jan 6, 2012, at 10:23 AM, Rob Weir wrote:
>
>> On Fri, Jan 6, 2012 at 1:17 PM, Dave Fisher <da...@comcast.net> wrote:
>>>
>>> On Jan 6, 2012, at 9:56 AM, Rob Weir wrote:
>>>
>>>> On Fri, Jan 6, 2012 at 12:39 PM, Ross Gardler
>>>> <rg...@opendirective.com> wrote:
>>>>> On 6 January 2012 16:31, Rob Weir <ro...@apache.org> wrote:
>>>>>> On Fri, Jan 6, 2012 at 11:20 AM, Ross Gardler
>>>>>> <rg...@opendirective.com> wrote:
>>>>>>> On 6 January 2012 15:49, Rob Weir <ro...@apache.org> wrote:
>>>>>>>> On Fri, Jan 6, 2012 at 10:24 AM, Ross Gardler
>>>>>>>> <rg...@opendirective.com> wrote:
>>>>>>>>> On 6 January 2012 15:03, Rob Weir <ro...@apache.org> wrote:
>>>>>>>>>
>>>>>>>>> ...
>>>>>>>>>
>>>>>>>>>>> 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 what
>>>>>>>>> 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 to
>>>>>>>> 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 ;-)
>>>
>>
>> It is very easy Dave, to dismiss someone who works for a large
>> corporation by suggesting that they are bureaucratic and inflexible
>> and otherwise have a defective thinking process.  This slur is a form
>> of personal attack and I suggest you (and others) drop it.
>
> I was not dismissing your comments. I base my comments about corporations from experience. I've worked for small companies most of my career where JFDI was the normal course. We were purchased by a publicly held corporation and there is all kinds of extra administrative actions to take. A lot of talk for what is sometimes a one liner. Corporations have different responsibilities than Individuals, like SOX compliance.
>
>>
>> No one has questioned whether or not we can appeal to the IPMC or the
>> ASF Board and change policy.  This is obviously possible.  But it
>> obviously requires time, effort and has an uncertain outcome.  So
>> let's not say it is impossible.  But let's also not say it is the only
>> path, or even the easiest path.
>
> We probably ought to do think about it, even if looks hard, but it might be easier than you think.
>
>>
>>
>>> 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?
>
> Don't we need to agree on the ideal (1) and then work back from that? You posted your view of (1) earlier and that seemed inflexible to me.
>

I'm puzzled by that remark.  What exactly do you think my view of (1)
is, and in what way do you think it is inflexible?

I thought it was very flexible.  In fact it could work even if we had
a single repository hosted by Infra.

In any case, I do not believe that the short term solution requires we
first agree on the long term solution.  What we have now is unstable.
If the problem were merely that the server was unplugged surely no
sane person would suggest that we cannot plug it in again until we had
a long term solution.  Would you?  Similarly, if the server is
unstable for lack of CPUs or lack of maintenance, then surely one
could accept an offer to stabilize it without prejudice to the long
term solution.

> But I'm already spending too much time on Apache this morning.
>
> Regards,
> Dave
>
>
>>>
>>>
>>>>
>>>>> 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
>>>
>

Re: Extensions hosting

[Dave Fisher <da...@comcast.net>]

On Jan 6, 2012, at 10:23 AM, Rob Weir wrote:

> On Fri, Jan 6, 2012 at 1:17 PM, Dave Fisher <da...@comcast.net> wrote:
>> 
>> On Jan 6, 2012, at 9:56 AM, Rob Weir wrote:
>> 
>>> On Fri, Jan 6, 2012 at 12:39 PM, Ross Gardler
>>> <rg...@opendirective.com> wrote:
>>>> On 6 January 2012 16:31, Rob Weir <ro...@apache.org> wrote:
>>>>> On Fri, Jan 6, 2012 at 11:20 AM, Ross Gardler
>>>>> <rg...@opendirective.com> wrote:
>>>>>> On 6 January 2012 15:49, Rob Weir <ro...@apache.org> wrote:
>>>>>>> On Fri, Jan 6, 2012 at 10:24 AM, Ross Gardler
>>>>>>> <rg...@opendirective.com> wrote:
>>>>>>>> On 6 January 2012 15:03, Rob Weir <ro...@apache.org> wrote:
>>>>>>>> 
>>>>>>>> ...
>>>>>>>> 
>>>>>>>>>> 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 what
>>>>>>>> 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 to
>>>>>>> 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 ;-)
>> 
> 
> It is very easy Dave, to dismiss someone who works for a large
> corporation by suggesting that they are bureaucratic and inflexible
> and otherwise have a defective thinking process.  This slur is a form
> of personal attack and I suggest you (and others) drop it.

I was not dismissing your comments. I base my comments about corporations from experience. I've worked for small companies most of my career where JFDI was the normal course. We were purchased by a publicly held corporation and there is all kinds of extra administrative actions to take. A lot of talk for what is sometimes a one liner. Corporations have different responsibilities than Individuals, like SOX compliance.

> 
> No one has questioned whether or not we can appeal to the IPMC or the
> ASF Board and change policy.  This is obviously possible.  But it
> obviously requires time, effort and has an uncertain outcome.  So
> let's not say it is impossible.  But let's also not say it is the only
> path, or even the easiest path.

We probably ought to do think about it, even if looks hard, but it might be easier than you think.

> 
> 
>> 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?

Don't we need to agree on the ideal (1) and then work back from that? You posted your view of (1) earlier and that seemed inflexible to me.

But I'm already spending too much time on Apache this morning.

Regards,
Dave


>> 
>> 
>>> 
>>>> 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
>> 

Re: Extensions hosting

[Rob Weir <ro...@apache.org>]

On Fri, Jan 6, 2012 at 1:17 PM, Dave Fisher <da...@comcast.net> wrote:
>
> On Jan 6, 2012, at 9:56 AM, Rob Weir wrote:
>
>> On Fri, Jan 6, 2012 at 12:39 PM, Ross Gardler
>> <rg...@opendirective.com> wrote:
>>> On 6 January 2012 16:31, Rob Weir <ro...@apache.org> wrote:
>>>> On Fri, Jan 6, 2012 at 11:20 AM, Ross Gardler
>>>> <rg...@opendirective.com> wrote:
>>>>> On 6 January 2012 15:49, Rob Weir <ro...@apache.org> wrote:
>>>>>> On Fri, Jan 6, 2012 at 10:24 AM, Ross Gardler
>>>>>> <rg...@opendirective.com> wrote:
>>>>>>> On 6 January 2012 15:03, Rob Weir <ro...@apache.org> wrote:
>>>>>>>
>>>>>>> ...
>>>>>>>
>>>>>>>>> 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 what
>>>>>>> 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 to
>>>>>> 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 ;-)
>

It is very easy Dave, to dismiss someone who works for a large
corporation by suggesting that they are bureaucratic and inflexible
and otherwise have a defective thinking process.  This slur is a form
of personal attack and I suggest you (and others) drop it.

No one has questioned whether or not we can appeal to the IPMC or the
ASF Board and change policy.  This is obviously possible.  But it
obviously requires time, effort and has an uncertain outcome.  So
let's not say it is impossible.  But let's also not say it is the only
path, or even the easiest path.


> 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?
>
>
>>
>>> 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
>

RE: Extensions hosting

["Dennis E. Hamilton" <de...@acm.org>]

An afterthought.

There is 

 1B. Binary distributions packaged by other originators and that are tied to the Apache OpenOffice project in some manner (e.g., it is someone else's "edition" but otherwise resembles an AOO binary release) that may have bundled extensions (1, below) that are not provided in the corresponding Apache OpenOffice release and should not be regarded as having the same provenance and being the responsibility of the Apache OpenOffice project.

-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] 
Sent: Friday, January 06, 2012 12:17
To: ooo-dev@incubator.apache.org
Subject: RE: Extensions hosting

At some point it would be good to return to the use cases that are of concern and what they represent:


 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, etc.

 - Dennis

-----Original Message-----
From: Dave Fisher [mailto:dave2wave@comcast.net] 
Sent: Friday, January 06, 2012 10:21
To: ooo-dev@incubator.apache.org
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
>> <rg...@opendirective.com> wrote:
>>> On 6 January 2012 16:31, Rob Weir <ro...@apache.org> wrote:
>>>> On Fri, Jan 6, 2012 at 11:20 AM, Ross Gardler
>>>> <rg...@opendirective.com> wrote:
>>>>> On 6 January 2012 15:49, Rob Weir <ro...@apache.org> wrote:
>>>>>> On Fri, Jan 6, 2012 at 10:24 AM, Ross Gardler
>>>>>> <rg...@opendirective.com> wrote:
>>>>>>> On 6 January 2012 15:03, Rob Weir <ro...@apache.org> wrote:
>>>>>>> 
>>>>>>> ...
>>>>>>> 
>>>>>>>>> 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 what
>>>>>>> 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 to
>>>>>> 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
> 

RE: Extensions hosting

["Dennis E. Hamilton" <de...@acm.org>]

At some point it would be good to return to the use cases that are of concern and what they represent:


 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, etc.

 - Dennis

-----Original Message-----
From: Dave Fisher [mailto:dave2wave@comcast.net] 
Sent: Friday, January 06, 2012 10:21
To: ooo-dev@incubator.apache.org
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
>> <rg...@opendirective.com> wrote:
>>> On 6 January 2012 16:31, Rob Weir <ro...@apache.org> wrote:
>>>> On Fri, Jan 6, 2012 at 11:20 AM, Ross Gardler
>>>> <rg...@opendirective.com> wrote:
>>>>> On 6 January 2012 15:49, Rob Weir <ro...@apache.org> wrote:
>>>>>> On Fri, Jan 6, 2012 at 10:24 AM, Ross Gardler
>>>>>> <rg...@opendirective.com> wrote:
>>>>>>> On 6 January 2012 15:03, Rob Weir <ro...@apache.org> wrote:
>>>>>>> 
>>>>>>> ...
>>>>>>> 
>>>>>>>>> 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 what
>>>>>>> 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 to
>>>>>> 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
> 

Re: Extensions hosting

[Dave Fisher <da...@comcast.net>]

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
>> <rg...@opendirective.com> wrote:
>>> On 6 January 2012 16:31, Rob Weir <ro...@apache.org> wrote:
>>>> On Fri, Jan 6, 2012 at 11:20 AM, Ross Gardler
>>>> <rg...@opendirective.com> wrote:
>>>>> On 6 January 2012 15:49, Rob Weir <ro...@apache.org> wrote:
>>>>>> On Fri, Jan 6, 2012 at 10:24 AM, Ross Gardler
>>>>>> <rg...@opendirective.com> wrote:
>>>>>>> On 6 January 2012 15:03, Rob Weir <ro...@apache.org> wrote:
>>>>>>> 
>>>>>>> ...
>>>>>>> 
>>>>>>>>> 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 what
>>>>>>> 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 to
>>>>>> 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
> 

Re: Extensions hosting

[Dave Fisher <da...@comcast.net>]

On Jan 6, 2012, at 9:56 AM, Rob Weir wrote:

> On Fri, Jan 6, 2012 at 12:39 PM, Ross Gardler
> <rg...@opendirective.com> wrote:
>> On 6 January 2012 16:31, Rob Weir <ro...@apache.org> wrote:
>>> On Fri, Jan 6, 2012 at 11:20 AM, Ross Gardler
>>> <rg...@opendirective.com> wrote:
>>>> On 6 January 2012 15:49, Rob Weir <ro...@apache.org> wrote:
>>>>> On Fri, Jan 6, 2012 at 10:24 AM, Ross Gardler
>>>>> <rg...@opendirective.com> wrote:
>>>>>> On 6 January 2012 15:03, Rob Weir <ro...@apache.org> wrote:
>>>>>> 
>>>>>> ...
>>>>>> 
>>>>>>>> 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 what
>>>>>> 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 to
>>>>> 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?


> 
>> 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

Re: Extensions hosting

[Rob Weir <ro...@apache.org>]

On Fri, Jan 6, 2012 at 12:39 PM, Ross Gardler
<rg...@opendirective.com> wrote:
> On 6 January 2012 16:31, Rob Weir <ro...@apache.org> wrote:
>> On Fri, Jan 6, 2012 at 11:20 AM, Ross Gardler
>> <rg...@opendirective.com> wrote:
>>> On 6 January 2012 15:49, Rob Weir <ro...@apache.org> wrote:
>>>> On Fri, Jan 6, 2012 at 10:24 AM, Ross Gardler
>>>> <rg...@opendirective.com> wrote:
>>>>> On 6 January 2012 15:03, Rob Weir <ro...@apache.org> wrote:
>>>>>
>>>>> ...
>>>>>
>>>>>>> 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 what
>>>>> 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 to
>>>> 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?

> 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.
>
> Ross

Re: Extensions hosting

[Ross Gardler <rg...@opendirective.com>]

On 6 January 2012 16:31, Rob Weir <ro...@apache.org> wrote:
> On Fri, Jan 6, 2012 at 11:20 AM, Ross Gardler
> <rg...@opendirective.com> wrote:
>> On 6 January 2012 15:49, Rob Weir <ro...@apache.org> wrote:
>>> On Fri, Jan 6, 2012 at 10:24 AM, Ross Gardler
>>> <rg...@opendirective.com> wrote:
>>>> On 6 January 2012 15:03, Rob Weir <ro...@apache.org> wrote:
>>>>
>>>> ...
>>>>
>>>>>> 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 what
>>>> 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 to
>>> 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.

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.

Ross

Re: Extensions hosting

[Rob Weir <ro...@apache.org>]

On Fri, Jan 6, 2012 at 11:20 AM, Ross Gardler
<rg...@opendirective.com> wrote:
> On 6 January 2012 15:49, Rob Weir <ro...@apache.org> wrote:
>> On Fri, Jan 6, 2012 at 10:24 AM, Ross Gardler
>> <rg...@opendirective.com> wrote:
>>> On 6 January 2012 15:03, Rob Weir <ro...@apache.org> wrote:
>>>
>>> ...
>>>
>>>>> 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 what
>>> 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 to
>> 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.  I
disagree.  For example, what if we wanted to sell "Re-elect Barack
Obama" umbrellas on an online store front at openoffice,org?   This
would not be "developing" software.  So it is allowed?  Of course not.
 You need to refer back to the Foundation's charitable mission, which
is not infinite in scope, by its charter and by law.  I'd question
whether the scope does in fact include distributing non OSS software
and even facilitating the collection of payment for the same.  This is
a Foundation question, not an IPMC one.  The question is far broader
than the copyleft versus non-copyleft question that the IPMC deals
with on a regular basis.

> As a by-product of these two policies we do not, at present,
> distribute any incompatible binaries under normal circumstances. This
> is the part that we would need to get approval. Remember that this
> approval has been delegated to the IPMC and anyone in this community
> can seek it at any time.
>
> As for using Apache trademarks we have a policy that, in my opinion,
> will cover the vast majority of cases for the extensions site (there
> might be a need to ask maintainers to update their sites and the PPMC
> will have to take ownership of this. This will be the case wherever
> the extension is hosted. How effective the PPMC can be in this matter
> is a different issue, but since it is not affected by the location of
> the hosting it is irrelevant in this discussion, I think.
>
>> 2) Similarly, the repository currently includes non OSS extensions,
>> including demos of proprietary extensions, and various forms of
>> demoware and trialware extensions.  We would need permission to host
>> these, again, on Apache servers that bear trademarked names, e.g., an
>> openoffice.org website.
>
> As with 1) above.
>
>> 3) Similarly we have at least one case today where the extension
>> website hosts a Paypal link for collecting money for an extension.  We
>> would need permission from the Board to host 3rd party revenue
>> collection links on Apache servers using domain names associated with
>> ASF-owned trademarks.
>
> It's hard for me to understand this one as the extensions site is down
> and so I can't see any examples. Are you saying the ASF extensions
> site would have a webpage with a paypal link (or similar), where the
> payment goes to some third party maintaining the extension?
>

Yes.  For a particular extension.  That is what we have in at least
one instance today.

> This one is a little harder. On the one hand I would say that as long
> as the trademark policy was enforced for these extensions then it
> would be fine. On the other hand, if the AOO PPMC is deciding who
> can/can not be listed there is a potential for conflict here. I'd like
> to get further guidance on this.
>
>> I still happen to
>> think, for other reasons that I've stated, that opening this up and
>> encouraging the broader ecosystem is the better way to do it, rather
>> than enforcing an Apache stranglehold.
>
> HA!!! I see you chose to throw the inflammatory language back at me,
> fair enough ;-)
>
> Seriously though, I have no objection to this being the outcome of
> this conversation. I agree there are some clear advantages. I just
> want to be certain that conclusion is drawn from the right facts.
>
>> But in parallel with that
>> discussion let's establish the policy change possibilities, so we're
>> not arguing on top of mush.
>
> Agreed. I remind the community of the purpose of this thread, from my
> first mail:
>
> "Once you've digested and debated the offer from Sourceforge the
> community needs to come up with a couple of paragraphs indicating a
> desired route forwards and reasons for it. I will try and attend the
> appropriate board meeting in order to answer any questions that arise."
>
> We've gone a very long way to coming to those couple of paras, this
> policy issue was a minor diversion that I think is now over.
>
> Ross
>
>
> --
> Ross Gardler (@rgardler)
> Programme Leader (Open Development)
> OpenDirective http://opendirective.com

Re: Extensions hosting

[Ross Gardler <rg...@opendirective.com>]

On 6 January 2012 17:24, Roberto Galoppini <rg...@geek.net> wrote:

...

> I want to take the chance here to say again we're not looking or
> exclusivity, just offering to help. As I wrote earlier, we can state
> it formally, providing the ASF and AOO with all necessary compliances
> and assurances.

Quite right. I apologise for using a word in the general context that
might have implied a specific criticism of your proposal, that was not
my intention.

Ross

Re: Extensions hosting

[MiguelAngel <ma...@miguelangel.mobi>]

El 06/01/12 19:30, Pedro Giffuni escribió:
>
> --- Ven 6/1/12, Roberto Galoppini ha scritto:
> ...
>>
>> I want to take the chance here to say again we're not
>> looking or exclusivity, just offering to help. As I
>> wrote earlier, we can state it formally, providing
>> the ASF and AOO with all necessary compliances
>> and assurances.
>>
>> Roberto
>>
>
> The ASF does have a similar arrangement with Google for
> apache-extras.org and no one is complaining about
> exclusivity or favoring anyone in particular. It's
> a cool service and we appreciate it.
>
> Most of us are rather new to this type of agreements but
> I, for one, have to say that I very much appreciate
> the SF proposal and the efforts to help in solving
> this important issue for OpenOffice users. If other
> providers want to join they are welcome but we have
> to recognize that SourceForge has taken the lead
> here.
>
> Pedro.

+1
If the policies of ASF allow the arrangement with SF.
Please solve the users issues first of all, as soon as can be.
(Save disagreements in the pocket for a while).
Thanks in advance, from an user.
Miguel Ángel.

Re: Extensions hosting

[Pedro Giffuni <pf...@apache.org>]

--- Ven 6/1/12, Roberto Galoppini ha scritto:
...
> 
> I want to take the chance here to say again we're not
> looking or exclusivity, just offering to help. As I
> wrote earlier, we can state it formally, providing
> the ASF and AOO with all necessary compliances
> and assurances.
> 
> Roberto
>

The ASF does have a similar arrangement with Google for
apache-extras.org and no one is complaining about
exclusivity or favoring anyone in particular. It's
a cool service and we appreciate it. 

Most of us are rather new to this type of agreements but
I, for one, have to say that I very much appreciate
the SF proposal and the efforts to help in solving
this important issue for OpenOffice users. If other
providers want to join they are welcome but we have
to recognize that SourceForge has taken the lead
here.

Pedro.

Re: Extensions hosting

[Roberto Galoppini <rg...@geek.net>]

On Fri, Jan 6, 2012 at 5:20 PM, Ross Gardler <rg...@opendirective.com> wrote:
> On 6 January 2012 15:49, Rob Weir <ro...@apache.org> wrote:
>> On Fri, Jan 6, 2012 at 10:24 AM, Ross Gardler
>> <rg...@opendirective.com> wrote:
>>> On 6 January 2012 15:03, Rob Weir <ro...@apache.org> wrote:
>>>
>>> ...
>>>
>>>>> 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 what
>>> 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 to
>> 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.
>
> As a by-product of these two policies we do not, at present,
> distribute any incompatible binaries under normal circumstances. This
> is the part that we would need to get approval. Remember that this
> approval has been delegated to the IPMC and anyone in this community
> can seek it at any time.
>
> As for using Apache trademarks we have a policy that, in my opinion,
> will cover the vast majority of cases for the extensions site (there
> might be a need to ask maintainers to update their sites and the PPMC
> will have to take ownership of this. This will be the case wherever
> the extension is hosted. How effective the PPMC can be in this matter
> is a different issue, but since it is not affected by the location of
> the hosting it is irrelevant in this discussion, I think.
>
>> 2) Similarly, the repository currently includes non OSS extensions,
>> including demos of proprietary extensions, and various forms of
>> demoware and trialware extensions.  We would need permission to host
>> these, again, on Apache servers that bear trademarked names, e.g., an
>> openoffice.org website.
>
> As with 1) above.
>
>> 3) Similarly we have at least one case today where the extension
>> website hosts a Paypal link for collecting money for an extension.  We
>> would need permission from the Board to host 3rd party revenue
>> collection links on Apache servers using domain names associated with
>> ASF-owned trademarks.
>
> It's hard for me to understand this one as the extensions site is down
> and so I can't see any examples. Are you saying the ASF extensions
> site would have a webpage with a paypal link (or similar), where the
> payment goes to some third party maintaining the extension?
>
> This one is a little harder. On the one hand I would say that as long
> as the trademark policy was enforced for these extensions then it
> would be fine. On the other hand, if the AOO PPMC is deciding who
> can/can not be listed there is a potential for conflict here. I'd like
> to get further guidance on this.
>
>> I still happen to
>> think, for other reasons that I've stated, that opening this up and
>> encouraging the broader ecosystem is the better way to do it, rather
>> than enforcing an Apache stranglehold.
>
> HA!!! I see you chose to throw the inflammatory language back at me,
> fair enough ;-)
>
> Seriously though, I have no objection to this being the outcome of
> this conversation. I agree there are some clear advantages. I just
> want to be certain that conclusion is drawn from the right facts.
>
>> But in parallel with that
>> discussion let's establish the policy change possibilities, so we're
>> not arguing on top of mush.
>
> Agreed. I remind the community of the purpose of this thread, from my
> first mail:
>
> "Once you've digested and debated the offer from Sourceforge the
> community needs to come up with a couple of paragraphs indicating a
> desired route forwards and reasons for it. I will try and attend the
> appropriate board meeting in order to answer any questions that arise."

I want to take the chance here to say again we're not looking or
exclusivity, just offering to help. As I wrote earlier, we can state
it formally, providing the ASF and AOO with all necessary compliances
and assurances.

Roberto


> We've gone a very long way to coming to those couple of paras, this
> policy issue was a minor diversion that I think is now over.
>
> Ross
>
>
> --
> Ross Gardler (@rgardler)
> Programme Leader (Open Development)
> OpenDirective http://opendirective.com
====
This e- mail message is intended only for the named recipient(s) above. It may contain confidential and privileged information. If you are not the intended recipient you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and delete the message and any attachment(s) from your system. Thank you.

Re: Extensions hosting

[Ross Gardler <rg...@opendirective.com>]

On 6 January 2012 15:49, Rob Weir <ro...@apache.org> wrote:
> On Fri, Jan 6, 2012 at 10:24 AM, Ross Gardler
> <rg...@opendirective.com> wrote:
>> On 6 January 2012 15:03, Rob Weir <ro...@apache.org> wrote:
>>
>> ...
>>
>>>> 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 what
>> 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 to
> 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.

As a by-product of these two policies we do not, at present,
distribute any incompatible binaries under normal circumstances. This
is the part that we would need to get approval. Remember that this
approval has been delegated to the IPMC and anyone in this community
can seek it at any time.

As for using Apache trademarks we have a policy that, in my opinion,
will cover the vast majority of cases for the extensions site (there
might be a need to ask maintainers to update their sites and the PPMC
will have to take ownership of this. This will be the case wherever
the extension is hosted. How effective the PPMC can be in this matter
is a different issue, but since it is not affected by the location of
the hosting it is irrelevant in this discussion, I think.

> 2) Similarly, the repository currently includes non OSS extensions,
> including demos of proprietary extensions, and various forms of
> demoware and trialware extensions.  We would need permission to host
> these, again, on Apache servers that bear trademarked names, e.g., an
> openoffice.org website.

As with 1) above.

> 3) Similarly we have at least one case today where the extension
> website hosts a Paypal link for collecting money for an extension.  We
> would need permission from the Board to host 3rd party revenue
> collection links on Apache servers using domain names associated with
> ASF-owned trademarks.

It's hard for me to understand this one as the extensions site is down
and so I can't see any examples. Are you saying the ASF extensions
site would have a webpage with a paypal link (or similar), where the
payment goes to some third party maintaining the extension?

This one is a little harder. On the one hand I would say that as long
as the trademark policy was enforced for these extensions then it
would be fine. On the other hand, if the AOO PPMC is deciding who
can/can not be listed there is a potential for conflict here. I'd like
to get further guidance on this.

> I still happen to
> think, for other reasons that I've stated, that opening this up and
> encouraging the broader ecosystem is the better way to do it, rather
> than enforcing an Apache stranglehold.

HA!!! I see you chose to throw the inflammatory language back at me,
fair enough ;-)

Seriously though, I have no objection to this being the outcome of
this conversation. I agree there are some clear advantages. I just
want to be certain that conclusion is drawn from the right facts.

> But in parallel with that
> discussion let's establish the policy change possibilities, so we're
> not arguing on top of mush.

Agreed. I remind the community of the purpose of this thread, from my
first mail:

"Once you've digested and debated the offer from Sourceforge the
community needs to come up with a couple of paragraphs indicating a
desired route forwards and reasons for it. I will try and attend the
appropriate board meeting in order to answer any questions that arise."

We've gone a very long way to coming to those couple of paras, this
policy issue was a minor diversion that I think is now over.

Ross


-- 
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com

Re: Extensions hosting

[Rob Weir <ro...@apache.org>]

On Fri, Jan 6, 2012 at 10:24 AM, Ross Gardler
<rg...@opendirective.com> wrote:
> On 6 January 2012 15:03, Rob Weir <ro...@apache.org> wrote:
>
> ...
>
>>> 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.
>>>
>>
>> You are playing games with semantics.  If something is out of policy
>> then it is correct to say we may not do it, where "we" is the PPPC.
>> That is a statement about the here and now.  Whether "we" could do it
>> if the policy changed, or whether "we" left Apache and set up
>> elsewhere, are all interesting questions, but not really the here and
>> now.
>
> This is really not helpful. The ASF is not a place where things are
> written in stone. On multiple occasions I and others, have said the
> policy might be changeable here.
>
> What we are discussing are the options for the *future*. I am not
> playing with semantics I am stating a simple fact - if the policy as
> it is today is restricting the AOO podling the ASF will consider
> changing that policy.
>
> At best arguing against this fact is a waste of time, at worst
> claiming this fact is not relevant is preventing us from considering
> other potential solutions.
>
> 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 what
> 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 to
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.

2) Similarly, the repository currently includes non OSS extensions,
including demos of proprietary extensions, and various forms of
demoware and trialware extensions.  We would need permission to host
these, again, on Apache servers that bear trademarked names, e.g., an
openoffice.org website.

3) Similarly we have at least one case today where the extension
website hosts a Paypal link for collecting money for an extension.  We
would need permission from the Board to host 3rd party revenue
collection links on Apache servers using domain names associated with
ASF-owned trademarks.

I apologize for suggesting that any of these might not be allowed at
Apache.  Let's keep an open mind and let Ross inquire whether policy
might be changed to allow these three things.  I still happen to
think, for other reasons that I've stated, that opening this up and
encouraging the broader ecosystem is the better way to do it, rather
than enforcing an Apache stranglehold.  But in parallel with that
discussion let's establish the policy change possibilities, so we're
not arguing on top of mush.

> Ross

Re: Extensions hosting

[Ross Gardler <rg...@opendirective.com>]

On 6 January 2012 15:03, Rob Weir <ro...@apache.org> wrote:

...

>> 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.
>>
>
> You are playing games with semantics.  If something is out of policy
> then it is correct to say we may not do it, where "we" is the PPPC.
> That is a statement about the here and now.  Whether "we" could do it
> if the policy changed, or whether "we" left Apache and set up
> elsewhere, are all interesting questions, but not really the here and
> now.

This is really not helpful. The ASF is not a place where things are
written in stone. On multiple occasions I and others, have said the
policy might be changeable here.

What we are discussing are the options for the *future*. I am not
playing with semantics I am stating a simple fact - if the policy as
it is today is restricting the AOO podling the ASF will consider
changing that policy.

At best arguing against this fact is a waste of time, at worst
claiming this fact is not relevant is preventing us from considering
other potential solutions.

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 what
is possible.

Ross

Re: Extensions hosting

[Rob Weir <ro...@apache.org>]

On Fri, Jan 6, 2012 at 9:39 AM, Ross Gardler <rg...@opendirective.com> wrote:
> On 6 January 2012 13:53, Rob Weir <ro...@apache.org> wrote:
>> On Fri, Jan 6, 2012 at 6:52 AM, Ross Gardler <rg...@opendirective.com> wrote:
>>> On 6 January 2012 09:32, Andrea Pescetti <pe...@apache.org> 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.
>>>
>>
>> If by "repository" you mean merely the software that hosts the
>> repository, then you are correct.  If by "repository" you mean also
>> all of the extensions and templates that are hosted in the repository,
>> including GPL, trialware, demoware and other commercial, non OSS
>> extensions, then I think Juergen is correct.
>
> I mean distributing the extensions from ASF hardware, including the
> licence incompatible ones.
>
> To my knowledge nobody has said that this cannot be done at the ASF in
> the long term. What has been said is that current policy does not
> allow for it. Permission is granted to serve them here during
> incubation and the resolution of the policy issue has been delegated
> to the IPMC.
>
> Nobody has said what the conclusion of the IPMC will be longer term
> and, to my knowledge, nobody has asked either.
>
>> In fact we've been told
>> that this would be an issue for graduation.
>
> One of us is mistaken. Please point me to a mail that says anything
> other than the *policy* issues need to be resolved.
>
> 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.
>

You are playing games with semantics.  If something is out of policy
then it is correct to say we may not do it, where "we" is the PPPC.
That is a statement about the here and now.  Whether "we" could do it
if the policy changed, or whether "we" left Apache and set up
elsewhere, are all interesting questions, but not really the here and
now.

> Ross

Re: Extensions hosting

[Ross Gardler <rg...@opendirective.com>]

On 6 January 2012 13:53, Rob Weir <ro...@apache.org> wrote:
> On Fri, Jan 6, 2012 at 6:52 AM, Ross Gardler <rg...@opendirective.com> wrote:
>> On 6 January 2012 09:32, Andrea Pescetti <pe...@apache.org> 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.
>>
>
> If by "repository" you mean merely the software that hosts the
> repository, then you are correct.  If by "repository" you mean also
> all of the extensions and templates that are hosted in the repository,
> including GPL, trialware, demoware and other commercial, non OSS
> extensions, then I think Juergen is correct.

I mean distributing the extensions from ASF hardware, including the
licence incompatible ones.

To my knowledge nobody has said that this cannot be done at the ASF in
the long term. What has been said is that current policy does not
allow for it. Permission is granted to serve them here during
incubation and the resolution of the policy issue has been delegated
to the IPMC.

Nobody has said what the conclusion of the IPMC will be longer term
and, to my knowledge, nobody has asked either.

> In fact we've been told
> that this would be an issue for graduation.

One of us is mistaken. Please point me to a mail that says anything
other than the *policy* issues need to be resolved.

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.

Ross

Re: Extensions hosting

[Rob Weir <ro...@apache.org>]

On Fri, Jan 6, 2012 at 6:52 AM, Ross Gardler <rg...@opendirective.com> wrote:
> On 6 January 2012 09:32, Andrea Pescetti <pe...@apache.org> 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.
>

If by "repository" you mean merely the software that hosts the
repository, then you are correct.  If by "repository" you mean also
all of the extensions and templates that are hosted in the repository,
including GPL, trialware, demoware and other commercial, non OSS
extensions, then I think Juergen is correct.  In fact we've been told
that this would be an issue for graduation.  Since the repository with
the hosted extensions is the relevant service to our users, I think
that is what we should be concerned about.

> Please keep your minds open. Starting from the assumption that the
> extensions hosting *has* to move from the ASF is false and is closing
> off one of the options available to the project.
>
> Ross

Re: Extensions hosting

[Rob Weir <ro...@apache.org>]

On Fri, Jan 6, 2012 at 2:49 PM, Dave Fisher <da...@comcast.net> wrote:
>
> On Jan 6, 2012, at 11:07 AM, Andrew Rist wrote:
>
>> +1
>>
>>   - short-medium term stabilise the extensions code and hosting
>>   - long term move to a federated approach
>>
>> I think this is indeed the growing consensus.  I support moving forward with SF in negotiating an approach that conforms to the boundaries you describe below and lead us in this direction.
>
> Agreed that this is the general consensus. I think that these are different threads of conversation.
>
> One thread is the MOU with SF defining what a stable E & T requires including dealing with the loss of the Oracle based user registrations on which it still depends.
>

Just to be fair, we should ask if Infra@ had a solution for how they
would maintain the service "with the loss of the Oracle based user
registrations on which still depends"?

> The second thread is what does the federated approach look-like. Jürgen has provided some of what is already supported. I think we need a page somewhere to show the existing structure. We can't proceed intelligently without real choices clearly presented. Otherwise we are talking generalities, or making decisions based on our perceptions of policy boundaries and not technical merit. The fastest approach to graduation might not be the best approach for the whole ecosystem.
>
> While we are on the topic of externally hosted services last week Rory Flatscher was happy to report that codesnippets.s.oo.o was still functional. This is an externally hosted site at BestSolutions@ ...
>
> Regards,
> Dave
>
>>
>> Andrew
>>
>>
>> On 1/6/2012 4:38 AM, Ross Gardler wrote:
>>> On 6 January 2012 11:52, Ross Gardler<rg...@opendirective.com>  wrote:
>>>> On 6 January 2012 09:32, Andrea Pescetti<pe...@apache.org>  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).
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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 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.
>>>
>>> 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?
>>>
>>> Ross
>>
>

Re: Extensions hosting

[Dave Fisher <da...@comcast.net>]

On Jan 6, 2012, at 11:07 AM, Andrew Rist wrote:

> +1
> 
>   - short-medium term stabilise the extensions code and hosting
>   - long term move to a federated approach
> 
> I think this is indeed the growing consensus.  I support moving forward with SF in negotiating an approach that conforms to the boundaries you describe below and lead us in this direction.

Agreed that this is the general consensus. I think that these are different threads of conversation.

One thread is the MOU with SF defining what a stable E & T requires including dealing with the loss of the Oracle based user registrations on which it still depends.

The second thread is what does the federated approach look-like. Jürgen has provided some of what is already supported. I think we need a page somewhere to show the existing structure. We can't proceed intelligently without real choices clearly presented. Otherwise we are talking generalities, or making decisions based on our perceptions of policy boundaries and not technical merit. The fastest approach to graduation might not be the best approach for the whole ecosystem.

While we are on the topic of externally hosted services last week Rory Flatscher was happy to report that codesnippets.s.oo.o was still functional. This is an externally hosted site at BestSolutions@ ...

Regards,
Dave

> 
> Andrew
> 
> 
> On 1/6/2012 4:38 AM, Ross Gardler wrote:
>> On 6 January 2012 11:52, Ross Gardler<rg...@opendirective.com>  wrote:
>>> On 6 January 2012 09:32, Andrea Pescetti<pe...@apache.org>  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).
>> 
>> 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.
>> 
>> 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.
>> 
>> 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 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.
>> 
>> 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?
>> 
>> Ross
> 

Re: Extensions hosting

[Andrew Rist <an...@oracle.com>]

+1

    - short-medium term stabilise the extensions code and hosting
    - long term move to a federated approach

I think this is indeed the growing consensus.  I support moving forward 
with SF in negotiating an approach that conforms to the boundaries you 
describe below and lead us in this direction.

Andrew


On 1/6/2012 4:38 AM, Ross Gardler wrote:
> On 6 January 2012 11:52, Ross Gardler<rg...@opendirective.com>  wrote:
>> On 6 January 2012 09:32, Andrea Pescetti<pe...@apache.org>  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).
>
> 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.
>
> 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.
>
> 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 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.
>
>  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?
>
> Ross

Re: Extensions hosting

[Jürgen Schmidt <jo...@googlemail.com>]

On 1/6/12 4:55 PM, Ross Gardler wrote:
> On 6 January 2012 15:35, Rob Weir<ro...@apache.org>  wrote:
>> On Fri, Jan 6, 2012 at 10:08 AM, Ross Gardler
>
> ...
>
>>> 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.
>
> I agree my language is too strong. Even without considering the fact
> that there are other catalogues as you point out.
>
>>> 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.
>
> I seem to have been misunderstanding something about how the
> extensions manager works. My fault for making assumptions. I imagined
> it listing all available extensions within the application,

that was the initial idea but for specific reasons not implemented yet. 
But it's the idea for the future and a long term solution.
Browsing directly form the app is a huge improvement and would increase 
the user experience a lot i would say ;-)

However,
> having actually looked at it, I see I am actually presented with a
> single link to the extensions site. Sorry, I should have looked
> earlier, would have saved us some time.
not only

The linked ext repo is the default and also used for updates of extensions.

Extensions from our repo don't contain an update Url. The extension 
manager knows if no update Url is present the default repo has to be 
asked for update info about this ext.

It's tricky and the technical details and relation are often really 
important to understand.

Juergen

>
> If that link were pointing at SF then I would be concerned me
> (remember we are talking about at the point of graduation). If it
> links to a website with multiple catalogues listed, or if there are
> multiple links within the product my concern is no longer valid. Such
> a modification is easy to make, even for 3.3.
>
> Thanks for putting me straight.
>
>> 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);.
>
> Yes, this is the long term strategy we've been discussing and I think
> it is a healthy goal. But does the AOO podling really want to limit it
> to ALv2?
>
> Ross

Re: Extensions hosting

[Rob Weir <ro...@apache.org>]

On Fri, Jan 6, 2012 at 10:55 AM, Ross Gardler
<rg...@opendirective.com> wrote:
> On 6 January 2012 15:35, Rob Weir <ro...@apache.org> wrote:
>> On Fri, Jan 6, 2012 at 10:08 AM, Ross Gardler
>
> ...
>
>>> 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.
>
> I agree my language is too strong. Even without considering the fact
> that there are other catalogues as you point out.
>
>>> 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.
>
> I seem to have been misunderstanding something about how the
> extensions manager works. My fault for making assumptions. I imagined
> it listing all available extensions within the application, However,
> having actually looked at it, I see I am actually presented with a
> single link to the extensions site. Sorry, I should have looked
> earlier, would have saved us some time.
>
> If that link were pointing at SF then I would be concerned me
> (remember we are talking about at the point of graduation). If it
> links to a website with multiple catalogues listed, or if there are
> multiple links within the product my concern is no longer valid. Such
> a modification is easy to make, even for 3.3.
>
> Thanks for putting me straight.
>
>> 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);.
>
> Yes, this is the long term strategy we've been discussing and I think
> it is a healthy goal. But does the AOO podling really want to limit it
> to ALv2?
>

Long term, I see something like this:

Product has a UI for extension repositories, with ability for user to
add, remove, enable or disable them.  Each repository is a URL.
Out-of-the-box, AOO releases would have only a single repository
enabled.  This would be the Apache one, containing only "released" (in
the Apache sense) extensions from this project, or maybe eventually
even other Apache projects.  We might have links to others in the
"extension repository" manager, but they would be disabled by default
and would have a warning when enabled.  There would be a UI for the
user to search across all enabled repositories, for keyboards, etc.
User can download/install extensions/templates from the UI. Maybe this
evolves to include clipart libraries, code snippets, and other
artifacts  eventually.

Honestly, to me the issue is not so much license, but vetting to
ensure users are not harmed.  We already see on the web today
companies that are using adulterated OpenOffice downloads to insert
adware onto machines.  The brand is strong enough to attract that.  If
we enable the outo-of-the-box install experience to allow direct
downloads/installs of non-Apache released extensions, then some users
will certainly be harmed.  Not all, but you can guarantee that there
will be malware in the repository.  The risk could be reduced by a
review/approval workflow controlled by the PMC, if we really wanted to
do that.

Of course, disabling the non-Apache repositories and requiring the
user to explicitly enable them doesn't really fix things either.  It
is more a point of making a clear separation between what is Apache
approved and what is not.

In some sense this is an iOS walled garden versus Android wild west question.

-Rob

> Ross

Re: Extensions hosting

[Ross Gardler <rg...@opendirective.com>]

On 6 January 2012 15:35, Rob Weir <ro...@apache.org> wrote:
> On Fri, Jan 6, 2012 at 10:08 AM, Ross Gardler

...

>> 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.

I agree my language is too strong. Even without considering the fact
that there are other catalogues as you point out.

>> 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.

I seem to have been misunderstanding something about how the
extensions manager works. My fault for making assumptions. I imagined
it listing all available extensions within the application, However,
having actually looked at it, I see I am actually presented with a
single link to the extensions site. Sorry, I should have looked
earlier, would have saved us some time.

If that link were pointing at SF then I would be concerned me
(remember we are talking about at the point of graduation). If it
links to a website with multiple catalogues listed, or if there are
multiple links within the product my concern is no longer valid. Such
a modification is easy to make, even for 3.3.

Thanks for putting me straight.

> 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);.

Yes, this is the long term strategy we've been discussing and I think
it is a healthy goal. But does the AOO podling really want to limit it
to ALv2?

Ross

Re: Extensions hosting

[Rob Weir <ro...@apache.org>]

On Fri, Jan 6, 2012 at 10:08 AM, Ross Gardler
<rg...@opendirective.com> wrote:
> On 6 January 2012 14:07, Rob Weir <ro...@apache.org> wrote:
>> On Fri, Jan 6, 2012 at 7:38 AM, Ross Gardler <rg...@opendirective.com> wrote:
>>> On 6 January 2012 11:52, Ross Gardler <rg...@opendirective.com> wrote:
>>>> On 6 January 2012 09:32, Andrea Pescetti <pe...@apache.org> 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".
>
> 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"

See: http://drupal.org/licensing/faq#q7

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
preferences:

http://libreplanet.org/wiki/Group:OpenOfficeExtensions/List

We could point to that.

The LibreOffice extensions repository should also be compatible:

http://extensions.libreoffice.org/extension-center

We could point to that.

There are other template collections for OpenOffice.

See:

http://openofficetemplates.net/

http://www.worldlabel.com/Pages/openoffice-template.htm

http://www.smalldataproblem.org/ooextras/

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 http://opendirective.com

Re: Extensions hosting

[Ross Gardler <rg...@opendirective.com>]

On 6 January 2012 14:07, Rob Weir <ro...@apache.org> wrote:
> On Fri, Jan 6, 2012 at 7:38 AM, Ross Gardler <rg...@opendirective.com> wrote:
>> On 6 January 2012 11:52, Ross Gardler <rg...@opendirective.com> wrote:
>>> On 6 January 2012 09:32, Andrea Pescetti <pe...@apache.org> 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".

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]

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

...

>> 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.

>> 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.

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.

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 http://opendirective.com

Re: Extensions hosting

[Rob Weir <ro...@apache.org>]

On Fri, Jan 6, 2012 at 7:38 AM, Ross Gardler <rg...@opendirective.com> wrote:
> On 6 January 2012 11:52, Ross Gardler <rg...@opendirective.com> wrote:
>> On 6 January 2012 09:32, Andrea Pescetti <pe...@apache.org> 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
extensions.

> 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:
http://extensions.services.openoffice.org/ 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

Re: Extensions hosting

[Ross Gardler <rg...@opendirective.com>]

On 6 January 2012 11:52, Ross Gardler <rg...@opendirective.com> wrote:
> On 6 January 2012 09:32, Andrea Pescetti <pe...@apache.org> 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).

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.

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.

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 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.

>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?

Ross

Re: Extensions hosting

[Ross Gardler <rg...@opendirective.com>]

On 6 January 2012 09:32, Andrea Pescetti <pe...@apache.org> 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.

Please keep your minds open. Starting from the assumption that the
extensions hosting *has* to move from the ASF is false and is closing
off one of the options available to the project.

Ross

Re: Extensions hosting

[Andrea Pescetti <pe...@apache.org>]

On 04/01/2012 Roberto Galoppini wrote:
> 2012/1/4 Jürgen Schmidt:
>> We should keep in mind that for many extension developers it's probably ok
>> to create a SF, GoogleCode or whatever project to host the extension code
>> and the binary. But i believe that there are also many developers who simply
>> want to put there macro collection in an extension container with the
>> necessary meta data and want share it with others. Means they simply want to
>> upload it for broader availability without creating their own project or the
>> necessity to have their own webspace for hosting the binary extension.
>
> The SourceForge proposed solution would support this in exactly the
> way the current system does

Perfect, and this addresses one of my few concerns with the (otherwise 
good, in my opinion) proposal from SourceForge. So it would possible to 
just upload an extension/template without turning it into a SF project.

> First, what we're proposing in the short term is to migrate and
> stabilize the current drupal instance using the sourceforge.net Secure
> Project Web infrastructure.   This would give selected members of the
> team SSH access to the server space where it's hosted, and full access
> to both the code and database content.

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.

> Middle term we would love to work with you to have this site become
> the center of a federated extensions community.

Again nice, but here I have a few issues:

1) The proposed Drupal 5 to Drupal 7 migration would indeed yield, if 
done properly, a "template site" that can be installed anywhere with the 
same capabilities. Would it be possible to design it so that as a result 
we have a ready-to-deploy "extension repository" website, under a proper 
free license, that can be installed in several places? This has partly 
been covered in other parts of the thread, but the key point here is to 
design the site to be flexible from the beginning: for example, the 
current Templates sites was developed this way (i.e., you can reinstall 
it and get a new Templates site) but the current Extensions site wasn't 
(i.e., to reinstall it you need to copy over the whole extensions 
database too and then try and clean it up properly).

2) For those preferring to use other tools than Drupal, the protocol 
should still allow others to build their repositories/catalogs with 
tools of their choice, but it would be good and helpful to provide the 
Drupal 7 site as "reference implementation" and document it properly.

3) The community would need free access to statistics. It is very 
important for us to know how extensions are downloaded and updated. The 
current statistics are not very reliable due to caching and the multiple 
attempts needed to download an extension. Would SourceForge be available 
to share download figures and other statistics with the community?

Regards,
   Andrea.

Re: Extensions hosting

[Roberto Galoppini <rg...@geek.net>]

Hi all, this is Roberto Galoppini (SourceForge),

I'd like to clarify a couple of things about what we're able to offer.

2012/1/4 Jürgen Schmidt <jo...@googlemail.com>:
> On 1/3/12 5:25 PM, Rob Weir wrote:
>>
>> On Tue, Jan 3, 2012 at 10:51 AM, Ross Gardler
>> <rg...@opendirective.com>  wrote:
>>>
>>> As the community know Gav, in his role at infrastructure@ has
>>> undertaken to stabilise and migrate the AOO extensions code to ASF
>>> infrastructure. His work has been progressing and he remains committed
>>> to completing this.
>>>
>>> However, as some know Sourceforge made an offer to help via our
>>> private list. At the time they did not want to discuss this topic in
>>> public for a number of reasons. I've had a couple of chats with
>>> Roberto Gallopini and Jeff Drobick in order to help them understand
>>> why the ASF prefers to host all services for its projects. In response
>>> SF have tailored their offer of support.
>>>
>>
>> Thanks for the wonderful job of reaching out to SourceForge and
>> connecting us to this offer, Ross.
>>
>>> I relayed the outline of our conversations to the infrastructure team
>>> who have asked me to have the AOO project provide some feedback, via a
>>> board report, on what problems the AOO project forsee for the
>>> extensions site and what options are available, if possible a
>>> recommendation for an optimal solution should also be made. Note that
>>> we can submit something out of cycle if we want, the next full report
>>> is not due till March.
>>>
>>
>> This has already been discussed, in detail in a previous thread:
>>
>> http://markmail.org/message/sm57zvd5gnblxpo6
>>
>> I believe that discussion is what prompted Gavin to action.  If
>> someone wants to copy and paste that into a Board report, then they
>> are welcome to do so.
>>
>>> The reason infra@ have escalated to board@ is probably that we need to
>>> figure out a long term solution for the AOO project and that solution
>>> is heavily influenced by ASF policy. Any solution that we are
>>> currently considering will have an impact on the AOO extensions site
>>> and/or on ASF policy.
>>>
>>> The current situation, as I understand it, is that the board have
>>> given permission for the extensions site to be managed by infra during
>>> incubation. The problem of distributing content under licences other
>>> than Apache is not seen to be a problem during the incubation process.
>>> Beyond incubation the board has delegated responsibility to the
>>> Incubator PMC. I don't believe that particular discussion has been
>>> started yet.
>>>
>>> Gav tells us that he has been thinking about making the extensions
>>> site an index site, thus allowing the extensions to be housed
>>> elsewhere (apache-extras, sourceforge, google code, github, FooBar
>>> corporation or wherever). This would neatly bypass the licence
>>> problem. Open source extensions needing hosting could go to
>>> apache-extras while commercially licensed extensions would need to
>>> provide their own hosting.
>>>
>>
>> That was my recommendation as well, in the previous thread referenced
>> above.  It is more work up front, but the resulting "directory" of
>> links and metadata associated with extensions (and templates -- don't
>> forget the templates) is very flexible.
>
>
> We should keep in mind that for many extension developers it's probably ok
> to create a SF, GoogleCode or whatever project to host the extension code
> and the binary. But i believe that there are also many developers who simply
> want to put there macro collection in an extension container with the
> necessary meta data and want share it with others. Means they simply want to
> upload it for broader availability without creating their own project or the
> necessity to have their own webspace for hosting the binary extension.

The SourceForge proposed solution would support this in exactly the
way the current system does, see below.

> And i think this is even more important for templates. People create a nice
> template and would ideally be able to upload it directly from the office. Ok
> for upload we would need some kind of registration and authentication to do
> that. But that would be very convenient for users.
> I can think about a similar mechanism (in the future) to package Basic
> libraries with the meta data into an extension and upload it also directly
> from the office.
> I think for such a service we can require the Apache license and can ask for
> it during the necessary registration process and for every upload.
>
>
>>
>>> An alternative is to work with a third party willing to help. I've
>>> copied below the text of a mail outlining the SF proposal. You will
>>> note that they are keen to ensure that we don't get locked into the SF
>>> services. Nevertheless, one of the reasons the ASF hosts its own
>>> services is to avoid exposing us to unmanageable risk.
>>>
>>
>> This doesn't necessarily need to be an either/or decision.  We could
>> decide to host the canonical directory of extensions/templates, and SF
>> hold host a prominent repository of some of the actual extensions.
>>
>> We also need to get out of the mindset of there being only one
>> extension repository, or even one extension directory, and instead
>> think of a federated approach.  Remember, in an ecosystem with
>> downstream consumers and enterprise deployments,  there will typically
>> be internal-only corporate repositories as well as distro-specific
>> ones, as well as possible directories and repositories from AOO (ones
>> that are project releases under ALv2).  So I'd recommend we think of
>> the problem as being more about protocols and formats for describing
>> and advertising (from a web services perspective) extensions.  On top
>> of that an ecosystem of repositories and directories would emerge.
>
>
> i think the current format supports (maybe with minor tweaks) all the
> described scenarios and it should be possible support multiple repos.
> Without checking the code I assume that we have to change the UI and make it
> possible to add further repos to the default. Or allow a list of repos.
>
>
>>
>> So:
>>
>> Short term -- stabilize what we have.  Whether at Apache or SF, I
>> offer no opinion.
>>
>> Long term -- take the federated approach.  In this approach we will
>> want a host for the non-ALv2 extensions, so SF's offer makes sense
>> there.
>>
> +1 for short and long term.

First, what we're proposing in the short term is to migrate and
stabilize the current drupal instance using the sourceforge.net Secure
Project Web infrastructure.   This would give selected members of the
team SSH access to the server space where it's hosted, and full access
to both the code and database content.

We would help update the code to sync the uploaded files into our
global mirror network, and have downloads go through there to aleviate
pressure on the Drupal infrastucture and give people local download
mirrors for all the extensions and templates.

Middle term we would love to work with you to have this site become
the center of a federated extensions community.   We are working on
mirroring and federation tools already, and would love to have this
new extensions site automatically pickup extensions projects created
in an Open Office Extensions neighborhood on SourceForge.net, and make
it trivial to register projects hosted at Google Code, and Github for
incision and automatic updates as well.

We have been working to make projects on the new Sourceforge platform
(http://sourceforge.net/p/allura) more flexible, so if
extensions/template authors want only to track issues, or just to have
a forum, but don't want or need SVN or other version control support,
we already support that kind of project setup.


>> Maybe the short-term offer from them for stabilization could migrate,
>> over time, for them to be a core repository in the eventual federated
>> approach?
>
>
> I agree and we should take also into account the promotion opportunities via
> SF that sounds interesting for me as well.

We're open to find ways to collaborate, included the possibility to
help you to find more developers/contributors.

Roberto

> Juergen
====
This e- mail message is intended only for the named recipient(s) above. It may contain confidential and privileged information. If you are not the intended recipient you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and delete the message and any attachment(s) from your system. Thank you.

Re: Extensions hosting

[Jürgen Schmidt <jo...@googlemail.com>]

On 1/3/12 5:25 PM, Rob Weir wrote:
> On Tue, Jan 3, 2012 at 10:51 AM, Ross Gardler
> <rg...@opendirective.com>  wrote:
>> As the community know Gav, in his role at infrastructure@ has
>> undertaken to stabilise and migrate the AOO extensions code to ASF
>> infrastructure. His work has been progressing and he remains committed
>> to completing this.
>>
>> However, as some know Sourceforge made an offer to help via our
>> private list. At the time they did not want to discuss this topic in
>> public for a number of reasons. I've had a couple of chats with
>> Roberto Gallopini and Jeff Drobick in order to help them understand
>> why the ASF prefers to host all services for its projects. In response
>> SF have tailored their offer of support.
>>
>
> Thanks for the wonderful job of reaching out to SourceForge and
> connecting us to this offer, Ross.
>
>> I relayed the outline of our conversations to the infrastructure team
>> who have asked me to have the AOO project provide some feedback, via a
>> board report, on what problems the AOO project forsee for the
>> extensions site and what options are available, if possible a
>> recommendation for an optimal solution should also be made. Note that
>> we can submit something out of cycle if we want, the next full report
>> is not due till March.
>>
>
> This has already been discussed, in detail in a previous thread:
>
> http://markmail.org/message/sm57zvd5gnblxpo6
>
> I believe that discussion is what prompted Gavin to action.  If
> someone wants to copy and paste that into a Board report, then they
> are welcome to do so.
>
>> The reason infra@ have escalated to board@ is probably that we need to
>> figure out a long term solution for the AOO project and that solution
>> is heavily influenced by ASF policy. Any solution that we are
>> currently considering will have an impact on the AOO extensions site
>> and/or on ASF policy.
>>
>> The current situation, as I understand it, is that the board have
>> given permission for the extensions site to be managed by infra during
>> incubation. The problem of distributing content under licences other
>> than Apache is not seen to be a problem during the incubation process.
>> Beyond incubation the board has delegated responsibility to the
>> Incubator PMC. I don't believe that particular discussion has been
>> started yet.
>>
>> Gav tells us that he has been thinking about making the extensions
>> site an index site, thus allowing the extensions to be housed
>> elsewhere (apache-extras, sourceforge, google code, github, FooBar
>> corporation or wherever). This would neatly bypass the licence
>> problem. Open source extensions needing hosting could go to
>> apache-extras while commercially licensed extensions would need to
>> provide their own hosting.
>>
>
> That was my recommendation as well, in the previous thread referenced
> above.  It is more work up front, but the resulting "directory" of
> links and metadata associated with extensions (and templates -- don't
> forget the templates) is very flexible.

We should keep in mind that for many extension developers it's probably 
ok to create a SF, GoogleCode or whatever project to host the extension 
code and the binary. But i believe that there are also many developers 
who simply want to put there macro collection in an extension container 
with the necessary meta data and want share it with others. Means they 
simply want to upload it for broader availability without creating their 
own project or the necessity to have their own webspace for hosting the 
binary extension.

And i think this is even more important for templates. People create a 
nice template and would ideally be able to upload it directly from the 
office. Ok for upload we would need some kind of registration and 
authentication to do that. But that would be very convenient for users.
I can think about a similar mechanism (in the future) to package Basic 
libraries with the meta data into an extension and upload it also 
directly from the office.
I think for such a service we can require the Apache license and can ask 
for it during the necessary registration process and for every upload.

>
>> An alternative is to work with a third party willing to help. I've
>> copied below the text of a mail outlining the SF proposal. You will
>> note that they are keen to ensure that we don't get locked into the SF
>> services. Nevertheless, one of the reasons the ASF hosts its own
>> services is to avoid exposing us to unmanageable risk.
>>
>
> This doesn't necessarily need to be an either/or decision.  We could
> decide to host the canonical directory of extensions/templates, and SF
> hold host a prominent repository of some of the actual extensions.
>
> We also need to get out of the mindset of there being only one
> extension repository, or even one extension directory, and instead
> think of a federated approach.  Remember, in an ecosystem with
> downstream consumers and enterprise deployments,  there will typically
> be internal-only corporate repositories as well as distro-specific
> ones, as well as possible directories and repositories from AOO (ones
> that are project releases under ALv2).  So I'd recommend we think of
> the problem as being more about protocols and formats for describing
> and advertising (from a web services perspective) extensions.  On top
> of that an ecosystem of repositories and directories would emerge.

i think the current format supports (maybe with minor tweaks) all the 
described scenarios and it should be possible support multiple repos. 
Without checking the code I assume that we have to change the UI and 
make it possible to add further repos to the default. Or allow a list of 
repos.

>
> So:
>
> Short term -- stabilize what we have.  Whether at Apache or SF, I
> offer no opinion.
>
> Long term -- take the federated approach.  In this approach we will
> want a host for the non-ALv2 extensions, so SF's offer makes sense
> there.
>
+1 for short and long term.

> Maybe the short-term offer from them for stabilization could migrate,
> over time, for them to be a core repository in the eventual federated
> approach?

I agree and we should take also into account the promotion opportunities 
via SF that sounds interesting for me as well.

Juergen

Re: Extensions hosting

[Rob Weir <ro...@apache.org>]

On Tue, Jan 3, 2012 at 10:51 AM, Ross Gardler
<rg...@opendirective.com> wrote:
> As the community know Gav, in his role at infrastructure@ has
> undertaken to stabilise and migrate the AOO extensions code to ASF
> infrastructure. His work has been progressing and he remains committed
> to completing this.
>
> However, as some know Sourceforge made an offer to help via our
> private list. At the time they did not want to discuss this topic in
> public for a number of reasons. I've had a couple of chats with
> Roberto Gallopini and Jeff Drobick in order to help them understand
> why the ASF prefers to host all services for its projects. In response
> SF have tailored their offer of support.
>

Thanks for the wonderful job of reaching out to SourceForge and
connecting us to this offer, Ross.

> I relayed the outline of our conversations to the infrastructure team
> who have asked me to have the AOO project provide some feedback, via a
> board report, on what problems the AOO project forsee for the
> extensions site and what options are available, if possible a
> recommendation for an optimal solution should also be made. Note that
> we can submit something out of cycle if we want, the next full report
> is not due till March.
>

This has already been discussed, in detail in a previous thread:

http://markmail.org/message/sm57zvd5gnblxpo6

I believe that discussion is what prompted Gavin to action.  If
someone wants to copy and paste that into a Board report, then they
are welcome to do so.

> The reason infra@ have escalated to board@ is probably that we need to
> figure out a long term solution for the AOO project and that solution
> is heavily influenced by ASF policy. Any solution that we are
> currently considering will have an impact on the AOO extensions site
> and/or on ASF policy.
>
> The current situation, as I understand it, is that the board have
> given permission for the extensions site to be managed by infra during
> incubation. The problem of distributing content under licences other
> than Apache is not seen to be a problem during the incubation process.
> Beyond incubation the board has delegated responsibility to the
> Incubator PMC. I don't believe that particular discussion has been
> started yet.
>
> Gav tells us that he has been thinking about making the extensions
> site an index site, thus allowing the extensions to be housed
> elsewhere (apache-extras, sourceforge, google code, github, FooBar
> corporation or wherever). This would neatly bypass the licence
> problem. Open source extensions needing hosting could go to
> apache-extras while commercially licensed extensions would need to
> provide their own hosting.
>

That was my recommendation as well, in the previous thread referenced
above.  It is more work up front, but the resulting "directory" of
links and metadata associated with extensions (and templates -- don't
forget the templates) is very flexible.

> An alternative is to work with a third party willing to help. I've
> copied below the text of a mail outlining the SF proposal. You will
> note that they are keen to ensure that we don't get locked into the SF
> services. Nevertheless, one of the reasons the ASF hosts its own
> services is to avoid exposing us to unmanageable risk.
>

This doesn't necessarily need to be an either/or decision.  We could
decide to host the canonical directory of extensions/templates, and SF
hold host a prominent repository of some of the actual extensions.

We also need to get out of the mindset of there being only one
extension repository, or even one extension directory, and instead
think of a federated approach.  Remember, in an ecosystem with
downstream consumers and enterprise deployments,  there will typically
be internal-only corporate repositories as well as distro-specific
ones, as well as possible directories and repositories from AOO (ones
that are project releases under ALv2).  So I'd recommend we think of
the problem as being more about protocols and formats for describing
and advertising (from a web services perspective) extensions.  On top
of that an ecosystem of repositories and directories would emerge.

So:

Short term -- stabilize what we have.  Whether at Apache or SF, I
offer no opinion.

Long term -- take the federated approach.  In this approach we will
want a host for the non-ALv2 extensions, so SF's offer makes sense
there.

Maybe the short-term offer from them for stabilization could migrate,
over time, for them to be a core repository in the eventual federated
approach?

-Rob

> I have no reason to believe SourceForge have anything other than good
> intentions in making this offer. SF has been supporting open source
> for a very long time. It is backed at the highest level (Jeff is
> President and CEO) and I believe Roberto is known within the
> OpenOffce.org community. However, many aspects of this will be outside
> of the control of the AOO project, despite SFs real attempts to
> mitigate our concerns relating to this.
>
> Please note that the timescales Jeff outlines are unrealistic given
> that we need to seek board input before being able to ensure the AOO
> project makes the right decision.  SF want to move quickly, but I
> don't think we need to be rushed into making a decision.
>
> Once you've digested and debated the offer from Sourceforge the
> community needs to come up with a couple of paragraphs indicating a
> desired route forwards and reasons for it. I will try and attend the
> appropriate board meeting in order to answer any questions that arise.
>
> Please be imaginative in your planning for the future. The optimal
> solution might be some combination of ASF and SF offerings.
>
> Note Roberto Gallopini has joined this list and is ready to make any
> clarifications necessary. I've also made Gav aware of this post so
> that he can answer any questions we have about what infra@ are able to
> do.
>
> Thanks,
> Ross
>
> --- COPIED PROPOSAL ---
>
> I'm glad we had a chance to talk last week - exciting times for Open
> Office as the product and community transition into the ASF.
>
> For over a decade, SourceForge has been committed to advancing the
> open source software community.  We host over 300,000 projects and are
> visited by over 40 MM users per month for free, secure, and fast
> downloads of open source software.  Trusted and reliable download
> delivery is an important part of our service, with over 4 million
> downloads per day and 2 PB from our mirror network each month.  We are
> committed to helping OSS projects scale and grow.
>
> Based on our discussions, we understand there are a few things you are
> solving for as part of the Open Office Incubation effort:
> Supporting a diverse licensing terms for Open Office extensions, that
> may not all comply with the Apache OSS policy;
> Stabilizing your Drupal OO Extensions site and ensuring high
> availability and download bandwidth without cost
> Expanding both the developer base who will move into working on the
> Apache framework as well as adoption of the Open Office product and
> extensions.
> We think we can help and that there would be mutual benefit.  To that
> end, we propose the following for your consideration:
>
> 1.) Stabilize the your OO Extensions Drupal instance by moving the it
> and all services to SourceForge.  Our Site Operations team will do teh
> work and oversee the operations for you as we do other services.  To
> your community the directory will look the same and extension and
> template files will move to SourceForge's globally-distributed
> download mirror network where we can ensure reliable, scalable
> delivery.  Drupal will be hosted on our project web service, serving
> your existing domain via a VHOST.  Standard infrastructure
> (monitoring, backups, etc.) and service levels (99.9% availability
> target) apply.
>
> These SourceForge services will be provided gratis, and without
> lock-in -- you are open to change your mind later.  We anticipate this
> migration would involve a week of planning and preparation, followed
> by a week of migration and pre/post-migration communications.  We're
> prepared to commence this work the next week if provided your approval
> and support.
>
> 2.) Once stabilized, we will work with you on a timeline to evaluate
> and execute a migration from Drupal 5 to Drupal 7.
>
> Allowing us to host the Extensions community will solve the license
> challenges - or at least give you time to work through a longer term
> solution.  We would also be able to cross promote the software titles
> to the development community as well - so perhaps expand not only your
> user base but developers.
>
> Roberto (our Sr. Director of Business Development) has been involved
> in the OpenOffice.org community for many years -- he will continue to
> be your point-of-contact.  If we secure the go-ahead this week, we
> will start on Tuesday next week and expect to be complete by 1/15 with
> step 1.  I have asked our head of Site Ops to oversee the
> implementation and he'll partner up with your technical folks to
> ensure the hosting transition goes well.
>
> Our motivation here is quite simple, it is all part of our mission to
> help Open Source Software initiatives succeed.  To that end,
> SourceForge and Geeknet Media are able to fund these services and make
> them free to the community through advertising largely on the download
> and directory pages.  So there won't ever be a charge back to your
> community and we are able to reinvest in R&D on our developer tools as
> well.
>
> We look forward to hearing back from you this week if possible.  Feel
> free to forward this on to whomever you would like in terms of getting
> to an aligned decision.
>
> I wish you a happy new year!
>
> --
> Thank you,
> Jeff
>
> --- End of copied text ---
> --
> Ross Gardler (@rgardler)
> Programme Leader (Open Development)
> OpenDirective http://opendirective.com

Re: Extensions hosting

[Ross Gardler <rg...@opendirective.com>]

2012/1/13 Jürgen Schmidt <jo...@googlemail.com>:
> On 1/13/12 12:32 PM, Ross Gardler wrote:

..

> My point was that in your email to the board this point was not clear enough
> for me.

OK. The board are clear in this point. When they discussed the
infrastructure proposal Gav asked them to consider JIRA or Hudson
without plugins in order to make this point.

However, if I see any evidence of this not being understood I'll be
sure to correct that. Thanks for flagging.

Ross

Re: Extensions hosting

[Jürgen Schmidt <jo...@googlemail.com>]

On 1/13/12 12:32 PM, Ross Gardler wrote:
> 2012/1/13 Jürgen Schmidt<jo...@googlemail.com>:
>> Hi Ross,
>>
>> sorry for my top posting.
>>
>> I have only one point that is important for me. The hosting aspect of binary
>> extensions and templates is a very important part and we should ensure can
>> we can provide such a service in some way.
>
> Yes, I think we all (including the board) agree. This is evidenced by
> their willingness to approve Gavs proposal.
>
> Can you please state explicitly whether you perceive a problem with
> the SF proposal or not. It is my understanding that the consensus here
> is to accept the SF proposal, it is this that I am seeking advice from
> the board on.

yes i support the SF proposal as well.

My point was that in your email to the board this point was not clear 
enough for me.

>
> I don't want to open up the whole discussion again,
me too

Juergen

the majority
> position is certainly to accept the SF proposal. However, if you feel
> this is a mistake I would like to understand you precise concerns so
> that I might respond to any questions from the board with maximum
> clarity.
>
> Note the proposal taken to the board is for the SF proposal to be an
> interim solution with the intention of the AOO project providing a
> longer term solution more tailored to the needs of the project and its
> users.
>
> Ross

Re: Extensions hosting

[Ross Gardler <rg...@opendirective.com>]

2012/1/13 Jürgen Schmidt <jo...@googlemail.com>:
> Hi Ross,
>
> sorry for my top posting.
>
> I have only one point that is important for me. The hosting aspect of binary
> extensions and templates is a very important part and we should ensure can
> we can provide such a service in some way.

Yes, I think we all (including the board) agree. This is evidenced by
their willingness to approve Gavs proposal.

Can you please state explicitly whether you perceive a problem with
the SF proposal or not. It is my understanding that the consensus here
is to accept the SF proposal, it is this that I am seeking advice from
the board on.

I don't want to open up the whole discussion again, the majority
position is certainly to accept the SF proposal. However, if you feel
this is a mistake I would like to understand you precise concerns so
that I might respond to any questions from the board with maximum
clarity.

Note the proposal taken to the board is for the SF proposal to be an
interim solution with the intention of the AOO project providing a
longer term solution more tailored to the needs of the project and its
users.

Ross

Re: Extensions hosting

[Jürgen Schmidt <jo...@googlemail.com>]

Hi Ross,

sorry for my top posting.

I have only one point that is important for me. The hosting aspect of 
binary extensions and templates is a very important part and we should 
ensure can we can provide such a service in some way. And here it is not 
important for our users if it is on Apache servers or any where else. 
Important is the usage from a user perspective of such a service. It is 
a huge difference if you put your binary on for example Sourceforge, 
move to extension.openoffice.org and register your extension with an 
Url. Or simply upload the binary during the registration on 
extensions.openoffice.org directly.

Keep in mind we have it here to do with experienced users and not always 
developers. Especially when you think about simply macro collections and 
templates.

Juergen




On 1/12/12 6:34 PM, Ross Gardler wrote:
> I'm attempting to summarise this thread and thus I'm top-posting on
> the orginal opening thread.
>
> I will send the below text to the board for consideration. I'll
> feedback here after the next board meeting (18th) or sooner if
> possible.
>
> Dear Board,
>
> The Apache Open Office project needs to stabilise the hosting of their
> extensions.openoffice.org service. The code needs updating and
> bandwidth requirements need to be addressed.
>
> Gav, on behalf of the infra team, has offered to move the server to
> ASF hardware and stabilise the code. Longer term Gav indicated that
> his desire was to turn the service into a meta-data hosting service
> whereby extensions could be discovered via extensions.openoffice.,org
> but hosted in third party locations.
>
> This plan requires the hosting non-apache software (including closed
> source) on ASF hardware. This was approved by the board with
> responsibility for resolving the IP issues being delegated to the IPMC
> (http://s.apache.org/fO - members only link).
>
> In the meantime Sourceforge have offered to help, initially through an
> approach to Rob Weir of the AOO project and then through myself. I
> took this proposal (via infra@ who requested the PPMC bring it to the
> boards attention) to the AOO dev project for discussion. The thread
> can be found at http://s.apache.org/sz6 (public) - the first post in
> that thread includes the proposal from Jeff Drobnick (President and
> CEO of Geeknet media, it also includes a number of clarifications from
> Roberto Gallopini of Geeknet. I've tried to summarise for you here.
>
> After a long discussion the AOO podling has reached a consensus that
> the best way forward would be to accept the proposal from Sourceforge
> as a short term solution whilst working towards the meta-data site for
> the long term. The PPMC feels that moving the service to a non-ASF
> host now will minimise disruption for extensions developers and
> end-users who are unwilling or unable to conform to ASF policy in the
> long term. Similarly the PPMC feels there is a sufficiently large
> number of edge cases to make changes in policy more complex than is
> necessary since it is the PPMCs desire to provide an "approved" list
> of extensions which are expected to conform to existing ASF IP
> policies, whilst also enabling third parties to host their own
> extensions sites that users can choose to access via a meta-data
> service.
>
> We have assurances from SF that they are not interested in locking the
> AOO project to their hosted services.  Members of the AOO PPMC will
> have shell access to the system and no attempt will be made by SF to
> own any of the IP involved.
>
> SF reserve the right to serve advertising on the downloads site (and
> possibly on the extensions site, this needs to be clarified).
> Downloads would be served from the existing SF mirror network.
>
> It is possible for AOO to point to an intermediate page giving users
> the option of visiting other extensions sites if required. That is
> extensions.openoffice.org could point to an ASF hosted web page
> listing multiple third party sites, one of which would be the SF
> hosted service. Consequently, if necessary it is possible for the PPMC
> to move hosting to a SF but not to point extensions.openoffice.org
> there.
>
> It is hoped that later releases of AOO will include the ability to
> search for extensions via a meta-data service managed by the AOO
> project. At this point extensions.openoffice.org would return to ASF
> hardware. It is expected that the SF hosted extensions repository will
> continue to exist and will be one of the first repositories from which
> users will be able to download non-ASF extensions.
>
> This proposal raises a few interesting policy questions. Therefore I
> would like to ask for guidance on how best to help the AOO project
> realise this objective. A few questions that come to mind are:
>
> Will it be necessary to draw up an MoU with SF? If so what are the key
> points the board would like to see covered?
>
> Will it be sufficient for the PPMC to work with SF to ensure the
> extensions site they provide respects the existing trademark policy?
> (bearing in mind that we will eventually be moving
> extensions.openoffice.org back to ASF hardware)
>
> Would the board prefer it if extensions.openoffice.org were to
> redirection to foo.sourceforge.net? (either automatically or via an
> information page) If so would this change the answer to the MoU
> question above?
>
> Will this simplify the AOO ability to address IP and fundraising
> concerns generated by non-ASF code and donations requests found on
> extensions.apache.org?
>
> Does the board have any concerns about advertising appearing on
> extensions.openoffice.org? Would this concern be mitigated by refusing
> permission to serve advertising from extensions.openoffice.org but
> allowing it on the download pages on an sf.net domain?
>
> If the board would like to discuss this at the next board meeting I
> will try and be on the call to answer an questions. In the meantime
> I'm here on this list.
>
> Ross
>
> On 3 January 2012 15:51, Ross Gardler<rg...@opendirective.com>  wrote:
>> As the community know Gav, in his role at infrastructure@ has
>> undertaken to stabilise and migrate the AOO extensions code to ASF
>> infrastructure. His work has been progressing and he remains committed
>> to completing this.
>>
>> However, as some know Sourceforge made an offer to help via our
>> private list. At the time they did not want to discuss this topic in
>> public for a number of reasons. I've had a couple of chats with
>> Roberto Gallopini and Jeff Drobick in order to help them understand
>> why the ASF prefers to host all services for its projects. In response
>> SF have tailored their offer of support.
>>
>> I relayed the outline of our conversations to the infrastructure team
>> who have asked me to have the AOO project provide some feedback, via a
>> board report, on what problems the AOO project forsee for the
>> extensions site and what options are available, if possible a
>> recommendation for an optimal solution should also be made. Note that
>> we can submit something out of cycle if we want, the next full report
>> is not due till March.
>>
>> The reason infra@ have escalated to board@ is probably that we need to
>> figure out a long term solution for the AOO project and that solution
>> is heavily influenced by ASF policy. Any solution that we are
>> currently considering will have an impact on the AOO extensions site
>> and/or on ASF policy.
>>
>> The current situation, as I understand it, is that the board have
>> given permission for the extensions site to be managed by infra during
>> incubation. The problem of distributing content under licences other
>> than Apache is not seen to be a problem during the incubation process.
>> Beyond incubation the board has delegated responsibility to the
>> Incubator PMC. I don't believe that particular discussion has been
>> started yet.
>>
>> Gav tells us that he has been thinking about making the extensions
>> site an index site, thus allowing the extensions to be housed
>> elsewhere (apache-extras, sourceforge, google code, github, FooBar
>> corporation or wherever). This would neatly bypass the licence
>> problem. Open source extensions needing hosting could go to
>> apache-extras while commercially licensed extensions would need to
>> provide their own hosting.
>>
>> An alternative is to work with a third party willing to help. I've
>> copied below the text of a mail outlining the SF proposal. You will
>> note that they are keen to ensure that we don't get locked into the SF
>> services. Nevertheless, one of the reasons the ASF hosts its own
>> services is to avoid exposing us to unmanageable risk.
>>
>> I have no reason to believe SourceForge have anything other than good
>> intentions in making this offer. SF has been supporting open source
>> for a very long time. It is backed at the highest level (Jeff is
>> President and CEO) and I believe Roberto is known within the
>> OpenOffce.org community. However, many aspects of this will be outside
>> of the control of the AOO project, despite SFs real attempts to
>> mitigate our concerns relating to this.
>>
>> Please note that the timescales Jeff outlines are unrealistic given
>> that we need to seek board input before being able to ensure the AOO
>> project makes the right decision.  SF want to move quickly, but I
>> don't think we need to be rushed into making a decision.
>>
>> Once you've digested and debated the offer from Sourceforge the
>> community needs to come up with a couple of paragraphs indicating a
>> desired route forwards and reasons for it. I will try and attend the
>> appropriate board meeting in order to answer any questions that arise.
>>
>> Please be imaginative in your planning for the future. The optimal
>> solution might be some combination of ASF and SF offerings.
>>
>> Note Roberto Gallopini has joined this list and is ready to make any
>> clarifications necessary. I've also made Gav aware of this post so
>> that he can answer any questions we have about what infra@ are able to
>> do.
>>
>> Thanks,
>> Ross
>>
>> --- COPIED PROPOSAL ---
>>
>> I'm glad we had a chance to talk last week - exciting times for Open
>> Office as the product and community transition into the ASF.
>>
>> For over a decade, SourceForge has been committed to advancing the
>> open source software community.  We host over 300,000 projects and are
>> visited by over 40 MM users per month for free, secure, and fast
>> downloads of open source software.  Trusted and reliable download
>> delivery is an important part of our service, with over 4 million
>> downloads per day and 2 PB from our mirror network each month.  We are
>> committed to helping OSS projects scale and grow.
>>
>> Based on our discussions, we understand there are a few things you are
>> solving for as part of the Open Office Incubation effort:
>> Supporting a diverse licensing terms for Open Office extensions, that
>> may not all comply with the Apache OSS policy;
>> Stabilizing your Drupal OO Extensions site and ensuring high
>> availability and download bandwidth without cost
>> Expanding both the developer base who will move into working on the
>> Apache framework as well as adoption of the Open Office product and
>> extensions.
>> We think we can help and that there would be mutual benefit.  To that
>> end, we propose the following for your consideration:
>>
>> 1.) Stabilize the your OO Extensions Drupal instance by moving the it
>> and all services to SourceForge.  Our Site Operations team will do teh
>> work and oversee the operations for you as we do other services.  To
>> your community the directory will look the same and extension and
>> template files will move to SourceForge's globally-distributed
>> download mirror network where we can ensure reliable, scalable
>> delivery.  Drupal will be hosted on our project web service, serving
>> your existing domain via a VHOST.  Standard infrastructure
>> (monitoring, backups, etc.) and service levels (99.9% availability
>> target) apply.
>>
>> These SourceForge services will be provided gratis, and without
>> lock-in -- you are open to change your mind later.  We anticipate this
>> migration would involve a week of planning and preparation, followed
>> by a week of migration and pre/post-migration communications.  We're
>> prepared to commence this work the next week if provided your approval
>> and support.
>>
>> 2.) Once stabilized, we will work with you on a timeline to evaluate
>> and execute a migration from Drupal 5 to Drupal 7.
>>
>> Allowing us to host the Extensions community will solve the license
>> challenges - or at least give you time to work through a longer term
>> solution.  We would also be able to cross promote the software titles
>> to the development community as well - so perhaps expand not only your
>> user base but developers.
>>
>> Roberto (our Sr. Director of Business Development) has been involved
>> in the OpenOffice.org community for many years -- he will continue to
>> be your point-of-contact.  If we secure the go-ahead this week, we
>> will start on Tuesday next week and expect to be complete by 1/15 with
>> step 1.  I have asked our head of Site Ops to oversee the
>> implementation and he'll partner up with your technical folks to
>> ensure the hosting transition goes well.
>>
>> Our motivation here is quite simple, it is all part of our mission to
>> help Open Source Software initiatives succeed.  To that end,
>> SourceForge and Geeknet Media are able to fund these services and make
>> them free to the community through advertising largely on the download
>> and directory pages.  So there won't ever be a charge back to your
>> community and we are able to reinvest in R&D on our developer tools as
>> well.
>>
>> We look forward to hearing back from you this week if possible.  Feel
>> free to forward this on to whomever you would like in terms of getting
>> to an aligned decision.
>>
>> I wish you a happy new year!
>>
>> --
>> Thank you,
>> Jeff
>>
>> --- End of copied text ---
>> --
>> Ross Gardler (@rgardler)
>> Programme Leader (Open Development)
>> OpenDirective http://opendirective.com
>
>
>

Re: Extensions hosting

[Jürgen Schmidt <jo...@googlemail.com>]

On 1/13/12 4:00 AM, Dave Fisher wrote:
>
>
> Sent from my iPhone
>
> On Jan 12, 2012, at 6:18 PM, Ross Gardler<rg...@opendirective.com>  wrote:
>
>> On 12 January 2012 19:01, Dave Fisher<da...@comcast.net>  wrote:
>>> Sorry to top post.
>>>
>>> A distinction exists between extensions.oo.o and extensions.services.oo.o.
>>>
>>> The first is part of the OOo-site and the second is the service.
>>
>> Thanks Dave. Just so I'm absolutely clear does this change the
>> proposal other than the precise domain names allocated? I'm not sure
>> this distinction had been made before.
>>
>> Specifically is the SF proposal to take both the site and the service?
>
> They would be hosting the service domain at extensions.services.oo.o.
>
> The ASF hosts extensions.oo.o within www.oo.o/extensions/
>
> Your second mention of e.oo.o makes sense the others should use the services URL.
>
> Try the two urls to see what I mean
>
yes that was always a problem and often confusing.
For the future I would propose that we drop the page on 
extensions.openoffice.org and merge the minimal content there with the 
api.openoffice.org page. Most of the content is already in the wiki anyway.

And we should use extensions.openoffice.org as the new Url for 
extensions.services.openoffice.org.

Similar to a proposed change of wiki.services.openoffice.org to 
wiki.openoffice.org.

Where possible we should drop *.services.openoffice.org with 
*.openoffice.org

Juergen

Re: Extensions hosting

[Ross Gardler <rg...@opendirective.com>]

Got it - thanks Dave.

Ross

On 13 January 2012 03:00, Dave Fisher <da...@comcast.net> wrote:
>
>
> Sent from my iPhone
>
> On Jan 12, 2012, at 6:18 PM, Ross Gardler <rg...@opendirective.com> wrote:
>
>> On 12 January 2012 19:01, Dave Fisher <da...@comcast.net> wrote:
>>> Sorry to top post.
>>>
>>> A distinction exists between extensions.oo.o and extensions.services.oo.o.
>>>
>>> The first is part of the OOo-site and the second is the service.
>>
>> Thanks Dave. Just so I'm absolutely clear does this change the
>> proposal other than the precise domain names allocated? I'm not sure
>> this distinction had been made before.
>>
>> Specifically is the SF proposal to take both the site and the service?
>
> They would be hosting the service domain at extensions.services.oo.o.
>
> The ASF hosts extensions.oo.o within www.oo.o/extensions/
>
> Your second mention of e.oo.o makes sense the others should use the services URL.
>
> Try the two urls to see what I mean
>
> Regards,
> Dave
>
>>
>> Ross
>>
>>
>>>
>>> Regards,
>>> Dave
>>>
>>> Sent from my iPhone
>>>
>>> On Jan 12, 2012, at 9:34 AM, Ross Gardler <rg...@opendirective.com> wrote:
>>>
>>>> I'm attempting to summarise this thread and thus I'm top-posting on
>>>> the orginal opening thread.
>>>>
>>>> I will send the below text to the board for consideration. I'll
>>>> feedback here after the next board meeting (18th) or sooner if
>>>> possible.
>>>>
>>>> Dear Board,
>>>>
>>>> The Apache Open Office project needs to stabilise the hosting of their
>>>> extensions.openoffice.org service. The code needs updating and
>>>> bandwidth requirements need to be addressed.
>>>>
>>>> Gav, on behalf of the infra team, has offered to move the server to
>>>> ASF hardware and stabilise the code. Longer term Gav indicated that
>>>> his desire was to turn the service into a meta-data hosting service
>>>> whereby extensions could be discovered via extensions.openoffice.,org
>>>> but hosted in third party locations.
>>>>
>>>> This plan requires the hosting non-apache software (including closed
>>>> source) on ASF hardware. This was approved by the board with
>>>> responsibility for resolving the IP issues being delegated to the IPMC
>>>> (http://s.apache.org/fO - members only link).
>>>>
>>>> In the meantime Sourceforge have offered to help, initially through an
>>>> approach to Rob Weir of the AOO project and then through myself. I
>>>> took this proposal (via infra@ who requested the PPMC bring it to the
>>>> boards attention) to the AOO dev project for discussion. The thread
>>>> can be found at http://s.apache.org/sz6 (public) - the first post in
>>>> that thread includes the proposal from Jeff Drobnick (President and
>>>> CEO of Geeknet media, it also includes a number of clarifications from
>>>> Roberto Gallopini of Geeknet. I've tried to summarise for you here.
>>>>
>>>> After a long discussion the AOO podling has reached a consensus that
>>>> the best way forward would be to accept the proposal from Sourceforge
>>>> as a short term solution whilst working towards the meta-data site for
>>>> the long term. The PPMC feels that moving the service to a non-ASF
>>>> host now will minimise disruption for extensions developers and
>>>> end-users who are unwilling or unable to conform to ASF policy in the
>>>> long term. Similarly the PPMC feels there is a sufficiently large
>>>> number of edge cases to make changes in policy more complex than is
>>>> necessary since it is the PPMCs desire to provide an "approved" list
>>>> of extensions which are expected to conform to existing ASF IP
>>>> policies, whilst also enabling third parties to host their own
>>>> extensions sites that users can choose to access via a meta-data
>>>> service.
>>>>
>>>> We have assurances from SF that they are not interested in locking the
>>>> AOO project to their hosted services.  Members of the AOO PPMC will
>>>> have shell access to the system and no attempt will be made by SF to
>>>> own any of the IP involved.
>>>>
>>>> SF reserve the right to serve advertising on the downloads site (and
>>>> possibly on the extensions site, this needs to be clarified).
>>>> Downloads would be served from the existing SF mirror network.
>>>>
>>>> It is possible for AOO to point to an intermediate page giving users
>>>> the option of visiting other extensions sites if required. That is
>>>> extensions.openoffice.org could point to an ASF hosted web page
>>>> listing multiple third party sites, one of which would be the SF
>>>> hosted service. Consequently, if necessary it is possible for the PPMC
>>>> to move hosting to a SF but not to point extensions.openoffice.org
>>>> there.
>>>>
>>>> It is hoped that later releases of AOO will include the ability to
>>>> search for extensions via a meta-data service managed by the AOO
>>>> project. At this point extensions.openoffice.org would return to ASF
>>>> hardware. It is expected that the SF hosted extensions repository will
>>>> continue to exist and will be one of the first repositories from which
>>>> users will be able to download non-ASF extensions.
>>>>
>>>> This proposal raises a few interesting policy questions. Therefore I
>>>> would like to ask for guidance on how best to help the AOO project
>>>> realise this objective. A few questions that come to mind are:
>>>>
>>>> Will it be necessary to draw up an MoU with SF? If so what are the key
>>>> points the board would like to see covered?
>>>>
>>>> Will it be sufficient for the PPMC to work with SF to ensure the
>>>> extensions site they provide respects the existing trademark policy?
>>>> (bearing in mind that we will eventually be moving
>>>> extensions.openoffice.org back to ASF hardware)
>>>>
>>>> Would the board prefer it if extensions.openoffice.org were to
>>>> redirection to foo.sourceforge.net? (either automatically or via an
>>>> information page) If so would this change the answer to the MoU
>>>> question above?
>>>>
>>>> Will this simplify the AOO ability to address IP and fundraising
>>>> concerns generated by non-ASF code and donations requests found on
>>>> extensions.apache.org?
>>>>
>>>> Does the board have any concerns about advertising appearing on
>>>> extensions.openoffice.org? Would this concern be mitigated by refusing
>>>> permission to serve advertising from extensions.openoffice.org but
>>>> allowing it on the download pages on an sf.net domain?
>>>>
>>>> If the board would like to discuss this at the next board meeting I
>>>> will try and be on the call to answer an questions. In the meantime
>>>> I'm here on this list.
>>>>
>>>> Ross
>>>>
>>>> On 3 January 2012 15:51, Ross Gardler <rg...@opendirective.com> wrote:
>>>>> As the community know Gav, in his role at infrastructure@ has
>>>>> undertaken to stabilise and migrate the AOO extensions code to ASF
>>>>> infrastructure. His work has been progressing and he remains committed
>>>>> to completing this.
>>>>>
>>>>> However, as some know Sourceforge made an offer to help via our
>>>>> private list. At the time they did not want to discuss this topic in
>>>>> public for a number of reasons. I've had a couple of chats with
>>>>> Roberto Gallopini and Jeff Drobick in order to help them understand
>>>>> why the ASF prefers to host all services for its projects. In response
>>>>> SF have tailored their offer of support.
>>>>>
>>>>> I relayed the outline of our conversations to the infrastructure team
>>>>> who have asked me to have the AOO project provide some feedback, via a
>>>>> board report, on what problems the AOO project forsee for the
>>>>> extensions site and what options are available, if possible a
>>>>> recommendation for an optimal solution should also be made. Note that
>>>>> we can submit something out of cycle if we want, the next full report
>>>>> is not due till March.
>>>>>
>>>>> The reason infra@ have escalated to board@ is probably that we need to
>>>>> figure out a long term solution for the AOO project and that solution
>>>>> is heavily influenced by ASF policy. Any solution that we are
>>>>> currently considering will have an impact on the AOO extensions site
>>>>> and/or on ASF policy.
>>>>>
>>>>> The current situation, as I understand it, is that the board have
>>>>> given permission for the extensions site to be managed by infra during
>>>>> incubation. The problem of distributing content under licences other
>>>>> than Apache is not seen to be a problem during the incubation process.
>>>>> Beyond incubation the board has delegated responsibility to the
>>>>> Incubator PMC. I don't believe that particular discussion has been
>>>>> started yet.
>>>>>
>>>>> Gav tells us that he has been thinking about making the extensions
>>>>> site an index site, thus allowing the extensions to be housed
>>>>> elsewhere (apache-extras, sourceforge, google code, github, FooBar
>>>>> corporation or wherever). This would neatly bypass the licence
>>>>> problem. Open source extensions needing hosting could go to
>>>>> apache-extras while commercially licensed extensions would need to
>>>>> provide their own hosting.
>>>>>
>>>>> An alternative is to work with a third party willing to help. I've
>>>>> copied below the text of a mail outlining the SF proposal. You will
>>>>> note that they are keen to ensure that we don't get locked into the SF
>>>>> services. Nevertheless, one of the reasons the ASF hosts its own
>>>>> services is to avoid exposing us to unmanageable risk.
>>>>>
>>>>> I have no reason to believe SourceForge have anything other than good
>>>>> intentions in making this offer. SF has been supporting open source
>>>>> for a very long time. It is backed at the highest level (Jeff is
>>>>> President and CEO) and I believe Roberto is known within the
>>>>> OpenOffce.org community. However, many aspects of this will be outside
>>>>> of the control of the AOO project, despite SFs real attempts to
>>>>> mitigate our concerns relating to this.
>>>>>
>>>>> Please note that the timescales Jeff outlines are unrealistic given
>>>>> that we need to seek board input before being able to ensure the AOO
>>>>> project makes the right decision.  SF want to move quickly, but I
>>>>> don't think we need to be rushed into making a decision.
>>>>>
>>>>> Once you've digested and debated the offer from Sourceforge the
>>>>> community needs to come up with a couple of paragraphs indicating a
>>>>> desired route forwards and reasons for it. I will try and attend the
>>>>> appropriate board meeting in order to answer any questions that arise.
>>>>>
>>>>> Please be imaginative in your planning for the future. The optimal
>>>>> solution might be some combination of ASF and SF offerings.
>>>>>
>>>>> Note Roberto Gallopini has joined this list and is ready to make any
>>>>> clarifications necessary. I've also made Gav aware of this post so
>>>>> that he can answer any questions we have about what infra@ are able to
>>>>> do.
>>>>>
>>>>> Thanks,
>>>>> Ross
>>>>>
>>>>> --- COPIED PROPOSAL ---
>>>>>
>>>>> I'm glad we had a chance to talk last week - exciting times for Open
>>>>> Office as the product and community transition into the ASF.
>>>>>
>>>>> For over a decade, SourceForge has been committed to advancing the
>>>>> open source software community.  We host over 300,000 projects and are
>>>>> visited by over 40 MM users per month for free, secure, and fast
>>>>> downloads of open source software.  Trusted and reliable download
>>>>> delivery is an important part of our service, with over 4 million
>>>>> downloads per day and 2 PB from our mirror network each month.  We are
>>>>> committed to helping OSS projects scale and grow.
>>>>>
>>>>> Based on our discussions, we understand there are a few things you are
>>>>> solving for as part of the Open Office Incubation effort:
>>>>> Supporting a diverse licensing terms for Open Office extensions, that
>>>>> may not all comply with the Apache OSS policy;
>>>>> Stabilizing your Drupal OO Extensions site and ensuring high
>>>>> availability and download bandwidth without cost
>>>>> Expanding both the developer base who will move into working on the
>>>>> Apache framework as well as adoption of the Open Office product and
>>>>> extensions.
>>>>> We think we can help and that there would be mutual benefit.  To that
>>>>> end, we propose the following for your consideration:
>>>>>
>>>>> 1.) Stabilize the your OO Extensions Drupal instance by moving the it
>>>>> and all services to SourceForge.  Our Site Operations team will do teh
>>>>> work and oversee the operations for you as we do other services.  To
>>>>> your community the directory will look the same and extension and
>>>>> template files will move to SourceForge's globally-distributed
>>>>> download mirror network where we can ensure reliable, scalable
>>>>> delivery.  Drupal will be hosted on our project web service, serving
>>>>> your existing domain via a VHOST.  Standard infrastructure
>>>>> (monitoring, backups, etc.) and service levels (99.9% availability
>>>>> target) apply.
>>>>>
>>>>> These SourceForge services will be provided gratis, and without
>>>>> lock-in -- you are open to change your mind later.  We anticipate this
>>>>> migration would involve a week of planning and preparation, followed
>>>>> by a week of migration and pre/post-migration communications.  We're
>>>>> prepared to commence this work the next week if provided your approval
>>>>> and support.
>>>>>
>>>>> 2.) Once stabilized, we will work with you on a timeline to evaluate
>>>>> and execute a migration from Drupal 5 to Drupal 7.
>>>>>
>>>>> Allowing us to host the Extensions community will solve the license
>>>>> challenges - or at least give you time to work through a longer term
>>>>> solution.  We would also be able to cross promote the software titles
>>>>> to the development community as well - so perhaps expand not only your
>>>>> user base but developers.
>>>>>
>>>>> Roberto (our Sr. Director of Business Development) has been involved
>>>>> in the OpenOffice.org community for many years -- he will continue to
>>>>> be your point-of-contact.  If we secure the go-ahead this week, we
>>>>> will start on Tuesday next week and expect to be complete by 1/15 with
>>>>> step 1.  I have asked our head of Site Ops to oversee the
>>>>> implementation and he'll partner up with your technical folks to
>>>>> ensure the hosting transition goes well.
>>>>>
>>>>> Our motivation here is quite simple, it is all part of our mission to
>>>>> help Open Source Software initiatives succeed.  To that end,
>>>>> SourceForge and Geeknet Media are able to fund these services and make
>>>>> them free to the community through advertising largely on the download
>>>>> and directory pages.  So there won't ever be a charge back to your
>>>>> community and we are able to reinvest in R&D on our developer tools as
>>>>> well.
>>>>>
>>>>> We look forward to hearing back from you this week if possible.  Feel
>>>>> free to forward this on to whomever you would like in terms of getting
>>>>> to an aligned decision.
>>>>>
>>>>> I wish you a happy new year!
>>>>>
>>>>> --
>>>>> Thank you,
>>>>> Jeff
>>>>>
>>>>> --- End of copied text ---
>>>>> --
>>>>> Ross Gardler (@rgardler)
>>>>> Programme Leader (Open Development)
>>>>> OpenDirective http://opendirective.com
>>>>
>>>>
>>>>
>>>> --
>>>> Ross Gardler (@rgardler)
>>>> Programme Leader (Open Development)
>>>> OpenDirective http://opendirective.com
>>
>>
>>
>> --
>> Ross Gardler (@rgardler)
>> Programme Leader (Open Development)
>> OpenDirective http://opendirective.com



-- 
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com

Re: Extensions hosting

[Dave Fisher <da...@comcast.net>]

Sent from my iPhone

On Jan 12, 2012, at 6:18 PM, Ross Gardler <rg...@opendirective.com> wrote:

> On 12 January 2012 19:01, Dave Fisher <da...@comcast.net> wrote:
>> Sorry to top post.
>> 
>> A distinction exists between extensions.oo.o and extensions.services.oo.o.
>> 
>> The first is part of the OOo-site and the second is the service.
> 
> Thanks Dave. Just so I'm absolutely clear does this change the
> proposal other than the precise domain names allocated? I'm not sure
> this distinction had been made before.
> 
> Specifically is the SF proposal to take both the site and the service?

They would be hosting the service domain at extensions.services.oo.o.

The ASF hosts extensions.oo.o within www.oo.o/extensions/

Your second mention of e.oo.o makes sense the others should use the services URL.

Try the two urls to see what I mean

Regards,
Dave

> 
> Ross
> 
> 
>> 
>> Regards,
>> Dave
>> 
>> Sent from my iPhone
>> 
>> On Jan 12, 2012, at 9:34 AM, Ross Gardler <rg...@opendirective.com> wrote:
>> 
>>> I'm attempting to summarise this thread and thus I'm top-posting on
>>> the orginal opening thread.
>>> 
>>> I will send the below text to the board for consideration. I'll
>>> feedback here after the next board meeting (18th) or sooner if
>>> possible.
>>> 
>>> Dear Board,
>>> 
>>> The Apache Open Office project needs to stabilise the hosting of their
>>> extensions.openoffice.org service. The code needs updating and
>>> bandwidth requirements need to be addressed.
>>> 
>>> Gav, on behalf of the infra team, has offered to move the server to
>>> ASF hardware and stabilise the code. Longer term Gav indicated that
>>> his desire was to turn the service into a meta-data hosting service
>>> whereby extensions could be discovered via extensions.openoffice.,org
>>> but hosted in third party locations.
>>> 
>>> This plan requires the hosting non-apache software (including closed
>>> source) on ASF hardware. This was approved by the board with
>>> responsibility for resolving the IP issues being delegated to the IPMC
>>> (http://s.apache.org/fO - members only link).
>>> 
>>> In the meantime Sourceforge have offered to help, initially through an
>>> approach to Rob Weir of the AOO project and then through myself. I
>>> took this proposal (via infra@ who requested the PPMC bring it to the
>>> boards attention) to the AOO dev project for discussion. The thread
>>> can be found at http://s.apache.org/sz6 (public) - the first post in
>>> that thread includes the proposal from Jeff Drobnick (President and
>>> CEO of Geeknet media, it also includes a number of clarifications from
>>> Roberto Gallopini of Geeknet. I've tried to summarise for you here.
>>> 
>>> After a long discussion the AOO podling has reached a consensus that
>>> the best way forward would be to accept the proposal from Sourceforge
>>> as a short term solution whilst working towards the meta-data site for
>>> the long term. The PPMC feels that moving the service to a non-ASF
>>> host now will minimise disruption for extensions developers and
>>> end-users who are unwilling or unable to conform to ASF policy in the
>>> long term. Similarly the PPMC feels there is a sufficiently large
>>> number of edge cases to make changes in policy more complex than is
>>> necessary since it is the PPMCs desire to provide an "approved" list
>>> of extensions which are expected to conform to existing ASF IP
>>> policies, whilst also enabling third parties to host their own
>>> extensions sites that users can choose to access via a meta-data
>>> service.
>>> 
>>> We have assurances from SF that they are not interested in locking the
>>> AOO project to their hosted services.  Members of the AOO PPMC will
>>> have shell access to the system and no attempt will be made by SF to
>>> own any of the IP involved.
>>> 
>>> SF reserve the right to serve advertising on the downloads site (and
>>> possibly on the extensions site, this needs to be clarified).
>>> Downloads would be served from the existing SF mirror network.
>>> 
>>> It is possible for AOO to point to an intermediate page giving users
>>> the option of visiting other extensions sites if required. That is
>>> extensions.openoffice.org could point to an ASF hosted web page
>>> listing multiple third party sites, one of which would be the SF
>>> hosted service. Consequently, if necessary it is possible for the PPMC
>>> to move hosting to a SF but not to point extensions.openoffice.org
>>> there.
>>> 
>>> It is hoped that later releases of AOO will include the ability to
>>> search for extensions via a meta-data service managed by the AOO
>>> project. At this point extensions.openoffice.org would return to ASF
>>> hardware. It is expected that the SF hosted extensions repository will
>>> continue to exist and will be one of the first repositories from which
>>> users will be able to download non-ASF extensions.
>>> 
>>> This proposal raises a few interesting policy questions. Therefore I
>>> would like to ask for guidance on how best to help the AOO project
>>> realise this objective. A few questions that come to mind are:
>>> 
>>> Will it be necessary to draw up an MoU with SF? If so what are the key
>>> points the board would like to see covered?
>>> 
>>> Will it be sufficient for the PPMC to work with SF to ensure the
>>> extensions site they provide respects the existing trademark policy?
>>> (bearing in mind that we will eventually be moving
>>> extensions.openoffice.org back to ASF hardware)
>>> 
>>> Would the board prefer it if extensions.openoffice.org were to
>>> redirection to foo.sourceforge.net? (either automatically or via an
>>> information page) If so would this change the answer to the MoU
>>> question above?
>>> 
>>> Will this simplify the AOO ability to address IP and fundraising
>>> concerns generated by non-ASF code and donations requests found on
>>> extensions.apache.org?
>>> 
>>> Does the board have any concerns about advertising appearing on
>>> extensions.openoffice.org? Would this concern be mitigated by refusing
>>> permission to serve advertising from extensions.openoffice.org but
>>> allowing it on the download pages on an sf.net domain?
>>> 
>>> If the board would like to discuss this at the next board meeting I
>>> will try and be on the call to answer an questions. In the meantime
>>> I'm here on this list.
>>> 
>>> Ross
>>> 
>>> On 3 January 2012 15:51, Ross Gardler <rg...@opendirective.com> wrote:
>>>> As the community know Gav, in his role at infrastructure@ has
>>>> undertaken to stabilise and migrate the AOO extensions code to ASF
>>>> infrastructure. His work has been progressing and he remains committed
>>>> to completing this.
>>>> 
>>>> However, as some know Sourceforge made an offer to help via our
>>>> private list. At the time they did not want to discuss this topic in
>>>> public for a number of reasons. I've had a couple of chats with
>>>> Roberto Gallopini and Jeff Drobick in order to help them understand
>>>> why the ASF prefers to host all services for its projects. In response
>>>> SF have tailored their offer of support.
>>>> 
>>>> I relayed the outline of our conversations to the infrastructure team
>>>> who have asked me to have the AOO project provide some feedback, via a
>>>> board report, on what problems the AOO project forsee for the
>>>> extensions site and what options are available, if possible a
>>>> recommendation for an optimal solution should also be made. Note that
>>>> we can submit something out of cycle if we want, the next full report
>>>> is not due till March.
>>>> 
>>>> The reason infra@ have escalated to board@ is probably that we need to
>>>> figure out a long term solution for the AOO project and that solution
>>>> is heavily influenced by ASF policy. Any solution that we are
>>>> currently considering will have an impact on the AOO extensions site
>>>> and/or on ASF policy.
>>>> 
>>>> The current situation, as I understand it, is that the board have
>>>> given permission for the extensions site to be managed by infra during
>>>> incubation. The problem of distributing content under licences other
>>>> than Apache is not seen to be a problem during the incubation process.
>>>> Beyond incubation the board has delegated responsibility to the
>>>> Incubator PMC. I don't believe that particular discussion has been
>>>> started yet.
>>>> 
>>>> Gav tells us that he has been thinking about making the extensions
>>>> site an index site, thus allowing the extensions to be housed
>>>> elsewhere (apache-extras, sourceforge, google code, github, FooBar
>>>> corporation or wherever). This would neatly bypass the licence
>>>> problem. Open source extensions needing hosting could go to
>>>> apache-extras while commercially licensed extensions would need to
>>>> provide their own hosting.
>>>> 
>>>> An alternative is to work with a third party willing to help. I've
>>>> copied below the text of a mail outlining the SF proposal. You will
>>>> note that they are keen to ensure that we don't get locked into the SF
>>>> services. Nevertheless, one of the reasons the ASF hosts its own
>>>> services is to avoid exposing us to unmanageable risk.
>>>> 
>>>> I have no reason to believe SourceForge have anything other than good
>>>> intentions in making this offer. SF has been supporting open source
>>>> for a very long time. It is backed at the highest level (Jeff is
>>>> President and CEO) and I believe Roberto is known within the
>>>> OpenOffce.org community. However, many aspects of this will be outside
>>>> of the control of the AOO project, despite SFs real attempts to
>>>> mitigate our concerns relating to this.
>>>> 
>>>> Please note that the timescales Jeff outlines are unrealistic given
>>>> that we need to seek board input before being able to ensure the AOO
>>>> project makes the right decision.  SF want to move quickly, but I
>>>> don't think we need to be rushed into making a decision.
>>>> 
>>>> Once you've digested and debated the offer from Sourceforge the
>>>> community needs to come up with a couple of paragraphs indicating a
>>>> desired route forwards and reasons for it. I will try and attend the
>>>> appropriate board meeting in order to answer any questions that arise.
>>>> 
>>>> Please be imaginative in your planning for the future. The optimal
>>>> solution might be some combination of ASF and SF offerings.
>>>> 
>>>> Note Roberto Gallopini has joined this list and is ready to make any
>>>> clarifications necessary. I've also made Gav aware of this post so
>>>> that he can answer any questions we have about what infra@ are able to
>>>> do.
>>>> 
>>>> Thanks,
>>>> Ross
>>>> 
>>>> --- COPIED PROPOSAL ---
>>>> 
>>>> I'm glad we had a chance to talk last week - exciting times for Open
>>>> Office as the product and community transition into the ASF.
>>>> 
>>>> For over a decade, SourceForge has been committed to advancing the
>>>> open source software community.  We host over 300,000 projects and are
>>>> visited by over 40 MM users per month for free, secure, and fast
>>>> downloads of open source software.  Trusted and reliable download
>>>> delivery is an important part of our service, with over 4 million
>>>> downloads per day and 2 PB from our mirror network each month.  We are
>>>> committed to helping OSS projects scale and grow.
>>>> 
>>>> Based on our discussions, we understand there are a few things you are
>>>> solving for as part of the Open Office Incubation effort:
>>>> Supporting a diverse licensing terms for Open Office extensions, that
>>>> may not all comply with the Apache OSS policy;
>>>> Stabilizing your Drupal OO Extensions site and ensuring high
>>>> availability and download bandwidth without cost
>>>> Expanding both the developer base who will move into working on the
>>>> Apache framework as well as adoption of the Open Office product and
>>>> extensions.
>>>> We think we can help and that there would be mutual benefit.  To that
>>>> end, we propose the following for your consideration:
>>>> 
>>>> 1.) Stabilize the your OO Extensions Drupal instance by moving the it
>>>> and all services to SourceForge.  Our Site Operations team will do teh
>>>> work and oversee the operations for you as we do other services.  To
>>>> your community the directory will look the same and extension and
>>>> template files will move to SourceForge's globally-distributed
>>>> download mirror network where we can ensure reliable, scalable
>>>> delivery.  Drupal will be hosted on our project web service, serving
>>>> your existing domain via a VHOST.  Standard infrastructure
>>>> (monitoring, backups, etc.) and service levels (99.9% availability
>>>> target) apply.
>>>> 
>>>> These SourceForge services will be provided gratis, and without
>>>> lock-in -- you are open to change your mind later.  We anticipate this
>>>> migration would involve a week of planning and preparation, followed
>>>> by a week of migration and pre/post-migration communications.  We're
>>>> prepared to commence this work the next week if provided your approval
>>>> and support.
>>>> 
>>>> 2.) Once stabilized, we will work with you on a timeline to evaluate
>>>> and execute a migration from Drupal 5 to Drupal 7.
>>>> 
>>>> Allowing us to host the Extensions community will solve the license
>>>> challenges - or at least give you time to work through a longer term
>>>> solution.  We would also be able to cross promote the software titles
>>>> to the development community as well - so perhaps expand not only your
>>>> user base but developers.
>>>> 
>>>> Roberto (our Sr. Director of Business Development) has been involved
>>>> in the OpenOffice.org community for many years -- he will continue to
>>>> be your point-of-contact.  If we secure the go-ahead this week, we
>>>> will start on Tuesday next week and expect to be complete by 1/15 with
>>>> step 1.  I have asked our head of Site Ops to oversee the
>>>> implementation and he'll partner up with your technical folks to
>>>> ensure the hosting transition goes well.
>>>> 
>>>> Our motivation here is quite simple, it is all part of our mission to
>>>> help Open Source Software initiatives succeed.  To that end,
>>>> SourceForge and Geeknet Media are able to fund these services and make
>>>> them free to the community through advertising largely on the download
>>>> and directory pages.  So there won't ever be a charge back to your
>>>> community and we are able to reinvest in R&D on our developer tools as
>>>> well.
>>>> 
>>>> We look forward to hearing back from you this week if possible.  Feel
>>>> free to forward this on to whomever you would like in terms of getting
>>>> to an aligned decision.
>>>> 
>>>> I wish you a happy new year!
>>>> 
>>>> --
>>>> Thank you,
>>>> Jeff
>>>> 
>>>> --- End of copied text ---
>>>> --
>>>> Ross Gardler (@rgardler)
>>>> Programme Leader (Open Development)
>>>> OpenDirective http://opendirective.com
>>> 
>>> 
>>> 
>>> --
>>> Ross Gardler (@rgardler)
>>> Programme Leader (Open Development)
>>> OpenDirective http://opendirective.com
> 
> 
> 
> -- 
> Ross Gardler (@rgardler)
> Programme Leader (Open Development)
> OpenDirective http://opendirective.com

Re: Extensions hosting

[Ross Gardler <rg...@opendirective.com>]

On 12 January 2012 19:01, Dave Fisher <da...@comcast.net> wrote:
> Sorry to top post.
>
> A distinction exists between extensions.oo.o and extensions.services.oo.o.
>
> The first is part of the OOo-site and the second is the service.

Thanks Dave. Just so I'm absolutely clear does this change the
proposal other than the precise domain names allocated? I'm not sure
this distinction had been made before.

Specifically is the SF proposal to take both the site and the service?

Ross


>
> Regards,
> Dave
>
> Sent from my iPhone
>
> On Jan 12, 2012, at 9:34 AM, Ross Gardler <rg...@opendirective.com> wrote:
>
>> I'm attempting to summarise this thread and thus I'm top-posting on
>> the orginal opening thread.
>>
>> I will send the below text to the board for consideration. I'll
>> feedback here after the next board meeting (18th) or sooner if
>> possible.
>>
>> Dear Board,
>>
>> The Apache Open Office project needs to stabilise the hosting of their
>> extensions.openoffice.org service. The code needs updating and
>> bandwidth requirements need to be addressed.
>>
>> Gav, on behalf of the infra team, has offered to move the server to
>> ASF hardware and stabilise the code. Longer term Gav indicated that
>> his desire was to turn the service into a meta-data hosting service
>> whereby extensions could be discovered via extensions.openoffice.,org
>> but hosted in third party locations.
>>
>> This plan requires the hosting non-apache software (including closed
>> source) on ASF hardware. This was approved by the board with
>> responsibility for resolving the IP issues being delegated to the IPMC
>> (http://s.apache.org/fO - members only link).
>>
>> In the meantime Sourceforge have offered to help, initially through an
>> approach to Rob Weir of the AOO project and then through myself. I
>> took this proposal (via infra@ who requested the PPMC bring it to the
>> boards attention) to the AOO dev project for discussion. The thread
>> can be found at http://s.apache.org/sz6 (public) - the first post in
>> that thread includes the proposal from Jeff Drobnick (President and
>> CEO of Geeknet media, it also includes a number of clarifications from
>> Roberto Gallopini of Geeknet. I've tried to summarise for you here.
>>
>> After a long discussion the AOO podling has reached a consensus that
>> the best way forward would be to accept the proposal from Sourceforge
>> as a short term solution whilst working towards the meta-data site for
>> the long term. The PPMC feels that moving the service to a non-ASF
>> host now will minimise disruption for extensions developers and
>> end-users who are unwilling or unable to conform to ASF policy in the
>> long term. Similarly the PPMC feels there is a sufficiently large
>> number of edge cases to make changes in policy more complex than is
>> necessary since it is the PPMCs desire to provide an "approved" list
>> of extensions which are expected to conform to existing ASF IP
>> policies, whilst also enabling third parties to host their own
>> extensions sites that users can choose to access via a meta-data
>> service.
>>
>> We have assurances from SF that they are not interested in locking the
>> AOO project to their hosted services.  Members of the AOO PPMC will
>> have shell access to the system and no attempt will be made by SF to
>> own any of the IP involved.
>>
>> SF reserve the right to serve advertising on the downloads site (and
>> possibly on the extensions site, this needs to be clarified).
>> Downloads would be served from the existing SF mirror network.
>>
>> It is possible for AOO to point to an intermediate page giving users
>> the option of visiting other extensions sites if required. That is
>> extensions.openoffice.org could point to an ASF hosted web page
>> listing multiple third party sites, one of which would be the SF
>> hosted service. Consequently, if necessary it is possible for the PPMC
>> to move hosting to a SF but not to point extensions.openoffice.org
>> there.
>>
>> It is hoped that later releases of AOO will include the ability to
>> search for extensions via a meta-data service managed by the AOO
>> project. At this point extensions.openoffice.org would return to ASF
>> hardware. It is expected that the SF hosted extensions repository will
>> continue to exist and will be one of the first repositories from which
>> users will be able to download non-ASF extensions.
>>
>> This proposal raises a few interesting policy questions. Therefore I
>> would like to ask for guidance on how best to help the AOO project
>> realise this objective. A few questions that come to mind are:
>>
>> Will it be necessary to draw up an MoU with SF? If so what are the key
>> points the board would like to see covered?
>>
>> Will it be sufficient for the PPMC to work with SF to ensure the
>> extensions site they provide respects the existing trademark policy?
>> (bearing in mind that we will eventually be moving
>> extensions.openoffice.org back to ASF hardware)
>>
>> Would the board prefer it if extensions.openoffice.org were to
>> redirection to foo.sourceforge.net? (either automatically or via an
>> information page) If so would this change the answer to the MoU
>> question above?
>>
>> Will this simplify the AOO ability to address IP and fundraising
>> concerns generated by non-ASF code and donations requests found on
>> extensions.apache.org?
>>
>> Does the board have any concerns about advertising appearing on
>> extensions.openoffice.org? Would this concern be mitigated by refusing
>> permission to serve advertising from extensions.openoffice.org but
>> allowing it on the download pages on an sf.net domain?
>>
>> If the board would like to discuss this at the next board meeting I
>> will try and be on the call to answer an questions. In the meantime
>> I'm here on this list.
>>
>> Ross
>>
>> On 3 January 2012 15:51, Ross Gardler <rg...@opendirective.com> wrote:
>>> As the community know Gav, in his role at infrastructure@ has
>>> undertaken to stabilise and migrate the AOO extensions code to ASF
>>> infrastructure. His work has been progressing and he remains committed
>>> to completing this.
>>>
>>> However, as some know Sourceforge made an offer to help via our
>>> private list. At the time they did not want to discuss this topic in
>>> public for a number of reasons. I've had a couple of chats with
>>> Roberto Gallopini and Jeff Drobick in order to help them understand
>>> why the ASF prefers to host all services for its projects. In response
>>> SF have tailored their offer of support.
>>>
>>> I relayed the outline of our conversations to the infrastructure team
>>> who have asked me to have the AOO project provide some feedback, via a
>>> board report, on what problems the AOO project forsee for the
>>> extensions site and what options are available, if possible a
>>> recommendation for an optimal solution should also be made. Note that
>>> we can submit something out of cycle if we want, the next full report
>>> is not due till March.
>>>
>>> The reason infra@ have escalated to board@ is probably that we need to
>>> figure out a long term solution for the AOO project and that solution
>>> is heavily influenced by ASF policy. Any solution that we are
>>> currently considering will have an impact on the AOO extensions site
>>> and/or on ASF policy.
>>>
>>> The current situation, as I understand it, is that the board have
>>> given permission for the extensions site to be managed by infra during
>>> incubation. The problem of distributing content under licences other
>>> than Apache is not seen to be a problem during the incubation process.
>>> Beyond incubation the board has delegated responsibility to the
>>> Incubator PMC. I don't believe that particular discussion has been
>>> started yet.
>>>
>>> Gav tells us that he has been thinking about making the extensions
>>> site an index site, thus allowing the extensions to be housed
>>> elsewhere (apache-extras, sourceforge, google code, github, FooBar
>>> corporation or wherever). This would neatly bypass the licence
>>> problem. Open source extensions needing hosting could go to
>>> apache-extras while commercially licensed extensions would need to
>>> provide their own hosting.
>>>
>>> An alternative is to work with a third party willing to help. I've
>>> copied below the text of a mail outlining the SF proposal. You will
>>> note that they are keen to ensure that we don't get locked into the SF
>>> services. Nevertheless, one of the reasons the ASF hosts its own
>>> services is to avoid exposing us to unmanageable risk.
>>>
>>> I have no reason to believe SourceForge have anything other than good
>>> intentions in making this offer. SF has been supporting open source
>>> for a very long time. It is backed at the highest level (Jeff is
>>> President and CEO) and I believe Roberto is known within the
>>> OpenOffce.org community. However, many aspects of this will be outside
>>> of the control of the AOO project, despite SFs real attempts to
>>> mitigate our concerns relating to this.
>>>
>>> Please note that the timescales Jeff outlines are unrealistic given
>>> that we need to seek board input before being able to ensure the AOO
>>> project makes the right decision.  SF want to move quickly, but I
>>> don't think we need to be rushed into making a decision.
>>>
>>> Once you've digested and debated the offer from Sourceforge the
>>> community needs to come up with a couple of paragraphs indicating a
>>> desired route forwards and reasons for it. I will try and attend the
>>> appropriate board meeting in order to answer any questions that arise.
>>>
>>> Please be imaginative in your planning for the future. The optimal
>>> solution might be some combination of ASF and SF offerings.
>>>
>>> Note Roberto Gallopini has joined this list and is ready to make any
>>> clarifications necessary. I've also made Gav aware of this post so
>>> that he can answer any questions we have about what infra@ are able to
>>> do.
>>>
>>> Thanks,
>>> Ross
>>>
>>> --- COPIED PROPOSAL ---
>>>
>>> I'm glad we had a chance to talk last week - exciting times for Open
>>> Office as the product and community transition into the ASF.
>>>
>>> For over a decade, SourceForge has been committed to advancing the
>>> open source software community.  We host over 300,000 projects and are
>>> visited by over 40 MM users per month for free, secure, and fast
>>> downloads of open source software.  Trusted and reliable download
>>> delivery is an important part of our service, with over 4 million
>>> downloads per day and 2 PB from our mirror network each month.  We are
>>> committed to helping OSS projects scale and grow.
>>>
>>> Based on our discussions, we understand there are a few things you are
>>> solving for as part of the Open Office Incubation effort:
>>> Supporting a diverse licensing terms for Open Office extensions, that
>>> may not all comply with the Apache OSS policy;
>>> Stabilizing your Drupal OO Extensions site and ensuring high
>>> availability and download bandwidth without cost
>>> Expanding both the developer base who will move into working on the
>>> Apache framework as well as adoption of the Open Office product and
>>> extensions.
>>> We think we can help and that there would be mutual benefit.  To that
>>> end, we propose the following for your consideration:
>>>
>>> 1.) Stabilize the your OO Extensions Drupal instance by moving the it
>>> and all services to SourceForge.  Our Site Operations team will do teh
>>> work and oversee the operations for you as we do other services.  To
>>> your community the directory will look the same and extension and
>>> template files will move to SourceForge's globally-distributed
>>> download mirror network where we can ensure reliable, scalable
>>> delivery.  Drupal will be hosted on our project web service, serving
>>> your existing domain via a VHOST.  Standard infrastructure
>>> (monitoring, backups, etc.) and service levels (99.9% availability
>>> target) apply.
>>>
>>> These SourceForge services will be provided gratis, and without
>>> lock-in -- you are open to change your mind later.  We anticipate this
>>> migration would involve a week of planning and preparation, followed
>>> by a week of migration and pre/post-migration communications.  We're
>>> prepared to commence this work the next week if provided your approval
>>> and support.
>>>
>>> 2.) Once stabilized, we will work with you on a timeline to evaluate
>>> and execute a migration from Drupal 5 to Drupal 7.
>>>
>>> Allowing us to host the Extensions community will solve the license
>>> challenges - or at least give you time to work through a longer term
>>> solution.  We would also be able to cross promote the software titles
>>> to the development community as well - so perhaps expand not only your
>>> user base but developers.
>>>
>>> Roberto (our Sr. Director of Business Development) has been involved
>>> in the OpenOffice.org community for many years -- he will continue to
>>> be your point-of-contact.  If we secure the go-ahead this week, we
>>> will start on Tuesday next week and expect to be complete by 1/15 with
>>> step 1.  I have asked our head of Site Ops to oversee the
>>> implementation and he'll partner up with your technical folks to
>>> ensure the hosting transition goes well.
>>>
>>> Our motivation here is quite simple, it is all part of our mission to
>>> help Open Source Software initiatives succeed.  To that end,
>>> SourceForge and Geeknet Media are able to fund these services and make
>>> them free to the community through advertising largely on the download
>>> and directory pages.  So there won't ever be a charge back to your
>>> community and we are able to reinvest in R&D on our developer tools as
>>> well.
>>>
>>> We look forward to hearing back from you this week if possible.  Feel
>>> free to forward this on to whomever you would like in terms of getting
>>> to an aligned decision.
>>>
>>> I wish you a happy new year!
>>>
>>> --
>>> Thank you,
>>> Jeff
>>>
>>> --- End of copied text ---
>>> --
>>> Ross Gardler (@rgardler)
>>> Programme Leader (Open Development)
>>> OpenDirective http://opendirective.com
>>
>>
>>
>> --
>> Ross Gardler (@rgardler)
>> Programme Leader (Open Development)
>> OpenDirective http://opendirective.com



-- 
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com

Re: Extensions hosting

[Dave Fisher <da...@comcast.net>]

Sorry to top post.

A distinction exists between extensions.oo.o and extensions.services.oo.o.

The first is part of the OOo-site and the second is the service.

Regards,
Dave

Sent from my iPhone

On Jan 12, 2012, at 9:34 AM, Ross Gardler <rg...@opendirective.com> wrote:

> I'm attempting to summarise this thread and thus I'm top-posting on
> the orginal opening thread.
> 
> I will send the below text to the board for consideration. I'll
> feedback here after the next board meeting (18th) or sooner if
> possible.
> 
> Dear Board,
> 
> The Apache Open Office project needs to stabilise the hosting of their
> extensions.openoffice.org service. The code needs updating and
> bandwidth requirements need to be addressed.
> 
> Gav, on behalf of the infra team, has offered to move the server to
> ASF hardware and stabilise the code. Longer term Gav indicated that
> his desire was to turn the service into a meta-data hosting service
> whereby extensions could be discovered via extensions.openoffice.,org
> but hosted in third party locations.
> 
> This plan requires the hosting non-apache software (including closed
> source) on ASF hardware. This was approved by the board with
> responsibility for resolving the IP issues being delegated to the IPMC
> (http://s.apache.org/fO - members only link).
> 
> In the meantime Sourceforge have offered to help, initially through an
> approach to Rob Weir of the AOO project and then through myself. I
> took this proposal (via infra@ who requested the PPMC bring it to the
> boards attention) to the AOO dev project for discussion. The thread
> can be found at http://s.apache.org/sz6 (public) - the first post in
> that thread includes the proposal from Jeff Drobnick (President and
> CEO of Geeknet media, it also includes a number of clarifications from
> Roberto Gallopini of Geeknet. I've tried to summarise for you here.
> 
> After a long discussion the AOO podling has reached a consensus that
> the best way forward would be to accept the proposal from Sourceforge
> as a short term solution whilst working towards the meta-data site for
> the long term. The PPMC feels that moving the service to a non-ASF
> host now will minimise disruption for extensions developers and
> end-users who are unwilling or unable to conform to ASF policy in the
> long term. Similarly the PPMC feels there is a sufficiently large
> number of edge cases to make changes in policy more complex than is
> necessary since it is the PPMCs desire to provide an "approved" list
> of extensions which are expected to conform to existing ASF IP
> policies, whilst also enabling third parties to host their own
> extensions sites that users can choose to access via a meta-data
> service.
> 
> We have assurances from SF that they are not interested in locking the
> AOO project to their hosted services.  Members of the AOO PPMC will
> have shell access to the system and no attempt will be made by SF to
> own any of the IP involved.
> 
> SF reserve the right to serve advertising on the downloads site (and
> possibly on the extensions site, this needs to be clarified).
> Downloads would be served from the existing SF mirror network.
> 
> It is possible for AOO to point to an intermediate page giving users
> the option of visiting other extensions sites if required. That is
> extensions.openoffice.org could point to an ASF hosted web page
> listing multiple third party sites, one of which would be the SF
> hosted service. Consequently, if necessary it is possible for the PPMC
> to move hosting to a SF but not to point extensions.openoffice.org
> there.
> 
> It is hoped that later releases of AOO will include the ability to
> search for extensions via a meta-data service managed by the AOO
> project. At this point extensions.openoffice.org would return to ASF
> hardware. It is expected that the SF hosted extensions repository will
> continue to exist and will be one of the first repositories from which
> users will be able to download non-ASF extensions.
> 
> This proposal raises a few interesting policy questions. Therefore I
> would like to ask for guidance on how best to help the AOO project
> realise this objective. A few questions that come to mind are:
> 
> Will it be necessary to draw up an MoU with SF? If so what are the key
> points the board would like to see covered?
> 
> Will it be sufficient for the PPMC to work with SF to ensure the
> extensions site they provide respects the existing trademark policy?
> (bearing in mind that we will eventually be moving
> extensions.openoffice.org back to ASF hardware)
> 
> Would the board prefer it if extensions.openoffice.org were to
> redirection to foo.sourceforge.net? (either automatically or via an
> information page) If so would this change the answer to the MoU
> question above?
> 
> Will this simplify the AOO ability to address IP and fundraising
> concerns generated by non-ASF code and donations requests found on
> extensions.apache.org?
> 
> Does the board have any concerns about advertising appearing on
> extensions.openoffice.org? Would this concern be mitigated by refusing
> permission to serve advertising from extensions.openoffice.org but
> allowing it on the download pages on an sf.net domain?
> 
> If the board would like to discuss this at the next board meeting I
> will try and be on the call to answer an questions. In the meantime
> I'm here on this list.
> 
> Ross
> 
> On 3 January 2012 15:51, Ross Gardler <rg...@opendirective.com> wrote:
>> As the community know Gav, in his role at infrastructure@ has
>> undertaken to stabilise and migrate the AOO extensions code to ASF
>> infrastructure. His work has been progressing and he remains committed
>> to completing this.
>> 
>> However, as some know Sourceforge made an offer to help via our
>> private list. At the time they did not want to discuss this topic in
>> public for a number of reasons. I've had a couple of chats with
>> Roberto Gallopini and Jeff Drobick in order to help them understand
>> why the ASF prefers to host all services for its projects. In response
>> SF have tailored their offer of support.
>> 
>> I relayed the outline of our conversations to the infrastructure team
>> who have asked me to have the AOO project provide some feedback, via a
>> board report, on what problems the AOO project forsee for the
>> extensions site and what options are available, if possible a
>> recommendation for an optimal solution should also be made. Note that
>> we can submit something out of cycle if we want, the next full report
>> is not due till March.
>> 
>> The reason infra@ have escalated to board@ is probably that we need to
>> figure out a long term solution for the AOO project and that solution
>> is heavily influenced by ASF policy. Any solution that we are
>> currently considering will have an impact on the AOO extensions site
>> and/or on ASF policy.
>> 
>> The current situation, as I understand it, is that the board have
>> given permission for the extensions site to be managed by infra during
>> incubation. The problem of distributing content under licences other
>> than Apache is not seen to be a problem during the incubation process.
>> Beyond incubation the board has delegated responsibility to the
>> Incubator PMC. I don't believe that particular discussion has been
>> started yet.
>> 
>> Gav tells us that he has been thinking about making the extensions
>> site an index site, thus allowing the extensions to be housed
>> elsewhere (apache-extras, sourceforge, google code, github, FooBar
>> corporation or wherever). This would neatly bypass the licence
>> problem. Open source extensions needing hosting could go to
>> apache-extras while commercially licensed extensions would need to
>> provide their own hosting.
>> 
>> An alternative is to work with a third party willing to help. I've
>> copied below the text of a mail outlining the SF proposal. You will
>> note that they are keen to ensure that we don't get locked into the SF
>> services. Nevertheless, one of the reasons the ASF hosts its own
>> services is to avoid exposing us to unmanageable risk.
>> 
>> I have no reason to believe SourceForge have anything other than good
>> intentions in making this offer. SF has been supporting open source
>> for a very long time. It is backed at the highest level (Jeff is
>> President and CEO) and I believe Roberto is known within the
>> OpenOffce.org community. However, many aspects of this will be outside
>> of the control of the AOO project, despite SFs real attempts to
>> mitigate our concerns relating to this.
>> 
>> Please note that the timescales Jeff outlines are unrealistic given
>> that we need to seek board input before being able to ensure the AOO
>> project makes the right decision.  SF want to move quickly, but I
>> don't think we need to be rushed into making a decision.
>> 
>> Once you've digested and debated the offer from Sourceforge the
>> community needs to come up with a couple of paragraphs indicating a
>> desired route forwards and reasons for it. I will try and attend the
>> appropriate board meeting in order to answer any questions that arise.
>> 
>> Please be imaginative in your planning for the future. The optimal
>> solution might be some combination of ASF and SF offerings.
>> 
>> Note Roberto Gallopini has joined this list and is ready to make any
>> clarifications necessary. I've also made Gav aware of this post so
>> that he can answer any questions we have about what infra@ are able to
>> do.
>> 
>> Thanks,
>> Ross
>> 
>> --- COPIED PROPOSAL ---
>> 
>> I'm glad we had a chance to talk last week - exciting times for Open
>> Office as the product and community transition into the ASF.
>> 
>> For over a decade, SourceForge has been committed to advancing the
>> open source software community.  We host over 300,000 projects and are
>> visited by over 40 MM users per month for free, secure, and fast
>> downloads of open source software.  Trusted and reliable download
>> delivery is an important part of our service, with over 4 million
>> downloads per day and 2 PB from our mirror network each month.  We are
>> committed to helping OSS projects scale and grow.
>> 
>> Based on our discussions, we understand there are a few things you are
>> solving for as part of the Open Office Incubation effort:
>> Supporting a diverse licensing terms for Open Office extensions, that
>> may not all comply with the Apache OSS policy;
>> Stabilizing your Drupal OO Extensions site and ensuring high
>> availability and download bandwidth without cost
>> Expanding both the developer base who will move into working on the
>> Apache framework as well as adoption of the Open Office product and
>> extensions.
>> We think we can help and that there would be mutual benefit.  To that
>> end, we propose the following for your consideration:
>> 
>> 1.) Stabilize the your OO Extensions Drupal instance by moving the it
>> and all services to SourceForge.  Our Site Operations team will do teh
>> work and oversee the operations for you as we do other services.  To
>> your community the directory will look the same and extension and
>> template files will move to SourceForge's globally-distributed
>> download mirror network where we can ensure reliable, scalable
>> delivery.  Drupal will be hosted on our project web service, serving
>> your existing domain via a VHOST.  Standard infrastructure
>> (monitoring, backups, etc.) and service levels (99.9% availability
>> target) apply.
>> 
>> These SourceForge services will be provided gratis, and without
>> lock-in -- you are open to change your mind later.  We anticipate this
>> migration would involve a week of planning and preparation, followed
>> by a week of migration and pre/post-migration communications.  We're
>> prepared to commence this work the next week if provided your approval
>> and support.
>> 
>> 2.) Once stabilized, we will work with you on a timeline to evaluate
>> and execute a migration from Drupal 5 to Drupal 7.
>> 
>> Allowing us to host the Extensions community will solve the license
>> challenges - or at least give you time to work through a longer term
>> solution.  We would also be able to cross promote the software titles
>> to the development community as well - so perhaps expand not only your
>> user base but developers.
>> 
>> Roberto (our Sr. Director of Business Development) has been involved
>> in the OpenOffice.org community for many years -- he will continue to
>> be your point-of-contact.  If we secure the go-ahead this week, we
>> will start on Tuesday next week and expect to be complete by 1/15 with
>> step 1.  I have asked our head of Site Ops to oversee the
>> implementation and he'll partner up with your technical folks to
>> ensure the hosting transition goes well.
>> 
>> Our motivation here is quite simple, it is all part of our mission to
>> help Open Source Software initiatives succeed.  To that end,
>> SourceForge and Geeknet Media are able to fund these services and make
>> them free to the community through advertising largely on the download
>> and directory pages.  So there won't ever be a charge back to your
>> community and we are able to reinvest in R&D on our developer tools as
>> well.
>> 
>> We look forward to hearing back from you this week if possible.  Feel
>> free to forward this on to whomever you would like in terms of getting
>> to an aligned decision.
>> 
>> I wish you a happy new year!
>> 
>> --
>> Thank you,
>> Jeff
>> 
>> --- End of copied text ---
>> --
>> Ross Gardler (@rgardler)
>> Programme Leader (Open Development)
>> OpenDirective http://opendirective.com
> 
> 
> 
> -- 
> Ross Gardler (@rgardler)
> Programme Leader (Open Development)
> OpenDirective http://opendirective.com

Re: Extensions hosting

[Ross Gardler <rg...@opendirective.com>]

I'm attempting to summarise this thread and thus I'm top-posting on
the orginal opening thread.

I will send the below text to the board for consideration. I'll
feedback here after the next board meeting (18th) or sooner if
possible.

Dear Board,

The Apache Open Office project needs to stabilise the hosting of their
extensions.openoffice.org service. The code needs updating and
bandwidth requirements need to be addressed.

Gav, on behalf of the infra team, has offered to move the server to
ASF hardware and stabilise the code. Longer term Gav indicated that
his desire was to turn the service into a meta-data hosting service
whereby extensions could be discovered via extensions.openoffice.,org
but hosted in third party locations.

This plan requires the hosting non-apache software (including closed
source) on ASF hardware. This was approved by the board with
responsibility for resolving the IP issues being delegated to the IPMC
(http://s.apache.org/fO - members only link).

In the meantime Sourceforge have offered to help, initially through an
approach to Rob Weir of the AOO project and then through myself. I
took this proposal (via infra@ who requested the PPMC bring it to the
boards attention) to the AOO dev project for discussion. The thread
can be found at http://s.apache.org/sz6 (public) - the first post in
that thread includes the proposal from Jeff Drobnick (President and
CEO of Geeknet media, it also includes a number of clarifications from
Roberto Gallopini of Geeknet. I've tried to summarise for you here.

After a long discussion the AOO podling has reached a consensus that
the best way forward would be to accept the proposal from Sourceforge
as a short term solution whilst working towards the meta-data site for
the long term. The PPMC feels that moving the service to a non-ASF
host now will minimise disruption for extensions developers and
end-users who are unwilling or unable to conform to ASF policy in the
long term. Similarly the PPMC feels there is a sufficiently large
number of edge cases to make changes in policy more complex than is
necessary since it is the PPMCs desire to provide an "approved" list
of extensions which are expected to conform to existing ASF IP
policies, whilst also enabling third parties to host their own
extensions sites that users can choose to access via a meta-data
service.

We have assurances from SF that they are not interested in locking the
AOO project to their hosted services.  Members of the AOO PPMC will
have shell access to the system and no attempt will be made by SF to
own any of the IP involved.

SF reserve the right to serve advertising on the downloads site (and
possibly on the extensions site, this needs to be clarified).
Downloads would be served from the existing SF mirror network.

It is possible for AOO to point to an intermediate page giving users
the option of visiting other extensions sites if required. That is
extensions.openoffice.org could point to an ASF hosted web page
listing multiple third party sites, one of which would be the SF
hosted service. Consequently, if necessary it is possible for the PPMC
to move hosting to a SF but not to point extensions.openoffice.org
there.

It is hoped that later releases of AOO will include the ability to
search for extensions via a meta-data service managed by the AOO
project. At this point extensions.openoffice.org would return to ASF
hardware. It is expected that the SF hosted extensions repository will
continue to exist and will be one of the first repositories from which
users will be able to download non-ASF extensions.

This proposal raises a few interesting policy questions. Therefore I
would like to ask for guidance on how best to help the AOO project
realise this objective. A few questions that come to mind are:

Will it be necessary to draw up an MoU with SF? If so what are the key
points the board would like to see covered?

Will it be sufficient for the PPMC to work with SF to ensure the
extensions site they provide respects the existing trademark policy?
(bearing in mind that we will eventually be moving
extensions.openoffice.org back to ASF hardware)

Would the board prefer it if extensions.openoffice.org were to
redirection to foo.sourceforge.net? (either automatically or via an
information page) If so would this change the answer to the MoU
question above?

Will this simplify the AOO ability to address IP and fundraising
concerns generated by non-ASF code and donations requests found on
extensions.apache.org?

Does the board have any concerns about advertising appearing on
extensions.openoffice.org? Would this concern be mitigated by refusing
permission to serve advertising from extensions.openoffice.org but
allowing it on the download pages on an sf.net domain?

If the board would like to discuss this at the next board meeting I
will try and be on the call to answer an questions. In the meantime
I'm here on this list.

Ross

On 3 January 2012 15:51, Ross Gardler <rg...@opendirective.com> wrote:
> As the community know Gav, in his role at infrastructure@ has
> undertaken to stabilise and migrate the AOO extensions code to ASF
> infrastructure. His work has been progressing and he remains committed
> to completing this.
>
> However, as some know Sourceforge made an offer to help via our
> private list. At the time they did not want to discuss this topic in
> public for a number of reasons. I've had a couple of chats with
> Roberto Gallopini and Jeff Drobick in order to help them understand
> why the ASF prefers to host all services for its projects. In response
> SF have tailored their offer of support.
>
> I relayed the outline of our conversations to the infrastructure team
> who have asked me to have the AOO project provide some feedback, via a
> board report, on what problems the AOO project forsee for the
> extensions site and what options are available, if possible a
> recommendation for an optimal solution should also be made. Note that
> we can submit something out of cycle if we want, the next full report
> is not due till March.
>
> The reason infra@ have escalated to board@ is probably that we need to
> figure out a long term solution for the AOO project and that solution
> is heavily influenced by ASF policy. Any solution that we are
> currently considering will have an impact on the AOO extensions site
> and/or on ASF policy.
>
> The current situation, as I understand it, is that the board have
> given permission for the extensions site to be managed by infra during
> incubation. The problem of distributing content under licences other
> than Apache is not seen to be a problem during the incubation process.
> Beyond incubation the board has delegated responsibility to the
> Incubator PMC. I don't believe that particular discussion has been
> started yet.
>
> Gav tells us that he has been thinking about making the extensions
> site an index site, thus allowing the extensions to be housed
> elsewhere (apache-extras, sourceforge, google code, github, FooBar
> corporation or wherever). This would neatly bypass the licence
> problem. Open source extensions needing hosting could go to
> apache-extras while commercially licensed extensions would need to
> provide their own hosting.
>
> An alternative is to work with a third party willing to help. I've
> copied below the text of a mail outlining the SF proposal. You will
> note that they are keen to ensure that we don't get locked into the SF
> services. Nevertheless, one of the reasons the ASF hosts its own
> services is to avoid exposing us to unmanageable risk.
>
> I have no reason to believe SourceForge have anything other than good
> intentions in making this offer. SF has been supporting open source
> for a very long time. It is backed at the highest level (Jeff is
> President and CEO) and I believe Roberto is known within the
> OpenOffce.org community. However, many aspects of this will be outside
> of the control of the AOO project, despite SFs real attempts to
> mitigate our concerns relating to this.
>
> Please note that the timescales Jeff outlines are unrealistic given
> that we need to seek board input before being able to ensure the AOO
> project makes the right decision.  SF want to move quickly, but I
> don't think we need to be rushed into making a decision.
>
> Once you've digested and debated the offer from Sourceforge the
> community needs to come up with a couple of paragraphs indicating a
> desired route forwards and reasons for it. I will try and attend the
> appropriate board meeting in order to answer any questions that arise.
>
> Please be imaginative in your planning for the future. The optimal
> solution might be some combination of ASF and SF offerings.
>
> Note Roberto Gallopini has joined this list and is ready to make any
> clarifications necessary. I've also made Gav aware of this post so
> that he can answer any questions we have about what infra@ are able to
> do.
>
> Thanks,
> Ross
>
> --- COPIED PROPOSAL ---
>
> I'm glad we had a chance to talk last week - exciting times for Open
> Office as the product and community transition into the ASF.
>
> For over a decade, SourceForge has been committed to advancing the
> open source software community.  We host over 300,000 projects and are
> visited by over 40 MM users per month for free, secure, and fast
> downloads of open source software.  Trusted and reliable download
> delivery is an important part of our service, with over 4 million
> downloads per day and 2 PB from our mirror network each month.  We are
> committed to helping OSS projects scale and grow.
>
> Based on our discussions, we understand there are a few things you are
> solving for as part of the Open Office Incubation effort:
> Supporting a diverse licensing terms for Open Office extensions, that
> may not all comply with the Apache OSS policy;
> Stabilizing your Drupal OO Extensions site and ensuring high
> availability and download bandwidth without cost
> Expanding both the developer base who will move into working on the
> Apache framework as well as adoption of the Open Office product and
> extensions.
> We think we can help and that there would be mutual benefit.  To that
> end, we propose the following for your consideration:
>
> 1.) Stabilize the your OO Extensions Drupal instance by moving the it
> and all services to SourceForge.  Our Site Operations team will do teh
> work and oversee the operations for you as we do other services.  To
> your community the directory will look the same and extension and
> template files will move to SourceForge's globally-distributed
> download mirror network where we can ensure reliable, scalable
> delivery.  Drupal will be hosted on our project web service, serving
> your existing domain via a VHOST.  Standard infrastructure
> (monitoring, backups, etc.) and service levels (99.9% availability
> target) apply.
>
> These SourceForge services will be provided gratis, and without
> lock-in -- you are open to change your mind later.  We anticipate this
> migration would involve a week of planning and preparation, followed
> by a week of migration and pre/post-migration communications.  We're
> prepared to commence this work the next week if provided your approval
> and support.
>
> 2.) Once stabilized, we will work with you on a timeline to evaluate
> and execute a migration from Drupal 5 to Drupal 7.
>
> Allowing us to host the Extensions community will solve the license
> challenges - or at least give you time to work through a longer term
> solution.  We would also be able to cross promote the software titles
> to the development community as well - so perhaps expand not only your
> user base but developers.
>
> Roberto (our Sr. Director of Business Development) has been involved
> in the OpenOffice.org community for many years -- he will continue to
> be your point-of-contact.  If we secure the go-ahead this week, we
> will start on Tuesday next week and expect to be complete by 1/15 with
> step 1.  I have asked our head of Site Ops to oversee the
> implementation and he'll partner up with your technical folks to
> ensure the hosting transition goes well.
>
> Our motivation here is quite simple, it is all part of our mission to
> help Open Source Software initiatives succeed.  To that end,
> SourceForge and Geeknet Media are able to fund these services and make
> them free to the community through advertising largely on the download
> and directory pages.  So there won't ever be a charge back to your
> community and we are able to reinvest in R&D on our developer tools as
> well.
>
> We look forward to hearing back from you this week if possible.  Feel
> free to forward this on to whomever you would like in terms of getting
> to an aligned decision.
>
> I wish you a happy new year!
>
> --
> Thank you,
> Jeff
>
> --- End of copied text ---
> --
> Ross Gardler (@rgardler)
> Programme Leader (Open Development)
> OpenDirective http://opendirective.com



-- 
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com

Re: Extensions hosting

[Jürgen Schmidt <jo...@googlemail.com>]

On 1/4/12 7:32 PM, Rob Weir wrote:
> On Tue, Jan 3, 2012 at 10:51 AM, Ross Gardler
> <rg...@opendirective.com>  wrote:
>
> <snip>
>
>> Once you've digested and debated the offer from Sourceforge the
>> community needs to come up with a couple of paragraphs indicating a
>> desired route forwards and reasons for it. I will try and attend the
>> appropriate board meeting in order to answer any questions that arise.
>>
>
> Maybe I'm the only dolt here, but one reason it is hard for me to make
> a recommendation on a "desired route forward" is that I only have SF's
> proposal in front of me.  I don't have any proposal from Infra on what
> they would like to do.  Or did I miss it?
>
> I agree with you that the proposed time frame (in two weeks) is too
> fast for us to react.  But I do think that we need a very solid and
> capable extension and template repository before we release AOO 3.4.
> I anticipate heavy traffic at that time. Since we're pushing for a Q1
> release of 3.4, that means we will need to move quickly on stabilizing
> these services.
>
> It would be great to better understand where we might be with an Infra
> effort in this same time frame.
>
> Also, as I understand it, even with a short term stabilization effort
> from Infra, we're still out-of-policy for graduation, and we'd need to
> move to another solution after that.   It sounds like the federated
> approach where host only an index might work.  I think I understand
> what that effort would entail.  Technically it can be clean and
> elegant, but it does have a high coordination cost, dealing with all
> of the extension and templates authors.
>
> On the other hand, an external host, like SF, could get us the
> stability we need, as well as deal with the OSS license compatibility
> policy issues. We resolve it all at once.
>
> I wonder whether one blended solution might be:
>
> 1) Accept SF's offer for the short term stability improvement and
> getting in policy with the copyleft extensions.
>
> 2) In parallel work with Apache Infra, volunteers from this project,
> and from SF (and maybe LibreOffice?), on an Apache Labs project to
> build a simple open source template/extensions management server.
> Maybe we can start from the existing server? (What license is it?)
> Extend that to give the kind of loose coupling and federation we want.
>   When that is ready, the SF will be well positioned to host one of the
> first servers of its kind.  But we'll also be making this software
> available to anyone to set up their own repository.

Important is the format the office requires and the office can handle an 
update feed as well as a plain xml snippet describing the update info. 
The current repo produce such an update feed.

But the backend producing such an update feed is independent. The 
current repo is using Drupal and i think LibreOffice is using plone.

A good resource to get an impression of the feed and xml format is to 
take a look on 
http://svn.apache.org/viewvc/incubator/ooo/trunk/main/desktop/test/deployment/update/...

I took a quick look on it and it seems that for tests we used files 
available on http://extensions.openoffice.org/testarea/desktop/...

This files seems to be lost during the migration. I can't at least find 
them.

See also 
http://svn.apache.org/viewvc/incubator/ooo/trunk/main/desktop/test/deployment/update/readme.txt?view=log

Juergen

>
> -Rob
>
>> Please be imaginative in your planning for the future. The optimal
>> solution might be some combination of ASF and SF offerings.
>>
>> Note Roberto Gallopini has joined this list and is ready to make any
>> clarifications necessary. I've also made Gav aware of this post so
>> that he can answer any questions we have about what infra@ are able to
>> do.
>>
>> Thanks,
>> Ross
>>
>> --- COPIED PROPOSAL ---
>>
>> I'm glad we had a chance to talk last week - exciting times for Open
>> Office as the product and community transition into the ASF.
>>
>> For over a decade, SourceForge has been committed to advancing the
>> open source software community.  We host over 300,000 projects and are
>> visited by over 40 MM users per month for free, secure, and fast
>> downloads of open source software.  Trusted and reliable download
>> delivery is an important part of our service, with over 4 million
>> downloads per day and 2 PB from our mirror network each month.  We are
>> committed to helping OSS projects scale and grow.
>>
>> Based on our discussions, we understand there are a few things you are
>> solving for as part of the Open Office Incubation effort:
>> Supporting a diverse licensing terms for Open Office extensions, that
>> may not all comply with the Apache OSS policy;
>> Stabilizing your Drupal OO Extensions site and ensuring high
>> availability and download bandwidth without cost
>> Expanding both the developer base who will move into working on the
>> Apache framework as well as adoption of the Open Office product and
>> extensions.
>> We think we can help and that there would be mutual benefit.  To that
>> end, we propose the following for your consideration:
>>
>> 1.) Stabilize the your OO Extensions Drupal instance by moving the it
>> and all services to SourceForge.  Our Site Operations team will do teh
>> work and oversee the operations for you as we do other services.  To
>> your community the directory will look the same and extension and
>> template files will move to SourceForge's globally-distributed
>> download mirror network where we can ensure reliable, scalable
>> delivery.  Drupal will be hosted on our project web service, serving
>> your existing domain via a VHOST.  Standard infrastructure
>> (monitoring, backups, etc.) and service levels (99.9% availability
>> target) apply.
>>
>> These SourceForge services will be provided gratis, and without
>> lock-in -- you are open to change your mind later.  We anticipate this
>> migration would involve a week of planning and preparation, followed
>> by a week of migration and pre/post-migration communications.  We're
>> prepared to commence this work the next week if provided your approval
>> and support.
>>
>> 2.) Once stabilized, we will work with you on a timeline to evaluate
>> and execute a migration from Drupal 5 to Drupal 7.
>>
>> Allowing us to host the Extensions community will solve the license
>> challenges - or at least give you time to work through a longer term
>> solution.  We would also be able to cross promote the software titles
>> to the development community as well - so perhaps expand not only your
>> user base but developers.
>>
>> Roberto (our Sr. Director of Business Development) has been involved
>> in the OpenOffice.org community for many years -- he will continue to
>> be your point-of-contact.  If we secure the go-ahead this week, we
>> will start on Tuesday next week and expect to be complete by 1/15 with
>> step 1.  I have asked our head of Site Ops to oversee the
>> implementation and he'll partner up with your technical folks to
>> ensure the hosting transition goes well.
>>
>> Our motivation here is quite simple, it is all part of our mission to
>> help Open Source Software initiatives succeed.  To that end,
>> SourceForge and Geeknet Media are able to fund these services and make
>> them free to the community through advertising largely on the download
>> and directory pages.  So there won't ever be a charge back to your
>> community and we are able to reinvest in R&D on our developer tools as
>> well.
>>
>> We look forward to hearing back from you this week if possible.  Feel
>> free to forward this on to whomever you would like in terms of getting
>> to an aligned decision.
>>
>> I wish you a happy new year!
>>
>> --
>> Thank you,
>> Jeff
>>
>> --- End of copied text ---
>> --
>> Ross Gardler (@rgardler)
>> Programme Leader (Open Development)
>> OpenDirective http://opendirective.com

Re: Extensions hosting

[Rob Weir <ro...@apache.org>]

On Wed, Jan 4, 2012 at 4:41 PM, Gavin McDonald <ga...@16degrees.com.au> wrote:
>
>
>> -----Original Message-----
>> From: Rob Weir [mailto:robweir@apache.org]
>> Sent: Thursday, 5 January 2012 4:32 AM
>> To: ooo-dev@incubator.apache.org
>> Subject: Re: Extensions hosting
>>
>> On Tue, Jan 3, 2012 at 10:51 AM, Ross Gardler <rg...@opendirective.com>
>> wrote:
>>
>> <snip>
>>
>> > Once you've digested and debated the offer from Sourceforge the
>> > community needs to come up with a couple of paragraphs indicating a
>> > desired route forwards and reasons for it. I will try and attend the
>> > appropriate board meeting in order to answer any questions that arise.
>> >
>>
>> Maybe I'm the only dolt here, but one reason it is hard for me to make a
>> recommendation on a "desired route forward" is that I only have SF's
>> proposal in front of me.  I don't have any proposal from Infra on what they
>> would like to do.  Or did I miss it?
>
> Yes you missed it, read the archives.
>

Could you give a link to the post?  I'm probably not the only one that
would like to compare the two proposals.

>>
>> I agree with you that the proposed time frame (in two weeks) is too fast for
>> us to react.  But I do think that we need a very solid and capable extension
>> and template repository before we release AOO 3.4.
>> I anticipate heavy traffic at that time. Since we're pushing for a Q1 release of
>> 3.4, that means we will need to move quickly on stabilizing these services.
>>
>> It would be great to better understand where we might be with an Infra
>> effort in this same time frame.
>>
>> Also, as I understand it, even with a short term stabilization effort from Infra,
>> we're still out-of-policy for graduation, and we'd need to
>> move to another solution after that.   It sounds like the federated
>> approach where host only an index might work.  I think I understand what
>> that effort would entail.  Technically it can be clean and elegant, but it does
>> have a high coordination cost, dealing with all of the extension and templates
>> authors.
>>
>> On the other hand, an external host, like SF, could get us the stability we
>> need, as well as deal with the OSS license compatibility policy issues. We
>> resolve it all at once.
>>
>> I wonder whether one blended solution might be:
>>
>> 1) Accept SF's offer for the short term stability improvement and getting in
>> policy with the copyleft extensions.
>>
>> 2) In parallel work with Apache Infra, volunteers from this project, and from
>> SF (and maybe LibreOffice?), on an Apache Labs project to build a simple
>> open source template/extensions management server.
>> Maybe we can start from the existing server? (What license is it?) Extend
>> that to give the kind of loose coupling and federation we want.
>>  When that is ready, the SF will be well positioned to host one of the first
>> servers of its kind.  But we'll also be making this software available to anyone
>> to set up their own repository.
>
> You are missing the point (well some of it.) Part of the reason for the templates
> and extensions being moved off ours servers for distribution was to reduce the
> heavy load demanded of it at OSUOSL. Our bandwidth is not finate and if we can
> reduce this by having template and extension owners self-host, all the better
> and is one reason why I intended to go with the suggested metadata approach.
>

That's fine. Loose coupling will have all sorts of benefits, not
limited to the ones I (or you) think of here and now

If bandwidth is an issue, then it would be good to resolve how we're
going to deal with the dictionaries -- the aggregation question we
have open with legal-discuss.   If we are not able to include
dictionaries with our releases (which would be mirrored) then every
user would need to download a dictionary very an extension.  That
would be a much bigger bandwidth problem.

> Gav...
>
>>
>> -Rob
>>
>> > Please be imaginative in your planning for the future. The optimal
>> > solution might be some combination of ASF and SF offerings.
>> >
>> > Note Roberto Gallopini has joined this list and is ready to make any
>> > clarifications necessary. I've also made Gav aware of this post so
>> > that he can answer any questions we have about what infra@ are able to
>> > do.
>> >
>> > Thanks,
>> > Ross
>> >
>> > --- COPIED PROPOSAL ---
>> >
>> > I'm glad we had a chance to talk last week - exciting times for Open
>> > Office as the product and community transition into the ASF.
>> >
>> > For over a decade, SourceForge has been committed to advancing the
>> > open source software community.  We host over 300,000 projects and are
>> > visited by over 40 MM users per month for free, secure, and fast
>> > downloads of open source software.  Trusted and reliable download
>> > delivery is an important part of our service, with over 4 million
>> > downloads per day and 2 PB from our mirror network each month.  We are
>> > committed to helping OSS projects scale and grow.
>> >
>> > Based on our discussions, we understand there are a few things you are
>> > solving for as part of the Open Office Incubation effort:
>> > Supporting a diverse licensing terms for Open Office extensions, that
>> > may not all comply with the Apache OSS policy; Stabilizing your Drupal
>> > OO Extensions site and ensuring high availability and download
>> > bandwidth without cost Expanding both the developer base who will move
>> > into working on the Apache framework as well as adoption of the Open
>> > Office product and extensions.
>> > We think we can help and that there would be mutual benefit.  To that
>> > end, we propose the following for your consideration:
>> >
>> > 1.) Stabilize the your OO Extensions Drupal instance by moving the it
>> > and all services to SourceForge.  Our Site Operations team will do teh
>> > work and oversee the operations for you as we do other services.  To
>> > your community the directory will look the same and extension and
>> > template files will move to SourceForge's globally-distributed
>> > download mirror network where we can ensure reliable, scalable
>> > delivery.  Drupal will be hosted on our project web service, serving
>> > your existing domain via a VHOST.  Standard infrastructure
>> > (monitoring, backups, etc.) and service levels (99.9% availability
>> > target) apply.
>> >
>> > These SourceForge services will be provided gratis, and without
>> > lock-in -- you are open to change your mind later.  We anticipate this
>> > migration would involve a week of planning and preparation, followed
>> > by a week of migration and pre/post-migration communications.  We're
>> > prepared to commence this work the next week if provided your approval
>> > and support.
>> >
>> > 2.) Once stabilized, we will work with you on a timeline to evaluate
>> > and execute a migration from Drupal 5 to Drupal 7.
>> >
>> > Allowing us to host the Extensions community will solve the license
>> > challenges - or at least give you time to work through a longer term
>> > solution.  We would also be able to cross promote the software titles
>> > to the development community as well - so perhaps expand not only your
>> > user base but developers.
>> >
>> > Roberto (our Sr. Director of Business Development) has been involved
>> > in the OpenOffice.org community for many years -- he will continue to
>> > be your point-of-contact.  If we secure the go-ahead this week, we
>> > will start on Tuesday next week and expect to be complete by 1/15 with
>> > step 1.  I have asked our head of Site Ops to oversee the
>> > implementation and he'll partner up with your technical folks to
>> > ensure the hosting transition goes well.
>> >
>> > Our motivation here is quite simple, it is all part of our mission to
>> > help Open Source Software initiatives succeed.  To that end,
>> > SourceForge and Geeknet Media are able to fund these services and make
>> > them free to the community through advertising largely on the download
>> > and directory pages.  So there won't ever be a charge back to your
>> > community and we are able to reinvest in R&D on our developer tools as
>> > well.
>> >
>> > We look forward to hearing back from you this week if possible.  Feel
>> > free to forward this on to whomever you would like in terms of getting
>> > to an aligned decision.
>> >
>> > I wish you a happy new year!
>> >
>> > --
>> > Thank you,
>> > Jeff
>> >
>> > --- End of copied text ---
>> > --
>> > Ross Gardler (@rgardler)
>> > Programme Leader (Open Development)
>> > OpenDirective http://opendirective.com
>

RE: Extensions hosting

[Gavin McDonald <ga...@16degrees.com.au>]

> -----Original Message-----
> From: Rob Weir [mailto:robweir@apache.org]
> Sent: Thursday, 5 January 2012 4:32 AM
> To: ooo-dev@incubator.apache.org
> Subject: Re: Extensions hosting
> 
> On Tue, Jan 3, 2012 at 10:51 AM, Ross Gardler <rg...@opendirective.com>
> wrote:
> 
> <snip>
> 
> > Once you've digested and debated the offer from Sourceforge the
> > community needs to come up with a couple of paragraphs indicating a
> > desired route forwards and reasons for it. I will try and attend the
> > appropriate board meeting in order to answer any questions that arise.
> >
> 
> Maybe I'm the only dolt here, but one reason it is hard for me to make a
> recommendation on a "desired route forward" is that I only have SF's
> proposal in front of me.  I don't have any proposal from Infra on what they
> would like to do.  Or did I miss it?

Yes you missed it, read the archives.

> 
> I agree with you that the proposed time frame (in two weeks) is too fast for
> us to react.  But I do think that we need a very solid and capable extension
> and template repository before we release AOO 3.4.
> I anticipate heavy traffic at that time. Since we're pushing for a Q1 release of
> 3.4, that means we will need to move quickly on stabilizing these services.
> 
> It would be great to better understand where we might be with an Infra
> effort in this same time frame.
> 
> Also, as I understand it, even with a short term stabilization effort from Infra,
> we're still out-of-policy for graduation, and we'd need to
> move to another solution after that.   It sounds like the federated
> approach where host only an index might work.  I think I understand what
> that effort would entail.  Technically it can be clean and elegant, but it does
> have a high coordination cost, dealing with all of the extension and templates
> authors.
> 
> On the other hand, an external host, like SF, could get us the stability we
> need, as well as deal with the OSS license compatibility policy issues. We
> resolve it all at once.
> 
> I wonder whether one blended solution might be:
> 
> 1) Accept SF's offer for the short term stability improvement and getting in
> policy with the copyleft extensions.
> 
> 2) In parallel work with Apache Infra, volunteers from this project, and from
> SF (and maybe LibreOffice?), on an Apache Labs project to build a simple
> open source template/extensions management server.
> Maybe we can start from the existing server? (What license is it?) Extend
> that to give the kind of loose coupling and federation we want.
>  When that is ready, the SF will be well positioned to host one of the first
> servers of its kind.  But we'll also be making this software available to anyone
> to set up their own repository.

You are missing the point (well some of it.) Part of the reason for the templates
and extensions being moved off ours servers for distribution was to reduce the
heavy load demanded of it at OSUOSL. Our bandwidth is not finate and if we can
reduce this by having template and extension owners self-host, all the better
and is one reason why I intended to go with the suggested metadata approach.

Gav...

> 
> -Rob
> 
> > Please be imaginative in your planning for the future. The optimal
> > solution might be some combination of ASF and SF offerings.
> >
> > Note Roberto Gallopini has joined this list and is ready to make any
> > clarifications necessary. I've also made Gav aware of this post so
> > that he can answer any questions we have about what infra@ are able to
> > do.
> >
> > Thanks,
> > Ross
> >
> > --- COPIED PROPOSAL ---
> >
> > I'm glad we had a chance to talk last week - exciting times for Open
> > Office as the product and community transition into the ASF.
> >
> > For over a decade, SourceForge has been committed to advancing the
> > open source software community.  We host over 300,000 projects and are
> > visited by over 40 MM users per month for free, secure, and fast
> > downloads of open source software.  Trusted and reliable download
> > delivery is an important part of our service, with over 4 million
> > downloads per day and 2 PB from our mirror network each month.  We are
> > committed to helping OSS projects scale and grow.
> >
> > Based on our discussions, we understand there are a few things you are
> > solving for as part of the Open Office Incubation effort:
> > Supporting a diverse licensing terms for Open Office extensions, that
> > may not all comply with the Apache OSS policy; Stabilizing your Drupal
> > OO Extensions site and ensuring high availability and download
> > bandwidth without cost Expanding both the developer base who will move
> > into working on the Apache framework as well as adoption of the Open
> > Office product and extensions.
> > We think we can help and that there would be mutual benefit.  To that
> > end, we propose the following for your consideration:
> >
> > 1.) Stabilize the your OO Extensions Drupal instance by moving the it
> > and all services to SourceForge.  Our Site Operations team will do teh
> > work and oversee the operations for you as we do other services.  To
> > your community the directory will look the same and extension and
> > template files will move to SourceForge's globally-distributed
> > download mirror network where we can ensure reliable, scalable
> > delivery.  Drupal will be hosted on our project web service, serving
> > your existing domain via a VHOST.  Standard infrastructure
> > (monitoring, backups, etc.) and service levels (99.9% availability
> > target) apply.
> >
> > These SourceForge services will be provided gratis, and without
> > lock-in -- you are open to change your mind later.  We anticipate this
> > migration would involve a week of planning and preparation, followed
> > by a week of migration and pre/post-migration communications.  We're
> > prepared to commence this work the next week if provided your approval
> > and support.
> >
> > 2.) Once stabilized, we will work with you on a timeline to evaluate
> > and execute a migration from Drupal 5 to Drupal 7.
> >
> > Allowing us to host the Extensions community will solve the license
> > challenges - or at least give you time to work through a longer term
> > solution.  We would also be able to cross promote the software titles
> > to the development community as well - so perhaps expand not only your
> > user base but developers.
> >
> > Roberto (our Sr. Director of Business Development) has been involved
> > in the OpenOffice.org community for many years -- he will continue to
> > be your point-of-contact.  If we secure the go-ahead this week, we
> > will start on Tuesday next week and expect to be complete by 1/15 with
> > step 1.  I have asked our head of Site Ops to oversee the
> > implementation and he'll partner up with your technical folks to
> > ensure the hosting transition goes well.
> >
> > Our motivation here is quite simple, it is all part of our mission to
> > help Open Source Software initiatives succeed.  To that end,
> > SourceForge and Geeknet Media are able to fund these services and make
> > them free to the community through advertising largely on the download
> > and directory pages.  So there won't ever be a charge back to your
> > community and we are able to reinvest in R&D on our developer tools as
> > well.
> >
> > We look forward to hearing back from you this week if possible.  Feel
> > free to forward this on to whomever you would like in terms of getting
> > to an aligned decision.
> >
> > I wish you a happy new year!
> >
> > --
> > Thank you,
> > Jeff
> >
> > --- End of copied text ---
> > --
> > Ross Gardler (@rgardler)
> > Programme Leader (Open Development)
> > OpenDirective http://opendirective.com

Re: Extensions hosting

[Roberto Galoppini <rg...@geek.net>]

On Thu, Jan 5, 2012 at 12:49 AM, Ross Gardler
<rg...@opendirective.com> wrote:
> On 4 January 2012 18:32, Rob Weir <ro...@apache.org> wrote:
>> On Tue, Jan 3, 2012 at 10:51 AM, Ross Gardler
>> <rg...@opendirective.com> wrote:
>>
>> <snip>
>>
>>> Once you've digested and debated the offer from Sourceforge the
>>> community needs to come up with a couple of paragraphs indicating a
>>> desired route forwards and reasons for it. I will try and attend the
>>> appropriate board meeting in order to answer any questions that arise.
>>>
>>
>> Maybe I'm the only dolt here, but one reason it is hard for me to make
>> a recommendation on a "desired route forward" is that I only have SF's
>> proposal in front of me.  I don't have any proposal from Infra on what
>> they would like to do.  Or did I miss it?
>
> I'm not if you missed it or not. I'll provide what Gav has told me on
> the infra list:
>
> Short term: migrate everything to ASF hardware. This is without any tweaking.
>
> Medium term will be to stabilise it (I'm not sure if this means
> migration to Drupal 7 or not, I guess that will depend on longer term
> plans).
>
> Longer term: revamp it into a metadata type site and let the creators
> self-host their templates etc.
>
>> Also, as I understand it, even with a short term stabilization effort
>> from Infra, we're still out-of-policy for graduation, and we'd need to
>> move to another solution after that.
>
> Lets not make too many assumptions. legal@ have said the IPMC can
> decide what to do with respect to requirements on graduation. We can't
> assume that the IPMC would forbid this kind of service. There has not
> been a test case to date. Furthermore, Gavs catalogue site proposal
> would solve the problem by simply pointing to third party hosting
> sites. The ASF recognises the importance of the extensions site to the
> legacy of OOo and thus to the future of AOO. As an Apache project AOO
> can expect the ASF to provide support for extensions.
>
> That being said, it would be dangerous to assume that whatever the
> PPMC comes up with now will be acceptable. That is one reason why
> board guidance is important at this early stage. If, once we ask
> board, they feel any required policy changes are too wide ranging they
> may decide to consult the members (to be honest I doubt that since the
> IPMC has already been given oversight over the graduation decision).
>
>> It sounds like the federated
>> approach where host only an index might work.  I think I understand
>> what that effort would entail.  Technically it can be clean and
>> elegant, but it does have a high coordination cost, dealing with all
>> of the extension and templates authors.
>
> This is an important observation. Thanks.
>
>> On the other hand, an external host, like SF, could get us the
>> stability we need, as well as deal with the OSS license compatibility
>> policy issues. We resolve it all at once.
>
> Agreed - but we potentially introduce an additional problem for the
> longer term by having no facility if SourceForge should change their
> plans. However, I should point out that SF have made it clear that
> they will ensure all code is available to us and are not looking to
> own any domain names or other assets (that was a verbal assurance, but
> I'm sure Jeff will put it in writing if necessary).
>
>> I wonder whether one blended solution might be:
>>
>> 1) Accept SF's offer for the short term stability improvement and
>> getting in policy with the copyleft extensions.
>>
>> 2) In parallel work with Apache Infra, volunteers from this project,
>> and from SF (and maybe LibreOffice?), on an Apache Labs project to
>> build a simple open source template/extensions management server.
>> Maybe we can start from the existing server? (What license is it?)
>
> 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]
>
> Note, I don't believe there is currently any license applied, Gav
> reported that he got permission from Oracle to just take it.
>
>> Extend that to give the kind of loose coupling and federation we want.
>>  When that is ready, the SF will be well positioned to host one of the
>> first servers of its kind.  But we'll also be making this software
>> available to anyone to set up their own repository.
>
> Gav, how do you feel about this? It would allow infra to jump straight
> to the long term goal without investing resources in the short term. I
> see your reply later in this thread but I'm not sure it addresses the
> proposal Rob makes. Which is to let SF handle the short-medium term
> goals of stabilisation but still have the ASF pursue the long term
> federated goal.
>
> Roberto, would not be a problem for you given that Jeff said you would
> be happy to hand everything back to the ASF if necessary. With this
> plan there is no intention to take it back (assuming you do it right
> of course), but there is an intention to provide facilities for a
> broader extensions ecosystem.

We are open to handle both the short and the medium terms goals of
stabilisation ensuring formally that all code is and will be available
to you. At the same extent we embrace also the long term federated
vision.

Roberto

>
> [1] http://drupal.org/licensing/faq#q7
>
>> -Rob
>>
>>> Please be imaginative in your planning for the future. The optimal
>>> solution might be some combination of ASF and SF offerings.
>>>
>>> Note Roberto Gallopini has joined this list and is ready to make any
>>> clarifications necessary. I've also made Gav aware of this post so
>>> that he can answer any questions we have about what infra@ are able to
>>> do.
>>>
>>> Thanks,
>>> Ross
>>>
>>> --- COPIED PROPOSAL ---
>>>
>>> I'm glad we had a chance to talk last week - exciting times for Open
>>> Office as the product and community transition into the ASF.
>>>
>>> For over a decade, SourceForge has been committed to advancing the
>>> open source software community.  We host over 300,000 projects and are
>>> visited by over 40 MM users per month for free, secure, and fast
>>> downloads of open source software.  Trusted and reliable download
>>> delivery is an important part of our service, with over 4 million
>>> downloads per day and 2 PB from our mirror network each month.  We are
>>> committed to helping OSS projects scale and grow.
>>>
>>> Based on our discussions, we understand there are a few things you are
>>> solving for as part of the Open Office Incubation effort:
>>> Supporting a diverse licensing terms for Open Office extensions, that
>>> may not all comply with the Apache OSS policy;
>>> Stabilizing your Drupal OO Extensions site and ensuring high
>>> availability and download bandwidth without cost
>>> Expanding both the developer base who will move into working on the
>>> Apache framework as well as adoption of the Open Office product and
>>> extensions.
>>> We think we can help and that there would be mutual benefit.  To that
>>> end, we propose the following for your consideration:
>>>
>>> 1.) Stabilize the your OO Extensions Drupal instance by moving the it
>>> and all services to SourceForge.  Our Site Operations team will do teh
>>> work and oversee the operations for you as we do other services.  To
>>> your community the directory will look the same and extension and
>>> template files will move to SourceForge's globally-distributed
>>> download mirror network where we can ensure reliable, scalable
>>> delivery.  Drupal will be hosted on our project web service, serving
>>> your existing domain via a VHOST.  Standard infrastructure
>>> (monitoring, backups, etc.) and service levels (99.9% availability
>>> target) apply.
>>>
>>> These SourceForge services will be provided gratis, and without
>>> lock-in -- you are open to change your mind later.  We anticipate this
>>> migration would involve a week of planning and preparation, followed
>>> by a week of migration and pre/post-migration communications.  We're
>>> prepared to commence this work the next week if provided your approval
>>> and support.
>>>
>>> 2.) Once stabilized, we will work with you on a timeline to evaluate
>>> and execute a migration from Drupal 5 to Drupal 7.
>>>
>>> Allowing us to host the Extensions community will solve the license
>>> challenges - or at least give you time to work through a longer term
>>> solution.  We would also be able to cross promote the software titles
>>> to the development community as well - so perhaps expand not only your
>>> user base but developers.
>>>
>>> Roberto (our Sr. Director of Business Development) has been involved
>>> in the OpenOffice.org community for many years -- he will continue to
>>> be your point-of-contact.  If we secure the go-ahead this week, we
>>> will start on Tuesday next week and expect to be complete by 1/15 with
>>> step 1.  I have asked our head of Site Ops to oversee the
>>> implementation and he'll partner up with your technical folks to
>>> ensure the hosting transition goes well.
>>>
>>> Our motivation here is quite simple, it is all part of our mission to
>>> help Open Source Software initiatives succeed.  To that end,
>>> SourceForge and Geeknet Media are able to fund these services and make
>>> them free to the community through advertising largely on the download
>>> and directory pages.  So there won't ever be a charge back to your
>>> community and we are able to reinvest in R&D on our developer tools as
>>> well.
>>>
>>> We look forward to hearing back from you this week if possible.  Feel
>>> free to forward this on to whomever you would like in terms of getting
>>> to an aligned decision.
>>>
>>> I wish you a happy new year!
>>>
>>> --
>>> Thank you,
>>> Jeff
>>>
>>> --- End of copied text ---
>>> --
>>> Ross Gardler (@rgardler)
>>> Programme Leader (Open Development)
>>> OpenDirective http://opendirective.com
>
>
>
> --
> Ross Gardler (@rgardler)
> Programme Leader (Open Development)
> OpenDirective http://opendirective.com
====
This e- mail message is intended only for the named recipient(s) above. It may contain confidential and privileged information. If you are not the intended recipient you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and delete the message and any attachment(s) from your system. Thank you.

Re: Extensions hosting

[Ross Gardler <rg...@opendirective.com>]

On 4 January 2012 18:32, Rob Weir <ro...@apache.org> wrote:
> On Tue, Jan 3, 2012 at 10:51 AM, Ross Gardler
> <rg...@opendirective.com> wrote:
>
> <snip>
>
>> Once you've digested and debated the offer from Sourceforge the
>> community needs to come up with a couple of paragraphs indicating a
>> desired route forwards and reasons for it. I will try and attend the
>> appropriate board meeting in order to answer any questions that arise.
>>
>
> Maybe I'm the only dolt here, but one reason it is hard for me to make
> a recommendation on a "desired route forward" is that I only have SF's
> proposal in front of me.  I don't have any proposal from Infra on what
> they would like to do.  Or did I miss it?

I'm not if you missed it or not. I'll provide what Gav has told me on
the infra list:

Short term: migrate everything to ASF hardware. This is without any tweaking.

Medium term will be to stabilise it (I'm not sure if this means
migration to Drupal 7 or not, I guess that will depend on longer term
plans).

Longer term: revamp it into a metadata type site and let the creators
self-host their templates etc.

> Also, as I understand it, even with a short term stabilization effort
> from Infra, we're still out-of-policy for graduation, and we'd need to
> move to another solution after that.

Lets not make too many assumptions. legal@ have said the IPMC can
decide what to do with respect to requirements on graduation. We can't
assume that the IPMC would forbid this kind of service. There has not
been a test case to date. Furthermore, Gavs catalogue site proposal
would solve the problem by simply pointing to third party hosting
sites. The ASF recognises the importance of the extensions site to the
legacy of OOo and thus to the future of AOO. As an Apache project AOO
can expect the ASF to provide support for extensions.

That being said, it would be dangerous to assume that whatever the
PPMC comes up with now will be acceptable. That is one reason why
board guidance is important at this early stage. If, once we ask
board, they feel any required policy changes are too wide ranging they
may decide to consult the members (to be honest I doubt that since the
IPMC has already been given oversight over the graduation decision).

> It sounds like the federated
> approach where host only an index might work.  I think I understand
> what that effort would entail.  Technically it can be clean and
> elegant, but it does have a high coordination cost, dealing with all
> of the extension and templates authors.

This is an important observation. Thanks.

> On the other hand, an external host, like SF, could get us the
> stability we need, as well as deal with the OSS license compatibility
> policy issues. We resolve it all at once.

Agreed - but we potentially introduce an additional problem for the
longer term by having no facility if SourceForge should change their
plans. However, I should point out that SF have made it clear that
they will ensure all code is available to us and are not looking to
own any domain names or other assets (that was a verbal assurance, but
I'm sure Jeff will put it in writing if necessary).

> I wonder whether one blended solution might be:
>
> 1) Accept SF's offer for the short term stability improvement and
> getting in policy with the copyleft extensions.
>
> 2) In parallel work with Apache Infra, volunteers from this project,
> and from SF (and maybe LibreOffice?), on an Apache Labs project to
> build a simple open source template/extensions management server.
> Maybe we can start from the existing server? (What license is it?)

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]

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

> Extend that to give the kind of loose coupling and federation we want.
>  When that is ready, the SF will be well positioned to host one of the
> first servers of its kind.  But we'll also be making this software
> available to anyone to set up their own repository.

Gav, how do you feel about this? It would allow infra to jump straight
to the long term goal without investing resources in the short term. I
see your reply later in this thread but I'm not sure it addresses the
proposal Rob makes. Which is to let SF handle the short-medium term
goals of stabilisation but still have the ASF pursue the long term
federated goal.

Roberto, would not be a problem for you given that Jeff said you would
be happy to hand everything back to the ASF if necessary. With this
plan there is no intention to take it back (assuming you do it right
of course), but there is an intention to provide facilities for a
broader extensions ecosystem.

[1] http://drupal.org/licensing/faq#q7

> -Rob
>
>> Please be imaginative in your planning for the future. The optimal
>> solution might be some combination of ASF and SF offerings.
>>
>> Note Roberto Gallopini has joined this list and is ready to make any
>> clarifications necessary. I've also made Gav aware of this post so
>> that he can answer any questions we have about what infra@ are able to
>> do.
>>
>> Thanks,
>> Ross
>>
>> --- COPIED PROPOSAL ---
>>
>> I'm glad we had a chance to talk last week - exciting times for Open
>> Office as the product and community transition into the ASF.
>>
>> For over a decade, SourceForge has been committed to advancing the
>> open source software community.  We host over 300,000 projects and are
>> visited by over 40 MM users per month for free, secure, and fast
>> downloads of open source software.  Trusted and reliable download
>> delivery is an important part of our service, with over 4 million
>> downloads per day and 2 PB from our mirror network each month.  We are
>> committed to helping OSS projects scale and grow.
>>
>> Based on our discussions, we understand there are a few things you are
>> solving for as part of the Open Office Incubation effort:
>> Supporting a diverse licensing terms for Open Office extensions, that
>> may not all comply with the Apache OSS policy;
>> Stabilizing your Drupal OO Extensions site and ensuring high
>> availability and download bandwidth without cost
>> Expanding both the developer base who will move into working on the
>> Apache framework as well as adoption of the Open Office product and
>> extensions.
>> We think we can help and that there would be mutual benefit.  To that
>> end, we propose the following for your consideration:
>>
>> 1.) Stabilize the your OO Extensions Drupal instance by moving the it
>> and all services to SourceForge.  Our Site Operations team will do teh
>> work and oversee the operations for you as we do other services.  To
>> your community the directory will look the same and extension and
>> template files will move to SourceForge's globally-distributed
>> download mirror network where we can ensure reliable, scalable
>> delivery.  Drupal will be hosted on our project web service, serving
>> your existing domain via a VHOST.  Standard infrastructure
>> (monitoring, backups, etc.) and service levels (99.9% availability
>> target) apply.
>>
>> These SourceForge services will be provided gratis, and without
>> lock-in -- you are open to change your mind later.  We anticipate this
>> migration would involve a week of planning and preparation, followed
>> by a week of migration and pre/post-migration communications.  We're
>> prepared to commence this work the next week if provided your approval
>> and support.
>>
>> 2.) Once stabilized, we will work with you on a timeline to evaluate
>> and execute a migration from Drupal 5 to Drupal 7.
>>
>> Allowing us to host the Extensions community will solve the license
>> challenges - or at least give you time to work through a longer term
>> solution.  We would also be able to cross promote the software titles
>> to the development community as well - so perhaps expand not only your
>> user base but developers.
>>
>> Roberto (our Sr. Director of Business Development) has been involved
>> in the OpenOffice.org community for many years -- he will continue to
>> be your point-of-contact.  If we secure the go-ahead this week, we
>> will start on Tuesday next week and expect to be complete by 1/15 with
>> step 1.  I have asked our head of Site Ops to oversee the
>> implementation and he'll partner up with your technical folks to
>> ensure the hosting transition goes well.
>>
>> Our motivation here is quite simple, it is all part of our mission to
>> help Open Source Software initiatives succeed.  To that end,
>> SourceForge and Geeknet Media are able to fund these services and make
>> them free to the community through advertising largely on the download
>> and directory pages.  So there won't ever be a charge back to your
>> community and we are able to reinvest in R&D on our developer tools as
>> well.
>>
>> We look forward to hearing back from you this week if possible.  Feel
>> free to forward this on to whomever you would like in terms of getting
>> to an aligned decision.
>>
>> I wish you a happy new year!
>>
>> --
>> Thank you,
>> Jeff
>>
>> --- End of copied text ---
>> --
>> Ross Gardler (@rgardler)
>> Programme Leader (Open Development)
>> OpenDirective http://opendirective.com



-- 
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com

Re: Extensions hosting

[Rob Weir <ro...@apache.org>]

On Tue, Jan 3, 2012 at 10:51 AM, Ross Gardler
<rg...@opendirective.com> wrote:

<snip>

> Once you've digested and debated the offer from Sourceforge the
> community needs to come up with a couple of paragraphs indicating a
> desired route forwards and reasons for it. I will try and attend the
> appropriate board meeting in order to answer any questions that arise.
>

Maybe I'm the only dolt here, but one reason it is hard for me to make
a recommendation on a "desired route forward" is that I only have SF's
proposal in front of me.  I don't have any proposal from Infra on what
they would like to do.  Or did I miss it?

I agree with you that the proposed time frame (in two weeks) is too
fast for us to react.  But I do think that we need a very solid and
capable extension and template repository before we release AOO 3.4.
I anticipate heavy traffic at that time. Since we're pushing for a Q1
release of 3.4, that means we will need to move quickly on stabilizing
these services.

It would be great to better understand where we might be with an Infra
effort in this same time frame.

Also, as I understand it, even with a short term stabilization effort
from Infra, we're still out-of-policy for graduation, and we'd need to
move to another solution after that.   It sounds like the federated
approach where host only an index might work.  I think I understand
what that effort would entail.  Technically it can be clean and
elegant, but it does have a high coordination cost, dealing with all
of the extension and templates authors.

On the other hand, an external host, like SF, could get us the
stability we need, as well as deal with the OSS license compatibility
policy issues. We resolve it all at once.

I wonder whether one blended solution might be:

1) Accept SF's offer for the short term stability improvement and
getting in policy with the copyleft extensions.

2) In parallel work with Apache Infra, volunteers from this project,
and from SF (and maybe LibreOffice?), on an Apache Labs project to
build a simple open source template/extensions management server.
Maybe we can start from the existing server? (What license is it?)
Extend that to give the kind of loose coupling and federation we want.
 When that is ready, the SF will be well positioned to host one of the
first servers of its kind.  But we'll also be making this software
available to anyone to set up their own repository.

-Rob

> Please be imaginative in your planning for the future. The optimal
> solution might be some combination of ASF and SF offerings.
>
> Note Roberto Gallopini has joined this list and is ready to make any
> clarifications necessary. I've also made Gav aware of this post so
> that he can answer any questions we have about what infra@ are able to
> do.
>
> Thanks,
> Ross
>
> --- COPIED PROPOSAL ---
>
> I'm glad we had a chance to talk last week - exciting times for Open
> Office as the product and community transition into the ASF.
>
> For over a decade, SourceForge has been committed to advancing the
> open source software community.  We host over 300,000 projects and are
> visited by over 40 MM users per month for free, secure, and fast
> downloads of open source software.  Trusted and reliable download
> delivery is an important part of our service, with over 4 million
> downloads per day and 2 PB from our mirror network each month.  We are
> committed to helping OSS projects scale and grow.
>
> Based on our discussions, we understand there are a few things you are
> solving for as part of the Open Office Incubation effort:
> Supporting a diverse licensing terms for Open Office extensions, that
> may not all comply with the Apache OSS policy;
> Stabilizing your Drupal OO Extensions site and ensuring high
> availability and download bandwidth without cost
> Expanding both the developer base who will move into working on the
> Apache framework as well as adoption of the Open Office product and
> extensions.
> We think we can help and that there would be mutual benefit.  To that
> end, we propose the following for your consideration:
>
> 1.) Stabilize the your OO Extensions Drupal instance by moving the it
> and all services to SourceForge.  Our Site Operations team will do teh
> work and oversee the operations for you as we do other services.  To
> your community the directory will look the same and extension and
> template files will move to SourceForge's globally-distributed
> download mirror network where we can ensure reliable, scalable
> delivery.  Drupal will be hosted on our project web service, serving
> your existing domain via a VHOST.  Standard infrastructure
> (monitoring, backups, etc.) and service levels (99.9% availability
> target) apply.
>
> These SourceForge services will be provided gratis, and without
> lock-in -- you are open to change your mind later.  We anticipate this
> migration would involve a week of planning and preparation, followed
> by a week of migration and pre/post-migration communications.  We're
> prepared to commence this work the next week if provided your approval
> and support.
>
> 2.) Once stabilized, we will work with you on a timeline to evaluate
> and execute a migration from Drupal 5 to Drupal 7.
>
> Allowing us to host the Extensions community will solve the license
> challenges - or at least give you time to work through a longer term
> solution.  We would also be able to cross promote the software titles
> to the development community as well - so perhaps expand not only your
> user base but developers.
>
> Roberto (our Sr. Director of Business Development) has been involved
> in the OpenOffice.org community for many years -- he will continue to
> be your point-of-contact.  If we secure the go-ahead this week, we
> will start on Tuesday next week and expect to be complete by 1/15 with
> step 1.  I have asked our head of Site Ops to oversee the
> implementation and he'll partner up with your technical folks to
> ensure the hosting transition goes well.
>
> Our motivation here is quite simple, it is all part of our mission to
> help Open Source Software initiatives succeed.  To that end,
> SourceForge and Geeknet Media are able to fund these services and make
> them free to the community through advertising largely on the download
> and directory pages.  So there won't ever be a charge back to your
> community and we are able to reinvest in R&D on our developer tools as
> well.
>
> We look forward to hearing back from you this week if possible.  Feel
> free to forward this on to whomever you would like in terms of getting
> to an aligned decision.
>
> I wish you a happy new year!
>
> --
> Thank you,
> Jeff
>
> --- End of copied text ---
> --
> Ross Gardler (@rgardler)
> Programme Leader (Open Development)
> OpenDirective http://opendirective.com

Re: Extensions hosting

[Dave Fisher <da...@comcast.net>]

On Jan 5, 2012, at 8:05 AM, Ross Gardler wrote:

> On 5 January 2012 13:57, Rob Weir <ro...@apache.org> wrote:
>> 2012/1/5 Jürgen Schmidt <jo...@googlemail.com>:
>>> On 1/5/12 12:12 PM, Ross Gardler wrote:
>>>> 
> 
> ...
> 
>>> And the proposed index only solution is not satisfying for me because of the
>>> explained reasons (missing hosting of the binary extension packages or
>>> templates). But I would like to learn more about it and especially how it
>>> should be maintained, the frontend how users would register their extensions
>>> ...
>> 
>> Let's take an example of the general pattern, with blogs.  ...  they all agree
>> on some basic standards:  HTML for the content, and RSS or Atom for
>> syndication.
> 
> ...
> 
>> So the model that I think is attractive for extensions and templates is:
> 
> ...
> 
>> 2) What we do specify are:
>> 
>> a) The metadata related to extensions.
> 
> ...
> 
>> 
>> b) An encoding of the metadata, in XML.
> 
> At the risk of diverting this thread too far from the goal of coming
> up with an overall plan for moving forwards short-medium-long term...
> 
> Consider the RDF Description of a Project format. The ASF uses it for
> http://projects.apache.org That site is generated from a bunch of
> PERL, XSL and the like pulling content from wherever the projects want
> to host their DOAP descriptor and publishing a catalogue. It's not as
> feature rich as needed for AOO but it is a good proof of concept.
> 
> For an intro to DOAP see http://www.oss-watch.ac.uk/resources/doap.xml
> 
> Remember that there are a whole load of ASF projects dealing with RDF
> data, it's quite possible some of those will be keen to help us if
> this were a route we took.

There are tools for handling RDF in the Apache CMS. The bridge from a set of rdf files in directories in svn to a website is short.

The extensions, templates and codesnippets ( a related third party relationship that we'll also need to address ) can all be entries in a directory structure.

Regards,
Dave

Regards,
Dave


> 
> Ross

Re: Extensions hosting

[Rob Weir <ro...@apache.org>]

On Thu, Jan 5, 2012 at 11:05 AM, Ross Gardler
<rg...@opendirective.com> wrote:
> On 5 January 2012 13:57, Rob Weir <ro...@apache.org> wrote:
>> 2012/1/5 Jürgen Schmidt <jo...@googlemail.com>:
>>> On 1/5/12 12:12 PM, Ross Gardler wrote:
>>>>
>
> ...
>
>>> And the proposed index only solution is not satisfying for me because of the
>>> explained reasons (missing hosting of the binary extension packages or
>>> templates). But I would like to learn more about it and especially how it
>>> should be maintained, the frontend how users would register their extensions
>>> ...
>>
>> Let's take an example of the general pattern, with blogs.  ...  they all agree
>> on some basic standards:  HTML for the content, and RSS or Atom for
>> syndication.
>
> ...
>
>> So the model that I think is attractive for extensions and templates is:
>
> ...
>
>> 2) What we do specify are:
>>
>> a) The metadata related to extensions.
>
> ...
>
>>
>> b) An encoding of the metadata, in XML.
>
> At the risk of diverting this thread too far from the goal of coming
> up with an overall plan for moving forwards short-medium-long term...
>
> Consider the RDF Description of a Project format. The ASF uses it for
> http://projects.apache.org That site is generated from a bunch of
> PERL, XSL and the like pulling content from wherever the projects want
> to host their DOAP descriptor and publishing a catalogue. It's not as
> feature rich as needed for AOO but it is a good proof of concept.
>
> For an intro to DOAP see http://www.oss-watch.ac.uk/resources/doap.xml
>
> Remember that there are a whole load of ASF projects dealing with RDF
> data, it's quite possible some of those will be keen to help us if
> this were a route we took.
>

RDF is fine as well.  The general thought is not to reinvent the wheel
with our own ad-hoc format.  Pick something that has broad support in
tools and libraries already.  We're fortunate to have several good
options for this kind of thing

> Ross

Re: Extensions hosting

[Ross Gardler <rg...@opendirective.com>]

On 5 January 2012 13:57, Rob Weir <ro...@apache.org> wrote:
> 2012/1/5 Jürgen Schmidt <jo...@googlemail.com>:
>> On 1/5/12 12:12 PM, Ross Gardler wrote:
>>>

...

>> And the proposed index only solution is not satisfying for me because of the
>> explained reasons (missing hosting of the binary extension packages or
>> templates). But I would like to learn more about it and especially how it
>> should be maintained, the frontend how users would register their extensions
>> ...
>
> Let's take an example of the general pattern, with blogs.  ...  they all agree
> on some basic standards:  HTML for the content, and RSS or Atom for
> syndication.

...

> So the model that I think is attractive for extensions and templates is:

...

> 2) What we do specify are:
>
> a) The metadata related to extensions.

...

>
> b) An encoding of the metadata, in XML.

At the risk of diverting this thread too far from the goal of coming
up with an overall plan for moving forwards short-medium-long term...

Consider the RDF Description of a Project format. The ASF uses it for
http://projects.apache.org That site is generated from a bunch of
PERL, XSL and the like pulling content from wherever the projects want
to host their DOAP descriptor and publishing a catalogue. It's not as
feature rich as needed for AOO but it is a good proof of concept.

For an intro to DOAP see http://www.oss-watch.ac.uk/resources/doap.xml

Remember that there are a whole load of ASF projects dealing with RDF
data, it's quite possible some of those will be keen to help us if
this were a route we took.

Ross

Re: Extensions hosting

[Jürgen Schmidt <jo...@googlemail.com>]

On 1/5/12 2:57 PM, Rob Weir wrote:
> 2012/1/5 Jürgen Schmidt<jo...@googlemail.com>:
>> On 1/5/12 12:12 PM, Ross Gardler wrote:
>>>
>>> As a separate point in this thread I should also point out that the
>>> ASF has some experience of dealing with off-site repository providers.
>>> Not all of it good. Most of the problems have been a result of lack of
>>> planning and lack of adequate protection of the trademarks involved.
>>>
>>> All those cases (to my knowledge) have now reached satisfactory
>>> states. I imagine the Board will be keen to see that The PPMC has
>>> considered the kinds of terms that will be offered to third party
>>> sites with respect to trademark usage. My recommendation would be to
>>> simply state that no use beyond those approved by existing ASF policy
>>> will be required.
>>>
>>> I also suggest that if the PPMC wants to take Sourceforge up on the
>>> offer that it is made clear to all parties that this will not be the
>>> "official" AOO extensions repository. Only the ASF will host official
>>> Apache services. However, this does not mean that the AOO site and
>>> product cannot link out to an SF provided repository.
>>>
>>> Remember also that the ASF cannot do anything that benefits a single
>>> organisation more than any other. Therefore, any agreement with
>>> Sourceforge cannot be exclusive. There must be opportunities for
>>> others to offer similar services if they want to put the effort into
>>> doing so.
>>
>>
>> I think that is fair enough. I see it in the way that SF comes first to
>> offer their help and help us to solve a problem with general hosting of GPL,
>> LGPL etc. extensions that we can't host in an official ASF repo. We can
>> probably rename it and find a way to make clear that it is a supported repo
>> but not the official one (long term when we an official ASF repo).
>>
>> And the proposed index only solution is not satisfying for me because of the
>> explained reasons (missing hosting of the binary extension packages or
>> templates). But I would like to learn more about it and especially how it
>> should be maintained, the frontend how users would register their extensions
>> ...
>
> Let's take an example of the general pattern, with blogs. Blogs are
> content, hosted all over the web, on millions of different sites.
> Sometimes they are hosted together, in one place, by blog hosting
> sites, like Blogger or Wordpress.com, and in other cases they are
> hosted by the individual owners on their own websites.  There are many
> different providers of blogging software as well.  But they all agree
> on some basic standards:  HTML for the content, and RSS or Atom for
> syndication.  RSS and Atom (and you only really need one of them.  The
> fact that there are two is an historical accident) are the glue that
> contexts the content stores (blogs) with other services. For example,
> Google Blog search, News Readers, mobile apps like Pulse, aggregator's
> for "Planet" websites, etc.  By separating the storage of the content
> from the advertising of the content, you open up a whole new set of
> possibilities.
>

i think i have understand the model quite well ;-)

> So the model that I think is attractive for extensions and templates is:
>
> 1) The actual repositories for the templates can be done anywhere.  We
> don't specify how they are stored.  It could be SourceForge, Google
> Code, here at Apache, on the author's own personal website, wherever.
> We don't specify the user interface, the account model, the
> interactions the extension author has with the repository site.  These
> details are all the concern of the repository owner. Let them compete
> for app developers based on the services they provide and how easy
> they make it for app developers.
>
> Of course, Apache can host a repository as well, but I think
> considerations of license and release policy will lead us,in the end,
> to only host extensions that are actual releases of the project.

that is exactly what i have tried to explain several times

>
> 2) What we do specify are:
>
> a) The metadata related to extensions.  For example, name of
> extension, version, author, website, short description, screen shot,
> language, versions of OpenOffice supported, license, and of course,
> the URL to download.
>
fine that is more that we have now but what i also tried to explain that 
we have such a format already

> b) An encoding of the metadata, in XML.

we have it already

>
> c) A mechanism for advertising the extensions hosted at a given
> repository.   If we just base this on Atom, we'll be able to reuse a
> lot of existing libraries, so that might be a good start.
>
> 3) It would then be the responsibility of the repository hosts to
> provide feeds of available extensions per the above specifications.
> This would be optional.   Similarly, you can have a "blog" today, but
> provide no RSS or Atom feed.  But by doing so you shut yourself out of
> the larger ecosystem that is enabled by having feeds.  For larger
> repository hosts, like SourceForge, these feeds could be automatically
> generated from the repository data.  But even a small personal website
> with just 1 or 2 extensions should be able to hand-author a correct
> feed.

nice idea, under which Url do you would like do collect all the repos?

>
> 4) We then have one or more aggregators of extension and template
> metadata.  These would be fed by a collection of feed URL's, submitted
> by repository  hosts.  The aggregator would periodically fetch updated
> metadata.  The aggregator would then have a user-facing UI for
> searching, filtering, rating, reviewing, and downloading, extensions.
> Apache could host one that was open to all feed submissions.

also nice

>
> 5) This model enables other things, like automatically sending a
> Twitter tweet when a new extension is added, or having a "Planet AOO
> Extensions" that posts the descriptions of new templates as they come
> in, etc.  Could even put that in a section of our website.
>
> 6) The feed mechanism could also work well for in-product use, to have
> the ability to browse one or more repositories for extensions.  Maybe
> out-of-the-box, we only point to the official Apache extension
> repository, including officially released extensions.  But the user
> can add (or enable) additional repositories. This could be similar to
> how some Linux distros deal with 3rd party packages, where you start
> with just supported packages, but can enable additional sources.
>

i agree and that is what i have also tried to explain ;-)

But the extended meta data, and the multiple repos support in the office 
are all long term ideas and not for 3.4, correct?

Juergen

>>
>> I haven't seen a long term solution that would solve our problem for
>> graduation. How do we want address for example a template repo with hosting
>> capabilites for templates?
>>
>> We can use the existing implementation of the repos (extensions and
>> templates) and can remove all content and allow ALv2 licensed stuff only.
>> But then we have again to answer the question of hosting binaries or
>> templates. Do we want support it, do we have the resources (storage,
>> bandwidth)?
>>
>> As we have discussed earlier it is fine to have several repos and one
>> official ASF repo. Support of multiple repos (not yet implemented) that are
>> configurable in the office. Especially when we think of internal repos in a
>> closed enterprise environment...
>>
>> If it won't work with SF we can revert it. For me it seems at least worse a
>> try because we have limited resources anyway, still enough to do and any
>> kind of help is welcome, or not?
>>
>> It's again a situation where the existing solution doesn't fit well in
>> Apache because of allowing copyleft licensed stuff as well. But it is
>> somewhat important for the overall eco-system. I hope we can find a
>> satisfying solution and i think multiple repos can be a solution.
>>
>> Juergen
>>
>>
>>>
>>> Ross
>>>
>>> On 3 January 2012 15:51, Ross Gardler<rg...@opendirective.com>    wrote:
>>>>
>>>> As the community know Gav, in his role at infrastructure@ has
>>>> undertaken to stabilise and migrate the AOO extensions code to ASF
>>>> infrastructure. His work has been progressing and he remains committed
>>>> to completing this.
>>>>
>>>> However, as some know Sourceforge made an offer to help via our
>>>> private list. At the time they did not want to discuss this topic in
>>>> public for a number of reasons. I've had a couple of chats with
>>>> Roberto Gallopini and Jeff Drobick in order to help them understand
>>>> why the ASF prefers to host all services for its projects. In response
>>>> SF have tailored their offer of support.
>>>>
>>>> I relayed the outline of our conversations to the infrastructure team
>>>> who have asked me to have the AOO project provide some feedback, via a
>>>> board report, on what problems the AOO project forsee for the
>>>> extensions site and what options are available, if possible a
>>>> recommendation for an optimal solution should also be made. Note that
>>>> we can submit something out of cycle if we want, the next full report
>>>> is not due till March.
>>>>
>>>> The reason infra@ have escalated to board@ is probably that we need to
>>>> figure out a long term solution for the AOO project and that solution
>>>> is heavily influenced by ASF policy. Any solution that we are
>>>> currently considering will have an impact on the AOO extensions site
>>>> and/or on ASF policy.
>>>>
>>>> The current situation, as I understand it, is that the board have
>>>> given permission for the extensions site to be managed by infra during
>>>> incubation. The problem of distributing content under licences other
>>>> than Apache is not seen to be a problem during the incubation process.
>>>> Beyond incubation the board has delegated responsibility to the
>>>> Incubator PMC. I don't believe that particular discussion has been
>>>> started yet.
>>>>
>>>> Gav tells us that he has been thinking about making the extensions
>>>> site an index site, thus allowing the extensions to be housed
>>>> elsewhere (apache-extras, sourceforge, google code, github, FooBar
>>>> corporation or wherever). This would neatly bypass the licence
>>>> problem. Open source extensions needing hosting could go to
>>>> apache-extras while commercially licensed extensions would need to
>>>> provide their own hosting.
>>>>
>>>> An alternative is to work with a third party willing to help. I've
>>>> copied below the text of a mail outlining the SF proposal. You will
>>>> note that they are keen to ensure that we don't get locked into the SF
>>>> services. Nevertheless, one of the reasons the ASF hosts its own
>>>> services is to avoid exposing us to unmanageable risk.
>>>>
>>>> I have no reason to believe SourceForge have anything other than good
>>>> intentions in making this offer. SF has been supporting open source
>>>> for a very long time. It is backed at the highest level (Jeff is
>>>> President and CEO) and I believe Roberto is known within the
>>>> OpenOffce.org community. However, many aspects of this will be outside
>>>> of the control of the AOO project, despite SFs real attempts to
>>>> mitigate our concerns relating to this.
>>>>
>>>> Please note that the timescales Jeff outlines are unrealistic given
>>>> that we need to seek board input before being able to ensure the AOO
>>>> project makes the right decision.  SF want to move quickly, but I
>>>> don't think we need to be rushed into making a decision.
>>>>
>>>> Once you've digested and debated the offer from Sourceforge the
>>>> community needs to come up with a couple of paragraphs indicating a
>>>> desired route forwards and reasons for it. I will try and attend the
>>>> appropriate board meeting in order to answer any questions that arise.
>>>>
>>>> Please be imaginative in your planning for the future. The optimal
>>>> solution might be some combination of ASF and SF offerings.
>>>>
>>>> Note Roberto Gallopini has joined this list and is ready to make any
>>>> clarifications necessary. I've also made Gav aware of this post so
>>>> that he can answer any questions we have about what infra@ are able to
>>>> do.
>>>>
>>>> Thanks,
>>>> Ross
>>>>
>>>> --- COPIED PROPOSAL ---
>>>>
>>>> I'm glad we had a chance to talk last week - exciting times for Open
>>>> Office as the product and community transition into the ASF.
>>>>
>>>> For over a decade, SourceForge has been committed to advancing the
>>>> open source software community.  We host over 300,000 projects and are
>>>> visited by over 40 MM users per month for free, secure, and fast
>>>> downloads of open source software.  Trusted and reliable download
>>>> delivery is an important part of our service, with over 4 million
>>>> downloads per day and 2 PB from our mirror network each month.  We are
>>>> committed to helping OSS projects scale and grow.
>>>>
>>>> Based on our discussions, we understand there are a few things you are
>>>> solving for as part of the Open Office Incubation effort:
>>>> Supporting a diverse licensing terms for Open Office extensions, that
>>>> may not all comply with the Apache OSS policy;
>>>> Stabilizing your Drupal OO Extensions site and ensuring high
>>>> availability and download bandwidth without cost
>>>> Expanding both the developer base who will move into working on the
>>>> Apache framework as well as adoption of the Open Office product and
>>>> extensions.
>>>> We think we can help and that there would be mutual benefit.  To that
>>>> end, we propose the following for your consideration:
>>>>
>>>> 1.) Stabilize the your OO Extensions Drupal instance by moving the it
>>>> and all services to SourceForge.  Our Site Operations team will do teh
>>>> work and oversee the operations for you as we do other services.  To
>>>> your community the directory will look the same and extension and
>>>> template files will move to SourceForge's globally-distributed
>>>> download mirror network where we can ensure reliable, scalable
>>>> delivery.  Drupal will be hosted on our project web service, serving
>>>> your existing domain via a VHOST.  Standard infrastructure
>>>> (monitoring, backups, etc.) and service levels (99.9% availability
>>>> target) apply.
>>>>
>>>> These SourceForge services will be provided gratis, and without
>>>> lock-in -- you are open to change your mind later.  We anticipate this
>>>> migration would involve a week of planning and preparation, followed
>>>> by a week of migration and pre/post-migration communications.  We're
>>>> prepared to commence this work the next week if provided your approval
>>>> and support.
>>>>
>>>> 2.) Once stabilized, we will work with you on a timeline to evaluate
>>>> and execute a migration from Drupal 5 to Drupal 7.
>>>>
>>>> Allowing us to host the Extensions community will solve the license
>>>> challenges - or at least give you time to work through a longer term
>>>> solution.  We would also be able to cross promote the software titles
>>>> to the development community as well - so perhaps expand not only your
>>>> user base but developers.
>>>>
>>>> Roberto (our Sr. Director of Business Development) has been involved
>>>> in the OpenOffice.org community for many years -- he will continue to
>>>> be your point-of-contact.  If we secure the go-ahead this week, we
>>>> will start on Tuesday next week and expect to be complete by 1/15 with
>>>> step 1.  I have asked our head of Site Ops to oversee the
>>>> implementation and he'll partner up with your technical folks to
>>>> ensure the hosting transition goes well.
>>>>
>>>> Our motivation here is quite simple, it is all part of our mission to
>>>> help Open Source Software initiatives succeed.  To that end,
>>>> SourceForge and Geeknet Media are able to fund these services and make
>>>> them free to the community through advertising largely on the download
>>>> and directory pages.  So there won't ever be a charge back to your
>>>> community and we are able to reinvest in R&D on our developer tools as
>>>> well.
>>>>
>>>> We look forward to hearing back from you this week if possible.  Feel
>>>> free to forward this on to whomever you would like in terms of getting
>>>> to an aligned decision.
>>>>
>>>> I wish you a happy new year!
>>>>
>>>> --
>>>> Thank you,
>>>> Jeff
>>>>
>>>> --- End of copied text ---
>>>> --
>>>> Ross Gardler (@rgardler)
>>>> Programme Leader (Open Development)
>>>> OpenDirective http://opendirective.com
>>>
>>>
>>>
>>>
>>

Re: Extensions hosting

[Rob Weir <ro...@apache.org>]

2012/1/5 Jürgen Schmidt <jo...@googlemail.com>:
> On 1/5/12 12:12 PM, Ross Gardler wrote:
>>
>> As a separate point in this thread I should also point out that the
>> ASF has some experience of dealing with off-site repository providers.
>> Not all of it good. Most of the problems have been a result of lack of
>> planning and lack of adequate protection of the trademarks involved.
>>
>> All those cases (to my knowledge) have now reached satisfactory
>> states. I imagine the Board will be keen to see that The PPMC has
>> considered the kinds of terms that will be offered to third party
>> sites with respect to trademark usage. My recommendation would be to
>> simply state that no use beyond those approved by existing ASF policy
>> will be required.
>>
>> I also suggest that if the PPMC wants to take Sourceforge up on the
>> offer that it is made clear to all parties that this will not be the
>> "official" AOO extensions repository. Only the ASF will host official
>> Apache services. However, this does not mean that the AOO site and
>> product cannot link out to an SF provided repository.
>>
>> Remember also that the ASF cannot do anything that benefits a single
>> organisation more than any other. Therefore, any agreement with
>> Sourceforge cannot be exclusive. There must be opportunities for
>> others to offer similar services if they want to put the effort into
>> doing so.
>
>
> I think that is fair enough. I see it in the way that SF comes first to
> offer their help and help us to solve a problem with general hosting of GPL,
> LGPL etc. extensions that we can't host in an official ASF repo. We can
> probably rename it and find a way to make clear that it is a supported repo
> but not the official one (long term when we an official ASF repo).
>
> And the proposed index only solution is not satisfying for me because of the
> explained reasons (missing hosting of the binary extension packages or
> templates). But I would like to learn more about it and especially how it
> should be maintained, the frontend how users would register their extensions
> ...

Let's take an example of the general pattern, with blogs. Blogs are
content, hosted all over the web, on millions of different sites.
Sometimes they are hosted together, in one place, by blog hosting
sites, like Blogger or Wordpress.com, and in other cases they are
hosted by the individual owners on their own websites.  There are many
different providers of blogging software as well.  But they all agree
on some basic standards:  HTML for the content, and RSS or Atom for
syndication.  RSS and Atom (and you only really need one of them.  The
fact that there are two is an historical accident) are the glue that
contexts the content stores (blogs) with other services. For example,
Google Blog search, News Readers, mobile apps like Pulse, aggregator's
for "Planet" websites, etc.  By separating the storage of the content
from the advertising of the content, you open up a whole new set of
possibilities.

So the model that I think is attractive for extensions and templates is:

1) The actual repositories for the templates can be done anywhere.  We
don't specify how they are stored.  It could be SourceForge, Google
Code, here at Apache, on the author's own personal website, wherever.
We don't specify the user interface, the account model, the
interactions the extension author has with the repository site.  These
details are all the concern of the repository owner. Let them compete
for app developers based on the services they provide and how easy
they make it for app developers.

Of course, Apache can host a repository as well, but I think
considerations of license and release policy will lead us,in the end,
to only host extensions that are actual releases of the project.

2) What we do specify are:

a) The metadata related to extensions.  For example, name of
extension, version, author, website, short description, screen shot,
language, versions of OpenOffice supported, license, and of course,
the URL to download.

b) An encoding of the metadata, in XML.

c) A mechanism for advertising the extensions hosted at a given
repository.   If we just base this on Atom, we'll be able to reuse a
lot of existing libraries, so that might be a good start.

3) It would then be the responsibility of the repository hosts to
provide feeds of available extensions per the above specifications.
This would be optional.   Similarly, you can have a "blog" today, but
provide no RSS or Atom feed.  But by doing so you shut yourself out of
the larger ecosystem that is enabled by having feeds.  For larger
repository hosts, like SourceForge, these feeds could be automatically
generated from the repository data.  But even a small personal website
with just 1 or 2 extensions should be able to hand-author a correct
feed.

4) We then have one or more aggregators of extension and template
metadata.  These would be fed by a collection of feed URL's, submitted
by repository  hosts.  The aggregator would periodically fetch updated
metadata.  The aggregator would then have a user-facing UI for
searching, filtering, rating, reviewing, and downloading, extensions.
Apache could host one that was open to all feed submissions.

5) This model enables other things, like automatically sending a
Twitter tweet when a new extension is added, or having a "Planet AOO
Extensions" that posts the descriptions of new templates as they come
in, etc.  Could even put that in a section of our website.

6) The feed mechanism could also work well for in-product use, to have
the ability to browse one or more repositories for extensions.  Maybe
out-of-the-box, we only point to the official Apache extension
repository, including officially released extensions.  But the user
can add (or enable) additional repositories. This could be similar to
how some Linux distros deal with 3rd party packages, where you start
with just supported packages, but can enable additional sources.

>
> I haven't seen a long term solution that would solve our problem for
> graduation. How do we want address for example a template repo with hosting
> capabilites for templates?
>
> We can use the existing implementation of the repos (extensions and
> templates) and can remove all content and allow ALv2 licensed stuff only.
> But then we have again to answer the question of hosting binaries or
> templates. Do we want support it, do we have the resources (storage,
> bandwidth)?
>
> As we have discussed earlier it is fine to have several repos and one
> official ASF repo. Support of multiple repos (not yet implemented) that are
> configurable in the office. Especially when we think of internal repos in a
> closed enterprise environment...
>
> If it won't work with SF we can revert it. For me it seems at least worse a
> try because we have limited resources anyway, still enough to do and any
> kind of help is welcome, or not?
>
> It's again a situation where the existing solution doesn't fit well in
> Apache because of allowing copyleft licensed stuff as well. But it is
> somewhat important for the overall eco-system. I hope we can find a
> satisfying solution and i think multiple repos can be a solution.
>
> Juergen
>
>
>>
>> Ross
>>
>> On 3 January 2012 15:51, Ross Gardler<rg...@opendirective.com>  wrote:
>>>
>>> As the community know Gav, in his role at infrastructure@ has
>>> undertaken to stabilise and migrate the AOO extensions code to ASF
>>> infrastructure. His work has been progressing and he remains committed
>>> to completing this.
>>>
>>> However, as some know Sourceforge made an offer to help via our
>>> private list. At the time they did not want to discuss this topic in
>>> public for a number of reasons. I've had a couple of chats with
>>> Roberto Gallopini and Jeff Drobick in order to help them understand
>>> why the ASF prefers to host all services for its projects. In response
>>> SF have tailored their offer of support.
>>>
>>> I relayed the outline of our conversations to the infrastructure team
>>> who have asked me to have the AOO project provide some feedback, via a
>>> board report, on what problems the AOO project forsee for the
>>> extensions site and what options are available, if possible a
>>> recommendation for an optimal solution should also be made. Note that
>>> we can submit something out of cycle if we want, the next full report
>>> is not due till March.
>>>
>>> The reason infra@ have escalated to board@ is probably that we need to
>>> figure out a long term solution for the AOO project and that solution
>>> is heavily influenced by ASF policy. Any solution that we are
>>> currently considering will have an impact on the AOO extensions site
>>> and/or on ASF policy.
>>>
>>> The current situation, as I understand it, is that the board have
>>> given permission for the extensions site to be managed by infra during
>>> incubation. The problem of distributing content under licences other
>>> than Apache is not seen to be a problem during the incubation process.
>>> Beyond incubation the board has delegated responsibility to the
>>> Incubator PMC. I don't believe that particular discussion has been
>>> started yet.
>>>
>>> Gav tells us that he has been thinking about making the extensions
>>> site an index site, thus allowing the extensions to be housed
>>> elsewhere (apache-extras, sourceforge, google code, github, FooBar
>>> corporation or wherever). This would neatly bypass the licence
>>> problem. Open source extensions needing hosting could go to
>>> apache-extras while commercially licensed extensions would need to
>>> provide their own hosting.
>>>
>>> An alternative is to work with a third party willing to help. I've
>>> copied below the text of a mail outlining the SF proposal. You will
>>> note that they are keen to ensure that we don't get locked into the SF
>>> services. Nevertheless, one of the reasons the ASF hosts its own
>>> services is to avoid exposing us to unmanageable risk.
>>>
>>> I have no reason to believe SourceForge have anything other than good
>>> intentions in making this offer. SF has been supporting open source
>>> for a very long time. It is backed at the highest level (Jeff is
>>> President and CEO) and I believe Roberto is known within the
>>> OpenOffce.org community. However, many aspects of this will be outside
>>> of the control of the AOO project, despite SFs real attempts to
>>> mitigate our concerns relating to this.
>>>
>>> Please note that the timescales Jeff outlines are unrealistic given
>>> that we need to seek board input before being able to ensure the AOO
>>> project makes the right decision.  SF want to move quickly, but I
>>> don't think we need to be rushed into making a decision.
>>>
>>> Once you've digested and debated the offer from Sourceforge the
>>> community needs to come up with a couple of paragraphs indicating a
>>> desired route forwards and reasons for it. I will try and attend the
>>> appropriate board meeting in order to answer any questions that arise.
>>>
>>> Please be imaginative in your planning for the future. The optimal
>>> solution might be some combination of ASF and SF offerings.
>>>
>>> Note Roberto Gallopini has joined this list and is ready to make any
>>> clarifications necessary. I've also made Gav aware of this post so
>>> that he can answer any questions we have about what infra@ are able to
>>> do.
>>>
>>> Thanks,
>>> Ross
>>>
>>> --- COPIED PROPOSAL ---
>>>
>>> I'm glad we had a chance to talk last week - exciting times for Open
>>> Office as the product and community transition into the ASF.
>>>
>>> For over a decade, SourceForge has been committed to advancing the
>>> open source software community.  We host over 300,000 projects and are
>>> visited by over 40 MM users per month for free, secure, and fast
>>> downloads of open source software.  Trusted and reliable download
>>> delivery is an important part of our service, with over 4 million
>>> downloads per day and 2 PB from our mirror network each month.  We are
>>> committed to helping OSS projects scale and grow.
>>>
>>> Based on our discussions, we understand there are a few things you are
>>> solving for as part of the Open Office Incubation effort:
>>> Supporting a diverse licensing terms for Open Office extensions, that
>>> may not all comply with the Apache OSS policy;
>>> Stabilizing your Drupal OO Extensions site and ensuring high
>>> availability and download bandwidth without cost
>>> Expanding both the developer base who will move into working on the
>>> Apache framework as well as adoption of the Open Office product and
>>> extensions.
>>> We think we can help and that there would be mutual benefit.  To that
>>> end, we propose the following for your consideration:
>>>
>>> 1.) Stabilize the your OO Extensions Drupal instance by moving the it
>>> and all services to SourceForge.  Our Site Operations team will do teh
>>> work and oversee the operations for you as we do other services.  To
>>> your community the directory will look the same and extension and
>>> template files will move to SourceForge's globally-distributed
>>> download mirror network where we can ensure reliable, scalable
>>> delivery.  Drupal will be hosted on our project web service, serving
>>> your existing domain via a VHOST.  Standard infrastructure
>>> (monitoring, backups, etc.) and service levels (99.9% availability
>>> target) apply.
>>>
>>> These SourceForge services will be provided gratis, and without
>>> lock-in -- you are open to change your mind later.  We anticipate this
>>> migration would involve a week of planning and preparation, followed
>>> by a week of migration and pre/post-migration communications.  We're
>>> prepared to commence this work the next week if provided your approval
>>> and support.
>>>
>>> 2.) Once stabilized, we will work with you on a timeline to evaluate
>>> and execute a migration from Drupal 5 to Drupal 7.
>>>
>>> Allowing us to host the Extensions community will solve the license
>>> challenges - or at least give you time to work through a longer term
>>> solution.  We would also be able to cross promote the software titles
>>> to the development community as well - so perhaps expand not only your
>>> user base but developers.
>>>
>>> Roberto (our Sr. Director of Business Development) has been involved
>>> in the OpenOffice.org community for many years -- he will continue to
>>> be your point-of-contact.  If we secure the go-ahead this week, we
>>> will start on Tuesday next week and expect to be complete by 1/15 with
>>> step 1.  I have asked our head of Site Ops to oversee the
>>> implementation and he'll partner up with your technical folks to
>>> ensure the hosting transition goes well.
>>>
>>> Our motivation here is quite simple, it is all part of our mission to
>>> help Open Source Software initiatives succeed.  To that end,
>>> SourceForge and Geeknet Media are able to fund these services and make
>>> them free to the community through advertising largely on the download
>>> and directory pages.  So there won't ever be a charge back to your
>>> community and we are able to reinvest in R&D on our developer tools as
>>> well.
>>>
>>> We look forward to hearing back from you this week if possible.  Feel
>>> free to forward this on to whomever you would like in terms of getting
>>> to an aligned decision.
>>>
>>> I wish you a happy new year!
>>>
>>> --
>>> Thank you,
>>> Jeff
>>>
>>> --- End of copied text ---
>>> --
>>> Ross Gardler (@rgardler)
>>> Programme Leader (Open Development)
>>> OpenDirective http://opendirective.com
>>
>>
>>
>>
>

Re: Extensions hosting

[Jürgen Schmidt <jo...@googlemail.com>]

On 1/5/12 12:12 PM, Ross Gardler wrote:
> As a separate point in this thread I should also point out that the
> ASF has some experience of dealing with off-site repository providers.
> Not all of it good. Most of the problems have been a result of lack of
> planning and lack of adequate protection of the trademarks involved.
>
> All those cases (to my knowledge) have now reached satisfactory
> states. I imagine the Board will be keen to see that The PPMC has
> considered the kinds of terms that will be offered to third party
> sites with respect to trademark usage. My recommendation would be to
> simply state that no use beyond those approved by existing ASF policy
> will be required.
>
> I also suggest that if the PPMC wants to take Sourceforge up on the
> offer that it is made clear to all parties that this will not be the
> "official" AOO extensions repository. Only the ASF will host official
> Apache services. However, this does not mean that the AOO site and
> product cannot link out to an SF provided repository.
>
> Remember also that the ASF cannot do anything that benefits a single
> organisation more than any other. Therefore, any agreement with
> Sourceforge cannot be exclusive. There must be opportunities for
> others to offer similar services if they want to put the effort into
> doing so.

I think that is fair enough. I see it in the way that SF comes first to 
offer their help and help us to solve a problem with general hosting of 
GPL, LGPL etc. extensions that we can't host in an official ASF repo. We 
can probably rename it and find a way to make clear that it is a 
supported repo but not the official one (long term when we an official 
ASF repo).

And the proposed index only solution is not satisfying for me because of 
the explained reasons (missing hosting of the binary extension packages 
or templates). But I would like to learn more about it and especially 
how it should be maintained, the frontend how users would register their 
extensions ...

I haven't seen a long term solution that would solve our problem for 
graduation. How do we want address for example a template repo with 
hosting capabilites for templates?

We can use the existing implementation of the repos (extensions and 
templates) and can remove all content and allow ALv2 licensed stuff 
only. But then we have again to answer the question of hosting binaries 
or templates. Do we want support it, do we have the resources (storage, 
bandwidth)?

As we have discussed earlier it is fine to have several repos and one 
official ASF repo. Support of multiple repos (not yet implemented) that 
are configurable in the office. Especially when we think of internal 
repos in a closed enterprise environment...

If it won't work with SF we can revert it. For me it seems at least 
worse a try because we have limited resources anyway, still enough to do 
and any kind of help is welcome, or not?

It's again a situation where the existing solution doesn't fit well in 
Apache because of allowing copyleft licensed stuff as well. But it is 
somewhat important for the overall eco-system. I hope we can find a 
satisfying solution and i think multiple repos can be a solution.

Juergen

>
> Ross
>
> On 3 January 2012 15:51, Ross Gardler<rg...@opendirective.com>  wrote:
>> As the community know Gav, in his role at infrastructure@ has
>> undertaken to stabilise and migrate the AOO extensions code to ASF
>> infrastructure. His work has been progressing and he remains committed
>> to completing this.
>>
>> However, as some know Sourceforge made an offer to help via our
>> private list. At the time they did not want to discuss this topic in
>> public for a number of reasons. I've had a couple of chats with
>> Roberto Gallopini and Jeff Drobick in order to help them understand
>> why the ASF prefers to host all services for its projects. In response
>> SF have tailored their offer of support.
>>
>> I relayed the outline of our conversations to the infrastructure team
>> who have asked me to have the AOO project provide some feedback, via a
>> board report, on what problems the AOO project forsee for the
>> extensions site and what options are available, if possible a
>> recommendation for an optimal solution should also be made. Note that
>> we can submit something out of cycle if we want, the next full report
>> is not due till March.
>>
>> The reason infra@ have escalated to board@ is probably that we need to
>> figure out a long term solution for the AOO project and that solution
>> is heavily influenced by ASF policy. Any solution that we are
>> currently considering will have an impact on the AOO extensions site
>> and/or on ASF policy.
>>
>> The current situation, as I understand it, is that the board have
>> given permission for the extensions site to be managed by infra during
>> incubation. The problem of distributing content under licences other
>> than Apache is not seen to be a problem during the incubation process.
>> Beyond incubation the board has delegated responsibility to the
>> Incubator PMC. I don't believe that particular discussion has been
>> started yet.
>>
>> Gav tells us that he has been thinking about making the extensions
>> site an index site, thus allowing the extensions to be housed
>> elsewhere (apache-extras, sourceforge, google code, github, FooBar
>> corporation or wherever). This would neatly bypass the licence
>> problem. Open source extensions needing hosting could go to
>> apache-extras while commercially licensed extensions would need to
>> provide their own hosting.
>>
>> An alternative is to work with a third party willing to help. I've
>> copied below the text of a mail outlining the SF proposal. You will
>> note that they are keen to ensure that we don't get locked into the SF
>> services. Nevertheless, one of the reasons the ASF hosts its own
>> services is to avoid exposing us to unmanageable risk.
>>
>> I have no reason to believe SourceForge have anything other than good
>> intentions in making this offer. SF has been supporting open source
>> for a very long time. It is backed at the highest level (Jeff is
>> President and CEO) and I believe Roberto is known within the
>> OpenOffce.org community. However, many aspects of this will be outside
>> of the control of the AOO project, despite SFs real attempts to
>> mitigate our concerns relating to this.
>>
>> Please note that the timescales Jeff outlines are unrealistic given
>> that we need to seek board input before being able to ensure the AOO
>> project makes the right decision.  SF want to move quickly, but I
>> don't think we need to be rushed into making a decision.
>>
>> Once you've digested and debated the offer from Sourceforge the
>> community needs to come up with a couple of paragraphs indicating a
>> desired route forwards and reasons for it. I will try and attend the
>> appropriate board meeting in order to answer any questions that arise.
>>
>> Please be imaginative in your planning for the future. The optimal
>> solution might be some combination of ASF and SF offerings.
>>
>> Note Roberto Gallopini has joined this list and is ready to make any
>> clarifications necessary. I've also made Gav aware of this post so
>> that he can answer any questions we have about what infra@ are able to
>> do.
>>
>> Thanks,
>> Ross
>>
>> --- COPIED PROPOSAL ---
>>
>> I'm glad we had a chance to talk last week - exciting times for Open
>> Office as the product and community transition into the ASF.
>>
>> For over a decade, SourceForge has been committed to advancing the
>> open source software community.  We host over 300,000 projects and are
>> visited by over 40 MM users per month for free, secure, and fast
>> downloads of open source software.  Trusted and reliable download
>> delivery is an important part of our service, with over 4 million
>> downloads per day and 2 PB from our mirror network each month.  We are
>> committed to helping OSS projects scale and grow.
>>
>> Based on our discussions, we understand there are a few things you are
>> solving for as part of the Open Office Incubation effort:
>> Supporting a diverse licensing terms for Open Office extensions, that
>> may not all comply with the Apache OSS policy;
>> Stabilizing your Drupal OO Extensions site and ensuring high
>> availability and download bandwidth without cost
>> Expanding both the developer base who will move into working on the
>> Apache framework as well as adoption of the Open Office product and
>> extensions.
>> We think we can help and that there would be mutual benefit.  To that
>> end, we propose the following for your consideration:
>>
>> 1.) Stabilize the your OO Extensions Drupal instance by moving the it
>> and all services to SourceForge.  Our Site Operations team will do teh
>> work and oversee the operations for you as we do other services.  To
>> your community the directory will look the same and extension and
>> template files will move to SourceForge's globally-distributed
>> download mirror network where we can ensure reliable, scalable
>> delivery.  Drupal will be hosted on our project web service, serving
>> your existing domain via a VHOST.  Standard infrastructure
>> (monitoring, backups, etc.) and service levels (99.9% availability
>> target) apply.
>>
>> These SourceForge services will be provided gratis, and without
>> lock-in -- you are open to change your mind later.  We anticipate this
>> migration would involve a week of planning and preparation, followed
>> by a week of migration and pre/post-migration communications.  We're
>> prepared to commence this work the next week if provided your approval
>> and support.
>>
>> 2.) Once stabilized, we will work with you on a timeline to evaluate
>> and execute a migration from Drupal 5 to Drupal 7.
>>
>> Allowing us to host the Extensions community will solve the license
>> challenges - or at least give you time to work through a longer term
>> solution.  We would also be able to cross promote the software titles
>> to the development community as well - so perhaps expand not only your
>> user base but developers.
>>
>> Roberto (our Sr. Director of Business Development) has been involved
>> in the OpenOffice.org community for many years -- he will continue to
>> be your point-of-contact.  If we secure the go-ahead this week, we
>> will start on Tuesday next week and expect to be complete by 1/15 with
>> step 1.  I have asked our head of Site Ops to oversee the
>> implementation and he'll partner up with your technical folks to
>> ensure the hosting transition goes well.
>>
>> Our motivation here is quite simple, it is all part of our mission to
>> help Open Source Software initiatives succeed.  To that end,
>> SourceForge and Geeknet Media are able to fund these services and make
>> them free to the community through advertising largely on the download
>> and directory pages.  So there won't ever be a charge back to your
>> community and we are able to reinvest in R&D on our developer tools as
>> well.
>>
>> We look forward to hearing back from you this week if possible.  Feel
>> free to forward this on to whomever you would like in terms of getting
>> to an aligned decision.
>>
>> I wish you a happy new year!
>>
>> --
>> Thank you,
>> Jeff
>>
>> --- End of copied text ---
>> --
>> Ross Gardler (@rgardler)
>> Programme Leader (Open Development)
>> OpenDirective http://opendirective.com
>
>
>

Re: Extensions hosting

[Ross Gardler <rg...@opendirective.com>]

As a separate point in this thread I should also point out that the
ASF has some experience of dealing with off-site repository providers.
Not all of it good. Most of the problems have been a result of lack of
planning and lack of adequate protection of the trademarks involved.

All those cases (to my knowledge) have now reached satisfactory
states. I imagine the Board will be keen to see that The PPMC has
considered the kinds of terms that will be offered to third party
sites with respect to trademark usage. My recommendation would be to
simply state that no use beyond those approved by existing ASF policy
will be required.

I also suggest that if the PPMC wants to take Sourceforge up on the
offer that it is made clear to all parties that this will not be the
"official" AOO extensions repository. Only the ASF will host official
Apache services. However, this does not mean that the AOO site and
product cannot link out to an SF provided repository.

Remember also that the ASF cannot do anything that benefits a single
organisation more than any other. Therefore, any agreement with
Sourceforge cannot be exclusive. There must be opportunities for
others to offer similar services if they want to put the effort into
doing so.

Ross

On 3 January 2012 15:51, Ross Gardler <rg...@opendirective.com> wrote:
> As the community know Gav, in his role at infrastructure@ has
> undertaken to stabilise and migrate the AOO extensions code to ASF
> infrastructure. His work has been progressing and he remains committed
> to completing this.
>
> However, as some know Sourceforge made an offer to help via our
> private list. At the time they did not want to discuss this topic in
> public for a number of reasons. I've had a couple of chats with
> Roberto Gallopini and Jeff Drobick in order to help them understand
> why the ASF prefers to host all services for its projects. In response
> SF have tailored their offer of support.
>
> I relayed the outline of our conversations to the infrastructure team
> who have asked me to have the AOO project provide some feedback, via a
> board report, on what problems the AOO project forsee for the
> extensions site and what options are available, if possible a
> recommendation for an optimal solution should also be made. Note that
> we can submit something out of cycle if we want, the next full report
> is not due till March.
>
> The reason infra@ have escalated to board@ is probably that we need to
> figure out a long term solution for the AOO project and that solution
> is heavily influenced by ASF policy. Any solution that we are
> currently considering will have an impact on the AOO extensions site
> and/or on ASF policy.
>
> The current situation, as I understand it, is that the board have
> given permission for the extensions site to be managed by infra during
> incubation. The problem of distributing content under licences other
> than Apache is not seen to be a problem during the incubation process.
> Beyond incubation the board has delegated responsibility to the
> Incubator PMC. I don't believe that particular discussion has been
> started yet.
>
> Gav tells us that he has been thinking about making the extensions
> site an index site, thus allowing the extensions to be housed
> elsewhere (apache-extras, sourceforge, google code, github, FooBar
> corporation or wherever). This would neatly bypass the licence
> problem. Open source extensions needing hosting could go to
> apache-extras while commercially licensed extensions would need to
> provide their own hosting.
>
> An alternative is to work with a third party willing to help. I've
> copied below the text of a mail outlining the SF proposal. You will
> note that they are keen to ensure that we don't get locked into the SF
> services. Nevertheless, one of the reasons the ASF hosts its own
> services is to avoid exposing us to unmanageable risk.
>
> I have no reason to believe SourceForge have anything other than good
> intentions in making this offer. SF has been supporting open source
> for a very long time. It is backed at the highest level (Jeff is
> President and CEO) and I believe Roberto is known within the
> OpenOffce.org community. However, many aspects of this will be outside
> of the control of the AOO project, despite SFs real attempts to
> mitigate our concerns relating to this.
>
> Please note that the timescales Jeff outlines are unrealistic given
> that we need to seek board input before being able to ensure the AOO
> project makes the right decision.  SF want to move quickly, but I
> don't think we need to be rushed into making a decision.
>
> Once you've digested and debated the offer from Sourceforge the
> community needs to come up with a couple of paragraphs indicating a
> desired route forwards and reasons for it. I will try and attend the
> appropriate board meeting in order to answer any questions that arise.
>
> Please be imaginative in your planning for the future. The optimal
> solution might be some combination of ASF and SF offerings.
>
> Note Roberto Gallopini has joined this list and is ready to make any
> clarifications necessary. I've also made Gav aware of this post so
> that he can answer any questions we have about what infra@ are able to
> do.
>
> Thanks,
> Ross
>
> --- COPIED PROPOSAL ---
>
> I'm glad we had a chance to talk last week - exciting times for Open
> Office as the product and community transition into the ASF.
>
> For over a decade, SourceForge has been committed to advancing the
> open source software community.  We host over 300,000 projects and are
> visited by over 40 MM users per month for free, secure, and fast
> downloads of open source software.  Trusted and reliable download
> delivery is an important part of our service, with over 4 million
> downloads per day and 2 PB from our mirror network each month.  We are
> committed to helping OSS projects scale and grow.
>
> Based on our discussions, we understand there are a few things you are
> solving for as part of the Open Office Incubation effort:
> Supporting a diverse licensing terms for Open Office extensions, that
> may not all comply with the Apache OSS policy;
> Stabilizing your Drupal OO Extensions site and ensuring high
> availability and download bandwidth without cost
> Expanding both the developer base who will move into working on the
> Apache framework as well as adoption of the Open Office product and
> extensions.
> We think we can help and that there would be mutual benefit.  To that
> end, we propose the following for your consideration:
>
> 1.) Stabilize the your OO Extensions Drupal instance by moving the it
> and all services to SourceForge.  Our Site Operations team will do teh
> work and oversee the operations for you as we do other services.  To
> your community the directory will look the same and extension and
> template files will move to SourceForge's globally-distributed
> download mirror network where we can ensure reliable, scalable
> delivery.  Drupal will be hosted on our project web service, serving
> your existing domain via a VHOST.  Standard infrastructure
> (monitoring, backups, etc.) and service levels (99.9% availability
> target) apply.
>
> These SourceForge services will be provided gratis, and without
> lock-in -- you are open to change your mind later.  We anticipate this
> migration would involve a week of planning and preparation, followed
> by a week of migration and pre/post-migration communications.  We're
> prepared to commence this work the next week if provided your approval
> and support.
>
> 2.) Once stabilized, we will work with you on a timeline to evaluate
> and execute a migration from Drupal 5 to Drupal 7.
>
> Allowing us to host the Extensions community will solve the license
> challenges - or at least give you time to work through a longer term
> solution.  We would also be able to cross promote the software titles
> to the development community as well - so perhaps expand not only your
> user base but developers.
>
> Roberto (our Sr. Director of Business Development) has been involved
> in the OpenOffice.org community for many years -- he will continue to
> be your point-of-contact.  If we secure the go-ahead this week, we
> will start on Tuesday next week and expect to be complete by 1/15 with
> step 1.  I have asked our head of Site Ops to oversee the
> implementation and he'll partner up with your technical folks to
> ensure the hosting transition goes well.
>
> Our motivation here is quite simple, it is all part of our mission to
> help Open Source Software initiatives succeed.  To that end,
> SourceForge and Geeknet Media are able to fund these services and make
> them free to the community through advertising largely on the download
> and directory pages.  So there won't ever be a charge back to your
> community and we are able to reinvest in R&D on our developer tools as
> well.
>
> We look forward to hearing back from you this week if possible.  Feel
> free to forward this on to whomever you would like in terms of getting
> to an aligned decision.
>
> I wish you a happy new year!
>
> --
> Thank you,
> Jeff
>
> --- End of copied text ---
> --
> Ross Gardler (@rgardler)
> Programme Leader (Open Development)
> OpenDirective http://opendirective.com



-- 
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com