www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Continuous release review
Date Fri, 30 May 2014 14:19:44 GMT
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.

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

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

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

>>
>>
>> [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
>>
>>
>

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


Mime
View raw message