Mailing-List: contact legal-discuss-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: legal-discuss@apache.org
MIME-Version: 1.0
In-Reply-To: <575AB39E.5090800@apache.org>
References: <575AB39E.5090800@apache.org>
From: Marvin Humphrey <marvin@rectangular.com>
Date: Fri, 10 Jun 2016 07:04:02 -0700
Message-ID: <CAAS6=7gVXGHqeKVeFV_r1849Qpi0+Ca0jc2QWQBQfRdZnCwVpA@mail.gmail.com>
Subject: Re: Request for clarification of Release Policy regarding external
 jar files
To: "legal-discuss@apache.org" <legal-discuss@apache.org>, sharan@apache.org
Content-Type: text/plain; charset=UTF-8
archived-at: Fri, 10 Jun 2016 14:04:26 -0000

On Fri, Jun 10, 2016 at 5:33 AM, Sharan F <sharan@apache.org> wrote:

> We need some confirmation regarding what is included in an Apache release.

The canonical page for Apache Release Policy is here:

  http://www.apache.org/legal/release-policy

> Based on these statements our understanding is that:
>
> projects must publish "source releases"

Yes.

> "source releases" do not contain binaries

Yes.

> projects may also publish "binary releases"

This is not accurate.  Third parties (most often the release manager) may
provide compiled packages.  The colloquialism typically used to refer to these
packages is "convenience binaries".

    http://www.apache.org/legal/release-policy#compiled-packages

    The Apache Software Foundation produces open source software. All releases
    are in the form of the source materials needed to make changes to the
    software being released.

    As a convenience to users that might not have the appropriate tools to
    build a compiled version of the source, binary/bytecode packages MAY be
    distributed alongside official Apache releases. In all such cases, the
    binary/bytecode package MUST have the same version number as the source
    release and MUST only add binary/bytecode files that are the result of
    compiling that version of the source code release and its dependencies.

The Foundation does not endorse binary packages because such packages are
opaque and cannot be audited by a PMC.

Over the last few years (post-Snowden), the extent to which security depends
on audited source and certified repeatable builds has become ever more clear.

> "binary releases" can contain binaries compiled from source code created by
> the project or binaries from external projects

See the quote above for constraints on what may go into convenience binaries.
Untrusted jar files (from wherever) are allowed.  They must represent
compilation of open source dependencies, but no verification step is
required -- i.e. there is no policy requirement that anyone actually validate
that dependency binaries actually derive from specific source code.

Security-conscious consumers will naturally take such matters into account
when deciding how best to consume our products.

Marvin Humphrey

---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org