www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: Release Policy
Date Sat, 24 May 2014 11:51:56 GMT
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
On May 24, 2014 2:22 AM, "Ross Gardler" <rgardler@opendirective.com> 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 <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.  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 <http://www.apache.org/dev/release.html> and then
>> revising; the revision history can be viewed at
>> <https://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".  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
>> 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
>> 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` <http://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
>> 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

View raw message