www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacques Le Roux <jacques.le.r...@les7arts.com>
Subject Re: Continuous release review
Date Fri, 30 May 2014 14:23:30 GMT
Le 30/05/2014 16:01, Stephen Connolly a écrit :
> hit send too early...
>
>
> On 30 May 2014 14:52, Stephen Connolly <stephen.alan.connolly@gmail.com <mailto:stephen.alan.connolly@gmail.com>>
wrote:
>
>     Well I have not seen anyone address my specific point with regard to separating the
concerns w.r.t. voting.
>
>     We vote on releases for legal and social reasons.
>
>     The legal reasons mandate that we need to download the archive and verify that it
is something we can legally ship. There are a set of criteria
>     with regards to shipping. Some of these criteria are things like:
>
>     * Does it include the LICENSE an NOTICE files
>     * All the source code of the project must be covered by the Apache License, version
2.0.
>     * The license must be included in each source file.
>     * Has the code been contributed by an individual covered by an appropriate contributor
license agreement, or have otherwise been licensed to the
>     Foundation and passed through IP clearance.
>     * Are bundled 3rd party dependencies compatible with the Apache License, version
2.0.
>
>     The social reasons pressure us to download the archive and check that it builds and
check that any included tests pass and check some relevant
>     smoke tests.
>
>     From my PoV - as a PMC chair [1] - the legal requirements are what matter to most
to me, as I am responsible for compliance with the legal
>     requirements...
>
>     The social requirements are something that can and should be easily replaced by a
CI system.
>
> The final question is then how thorough do we have to be in checking the legal stuff.
>
> So let's take the bits that we know
> * Does it include the LICENSE an NOTICE files
>
> RAT will check this... so simple and quick (if there is a RAT configuration in the project)
>
> * All the source code of the project must be covered by the Apache License, version 2.0.
>

We can't rely safely only on RAT (as least as it is now) for that, for instance too much false
positive in my experience

> RAT will check this... so simple and quick (if there is a RAT configuration in the project)
>
> * The license must be included in each source file.
>
> RAT will check this... so simple and quick (if there is a RAT configuration in the project)

Idem, not enough (or I don't know enough about RAT configuration and how to maintain it in
time)

Jacques

>
> * Has the code been contributed by an individual covered by an appropriate contributor
license agreement, or have otherwise been licensed to the 
> Foundation and passed through IP clearance.
>
> Here things get wooly. If all the files came via source control and the commited-by info
is ASF committers then I can safely assume that the code 
> has been "contributed by an individual covered by an appropriate contributor license
agreement" *but* for big commits I don't know if those 
> committers were sticking to the rules or just committing a big pull request / patch submitted
without the required IP clearance.
>
> If I have been watching the commits list, I should have a handle on these things... but
can everyone honestly say they have never just wiped their 
> inbox clean when they got back from a 2 week vacation?
>
> Also if we are being strict in the legal sense, it's not just the commits since the last
release... its the code since the start of time.
>
> It is this check that I likened to the QA of a batch of toys...
>
> * Are bundled 3rd party dependencies compatible with the Apache License, version 2.0.
>
> Should be easy to check in those cases where you cannot automate... the 3rd party dependencies
should be small in number and not subject to major 
> deltas from the last release
>
>
>     [1]: http://www.apache.org/dev/release-publishing.html says
>         The PMC in general, and the PMC chair in particular (as an officer of the Foundation)
is responsible for compliance with requirements.
>
>
>     On 30 May 2014 14:25, Jim Jagielski <jim@jagunet.com <mailto:jim@jagunet.com>>
wrote:
>
>         Who says that we can't... in fact, we should. We should
>         use technology as much as we can. But CI does not
>         remove the need for reviewing/vetting/verifying
>         the release as we do (and should).
>
>         It appears to me that many people are arguing that
>         the existance of CI obliviates the need to perform
>         the release process (eg: 3 +1s, 72 hour wait, etc)...
>         That is the issue we are trying to clear up.
>
>         On Fri, May 30, 2014 at 03:04:17PM +0200, Jacques Le Roux wrote:
>         > I'm curious, why not having both?
>         >
>         > 1) A CI tool to ease things
>         > 2) To continue to review releases as it's done now
>         >
>         > Jacques
>         >
>         > Le 30/05/2014 14:22, Jim Jagielski a ?crit :
>         > >The Board expects the PMC to do its job, and the
>         > >Board expects the PMC Chair to do his/her job.
>         > >
>         > >If they don't, the board acts; and, as has been said
>         > >many times, the board is not a surgical scalpel; it
>         > >is a hammer.
>         > >
>         > >On May 30, 2014, at 8:09 AM, Emmanuel L?charny <elecharny@gmail.com
<mailto:elecharny@gmail.com>> wrote:
>         > >
>         > >>Le 29/05/2014 17:47, Jim Jagielski a ?crit :
>         > >>>On May 29, 2014, at 11:28 AM, Emmanuel L?charny <elecharny@gmail.com
<mailto:elecharny@gmail.com>>
>         > >>>wrote:
>         > >>>
>         > >>>>Le 29/05/2014 15:56, Jim Jagielski a ?crit :
>         > >>>>>I disagree. And until the policy is changed, PMCs and
>         > >>>>>RMs are expected and *required* to comply.
>         > >>>>Yes, but actually, most f the PMCs and RMs *aren't* Like
it or not.
>         > >>>>
>         > >>>>...
>         > >>>>And, yes, it's probably a good idea to fix the policy if
it can't be
>         > >>>>enforced.
>         > >>>>
>         > >>>To be clear: If it is found out that there are "releases" out
>         > >>>there that really aren't releases, the board will tell the
>         > >>>PMC to:
>         > >>>
>         > >>>  1: Remove those releases immediately.
>         > >>>  2: Re-release those "releases" as real releases
>         > >>>     by complying w/ the release policy (basically,
>         > >>>     taking those "releases" and doing the required
>         > >>>     vetting and voting).
>         > >>>
>         > >>>The board can, and will, also remove a PMCs ability
>         > >>>to "release" stuff if it refuses to comply with the
>         > >>>release policy. So it can be enforced. It is being
>         > >>>enforced. It will be enforced.
>         > >>This is not an enforcement. This is a punishment. And it's totally
vain.
>         > >>
>         > >>Unless the board is ready to check all the releases for all the
151
>         > >>projects, and verify that *every* PMC member is eventually going
through
>         > >>the whole process, this is just a void statement.
>         > >>
>         > >>Btw, just tell me how you are going to control that ? I'm curious...
>         > >>OTOH, we van make it easier for the PMC members to cast a vote,
by
>         > >>verifying the output of a documented/replayable process, which will
take
>         > >>a few minutes instead of hours in some cases. How possibly can someone
>         > >>object that it would be a progress ?
>         > >>
>         > >>
>         > >>
>         > >>---------------------------------------------------------------------
>         > >>To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org <mailto:legal-discuss-unsubscribe@apache.org>
>         > >>For additional commands, e-mail: legal-discuss-help@apache.org <mailto:legal-discuss-help@apache.org>
>         > >
>         > >---------------------------------------------------------------------
>         > >To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org <mailto:legal-discuss-unsubscribe@apache.org>
>         > >For additional commands, e-mail: legal-discuss-help@apache.org <mailto:legal-discuss-help@apache.org>
>         > >
>         > >
>         > >
>         >
>         > --
>         >
>         > ---------------------------------------------------------------------
>         > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org <mailto:legal-discuss-unsubscribe@apache.org>
>         > For additional commands, e-mail: legal-discuss-help@apache.org <mailto:legal-discuss-help@apache.org>
>
>         --
>         ===========================================================================
>            Jim Jagielski   [|]   jim@jaguNET.com [|] http://www.jaguNET.com/
>                 "Great is the guilt of an unnecessary war"  ~ John Adams
>
>
>

-- 


Mime
View raw message