incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davor Bonaci <da...@apache.org>
Subject Re: [IMPORTANT] Board proposal on podling releases
Date Sat, 08 Jun 2019 19:19:50 GMT
I think my position is well-known, but I'll restate it for completeness:

(1) Podling releases are foundation releases; no exceptions. They are
distributed in the same way, adopted by a foundation PMC in the same
manner, and they being with word "Apache". We are responsible for them.
(2) IPMC desires to foster learning and iterative improvement. We want to
be lenient with releases, and waive various *ASF policies* as deemed in the
best interest of the podling and the foundation.
(3) IPMC does not have authority to waive any legal requirements (like
someone's license) or policies of others (like someone's trademark policy).
If such an issue in a release *against a third party* is discovered, even
if minor, the IPMC should block such a release unconditionally. Note that
accidental and unintentional omission is fine, but known and willful is not.
(4) Given the above, it would be beneficial for the IPMC if the Board would
explicitly confirm IPMC's discretionary authority in waiving ASF release
and distribution policy.

I feel less strongly about:
(5) IPMC doesn't need to specify what is "may", "should", or "must" too
precisely. The precision above is good enough. In fact, "best interests"
doesn't mean "equality". Even if two releases suffer from the same issue,
it may be fine for a podling in early stages, but be blocked for a podling
where they have a regression compared to a previous release. "Committee
discretion" is much better than "rules". No new rules please.

On Sat, Jun 8, 2019 at 9:31 AM Julian Hyde <jhyde.apache@gmail.com> wrote:

> We’re trying to nail down the definition of “serious”.  May I suggest that
> we divide the guidelines into MAY, SHOULD and MUST. Anything with MUST is
> mandatory for all podling releases.
>
> The list may or may not be the same as for TLP releases.
>
> Julian
>
>
>
> Sent from my iPad
> > On Jun 7, 2019, at 5:56 PM, Justin Mclean <justin@classsoftware.com>
> wrote:
> >
> > Hi,
> >
> >> 1) Is it legal to include GPL licensed software in releases?  The
> >> answer is yes... as long as we comply with the terms of that license.
> >> In the case of strong copyleft licenses, that could mean that the
> >> podling release itself may need also be GPL licensed.
> >
> > And in cases where this has happened, it’s been ALv2 licensed, so I
> guess that wouldn’t be legal. But we also allow minor stuff like this a lot
> of the time e.g forgetting to add  MIT license text to LICENSE.
> >
> >> 2) Is it legal to include compiled code in releases?  Yes.
> >
> > But certainly against ASF policy and one of it core values.
> >
> >> 3) Is it legal to include copyright violations in releases?  No.
> >
> > In most cases, where this has occurred this has been minor, like
> including a cat photo, and can be easily sorted by removing or asking for
> permission. If someone did come along as say you don’t have permission to
> do that, we’d say we were very sorry and fix it.
> >
> > Perhaps rewording the proposal to say "serious issue typically found in
> podling releases” would help? Podlings generally make some effort to try
> and get things right.
> >
> > Thanks,
> > Justin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message