blah blah "legal risk" blah blah. Really. Let's step back and consider what we're talking about. A podling making a release as they learn the ropes of Apache-style governance. With a disclaimer.
"OMG! There is GPL code in there!" ... no legal risk. We only care about GPL from a policy standpoint. Let it through. "OMG! No NOTICE file!" ... well, easy to fix, unlike a GPL dependency. Maybe stop the release, but there isn't any "legal risk" so maybe just write a Jira ticket and move on. Copyrights, IP, and licensing are not magically thrown out the window if a file is not present. All of that is inherent, and a NOTICE file merely helps to surface IP issues, rather than specify. And just what is this "legal risk" term that people are throwing about? Please define, before use. -g On Fri, Jun 7, 2019 at 1:00 PM Craig Russell <apache....@gmail.com> wrote: > Hi Justin, > > As a board member, I'm not comfortable with granting a blanket exception > to policy that might put us at legal risk. > > As an IPMC member, I think that we do not want to allow podlings to > release material that might put us at legal risk. I do think that the IPMC > under today's policy has the ability to decide whether a podling release > puts us at risk and therefore should be blocked. So I am not convinced that > the IPMC needs to ask for this waiver from the board. > > My understanding as an IPMC member is that there are some items in a > release that can be allowed where they would not be in a TLP release. > These things have historically drawn -1 votes from IPMC members. > > I think there is consensus that a podling release does not have to conform > in every respect to what we expect from a TLP release. > > I think that the incubator IPMC should first flesh out (on the general@ > list) which materials in a podling release are > a) fine; > b) minor issue (file a JIRA and fix before graduation); or > c) blocker (puts the foundation at risk). > > The detail of what is minor versus what it a blocker is the most important > thing that needs clarity. As of now, I don't see consensus although I see > movement. > > Craig > > > > On Jun 6, 2019, at 11:45 PM, Justin Mclean <jus...@classsoftware.com> > wrote: > > > > Hi, > > > > As suggested I’ve collated information from several threads and turned > it into a proposal for the board. Any edits, feedback, agreement, > disagreement etc etc is welcome. In particular it would be nice to hear > some feedback from people who are in favour of this. > > > > Note that this is important as it probably changes the advice mentors > will give their podlings on releases and change in a positive way how we > vote on releases with serious issues in them. If you are a mentor or vote > on releases please read it. Again feedback welcome. > > > > If the board agrees with the proposal I think we'll need to update the > incubator DISCLAIMER. I’ve suggested what we might add in the proposal but > the exact changes can to be discussed here. If the board disagrees with the > proposal I suggest we discuss and come up with a list of serious issues > that the IPMC recommends voting -1 vote on a release. This is just > guidance, not rules, and there may of course be exceptions. (For instance > you could ask VP legal for an exception as has been done in the past.) > That way mentors and podlings have clear expectations on releases must > contain. > > > > The proposal can be found in the draft board report. [1] > > > > Thanks, > > Justin > > > > 1. https://cwiki.apache.org/confluence/display/INCUBATOR/June2019 > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > Craig L Russell > c...@apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
