Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAKQbXgAt0TmLU6-JqJ6PNMPGOYgOF+AKhTk_KmrpqNvQfWA+cw@mail.gmail.com>
References: 
 <CAP-ksojgo1werGZ9oW-3-j1GWZ9Y8x3N78MdHCruURwzc6xJ=w@mail.gmail.com>
	<1326486446.61183.YahooMailClassic@web113510.mail.gq1.yahoo.com>
	<CAP-ksoi1iT5vtzr=4xwudMFN5kUznpYe5P_L0XoSE4QiyKW_1A@mail.gmail.com>
	<CAKQbXgAt0TmLU6-JqJ6PNMPGOYgOF+AKhTk_KmrpqNvQfWA+cw@mail.gmail.com>
Date: Mon, 16 Jan 2012 16:05:34 -0500
Message-ID: 
 <CAP-ksogSuom=DqB59unjyK+AjtdQ8hOsppFFDzLZJZZuGU4X9A@mail.gmail.com>
Subject: Re: PROPOSAL (was Re: Category-B tarballs in SVN )
From: Rob Weir <robweir@apache.org>
To: ooo-dev@incubator.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Jan 16, 2012 at 6:07 AM, Ross Gardler
<rgardler@opendirective.com> wrote:
> On 15 January 2012 03:29, Rob Weir <robweir@apache.org> wrote:
>> On Fri, Jan 13, 2012 at 3:27 PM, Pedro Giffuni <pfg@apache.org> wrote:
>>> Hello fellow indians; ;)
>>>
>>> I think there is consensus that this is (at least)
>>> a gray area so I have the following proposal, which
>>> shouldn't get in the way of having this properly
>>> solved by legal but which I think should solve at
>>> least temporarily the issues that we have. It's
>>> actually very simple but who knows, maybe it's even
>>> acceptable as a general incubator policy at the ASF.
>>>
>>> The ext_source in shall be divided, according to
>>> the categories of the licenses, into two
>>> directories in SVN, namely:
>>>
>>> ext_source_A
>>> ext_source_B
>>>
>>
>> This is assuming all 3rd party modules are pure, under a single
>> license. =C2=A0I don't believe this is always the case.
>
> Then can /should they be put in the most restrictive category?
>

They certainly could.  But the categories are really an creature of
Apache policy.  They are not necessarily relevant to downstream
consumers, whose policies could be quite different than ours.   That's
why it is good that we give the complete details in the LICENSE file
rather than some Apache-centric view of the world.  That's why I think
it would be far more useful to summarize exactly what license applies.
 We could even make a nice HTML table of this:  component, version,
original URL, license, etc.

>> Why not treat it the way we treat 3rd party modules in releases, e.g.,
>> with a LICENSE and NOTICE file? =C2=A0We could put a LICENSE file in
>> /ext-src. =C2=A0That would make it clear to anyone who browses that
>> directory.
>
> +1
>
> On one of the projects I work on we require libraries to have a
> corresponding licences/FOOBAR_license.txt file This then allows some
> simple machine processing to check the license is correctly recorded
> against all libraries included. This is built into the build system
> and automatically flags when something seems to be missing.
>

That could work.

>>> - Ext_source_B shall have a prominent text note that warns
>>> users that the code there is made available only for
>>> builder convenience but that the code is in general
>>> not acceptable for inclusion in Apache source code
>>> releases.
>>>
>>
>> OK, though this is solving a problem we don't really have, right?
>
> I think the point is that it clearly separates out stuff that is OK to
> stay and stuff that needs to be carefully managed. It's a step towards
> satisfying those who are concerned about including this source whilst
> avoiding the need to remove the convenience for developers of having
> the source available.
>

We already do that.  All of these third party modules are already
segregated from the main SVN tree.  This is true regardless of
license.   The legacy project didn't have them under version control.
They just stored them on a web server, totally separated from the
source code for OOo.    That option did not appear to be available to
us at Apache, so we stick them in the ext-src directory in SVN.

> This separation will make it easier for people to evaluate the impact
> of these files when it comes to graduation and will serve to signal
> that there is a process in place for the management of these
> dependencies (or that there needs to be a process).
>

Or we could document exactly what we're doing now, the precautions
we're already taking.  It seems that it would be hard to say whether
what we're doing already is inadequate if you don't know what exactly
we're already doing.  Not you specifically, but in general.

>> =C2=A0So if we really want to give proper notice
>> to the person downloading our source release, this needs to be done:
>> 1) In the LICENSE and NOTICE files
>
> That has to happen anyway (for cat b licenses).
>

Category-b doesn't go out in released source packages.  And for binary
packages we're already include the required licenses and
notifications.


>> Putting extra verbiage in the SVN tree that is not included in the
>> releases -- I don't see the point. =C2=A0Is this to protect casual brows=
ers
>> of our SVN tree?
>
> For me the point is not about casual browers it is about developers
> like me who don't download source tars but instead checkout from SVN.
> We can't assume that all such developers will understand the nuances
> of license compatibility or even bother to check.
>

That maybe is the piece of the puzzle that may not be clear unless you
are a developer building AOO.  You do not need to checkout the
category-b source bundles from SVN.  In fact you should not.  You
would only be wasting harddrive space. Our build doc doesn't call for
these modules to be checked-out.  Someone would need to go out of
their way to check them out of SVN explicitly.  The whole idea is that
these are downloaded via the build script, based on the configure
options chosen by the builder.  If they want to build the default
binaries, with no category-b code, then of course, none of these
modules are downloaded.  And if they want to enable the optional
category-b stuff, then they override the configure settings and the
bootstrap script downloads the additional components, according to the
user's platform.  I believe this is done via http requests, not even
via an automated svn co.

We can't prevent someone from modifying the MPL code.  But they would
need to go far out of their way to do this.

> Ross