Return-Path: X-Original-To: apmail-legal-discuss-archive@www.apache.org Delivered-To: apmail-legal-discuss-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 69AC111633 for ; Sat, 24 May 2014 11:52:24 +0000 (UTC) Received: (qmail 62856 invoked by uid 500); 24 May 2014 11:52:24 -0000 Delivered-To: apmail-legal-discuss-archive@apache.org Received: (qmail 62677 invoked by uid 500); 24 May 2014 11:52:24 -0000 Mailing-List: contact legal-discuss-help@apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: Reply-To: legal-discuss@apache.org List-Id: Delivered-To: mailing list legal-discuss@apache.org Received: (qmail 62670 invoked by uid 99); 24 May 2014 11:52:23 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 24 May 2014 11:52:23 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of brian.leroux@gmail.com designates 209.85.223.178 as permitted sender) Received: from [209.85.223.178] (HELO mail-ie0-f178.google.com) (209.85.223.178) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 24 May 2014 11:52:20 +0000 Received: by mail-ie0-f178.google.com with SMTP id rl12so6120296iec.9 for ; Sat, 24 May 2014 04:51:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=oBtq4GBorQh9/BIDKa4HSG0kFSX0dBY/wxQ6UybLlrU=; b=RjWh63F29mQ55OPVM4/hKxhZDxLhgT1iF76o1Bv/YhkQlix/7x48G3ylWn2K5xteaU zwQr2B5pUeQZPB7RN+sVpwl39sggmI4lqtVMHOHfU9L9KdOQkiaz+tQ7IV4DZrB2Ma/K upQ1x2iHDcKSvVYbE1RICiV3DuWqsK+HyAMS+PQXdO0fJ1sisUBqrcV4RPdtFP4NBV52 cXZZ3RmxCCGDLo6nmEGidpN8ti8u/2iCUrfUhdUSdr0GMLJiWjlGuYxPBH1X1wIUgicn iaRtnrpkWJypYDAi/SBcpmJNEVNtvO5hXgBGAAJysfsqZD1W85eCW4GfqD7iNVFTnCdJ 9Edg== MIME-Version: 1.0 X-Received: by 10.50.45.3 with SMTP id i3mr11422573igm.7.1400932316744; Sat, 24 May 2014 04:51:56 -0700 (PDT) Sender: brian.leroux@gmail.com Received: by 10.50.173.40 with HTTP; Sat, 24 May 2014 04:51:56 -0700 (PDT) Received: by 10.50.173.40 with HTTP; Sat, 24 May 2014 04:51:56 -0700 (PDT) In-Reply-To: References: Date: Sat, 24 May 2014 06:51:56 -0500 X-Google-Sender-Auth: NJUD9ZTZ94WkDDJfGX_3-Wo-dDc Message-ID: Subject: Re: Release Policy From: Brian LeRoux To: legal discuss Content-Type: multipart/alternative; boundary=089e0115ec0818142a04fa23f981 X-Virus-Checked: Checked by ClamAV on apache.org --089e0115ec0818142a04fa23f981 Content-Type: text/plain; charset=UTF-8 Being that the purpose of this thread was to seek clarity I won't apologize for politely seeking that. >=| Mark: thank you for your lucid descriptions of what the *actual* reasoning for this policy is: a final check of the SRC for legal compliance. This is, in my opinion, the most important responsibility for commit rights. I am concerned the VOTE assumes this daily role of committer is being ignored (to ensure legal compliance) and therefore feel the VOTE is a SHOULD as it is added precaution and, in my view, encouraging a sloppy and irresponsible committership. On May 24, 2014 2:22 AM, "Ross Gardler" wrote: > Mark, first of all thank you for delivering on your promise at ApacheCon > :-D > > Secondly, apologies if my comment has already been covered. The thread > seems to have got bogged down in a repeat of past arguments rather than an > effort to improve the policy around those arguments. With my comment I'm > trying to avoid that argument and instead provide a concrete suggestion for > improvement for your doc. If it has been covered somewhere - sorry for the > duplication. > > In the section on release approval. You state: > > "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." > > For me the most important part of voting +1 is that the individual is > asserting that they have reviewed the source for compliance with ASF > policies. You have this in the last sentence as "verifying that the package > meets the requirements of the ASF policy on releases". However, it almost > feels like an afterthought rather than the most important part. I would > move this to the front of the paragraph and possibly even add "including, > but not limited to, verifying license files, notice file, ... as described > below." > > My concern is that because all of the initial steps in your current > version can be automated it can be argued they are unnecessary. However, > verifying the notice files, license files, upstream dependency licenses > etc. cannot be reliably automated. Hence we need 3 +1's to indicate that at > least 3 people have verified these items and thus the ASF can demonstrate > that to the best of the foundations knowledge the release is legally sound. > If it can be shown that people voting +1 did not perform these checks then > the foundations position is weakened, whereas not building on a local > machine is far less damaging from a legal perspective. > > I would even consider making the part about meeting the requirements of > the ASF policy a MUST and the other items a SHOULD. > > Ross > > > > > > > > On 22 May 2014 11: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. >> >> The current FAQ-style formulation is verbose, lacks crisp boundaries, >> and is prone to policy creep as new "questions" calcify into >> requirements over time. Its ambiguities impose a burdensome "tax" on >> volunteer resources that must be paid every time someone attempts to >> understand, explain, comply with or enforce it. As the ASF continues to >> expand and more of our projects and contributors live at a distance from >> the Membership core where policy is forged, clarified policy >> documentation is key to the sustainability of the Foundation's culture. >> >> A draft of the proposed policy is included below; your comments are >> solicited. The draft was created by selecting excerpts from the >> present policy at and then >> revising; the revision history can be viewed at >> . >> >> In the proposal's current form, the FAQs which compose the existing >> policy are not removed, but are instead "demoted" by dividing the page >> into two parts: "Release Policy" and "Release FAQ". Should we arrive at >> an acceptable draft policy, the next step before publication will be to >> adapt the FAQ to eliminate redundancies. >> >> Please note that the goal of this initiative is only to clarify policy, >> NOT TO CHANGE IT. The proposal's more direct language may well reveal >> aspects of our policy which ought to be changed, but if the >> scope of this discussion expands to what release policy *should be* >> instead of remaining limited to what release policy *is*, our task will >> be made much more difficult. >> >> Marvin Humphrey >> >> ---------------- >> >> # 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. >> >> 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. >> >> 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. >> >> ## 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. >> >> ### 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. >> >> ### 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) >> >> ---------------- >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org >> For additional commands, e-mail: legal-discuss-help@apache.org >> >> > --089e0115ec0818142a04fa23f981 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Being that the purpose of this thread was to seek clarity I = won't apologize for politely seeking that. >=3D|

Mark: thank you for your lucid descriptions of what the *act= ual* reasoning for this policy is: a final check of the SRC for legal compl= iance. This is, in my opinion, the most important responsibility for commit= rights. I am concerned the VOTE assumes this daily role of committer is be= ing ignored (to ensure legal compliance) and therefore feel the VOTE is a S= HOULD as it is added precaution and, in my view, encouraging a sloppy and i= rresponsible committership.

On May 24, 2014 2:22 AM, "Ross Gardler"= ; <rgardler@opendirective.= com> wrote:
Mark, first of all thank you for delivering on your p= romise at ApacheCon :-D

Secondly, apologies if my = comment has already been covered. The thread seems to have got bogged down = in a repeat of past arguments rather than an effort to improve the policy a= round those arguments. With my comment I'm trying to avoid that argumen= t and instead provide a concrete suggestion for improvement for your doc. I= f it has been covered somewhere - sorry for the duplication.

In the section on=C2=A0release approval. You state:

"Before casting +1 binding votes, individuals ar= e required
to download the signed source code package onto their own ha= rdware, compile it
as provided, and test the resulting executable on their own platform, alon= g
with also validating cryptographic signatures and verifying that the = package
meets the requirements of the ASF policy on releases."

For me the most important part of voting +1 is that the= individual is asserting that they=C2=A0have reviewed the source for compli= ance with ASF policies. You have this in the last sentence as "verifyi= ng that the package meets the requirements of the ASF policy on releases&qu= ot;. However, it almost feels like an afterthought rather than the most imp= ortant part. I would move this to the front of the paragraph and possibly e= ven add "including, but not limited to, verifying license files, notic= e file, ... as described below."

My concern is that because=C2=A0all of the initial step= s in your current version can be automated=C2=A0it can be argued=C2=A0they = are=C2=A0unnecessary. However, verifying the notice files, license files, u= pstream dependency licenses etc. cannot be reliably automated. Hence we nee= d=C2=A03 +1's to indicate that at least 3 people have verified these it= ems and thus the ASF can demonstrate that to the best of the foundations kn= owledge the release is legally sound. If it can be shown that people voting= +1 did not perform these checks then the foundations position is weakened,= whereas not building on a local machine is far less damaging from a legal = perspective.

I would even consider making the part about meeting the= requirements of the ASF policy a MUST and the other items a SHOULD.
<= div>
Ross


=C2=A0
=C2= =A0
=C2=A0


On 22 May 2014 11:42, Marvin Humphrey <marvin@rectangular.com> 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.

The current FAQ-style formulation is verbose, lacks crisp boundaries,
and is prone to policy creep as new "questions" calcify into
requirements over time. =C2=A0Its ambiguities impose a burdensome "tax= " on
volunteer resources that must be paid every time someone attempts to
understand, explain, comply with or enforce it. =C2=A0As the ASF continues = to
expand and more of our projects and contributors live at a distance from the Membership core where policy is forged, clarified policy
documentation is key to the sustainability of the Foundation's culture.=

A draft of the proposed policy is included below; your comments are
solicited. =C2=A0The draft was created by selecting excerpts from the
present policy at <http://www.apache.org/dev/release.html> and then
revising; the revision history can be viewed at
<htt= ps://github.com/rectang/asfrelease>.

In the proposal's current form, the FAQs which compose the existing
policy are not removed, but are instead "demoted" by dividing the= page
into two parts: "Release Policy" and "Release FAQ". =C2= =A0Should we arrive at
an acceptable draft policy, the next step before publication will be to
adapt the FAQ to eliminate redundancies.

Please note that the goal of this initiative is only to clarify policy,
NOT TO CHANGE IT. =C2=A0The proposal's more direct language may well re= veal
aspects of our policy which ought to be changed, but if the
scope of this discussion expands to what release policy *should be*
instead of remaining limited to what release policy *is*, our task will
be made much more difficult.

Marvin Humphrey

----------------

# Release Policy # {#policy}

## Definition of "release" ## {#release-definition}

Generically, a release is anything that is published beyond the group
that owns it. =C2=A0For an Apache project, that means any publication outsi= de the
developer community, defined as the subscribers to the product dev list.
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. =C2=A0Releases 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 packag= e
meets the requirements of the ASF policy on releases.

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<= br> 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<= br> (or searching its archives) and thus aware of the conditions placed on the<= br> package.

## 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.

### Release signing ### {#release-signing}

All supplied packages MUST be cryptographically signed by the Release
Manager with a detached signature. =C2=A0Folks who vote +1
for release MAY offer their own cryptographic signature to be concatenated<= br> with the detached signature file (at the Release Manager's discretion)<= br> prior to release.

### Compiled packages ### {#compiled-packages}

The Apache Software Foundation produces open source software. All releases<= br> 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 buil= d a
compiled version of the source, binary/bytecode packages MAY be distributed=
alongside official Apache releases. =C2=A0In 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. =C2=A0In particular, every artifact distribute= d 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 accoun= t
for the package's exact content. =C2=A0`LICENSE` and `NOTICE` MUST NOT = provide
unnecessary information about materials which are not bundled in the packag= e,
such as separately downloaded dependencies.

For source packages, `LICENSE` and `NOTICE` MUST be located at the root of = the
distribution. =C2=A0For 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. =C2=A0The component license itself MUST either be appended or else st= ored
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 lice= nse
header](http://www.apache.org/legal/src-headers.html#headers).<= br>
## Release Distribution ## {#release-distribution}

Once a release is approved, all artifacts MUST be uploaded to the project&#= 39;s
subdirectory within the canonical Apache distribution channel,
`www.apache.org/di= st`.

The PMC is responsible for the project distribution directory and MUST be a= ble
to account for its entire contents. =C2=A0All artifacts within the director= y MUST
be signed by a committer, preferably a PMC member.

After uploading to the canonical distribution channel, the project (or anyo= ne
else) MAY redistribute the artifacts in accordance with their licensing
through other channels.

### 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:=

* =C2=A0 _ASF Licensing Policy_ (curated by Legal Affairs, applies to both = released
=C2=A0 =C2=A0 and unreleased code)
* =C2=A0 _ASF Release Distribution Policy_ (curated by Infrastructure)

----------------

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


--089e0115ec0818142a04fa23f981--