incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
Date Thu, 31 May 2012 12:30:33 GMT
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.


View raw message