www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hen <bay...@apache.org>
Subject Re: Podling releases and ASF policy
Date Fri, 14 Jun 2019 07:25:12 GMT
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.

On Thu, Jun 13, 2019 at 9:06 PM Justin Mclean <justin@classsoftware.com>

> Hi,
> As requested by Roman, bringing this here. There's been a lot said in
> other threads on the IPMC so I'll attempt to summarise.
> Here the list of things that have traditionally has caused -1 vote on
> podling releases by the IPMC:


Release Blocker

> - Missing DISCLAIMER  : HY(Basic statement)
- Missing LICENSE   : HY(Apache 2.0 text)
- Missing NOTICE    : HY(Apache text)

- Includes content that they don’t have permission to distribute (copyright
> issue)


> - Missing 3rd party bundled code licenses listed in LICENSE

Or Missing 3rd party items in NOTICE. Both of these would be fine if they
are otherwise included somewhere else in the overall codebase. For example
there may be a link to a license rather than a local copy.

Fixable outside the release per Justin:

> - Missing KEYS file [1]
> - Distribution not incorrect dist directory [1]
> - Invalid signatures and checksums    (HY: Wouldn't this be fixable?)
> - Missing checksums [1]

Okay for one release:

> - Missing ASF headers
> - Included compile code (which is Category A)
- 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:

> - Included compile code (which is Category X)
- Includes Category X source code (or other files)

- Has Category X dependencies


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

> - Includes uncategorised source code [2]
> - Has uncategorised dependencies [2]

Agreed. Figure out the license situation.

> 1. Can be fixed right away without having to re-vote so not an issue
> 2. Depends on the license of included code/dependencies
> 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. 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.
> These are things the IPMC usually allows in podling releases, which don't
> follow ASF policy:
> - Missing some Category A licenses in LICENSE
> - Not complying with terms of  Category A 3rd party licenses (usually
> missing the license text)
> - Extra information in NOTICE or LICENSE
> - Malformed NOTICE
> - A few ASF headers missing or incorrect headers on files

For me the first two items would be a judgement call on whether this was
natural usage or not. For example if we put the source code for said
project in and it lacked a license file or source headers (but was clearly
under a Cat A license), I don't feel very bad. If we removed their source
headers or license file, then I feel very bad and would want to block the

As a principle: We shouldn't block our release to fix someone else's
project's license formatting.

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

> 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?
I think there's a lot of judgement call to be had; and we should create
some guidelines on those judgement calls.


View raw message