www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: Continuous release review
Date Fri, 30 May 2014 14:27:04 GMT
On 30 May 2014 15:19, sebb <sebbaz@gmail.com> wrote:

> On 30 May 2014 15:01, Stephen Connolly <stephen.alan.connolly@gmail.com>
> wrote:
> > hit send too early...
> >
> >
> > On 30 May 2014 14:52, Stephen Connolly <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)
>
> AFAIK RAT does not check this.
> And it does not check that the NOTICE and LICENSE files agree with the
> included dependencies.
> Since it works on the source files, the most it can check is that the
> files exist.
> It cannot check for dependencies bundled with the binary (or source!)
> archive.
> I don't see how it can check the attributions in the NOTICE file
> (apart from the ones require for each project), nor can it check the
> contents of the LICENSE file apart from ensuring that the ALv2 is
> there at the start.
>

Well we always have you to do random spot checks that we reserve the right
to disagree with ;-)


>
> > * All the source code of the project must be covered by the Apache
> License,
> > version 2.0.
> >
> > RAT will check this... so simple and quick (if there is a RAT
> configuration
> > in the project)
>
> There is no way that RAT can check this.
> All RAT can do is check that it has the appropriate header; it cannot
> check if the header actually applies to the file.
>

Well the second question is a separate issue, i.e. my 4th point. If my 4th
point is addressed you can assume that the presence of the header implies
the code is covered.


>
> > * 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)
>
> RAT does check this, but the config can easily be set to exclude certain
> files.
>
> > * 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
>
> Some projects ship lots of dependencies.
> It can be a big job assessing them first time round.
> It's not always obvious what the 3rd party license is, and then one
> has to determine what the ASF classification for that license is.
> That is not always immediately obvious either.
>

I agree that this is a pain for some the first time around... but once you
have got over that pain it should be deltas only.


>
> The dependencies also need to be manually checked with every update
> because licenses can change between versions.
>

Yep... My point was that you should be able to easily check them. I did not
suggest a manual check for this point. I suggested checking them via a
delta 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> 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
> >
> >>> > > 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>
> >>> > >>>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
> >>> > >>For additional commands, e-mail: legal-discuss-help@apache.org
> >>> > >
> >>> >
> >---------------------------------------------------------------------
> >>> > >To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> >>> > >For additional commands, e-mail: legal-discuss-help@apache.org
> >>> > >
> >>> > >
> >>> > >
> >>> >
> >>> > --
> >>> >
> >>> > ---------------------------------------------------------------------
> >>> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> >>> > For additional commands, e-mail: 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