www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roman Shaposhnik <ro...@shaposhnik.org>
Subject Re: Podling releases and ASF policy
Date Sun, 23 Jun 2019 23:17:55 GMT
Before I comments on this thread, I must point everybody to the thread
that's going on over on general@incubator:
     https://lists.apache.org/thread.html/1a4c137100e76bedd3ed202874c8b8e306c8990a439938d70b64ad54@%3Cgeneral.incubator.apache.org%3E

With my VP Legal hat on (and with my Incubator IPMC hat off) the only
way I can interpret that thread is this: IPMC
is trying to come up with *business* decision on whether Incubator
*itself* is a bonafide TLP producing multiple
unrelated artifacts (not unheard of at ASF since something like Apache
Commands does exactly that) or it is
a special construct within the foundation.

As a VP Legal I have no opinion one way or the other, but I must say
that if the business decision is to treat it as
a TPL when it comes to releases -- the rest of this discussion is
moot: we can NOT allow any relaxation of
the ASF release policy for a TLP.

So I'll proceed commenting on the assumption that the business
decision will lean towards treating Incubator
as a special construct within the Foundation.

On Fri, Jun 21, 2019 at 4:59 PM Craig Russell <apache.clr@gmail.com> wrote:
>
> Hi Justin,
>
> I took an action item from this week's board meeting to work with Roman and the IPMC
to get clarity on the expectations of the board and legal for incubator releases.
>
> I'm not sure that email is the best way to deal with this, but I'll reformat and re-post
your earlier message in hopes that we can work on one list.
>
> Blocker: Must be fixed and then revote:
> > - Missing DISCLAIMER
> > - Missing LICENSE
> > - Missing NOTICE
> > - 3rd party Category X or Category B bundled code licenses not listed in LICENSE

I would also add to it a new requirement of listing that bundled code
in DISCLAIMER.
In addition to that, if there are binaries bundled in the release the
origin of those binaries
also need to be DISCLAIMEd.

> > - Missing both checksums and signatures[0]
> > - Invalid/missing both checksums and signatures [0]
>
> Blocker: Must be fixed and then release:
> > - Missing KEYS file [1]
> > - Distribution not in the correct dist directory [1]
> > - Invalid/missing signatures as long as checksum is ok [1]
> > - Invalid/missing checksum as long as signature is ok [1]
> > - SHA1 or MD5 checksum instead of SHA256 or SHA512 [1]
>
> Issue: Release then file a JIRA to fix before next release
> > - Missing ASF headers
> > - ASF headers missing or incorrect headers on files
> > - 3rd party Category A bundled code licenses not listed in LICENSE
> > - Included compiled code (which is Category A)
> > - Included compiled code (which is Category B/X) [3]
> > - Includes uncategorised source code [2]
>
> Minor Issue: Release then file a JIRA to fix before graduation
> > - Includes Category X source code (or other files) [3]
> > - Includes Category B source code (which makes it Category X) [3]
> > - Includes content that they don’t have permission to distribute (copyright issue)

This will have to be explained and under some conditions it may end up
being a blocker.

> > - Has Category X dependencies
> > - Has uncategorised dependencies [2]
> > - Extra information in NOTICE or LICENSE
> > - Malformed NOTICE
>
> > [0] Without a proper checksum, no guarantee what was voted on.
> > [1] Can be fixed right away without having to re-vote so not an issue
> > [2] Depends on the license of included code/dependencies
> > [3] Must be properly documented in LICENSE
> >
> Earlier comments from Hen:
> > One premise that I think is assumed, but could do with stating, is that no item
should be included in a release if it was previously highlighted as a non-blocking issue in
a previous release. I'm sure there are exceptional items, but I expect them to be rare.
>  clr: some features of existing code might need several releases to completely get rid
of issues
>
> >> - Included compile code (which is Category B)
>
> > These would depend on the license and situation; I would worry about whether the
license allows it to be included in the release, whether it would cause a typical user an
unpleasant surprise, and whether it would affect the licensing of the core product
> clr: as long as the code has its license in the LICENSE these can be resolved later
>
> >> - Includes Category B source code (which makes it Category X)
>
> > Cat B source code is a scenario that, while it's not Cat A or B (thus I see your
point about Cat X), I think it would usually be safe. Again I wonder if it is causing a typical
user an unpleasant surprise and whether it affects the licensing of the core product (typically
unlikely). If we are able to highlight the issue outside of the release (release notes for
example), then I think the inclusion can be mitigated for users.
> clr: as long as the code has its license in the LICENSE these can be resolved later
>
> >> There's a thread on the IPMC general list to improve the DISCLAIMER (text to
be decided) to make it clear that podling releases content may not be fully compliant with
ASF policies. It also expected that podling documents any issues found so people are aware
of them and that they can be tracked and fixed before graduation.
> >> Note this would only apply to podling releases, not TLP ones. By the time a
podling graduated, their releases will follow all ASF policy.
> > I don't see why we wouldn't treat TLP and Podlings the same.
> clr: podlings releases need to be given additional time to resolve all the issues; TLPs
have had plenty of time
>
> > Except for some people, who think that most things should be allowed, there seems
to be general agreement in the IPMC on this list, except for allowing compiled code or having
a category X dependency in a podling release.
> clr: this statement is a bit ambiguous
>
> > Votes on releases on the IPMC general list also confirm this. Some people have expressed
the view that as long as it is legal it is allowed, but it unclear if that means full compliance
with 3rd party licenses or not. In a few cases, things from this list have been allowed with
permission from V.P legal / V.P incubator.
> clr: I think we all agree that getting special permission should be a last resort because
by definition it delays a release
> >
> > The incubator wants to be more lenient on podling releases but is wary of not following
ASF policy that it doesn’t set. Does the legal committee have any guidance on what could
be allowed, from the above list in podling releases? Basically what parts of ASF policy can
we safely ignore?
> clr: my proposal is contained in the Issues and Minor Issues above.
>
> Please discuss,
>
> Craig
> >
> > Thanks,
> > Justin
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > For additional commands, e-mail: legal-discuss-help@apache.org
> >
>
> Craig L Russell
> clr@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


Mime
View raw message