incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From J├╝rgen Schmidt <>
Subject Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
Date Thu, 31 May 2012 15:39:42 GMT
On 5/31/12 2:30 PM, Ross Gardler wrote:
> On 31 May 2012 12:54, Andre Fischer <> wrote:
>> On 31.05.2012 03:45, Pedro Giffuni wrote:
>>> --- Mer 30/5/12, Rob Weir<>  ha scritto:
> ...
>>> You mean source distribution (tarballs) don't build on
>>> their own and depend on what we carry in SVN? Sounds
>>> like something is wrong.
>> It will still build but without the tar-balls there will be missing
>> features.  And I think that missing features are much harder to explain to
>> end users than a clean license status.
> (NOTE: I am neither making nor implying judgement on the dispute here
> about category-b licenses, I'm just making some general observations)
> ASF projects release source artifacts for downstream users, not
> binaries for end users.  Yes, many projects, such as AOO, choose to
> provide a service whereby binaries are released. Those binaries must
> conform to the ASF licensing policies and, in the case of category-b
> licensed libraries, we have more room for maneuver since distribution
> is in binary form. The AOO3.4 binary release was audited and deemed
> conformant.  I don't think anyone is questioning this so lets leave
> binaries and end-user needs out of the discussion.
> The complexity arises when the project deems it necessary to maintain
> category-b licensed source code independently of the originating
> project. Most ASF projects do not concern themselves with these
> complexities because either:
> a) they are implemented in a cross platform language,
> b) they do not release binaries for multiple platforms (although they
> may provide links to third-party binary builds, e.g. Subversion)
> c) they only use libraries that are available on the platforms needed,
> working with the upstream projects where necessary
> (there may be other approaches in projects I'm not familiar with).
> Option a) is not possible here, so option b) or c) are the only ones
> needing consideration (other than asking for legal@ or IPMC guidance
> on alternatives).
> As a mentor I want this resolved before graduation can progress. It
> might turn out that the current solution is acceptable to legal@, it
> might turn out that it is not. I don't really care as long as we are
> clear that the AOO approach to managing its dependencies is acceptable
> from an ASF policy perspective. At the time of writing the only thing
> I am certain of is that I, and at least two other mentors, have
> expressed a desire to see this issue resolved.

let me explain some details here because I think they can help to

1. we have dependencies to several external libraries including
category-b for some features
2. we have checked in all this source tar-balls in ext_sources for
convenience and to ensure that they are always available. Another option
would have been to host them somewhere else on extras or any other
reliable server. We use the easier way for convenience reasons I think.
3. our source release don't contain any category-b source tar-balls
4. from a source release perspective we don't make use of any category-b
stuff per default. A user have to explicitly trigger the use of
category-b stuff and related features. The tar-balls are downloaded on
demand, some kind of dependency mechanism if you want.
5. the download on demand is the same and I don't really see a
difference between downloading the tar-balls from svn or any other place.
6. we agreed to upstream changes to external libs where possible and
necessary. And we agreed to improve the workflow to use the tar-balls
from their original source where possible over time and where we can
rely on the overall availability (e.g. dependencies to Apache libs, etc.)

It seems to be really an item for legal to decide if hosting the
category-b tar-balls in svn is not allowed for convenience at all.

Furthermore we agreed to accept and of course support the move to
another server but it is important that we don't break our 3.4 release.

We also agreed to clean up as much as possible of the dependencies to
category-b stuff over time. But that takes time and is a lot of work.

We are also open for any other action that we have to take to be conform
to existing policies.

I think we have shown in the past that we take everything serious and
address issues in time where possible.


View raw message