On Thu, Jun 13, 2019 at 02:53 Justin Mclean <jus...@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-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
