incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hen <bay...@apache.org>
Subject Re: [IMPORTANT] Board proposal on podling releases
Date Thu, 13 Jun 2019 16:28:21 GMT
On Thu, Jun 13, 2019 at 02:53 Justin Mclean <justin@classsoftware.com>
wrote:

> HI,
>
> > I think that serious = release blocker;
>
> That would also be my meaning. People / podlings have requested that
> release blockers be allowed in podling releases.
>
> > I'd love to hear some examples. I suspect they are all legal.
>
> Sure some recent examples (without mentioning any pooling name, but I can
> supply links if you want):
> - Including code license under a category B license


Boring imo. You have to try hard to screw up Cat B (though I’ve seen it
done).


> - Including code under an unknown license


Case by case.  Many would be (temporarily) okay imo under a “well it’s
clearly published for folk to use”.


> - including code under a permissive license, which required you to include
> the copyright and license text, but not including that text anywhere
> (LICENSE file or file header)


Put it on website/release announcements.

That partly argues to the disclaimer being partially I dependent of the
release


>
> The last one is probably the most common, especially with Javascript when
> license headers seem to be optional.


IMO those projects are inducing users to not comply by failing to
self-attribute.

Any project including jQuery or Bootstrap immediately encounters this as
> they have embedded 3rd party code without license headers.
>
> We’ve allowed all of these situations, although I can also point to
> Category B inclusions where we have not allowed them.
>
> We’ve also allowed GPL dependancy and I think GPL inclusion (would need to
> check) with VP legal/VP incubator OK on a once off basis a while back. The
> provision being that it was fixed next release.
>
> All of those would be against the terms of the license, which I assume you
> mean by legal? Or do you mean something else by that term?


I mean clearly against the terms and intention. i.e. I’m less cut up if a
3rd party project did a crap job of their attribution such that we had to
fix their problems in obeying their license. GPL, MPL can happily be
included; it breaks our policy not their license.


>
> > I'd definitely like to see change. My feeling is that there's a lot we
> can
> > make that falls comfortably within the scope of the Incubator PMC.
>
> As Roman also suggested, we should discuss this with the legal committee
> and come up with a list to give podlings clearer guidance.
>
> > IIRC the release policies came out of the Incubator; I don't recall
> there being a
> > request for the board to ratify them, but I might be failing to remember
> > something a decade+ ago :)
>
> From several discussion it been made clear that we don’t own them, the
> board does. Interesting enough this say legal affairs does [1] when we’ve
> also been told they don’t. :-) In some cases there's been a nice triangle,
> where legal, infra and the board all say it someone else responsibility but
> not the incubators :-)


I’ll agree on that :) personally I speculate that the incubator went
over-bureaucracy on the topic a decade ago and there was a unofficial
“slowdown” push back that should have been more clearly owned.


>
> > By that are you suggesting that the text implies a guarantee that those
> are
> > the only issues?
>
>  Issues can be found in the IPMC vote not the podling vote, so some of
> these serious issues won’t be listed in the disclaimer when the IPMC votes
> on it.
>

We should decouple (a copy of) the disclaimer. Put it next you KEYS
perhaps. Our desire for atomic artifacts causes a lot of our pain.


> Thanks,
> Justin
>
> 1. http://www.apache.org/legal/release-policy.html#administration
>
>
> ---------------------------------------------------------------------
> 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