Mailing-List: contact legal-discuss-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: legal-discuss@apache.org
Message-ID: <537E5DDB.20407@apache.org>
Date: Thu, 22 May 2014 21:28:11 +0100
From: Mark Thomas <markt@apache.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: legal-discuss@apache.org
Subject: Re: Release Policy
References: 
 <CAAS6=7jTVyaDhwepAqob-=83DxJ-uaMS9GyG5j5XdHYybvAtGQ@mail.gmail.com>
In-Reply-To: 
 <CAAS6=7jTVyaDhwepAqob-=83DxJ-uaMS9GyG5j5XdHYybvAtGQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 22/05/2014 19:42, Marvin Humphrey wrote:
> Greetings,
> 
> As discussed at ApacheCon Denver and elsewhere, I propose to migrate ASF
> Release Policy from FAQ-style to MUST/SHOULD/MAY imperative style, and
> to give Legal Affairs custodial responsibility for maintaining it.

+1. I think this is an excellent initiative.

Comments on the draft in-line.

<snip/>

> ----------------
> 
> # Release Policy # {#policy}
> 
> ## Definition of "release" ## {#release-definition}
> 
> Generically, a release is anything that is published beyond the group
> that owns it.  For an Apache project, that means any publication outside the
> developer community, defined as the subscribers to the product dev list.

I like the "subscribed to the dev list" definition because it is short
and unambiguous.

However, I think the developer community is a little wider than that.
For example a user who reports a bug and then offers to test the fix
becomes a (temporary) part of the dev community but they might never
subscribe to the dev list.

My best suggestion is to extend dev community to anyone who interacts
with a development resource (dev list, review board, ci system, issue
tracker, etc.).

The important part of this is the "published beyond bit". As long as
someone has to knowingly go past a clear "You are now leaving the user
community. Welcome to the dev community." sign of some form I think we
are fine. The issue is when developer resources (e.g. a CI build) are
advertised directly to the users list or linked to from the product
downloads page etc. (linking from a dev resources page would be fine in
my view).

> More narrowly, an official Apache release is one which has been endorsed as an
> "act of the Foundation" by a PMC.
> 
> ## Release approval ## {#release-approval}
> 
> Each PMC MUST obey the ASF requirements on approving any release.
> 
> For a release vote to pass, a minimum of three positive votes and more
> positive than negative votes MUST be cast.  Releases may not be vetoed.
> Votes cast by PMC members are binding.
> 
> Before casting +1 binding votes, individuals are required
> to download the signed source code package onto their own hardware, compile it
> as provided, and test the resulting executable on their own platform, along
> with also validating cryptographic signatures and verifying that the package
> meets the requirements of the ASF policy on releases.

That is a big ask for some projects. In particular I am thinking of
OpenOffice. I'm wondering if there is an alternative form of words -
something like "validate that the binary package is the result of
compilation from the source package" that would allow folks to validate
that the CI system did the right thing with the right inputs to generate
the binaries.

> Release votes SHOULD remain open for at least 72 hours.
> 
> ## Publication ## {#publication}
> 
> Projects SHALL publish official releases and SHALL NOT publish unreleased
> materials outside the developer community.
> 
> During the process of developing software and preparing a release, various
> packages are made available to the developer community for testing
> purposes. **Projects MUST NOT take any action that might
> encourage non-developers to download or use nightly builds, snapshots,
> release candidates, or any other similar package.** The only people who are
> supposed to know about such packages are the people following the dev list
> (or searching its archives) and thus aware of the conditions placed on the
> package.

Again, I'd be a little more relaxed here. For example the above would
prevent a project creating a developer resources page and linking to the
CI builds from that. That seems overly restrictive.

> ## Artifacts ## {#artifacts}
> 
> ### Source packages ### {#source-packages}
> 
> Every ASF release MUST contain one or more source packages, which MUST be
> sufficient for a user to build and test the release provided they have
> access to the appropriate platform and tools.

Define test. The Tomcat project uses the TCK (where it has it) to test
releases but we can't make that available to end users.

> ### Release signing ### {#release-signing}
> 
> All supplied packages MUST be cryptographically signed by the Release
> Manager with a detached signature.  Folks who vote +1
> for release MAY offer their own cryptographic signature to be concatenated
> with the detached signature file (at the Release Manager's discretion)
> prior to release.
> 
> ### Compiled packages ### {#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.
> 
> ## Licensing ## {#licensing}
> 
> Every ASF release MUST comply with ASF licensing policy. This
> requirement is of utmost importance and an audit SHOULD be performed before
> any full release is created.  In particular, every artifact distributed MUST
> contain only appropriately licensed code per [Apache Licensing
> Policy](/legal/resolved).
> 
> ## Licensing Documentation ## {#licensing-documentation}
> 
> Each package MUST provide a `LICENSE` file and a `NOTICE` file which account
> for the package's exact content.  `LICENSE` and `NOTICE` MUST NOT provide
> unnecessary information about materials which are not bundled in the package,
> such as separately downloaded dependencies.
> 
> For source packages, `LICENSE` and `NOTICE` MUST be located at the root of the
> distribution.  For additional packages, they MUST be located in the
> distribution format's customary location for licensing materials, such as the
> `META-INF` directory of Java "jar" files.
> 
> ### The `LICENSE` file ### {#license-file}
> 
> The `LICENSE` file MUST contain the full text of the [Apache License
> 2.0](/licenses/LICENSE-2.0.txt).
> 
> When a package bundles code under several licenses, the `LICENSE` file
> MUST contain details of all these licenses. For each component which is not
> Apache licensed, details of the component MUST be appended to the `LICENSE`
> file.  The component license itself MUST either be appended or else stored
> elsewhere in the package with a pointer to it from the `LICENSE` file, e.g.
> if the license is long.
> 
> ### The `NOTICE` file ### {#notice-file}
> 
> The `NOTICE` file must conform to the requirements of [Apache licensing
> policy](http://apache.org/legal/src-headers.html#notice).
> 
> See also [section 4(d)](licenses/LICENSE-2.0.html#redistribution) of the
> Apache License 2.0.
> 
> ### License Headers ### {#license-headers}
> 
> Source files consisting of works submitted directly to the ASF by the
> copyright owner or owner's agent must contain the appropriate [ASF license
> header](http://www.apache.org/legal/src-headers.html#headers).
> 
> ## Release Distribution ## {#release-distribution}
> 
> Once a release is approved, all artifacts MUST be uploaded to the project's
> subdirectory within the canonical Apache distribution channel,
> `www.apache.org/dist`.
> 
> The PMC is responsible for the project distribution directory and MUST be able
> to account for its entire contents.  All artifacts within the directory MUST
> be signed by a committer, preferably a PMC member.
> 
> After uploading to the canonical distribution channel, the project (or anyone
> else) MAY redistribute the artifacts in accordance with their licensing
> through other channels.

Probably want to add something about only latest releases being on dist.
It is hard to come up with a hard and fast rule since projects use
different versioning schemes.

> ### Release Archival ## {#release-archival}
> 
> All official releases MUST be archived permanently on archive.apache.org.
> 
> ## Policy Changes ## {#policy-changes}
> 
> Changes to Release Policy must be approved by Legal Affairs.
> 
> ## TODO
> 
> Formalize additional official policies and reference them from this policy:
> 
> *   _ASF Licensing Policy_ (curated by Legal Affairs, applies to both released
>     and unreleased code)
> *   _ASF Release Distribution Policy_ (curated by Infrastructure)

Overall I like this a lot. There are a few areas where I think some
tweaks are required but this draft is pretty much in line with my
understanding of the release policy.

Mark


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