www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig Russell <apache....@gmail.com>
Subject Re: Podling releases and ASF policy
Date Fri, 21 Jun 2019 23:59:31 GMT
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
> - 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)
> - 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


Mime
View raw message