Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <4F105583.7080302@a-w-f.de>
Date: Fri, 13 Jan 2012 17:02:11 +0100
From: Andre Fischer <af@a-w-f.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: ooo-dev@incubator.apache.org
Subject: Re: Category-B tarballs in SVN (was Re: External libraries)
References: <1326466786.35062.YahooMailNeo@web160902.mail.bf1.yahoo.com>
 <1326467323.8801.YahooMailClassic@web113520.mail.gq1.yahoo.com>
 <1326467553.12721.YahooMailNeo@web160906.mail.bf1.yahoo.com>
 <CAKQbXgBu9sJ5iwqKpcq9YKThrDVETapqt96Qdn7bc=dhhsrdzQ@mail.gmail.com>
In-Reply-To: 
 <CAKQbXgBu9sJ5iwqKpcq9YKThrDVETapqt96Qdn7bc=dhhsrdzQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


On 13.01.2012 16:25, Ross Gardler wrote:
> For what it is worth, I agree with Joe here. The question is whether there
> is a valid reason to keep them here.

I don't know if the reasons are valid.  We are trying to find a 
pragmatical solution that is a good compromise for the different 
requirements of the ASF, the OpenOffice developers/community, and the 
OpenOffice users:

- For the ASF we use no code under category X license and try to use as 
little code under category B license.

- For the users we want to retain as many features as possible.

- For the developers we want to make development as accessible as possible.


We should also keep in mind that, compared to before the transition from 
Oracle to Apache, at the moment there are only a few developers working 
on the code:

- Every category B project that is removed will lead to missing features 
because we do not have the resources to replace it.

- Loading the cat B tar balls from their home servers
a) is not always possible (eg because the version we use is no longer 
available, or the server is not reliable or can not handle the load)

b) will make setting up of a development environment more difficult and 
may scare away new developers

c) does not solve the underlying legal problems anyway (as far as I 
understand the discussion so far)


 >[...]


I think that we should try to work an a pragmatical compromise.  We 
should also keep our users in mind, which do not have a voice in this 
discussion.  An who may not be too interested in licenses and policies.

Regards,
Andre