Re: [IMPORTANT] Board proposal on podling releases
Hi Greg, I agree. A pragmatic, incremental, trust in a community’s best intentions is all we should ask. To me the minimum requirements are: (1) License is AL v2. (2) Disclaimer is standard. I don’t want it to vary because then we’ll discuss correctness. (3) Signature. (4) Checksum. The rest is up to the podling community to grow more towards policy than away. Treating it as an existential crisis is in conflict with “Community over Code” and turns into a form of “filibustering”. Users who are vested in a podling’s “correctness” and graduation should join and “scratch their itch.” Regards, Dave Sent from my iPhone > On Jun 14, 2019, at 3:48 AM, Greg Stein wrote: > >> On Thu, Jun 13, 2019, 18:57 Justin Mclean wrote: >> >> Hi, >> >>> Boring imo. You have to try hard to screw up Cat B (though I’ve seen it >>> done). >> >> Really? Category B source code is generally not allowed in sources >> releases. It's actually Category X. Category B as image and the like is >> allowed. >> > > And if it appears in a tarball... So what happens? > > Really. Answer that. (licenses for each piece of work get sorted) > > We are getting all twisted up in nonsense. Make some podling releases, and > improve them each time. Nothing more than that . > >> 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. >> >> Well if you include GPL (and this has happened), you need to abide by >> terms of it license, claiming it's ALv2 doesn’t really do that. >> > > So what? Think on it: what is *really* going on? Various bits of code under > different licensed. That is all. > > Whatever mislabel occurs, doesn't change the underlying licenses. So > despite the furor, there isn't a problem. > > We claim ALv2 on the larger work/distribution. We do not override license > claims on pieces within that distro. > > -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [IMPORTANT] Board proposal on podling releases
On Thu, Jun 13, 2019, 18:57 Justin Mclean wrote: > Hi, > > > Boring imo. You have to try hard to screw up Cat B (though I’ve seen it > > done). > > Really? Category B source code is generally not allowed in sources > releases. It's actually Category X. Category B as image and the like is > allowed. > And if it appears in a tarball... So what happens? Really. Answer that. (licenses for each piece of work get sorted) We are getting all twisted up in nonsense. Make some podling releases, and improve them each time. Nothing more than that . > 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. > > Well if you include GPL (and this has happened), you need to abide by > terms of it license, claiming it's ALv2 doesn’t really do that. > So what? Think on it: what is *really* going on? Various bits of code under different licensed. That is all. Whatever mislabel occurs, doesn't change the underlying licenses. So despite the furor, there isn't a problem. We claim ALv2 on the larger work/distribution. We do not override license claims on pieces within that distro. -g
Re: [IMPORTANT] Board proposal on podling releases
Hi, As mentioned in the board report (under actions) and requested by Roman I’ve raised this issue over on legal-discuss. Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [IMPORTANT] Board proposal on podling releases
Hi, > Boring imo. You have to try hard to screw up Cat B (though I’ve seen it > done). Really? Category B source code is generally not allowed in sources releases. It's actually Category X. Category B as image and the like is allowed. > 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. Well if you include GPL (and this has happened), you need to abide by terms of it license, claiming it's ALv2 doesn’t really do that. > 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. I think that’s an interesting idea. Thanks, Justin
Re: [IMPORTANT] Board proposal on podling releases
On Thu, Jun 13, 2019 at 02:53 Justin Mclean 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 > >
Re: [IMPORTANT] Board proposal on podling releases
On Thu, Jun 13, 2019 at 01:15 Greg Stein wrote: > On Thu, Jun 13, 2019, 02:47 Alex Harui wrote: > > > Maybe the next question is: Are all release policy violations > > showstoppers? I suspect the answer is no. And thus, if any TLP can punt > > release policy violations to a future release, > > > What are you talking about? > > Nobody has suggested any modifications to TLP's policy. I hearby suggest we modify TLP policy :) Alex is right. > > > -g > > [deleting entire rest of irrelevant goo] Ever the diplomat ;) > >
Re: [IMPORTANT] Board proposal on podling releases
On Thu, Jun 13, 2019 at 12:09 PM Bertrand Delacretaz wrote: > ...IOW, base those exceptions on a strictly managed list of acceptable > issues... And add the URL of that list to the DISCLAIMER, so users know what to expect. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [IMPORTANT] Board proposal on podling releases
Hi, On Thu, Jun 13, 2019 at 11:53 AM Justin Mclean wrote: > > I think that serious = release blocker; >...People / podlings have requested that release blockers be allowed in >podling releases... Ok, "release blocker" says much more to me than "serious issues" to which I objected as being too vague. I think this can only work backed by a list of issues (each with a unique ID) which are acceptable for podlings, even though they would not be for a TLP. Then, if new issues are discovered that we think fall into that category, add them to the list subject to Incubator PMC approval. IOW, base those exceptions on a strictly managed list of acceptable issues. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [IMPORTANT] Board proposal on podling releases
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 - Including code under an unknown license - 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) The last one is probably the most common, especially with Javascript when license headers seem to be optional. 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'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 :-) > 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. 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
Re: [IMPORTANT] Board proposal on podling releases
On Thu, Jun 13, 2019, 02:47 Alex Harui wrote: > Maybe the next question is: Are all release policy violations > showstoppers? I suspect the answer is no. And thus, if any TLP can punt > release policy violations to a future release, What are you talking about? Nobody has suggested any modifications to TLP's policy. -g [deleting entire rest of irrelevant goo]
Re: [IMPORTANT] Board proposal on podling releases
Maybe the next question is: Are all release policy violations showstoppers? I suspect the answer is no. And thus, if any TLP can punt release policy violations to a future release, then so can podlings, and the IPMC can let more things go without really needing another decision from the board. Or maybe the only question for board or some authority is: Can the IPMC be authorized to allow CatX in podling releases? Ted gave an example in this thread of a legal issue where an attribution required by a dependency's license is missing. I believe I've seen some long-timers say that those are not showstoppers. Nobody is going to sue the ASF over that legal mistake as long as we respond positively towards fixing it in the next release. I also think Ted explained in this thread the "why" behind many release policies more clearly and in fewer words than I recall from incubator documentation when I was in the incubator in 2012. And that might better educate podlings and TLPs on how to make good choices on what can be deferred to a future release. Seems like the only showstoppers for TLPs are: 1) content we have no right to distribute 2) content that distribution would break a law (maybe export restrictions, adult content) 3) CatX content Maybe other legal issues like missing attributions MUST be fixed in the next release. Other release policy violations SHOULD be fixed in the next release. Not sure where to put inclusion of CatB source. Would that also be a showstopper? Podlings would be given flexibility on CatX/CatB, but also have showstoppers for A) missing DISCLAIMER B) missing "-incubating" in the source artifact package name. My 2 cents, -Alex On 6/12/19, 11:44 PM, "Hen" wrote: On Sun, Jun 9, 2019 at 4:11 PM Justin Mclean wrote: > Hi, > > > I agree with other respondents that 'serious' seems bad here. To me the > > serious ones are the only ones they can't release with. > > So we just continue as is then? You have any suggests to what we change? > I don't think we're using the same word meanings. I think that serious = release blocker; but I equally think there are very few items that are serious. > > > ReleaseBlocking: Has a LICENSE. Legally permitted to release and > complies > > with the license via some mechanism. > > We currently allow releases that are not strictly legal. This would be a > step backwards. > > I'd love to hear some examples. I suspect they are all legal. Speculating hypothetically: * We should never make a release that we know there is some content in that we explicitly do not have permission to publish. * We should never make a release that we know contains content that is criminal (for whatever that would mean). Other than that... I'm not sure what else would come under 'all legal' label. > > GraduationBlocking: Everything else; including complying with the > license > > via our preferred mechanism (i.e. we might want the MIT license text in > our > > LICENSE file, but would accept it being in the source header of the files > > themselves). > > We currently allow podlings to graduate with some issues as longs as the > PPMC is dealing with them. This would be a step backwards. > > Yeah. We need a third category for "MehNotBlockingPleaseFix". > > I don't see a need to go to the board on this :) > > If we don’t want to change anything - sure there's no need to go to the > board. > 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. 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 :) > > >> issues have been fixed. The IPMC will add additional information to the > > incubator DISCLAIMER to cover that podling release may not abide by all > > > > The IPMC? That sounds like a people scaling problem. The podling > committee > > should handle it. > > I mean just changing this page [1] , podlings can update their own > disclaimers. > Gotya :) > > > "This release still has the following issues that will need to be > resolved > > before the Foo Project can graduate to an Apache vetted Top Level > Project” > > What about unknown issues? > By that are you suggesting that the text implies a guarantee that those are the only issues? (Otherwise I'm off into philosophy of whether the unknown can exist when the only test makes it known :) ). "The Foo Project have currently identified the following issues that will need to be resolved before the project
Re: [IMPORTANT] Board proposal on podling releases
On Sun, Jun 9, 2019 at 4:11 PM Justin Mclean wrote: > Hi, > > > I agree with other respondents that 'serious' seems bad here. To me the > > serious ones are the only ones they can't release with. > > So we just continue as is then? You have any suggests to what we change? > I don't think we're using the same word meanings. I think that serious = release blocker; but I equally think there are very few items that are serious. > > > ReleaseBlocking: Has a LICENSE. Legally permitted to release and > complies > > with the license via some mechanism. > > We currently allow releases that are not strictly legal. This would be a > step backwards. > > I'd love to hear some examples. I suspect they are all legal. Speculating hypothetically: * We should never make a release that we know there is some content in that we explicitly do not have permission to publish. * We should never make a release that we know contains content that is criminal (for whatever that would mean). Other than that... I'm not sure what else would come under 'all legal' label. > > GraduationBlocking: Everything else; including complying with the > license > > via our preferred mechanism (i.e. we might want the MIT license text in > our > > LICENSE file, but would accept it being in the source header of the files > > themselves). > > We currently allow podlings to graduate with some issues as longs as the > PPMC is dealing with them. This would be a step backwards. > > Yeah. We need a third category for "MehNotBlockingPleaseFix". > > I don't see a need to go to the board on this :) > > If we don’t want to change anything - sure there's no need to go to the > board. > 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. 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 :) > > >> issues have been fixed. The IPMC will add additional information to the > > incubator DISCLAIMER to cover that podling release may not abide by all > > > > The IPMC? That sounds like a people scaling problem. The podling > committee > > should handle it. > > I mean just changing this page [1] , podlings can update their own > disclaimers. > Gotya :) > > > "This release still has the following issues that will need to be > resolved > > before the Foo Project can graduate to an Apache vetted Top Level > Project” > > What about unknown issues? > By that are you suggesting that the text implies a guarantee that those are the only issues? (Otherwise I'm off into philosophy of whether the unknown can exist when the only test makes it known :) ). "The Foo Project have currently identified the following issues that will need to be resolved before the project can graduate to an Apache vetted Top Level Project” Any better? > > Are the board lawyers? :) Until you have a well-defined list, I doubt > > anything could be confirmed. I'd go with: "Conceptually what you > describe > > could lead to a situation where a PPMC releases a project fully compliant > > with the ASF's expectations. “ > > I assume you mean “not fully compliant”? > Nope. I was being defensive in my broad statements. For the given question; sure, someone might manage a perfect release someday :) Hen
Re: [IMPORTANT] Board proposal on podling releases
Hi, Given we didn’t have consensus I’ve removed the proposal [1] and submitted the report to the board.[2] I’ve added further commentary about this thread. Feedback, as always welcome, I’ve tried to give an overview of the situation and actions going forward, but I may of missed something and it may not the the whole picture or how any individual IPMC member see it. Thanks, Justin 1. https://cwiki.apache.org/confluence/display/INCUBATOR/June2019 2. https://whimsy.apache.org/board/agenda/2019-06-19/Incubator - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [IMPORTANT] Board proposal on podling releases
Alex, Many of the apparently minor issues actually bear on the legality and restriction of use issues. For instance, some licenses *require* attribution. Distribution of code with that requirement that has no attribution is not allowed under the license. It may be that a podling would be allowed to squeak out a release or two with a disclaimer that the release might be defective, but it really should be remedied. But I think that the real issue you are highlighting is that there are many ways to comply with the Apache intent. Once upon a time, the Incubator tried to give podlings all the flexibility possible in complying. To do this required that the podlings be educated in a very hazy, somewhat self-contradictory and only vaguely documented philosophy. That proved essentially unworkable. The current Incubator approach is to define one particular way to proceed that fits with the philosophy. This has at least a chance of being documented. But it is important for the IPMC to never forget that it is only one way and variations will probably work almost as well. It is also really important to remember that trying to express that potential flexibility is potentially a disastrous approach in terms of helping projects get to TLP easily and effectively. Even just having long discussions about what can work is likely to cause huge amounts of confusion. On Tue, Jun 11, 2019 at 1:20 PM Alex Harui wrote: > The "legal shield" has been brought up by others as the reason for being > so strict on policy compliance, hence my questions. > > My takeaway from your responses is that the key factors are: > 1) legal right to distribute. > 2) no downstream limitations on field of use. > > which I agree with and see no reason to change it. However, that implies > that other policy compliance issues (missing source headers, > not-quite-right handling of LICENSE and maybe NOTICE) are not showstoppers > and can be addressed in a future release, and that would save time not only > for podlings, but for TLPs as well. > > Then the main decision point for this thread is whether to allow podlings > more slack on #2 given their artifacts are appropriately labelled and > disclaimed. > > Could an incentive be offered to podlings that if their release complies > with both #1 and #2 that they can remove the -incubating label when copying > the artifacts to dist.a.o? > > Thanks, > -Alex > > On 6/10/19, 11:13 AM, "Ted Dunning" wrote: > > The content of a release and the downstream limitations on field of > use are > not a matter of legal shield. It has always been the case that the > fundamental promise of Apache has been that Apache software is easy and > safe to adopt and use. > > Easy and safe meaning that you won't have nasty surprises like somebody > suing you for "being evil" or, worse, having your own lawyers veto a > critical release because a dependency of a dependency is GPL licensed > or is > restricted from being used in anything that competes with smart > plumbing > accessories. > > Getting the foundation to relax that attitude of no downstream > restrictions > is going to be nearly impossible. > > On Sun, Jun 9, 2019 at 10:53 PM Alex Harui > wrote: > > > There's been a lot of discussion on relaxing requirements, but I > don't > > recall any long-time ASF person explaining how fragile or durable the > > legal-shield and the insurance rates for it are. > > > > ... > > > > Unless someone can explain why that would ruin the legal-shield or > raise > > insurance rates, I think that would save lots of community time > getting > > releases out. Otherwise, we might be expending precious energy > > overzealously trying to protect a legal-shield that doesn't need > that level > > of protection. > > > > Does anybody truly know what will and will not ruin the > legal-shield? I > > have to imagine that releases have been shipped by the ASF and later > found > > to be non-compliant with policy and that didn't ruin the legal > shield or > > raise insurance rates. > > > > >
Re: [IMPORTANT] Board proposal on podling releases
Hi, > My takeaway from your responses is that the key factors are: > 1) legal right to distribute. > 2) no downstream limitations on field of use. I think most people have seen saying that are “legal”, that would be more restrictive that what the IPMC currently practices. > which I agree with and see no reason to change it. However, that implies > that other policy compliance issues (missing source headers, not-quite-right > handling of LICENSE and maybe NOTICE) are not showstoppers Well a lot of LICENSE issues fall into above categories. > and can be addressed in a future release, and that would save time not only > for podlings, but for TLPs as well. The incubator has no remit over TLPs, that is a conversation for another list. Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [IMPORTANT] Board proposal on podling releases
The "legal shield" has been brought up by others as the reason for being so strict on policy compliance, hence my questions. My takeaway from your responses is that the key factors are: 1) legal right to distribute. 2) no downstream limitations on field of use. which I agree with and see no reason to change it. However, that implies that other policy compliance issues (missing source headers, not-quite-right handling of LICENSE and maybe NOTICE) are not showstoppers and can be addressed in a future release, and that would save time not only for podlings, but for TLPs as well. Then the main decision point for this thread is whether to allow podlings more slack on #2 given their artifacts are appropriately labelled and disclaimed. Could an incentive be offered to podlings that if their release complies with both #1 and #2 that they can remove the -incubating label when copying the artifacts to dist.a.o? Thanks, -Alex On 6/10/19, 11:13 AM, "Ted Dunning" wrote: The content of a release and the downstream limitations on field of use are not a matter of legal shield. It has always been the case that the fundamental promise of Apache has been that Apache software is easy and safe to adopt and use. Easy and safe meaning that you won't have nasty surprises like somebody suing you for "being evil" or, worse, having your own lawyers veto a critical release because a dependency of a dependency is GPL licensed or is restricted from being used in anything that competes with smart plumbing accessories. Getting the foundation to relax that attitude of no downstream restrictions is going to be nearly impossible. On Sun, Jun 9, 2019 at 10:53 PM Alex Harui wrote: > There's been a lot of discussion on relaxing requirements, but I don't > recall any long-time ASF person explaining how fragile or durable the > legal-shield and the insurance rates for it are. > > ... > > Unless someone can explain why that would ruin the legal-shield or raise > insurance rates, I think that would save lots of community time getting > releases out. Otherwise, we might be expending precious energy > overzealously trying to protect a legal-shield that doesn't need that level > of protection. > > Does anybody truly know what will and will not ruin the legal-shield? I > have to imagine that releases have been shipped by the ASF and later found > to be non-compliant with policy and that didn't ruin the legal shield or > raise insurance rates. >
Re: [IMPORTANT] Board proposal on podling releases
The content of a release and the downstream limitations on field of use are not a matter of legal shield. It has always been the case that the fundamental promise of Apache has been that Apache software is easy and safe to adopt and use. Easy and safe meaning that you won't have nasty surprises like somebody suing you for "being evil" or, worse, having your own lawyers veto a critical release because a dependency of a dependency is GPL licensed or is restricted from being used in anything that competes with smart plumbing accessories. Getting the foundation to relax that attitude of no downstream restrictions is going to be nearly impossible. On Sun, Jun 9, 2019 at 10:53 PM Alex Harui wrote: > There's been a lot of discussion on relaxing requirements, but I don't > recall any long-time ASF person explaining how fragile or durable the > legal-shield and the insurance rates for it are. > > ... > > Unless someone can explain why that would ruin the legal-shield or raise > insurance rates, I think that would save lots of community time getting > releases out. Otherwise, we might be expending precious energy > overzealously trying to protect a legal-shield that doesn't need that level > of protection. > > Does anybody truly know what will and will not ruin the legal-shield? I > have to imagine that releases have been shipped by the ASF and later found > to be non-compliant with policy and that didn't ruin the legal shield or > raise insurance rates. >
Re: [IMPORTANT] Board proposal on podling releases
Agreed... isn't the whole point of the Incubator is to provide not only training and guidance but also a "safe place" where these codlings can learn the ropes, including How To Do A Release? And don't we stress that such podlings are under incubation is to ensure (as much as we can) that those who download and/or use the project are aware that there might be 'issues' with that codebase and that they may not 100% comply with the standards associated w/ 'real' ASF projects? Unless there is an actual *LEGAL* issue w/ assets within the released codebase, such that we do not have the rights to release said assets, I'm not sure what the hub-bub is. These are podling releases. PS: and '*LEGAL*' is not GPL code or whatever > On Jun 7, 2019, at 2:47 PM, Greg Stein wrote: > > 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 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 >> 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 >> >> - To unsubscribe, e-mail:
Re: [IMPORTANT] Board proposal on podling releases
Hi, > Ted and Roy (in other threads) seem to have said that Ted's bucket #1 is the > only thing that is a true showstopper. And other board members have said said at various points that peddling release must follow release and distribution policy, and legal VP has said that podling releases must follow ALL 3rd party requirements. > Does anybody truly know what will and will not ruin the legal-shield? I asked exactly this in the proposal. Romain said they probably couldn’t answer without knowing specific details. Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [IMPORTANT] Board proposal on podling releases
Hi, >> It’s a pity that the people who are strongly for this position, don’t seem >> to actually want to be involved in helping out, but just want to discuss >> and tell the people actually doing the work are going the wrong way about >> this. :-) >> > > Dude. Totally out of bounds. Please don't take it the wrong way, no offence was intended, note the “:-)” Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [IMPORTANT] Board proposal on podling releases
On Mon, Jun 10, 2019 at 12:15 AM Justin Mclean wrote: > Hi, > > It’s a pity that the people who are strongly for this position, don’t seem > to actually want to be involved in helping out, but just want to discuss > and tell the people actually doing the work are going the wrong way about > this. :-) > Dude. Totally out of bounds. I am offering suggestion on how to rethink releases. I was up front and honest that my time is going elsewhere to the Foundation. bye, -g
Re: [IMPORTANT] Board proposal on podling releases
There's been a lot of discussion on relaxing requirements, but I don't recall
any long-time ASF person explaining how fragile or durable the legal-shield and
the insurance rates for it are.
Ted and Roy (in other threads) seem to have said that Ted's bucket #1 is the
only thing that is a true showstopper. And Ted's adds a bucket #2 for TLPs.
So maybe even for TLPs, all other issues can be punted to a next release.
Maybe that's the only clarification that is needed from the board. That no TLP
will be frowned upon for deferring anything outside of bucket #1 and #2 to a
future release and additionally no Podling will be frowned upon for deferring
anything in bucket #2 to a future release.
Unless someone can explain why that would ruin the legal-shield or raise
insurance rates, I think that would save lots of community time getting
releases out. Otherwise, we might be expending precious energy overzealously
trying to protect a legal-shield that doesn't need that level of protection.
Does anybody truly know what will and will not ruin the legal-shield? I have
to imagine that releases have been shipped by the ASF and later found to be
non-compliant with policy and that didn't ruin the legal shield or raise
insurance rates.
Of course, I could be wrong...
-Alex
On 6/9/19, 9:13 PM, "Greg Stein" wrote:
On Sun, Jun 9, 2019 at 8:27 PM Justin Mclean
wrote:
>...
> Hi,
>
> > It takes a new mindset. What is the *bare* minimum MUST? Two items?
> > maaaybe three?
>
> Given this is probably a radical departure, would it be best to do as an
> experiment with a couple of podlings? Small reversible steps. Would you be
> willing to work on a proposal to the board and act a mentor on one or more
> podlings who took this path?
>
Not me. Any of my spare/hobby time goes to supplement my work for Infra.
There is no way that I could sustainably mentor a podling.
> And keep the IPMC out of it. No votes on releases. Stop second-guessing
> the
> > mentors and the podling communities.
>
> I don't see how IPMC votes are second guessing. IPMC votes are required.
"required"? Said who?
Be honest now. We are not talking a TLP release. This is "some code" from a
podling. It may have stuff in it that would make a Director stroke out
(maybe not Ted, it seems :p ) ... Why does the IPMC feel a need to put its
"imprimatur" on the release? And who/when said they must? And let's say we
can dig that up from the past ... why not remove/relax it?
It seems there is some consensus that podling releases are getting jammed
up by IPMC rules. Assuming that is true, then why not question the vote
process itself?
Let's say at least ONE of a podling's Mentors MUST give a +1. Then the PPMC
gets at least (2) more, majority blah blah. Then they throw some code into
the release directory. Go out for a beer.
Wouldn't that be acceptable?
>...
> That's ASF policy / bylaws not incubator policy.
Again: I disagree. This is not a TLP release. It is "some code" from a
podling.
> We could look into changing this, but probably best discussed in another
> thread.
>
Seems to apply here. Aren't we talking about releases from podlings?
> Not all mentors (who are IPMC members) vote on releases and podlings in
> most cases need to ask for extra votes from the wider IPMC. I would guess
> 90% of them, so I’m not sure how your proposal deals with that.
Just stop having the IPMC vote. No need to ask for votes. Done. Easy Peasy.
>...
> The IPMC already added one way for releases to get reviewed by the IPMC
> without a vote, but so far no podling has taken the IPMC up on the offer.
>
What other way? Link? Publicity for this? Never heard of it. One wonders
how podlings could do this, if they never learn of it. Now, I'm not
"steeped" in Incubator like you are, and apparently missed this. But I do
tend to follow much of the goings-on ...
And:
On Sun, Jun 9, 2019 at 9:30 PM Roman Shaposhnik
wrote:
>...
> > I would expect that any graduating podling has this under control before
> > graduating and will not make any TLP releases with this kind of defect.
>
> I would suggest we make it a policy to document those exceptions in
> the DISCLAIMER file.
>
I would posit that most are not known at release time, but yes: it would be
a Best Practice to add those to a project's DISCLAIMER when found, to
inform downstream on the next release. And let's please not hold a
podling's release until things get added. ("no! stop! add to disclaimer".
rinse. repeat.)
Cheers,
-g
Re: [IMPORTANT] Board proposal on podling releases
Hi, It’s a pity that the people who are strongly for this position, don’t seem to actually want to be involved in helping out, but just want to discuss and tell the people actually doing the work are going the wrong way about this. :-) > Be honest now. We are not talking a TLP release. This is "some code" from a > podling. It may have stuff in it that would make a Director stroke out > (maybe not Ted, it seems :p ) ... Why does the IPMC feel a need to put its > "imprimatur" on the release? And who/when said they must? And let's say we > can dig that up from the past ... why not remove/relax it? I'st a release by the incubator PMC and thus needs to follow ASF policies, do you consider the incubator a TLP or not? As to why was it originally done this way, that’s before my time so I don’t actually know. Perhaps someone else can find or comment on that. > It seems there is some consensus that podling releases are getting jammed > up by IPMC rules. No exactly a) release policy is not IPMC rules. b) The large majority of releases have no issues. c) Where a -1 happens it for a good reason. > Assuming that is true, then why not question the vote process itself? Sure but that is side tracking this thread which is on the actual proposal to the board. > Let's say at least ONE of a podling's Mentors MUST give a +1. Then the PPMC > gets at least (2) more, majority blah blah. PPMC votes are not binding on releases, again exactly why it was set up this way I do not know, but I guess it because they are just learning about the process and not a "full citizen” yet. You need 3 + 1 binding votes from the PMC and more +1s than -1s to make a release. > Wouldn't that be acceptable? I have no idea, it probably break several ASF bylaws / policies which are not set by the IPMC and it don’t follow what TLP projects do. I’m fairly sure that the IPMC can't ignore those policies without permission from the board. Hence why this proposal exists. > What other way? Link? Publicity for this? See [1], there was a large amount of discussion about this onlist and it was in a recent board report, so the mentors should be aware of it. There was also an alternative voting process put forward 3 or 4 years ago. Thanks, Justin 1. https://lists.apache.org/thread.html/495ed84b43c1ba2662075a6c8c869bcd337b6bf4bc1895149c1483de@%3Cgeneral.incubator.apache.org%3E - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [IMPORTANT] Board proposal on podling releases
On Sun, Jun 9, 2019 at 8:27 PM Justin Mclean
wrote:
>...
> Hi,
>
> > It takes a new mindset. What is the *bare* minimum MUST? Two items?
> > maaaybe three?
>
> Given this is probably a radical departure, would it be best to do as an
> experiment with a couple of podlings? Small reversible steps. Would you be
> willing to work on a proposal to the board and act a mentor on one or more
> podlings who took this path?
>
Not me. Any of my spare/hobby time goes to supplement my work for Infra.
There is no way that I could sustainably mentor a podling.
> And keep the IPMC out of it. No votes on releases. Stop second-guessing
> the
> > mentors and the podling communities.
>
> I don't see how IPMC votes are second guessing. IPMC votes are required.
"required"? Said who?
Be honest now. We are not talking a TLP release. This is "some code" from a
podling. It may have stuff in it that would make a Director stroke out
(maybe not Ted, it seems :p ) ... Why does the IPMC feel a need to put its
"imprimatur" on the release? And who/when said they must? And let's say we
can dig that up from the past ... why not remove/relax it?
It seems there is some consensus that podling releases are getting jammed
up by IPMC rules. Assuming that is true, then why not question the vote
process itself?
Let's say at least ONE of a podling's Mentors MUST give a +1. Then the PPMC
gets at least (2) more, majority blah blah. Then they throw some code into
the release directory. Go out for a beer.
Wouldn't that be acceptable?
>...
> That's ASF policy / bylaws not incubator policy.
Again: I disagree. This is not a TLP release. It is "some code" from a
podling.
> We could look into changing this, but probably best discussed in another
> thread.
>
Seems to apply here. Aren't we talking about releases from podlings?
> Not all mentors (who are IPMC members) vote on releases and podlings in
> most cases need to ask for extra votes from the wider IPMC. I would guess
> 90% of them, so I’m not sure how your proposal deals with that.
Just stop having the IPMC vote. No need to ask for votes. Done. Easy Peasy.
>...
> The IPMC already added one way for releases to get reviewed by the IPMC
> without a vote, but so far no podling has taken the IPMC up on the offer.
>
What other way? Link? Publicity for this? Never heard of it. One wonders
how podlings could do this, if they never learn of it. Now, I'm not
"steeped" in Incubator like you are, and apparently missed this. But I do
tend to follow much of the goings-on ...
And:
On Sun, Jun 9, 2019 at 9:30 PM Roman Shaposhnik
wrote:
>...
> > I would expect that any graduating podling has this under control before
> > graduating and will not make any TLP releases with this kind of defect.
>
> I would suggest we make it a policy to document those exceptions in
> the DISCLAIMER file.
>
I would posit that most are not known at release time, but yes: it would be
a Best Practice to add those to a project's DISCLAIMER when found, to
inform downstream on the next release. And let's please not hold a
podling's release until things get added. ("no! stop! add to disclaimer".
rinse. repeat.)
Cheers,
-g
Re: [IMPORTANT] Board proposal on podling releases
On Sun, Jun 9, 2019 at 8:20 PM Justin Mclean wrote: > > Hi, > > > Big +1 to the above. I would strongly suggest trying to resolve > > this first between IPMC and ASF Legal Committee > > JFYI - I’ve tried to do this before and was told (by aboard member) it was > the boards policy not the Legal Committer. All policy is ultimately a board policy (well, you know ;-)) so what I was suggesting is that a draft is worked on the legal committee side and then submitted to the board if needed. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [IMPORTANT] Board proposal on podling releases
Hi, > Big +1 to the above. I would strongly suggest trying to resolve > this first between IPMC and ASF Legal Committee JFYI - I’ve tried to do this before and was told (by aboard member) it was the boards policy not the Legal Committer. Thanks, Justin
Re: [IMPORTANT] Board proposal on podling releases
A few comments based on various excellent previous posts: On Sun, Jun 9, 2019 at 12:34 AM Hen wrote: > I don't see a need to go to the board on this :) Big +1 to the above. I would strongly suggest trying to resolve this first between IPMC and ASF Legal Committee On Sun, Jun 9, 2019 at 6:33 PM Ted Dunning wrote: > > There are three kinds of release constraints at Apache. Only one is > critical for new podlings. > > 1. Legal constraints on whether Apache has the right to distribute the > source code in question and link to any non-source dependencies. This > mostly applies to projects coming out of commercial entities, but I would > lump adversarial forks of open source projects into this category. Note > that GPL inclusions are not a problem at this level, since they still allow > us to make a source release legally. > > My feeling is that this is the only truly non-negotiable item for a podling > release made at Apache. Agreed 100%. > 2. Downstream constraints on users. Mature projects at Apache provide good > guarantees that using the release will not have limited allowable field of > use or strange license terms. This is a MUST-DO for a top-level project > release, but it is plausible to allow this for early podling releases with > LOTs of disclaimers and warning signs. Examples of this are GPL inclusions, > the JSON.org "don't be evil" license, non-commercial licenses and > non-optional binary dependencies that are not open source. All of these > could plausibly be allowable in an incubating release if the fact that the > release doesn't have the normal safety of an Apache release. > > I would expect that any graduating podling has this under control before > graduating and will not make any TLP releases with this kind of defect. I would suggest we make it a policy to document those exceptions in the DISCLAIMER file. Later on, whether to allow graduation with non-trivial DISCLAIMER file can be decided on a case-by-case basis. > 3. Infrastructural impact on Apache itself. This means that a project can't > require that infra rebuild their systems just to accommodate some > idiosyncratic strangeness of the podling. This is typically a pretty strict > constraint, but is reasonable to waive for early releases if, say, the > podling uses non-Apache resources on an interim basis or if the project > really does have some special needs and infra is willing to help. > > Again, this issue probably has to be dealt with one way or another before > graduation. Agreed. Thanks, Roman. > > > > > > On Sun, Jun 9, 2019 at 5:41 PM Greg Stein wrote: > > > The entire note below sounds like "business as usual. we haven't learned > > anything." > > > > Release offsite is not a solution, IMO. I believe it is Best(tm) to have a > > DISCLAIMER.txt in the incubator/$podling/release/ directory, and "podling > > releases" which do not meet our normal policies for TLPs. I think our goal > > should be that a podling release has (say) two MUST items (add a > > disclaimer, use Foundation dist system; I wouldn't even care about a > > LICENSE file -- let users decide if that concerns them), and the rest is > > forgiven as long as notes/fixes will be made before graduation. > > > > It takes a new mindset. What is the *bare* minimum MUST? Two items? > > maaaybe three? > > > > And keep the IPMC out of it. No votes on releases. Stop second-guessing the > > mentors and the podling communities. > > > > Cheers, > > -g > > > > > > On Sun, Jun 9, 2019 at 6:27 PM Justin Mclean wrote: > > > > > Hi, > > > > > > > (2) We all know that for many incubating projects immediately requiring > > > full Release Policy compliance is too steep a slope. > > > > > > This is solved by allowing them to make non Apache releases out side of > > > the ASF. We currently do this. However branding and release policy also > > > need to be followed there. i.e. A (P)PMC can’t release unreleased > > materials > > > outside the their development community, so they can’t be called Apache > > > releases, and it’s not the (P)PMC who is releasing them. > > > > > > > (3) We should be willing to provide guidance to podlings about which > > > requirements should be fully met first. We don’t need to define serious > > for > > > this. > > > > > > +1 > > > > > > > (4) We already have tracking in place in the Podling Status XML/YAML > > > about the dates where podlings have met various requirements with > > licensing > > > and copyright. If properly updated then we already providing for > > additional > > > DISCLAIMERs. > > > > > > I think those disclaimers would need to be in a more visible place, i.e. > > > in the release artefacts, so end users can see them. > > > > > > > (5) We should work to modernize (3) and (4) to properly discuss the > > > modern workflow using GitBox/GitHub. For example, at what point should a > > > podling stop making releases in their pre-Apache process and switch to an > > > Apache process and how should we handle repositories that are
Re: [IMPORTANT] Board proposal on podling releases
There are three kinds of release constraints at Apache. Only one is critical for new podlings. 1. Legal constraints on whether Apache has the right to distribute the source code in question and link to any non-source dependencies. This mostly applies to projects coming out of commercial entities, but I would lump adversarial forks of open source projects into this category. Note that GPL inclusions are not a problem at this level, since they still allow us to make a source release legally. My feeling is that this is the only truly non-negotiable item for a podling release made at Apache. 2. Downstream constraints on users. Mature projects at Apache provide good guarantees that using the release will not have limited allowable field of use or strange license terms. This is a MUST-DO for a top-level project release, but it is plausible to allow this for early podling releases with LOTs of disclaimers and warning signs. Examples of this are GPL inclusions, the JSON.org "don't be evil" license, non-commercial licenses and non-optional binary dependencies that are not open source. All of these could plausibly be allowable in an incubating release if the fact that the release doesn't have the normal safety of an Apache release. I would expect that any graduating podling has this under control before graduating and will not make any TLP releases with this kind of defect. 3. Infrastructural impact on Apache itself. This means that a project can't require that infra rebuild their systems just to accommodate some idiosyncratic strangeness of the podling. This is typically a pretty strict constraint, but is reasonable to waive for early releases if, say, the podling uses non-Apache resources on an interim basis or if the project really does have some special needs and infra is willing to help. Again, this issue probably has to be dealt with one way or another before graduation. On Sun, Jun 9, 2019 at 5:41 PM Greg Stein wrote: > The entire note below sounds like "business as usual. we haven't learned > anything." > > Release offsite is not a solution, IMO. I believe it is Best(tm) to have a > DISCLAIMER.txt in the incubator/$podling/release/ directory, and "podling > releases" which do not meet our normal policies for TLPs. I think our goal > should be that a podling release has (say) two MUST items (add a > disclaimer, use Foundation dist system; I wouldn't even care about a > LICENSE file -- let users decide if that concerns them), and the rest is > forgiven as long as notes/fixes will be made before graduation. > > It takes a new mindset. What is the *bare* minimum MUST? Two items? > maaaybe three? > > And keep the IPMC out of it. No votes on releases. Stop second-guessing the > mentors and the podling communities. > > Cheers, > -g > > > On Sun, Jun 9, 2019 at 6:27 PM Justin Mclean wrote: > > > Hi, > > > > > (2) We all know that for many incubating projects immediately requiring > > full Release Policy compliance is too steep a slope. > > > > This is solved by allowing them to make non Apache releases out side of > > the ASF. We currently do this. However branding and release policy also > > need to be followed there. i.e. A (P)PMC can’t release unreleased > materials > > outside the their development community, so they can’t be called Apache > > releases, and it’s not the (P)PMC who is releasing them. > > > > > (3) We should be willing to provide guidance to podlings about which > > requirements should be fully met first. We don’t need to define serious > for > > this. > > > > +1 > > > > > (4) We already have tracking in place in the Podling Status XML/YAML > > about the dates where podlings have met various requirements with > licensing > > and copyright. If properly updated then we already providing for > additional > > DISCLAIMERs. > > > > I think those disclaimers would need to be in a more visible place, i.e. > > in the release artefacts, so end users can see them. > > > > > (5) We should work to modernize (3) and (4) to properly discuss the > > modern workflow using GitBox/GitHub. For example, at what point should a > > podling stop making releases in their pre-Apache process and switch to an > > Apache process and how should we handle repositories that are transferred > > to the ASF. > > > > +1 > > > > > (6) The IPMC and Mentors should provide additional Status around the > > current state of Incubation. See the clutch page and podling clutch > > analysis for one place we can improve on policy “Status”. > > > > +1 > > > > > A simple checkbox list similar to what we have in the podling status > > page. > > > > You mean like this but for all releases? [1] > > > > Thanks, > > Justin > > > > 1. > > > https://cwiki.apache.org/confluence/display/INCUBATOR/Incubator+Release+Checklist > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org >
Re: [IMPORTANT] Board proposal on podling releases
Hi, > It takes a new mindset. What is the *bare* minimum MUST? Two items? > maaaybe three? Given this is probably a radical departure, would it be best to do as an experiment with a couple of podlings? Small reversible steps. Would you be willing to work on a proposal to the board and act a mentor on one or more podlings who took this path? > And keep the IPMC out of it. No votes on releases. Stop second-guessing the > mentors and the podling communities. I don't see how IPMC votes are second guessing. IPMC votes are required. That's ASF policy / bylaws not incubator policy. We could look into changing this, but probably best discussed in another thread. Not all mentors (who are IPMC members) vote on releases and podlings in most cases need to ask for extra votes from the wider IPMC. I would guess 90% of them, so I’m not sure how your proposal deals with that. IPMC votes also pick up things the podlings/mentors miss, about 1 in 5 releases have a serious issue that the IPMC finds. That I think is a valuable service, one that we may not want to throw away. One way perhaps to deal with that is mentor education / engagement. The IPMC already added one way for releases to get reviewed by the IPMC without a vote, but so far no podling has taken the IPMC up on the offer. Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [IMPORTANT] Board proposal on podling releases
The entire note below sounds like "business as usual. we haven't learned anything." Release offsite is not a solution, IMO. I believe it is Best(tm) to have a DISCLAIMER.txt in the incubator/$podling/release/ directory, and "podling releases" which do not meet our normal policies for TLPs. I think our goal should be that a podling release has (say) two MUST items (add a disclaimer, use Foundation dist system; I wouldn't even care about a LICENSE file -- let users decide if that concerns them), and the rest is forgiven as long as notes/fixes will be made before graduation. It takes a new mindset. What is the *bare* minimum MUST? Two items? maaaybe three? And keep the IPMC out of it. No votes on releases. Stop second-guessing the mentors and the podling communities. Cheers, -g On Sun, Jun 9, 2019 at 6:27 PM Justin Mclean wrote: > Hi, > > > (2) We all know that for many incubating projects immediately requiring > full Release Policy compliance is too steep a slope. > > This is solved by allowing them to make non Apache releases out side of > the ASF. We currently do this. However branding and release policy also > need to be followed there. i.e. A (P)PMC can’t release unreleased materials > outside the their development community, so they can’t be called Apache > releases, and it’s not the (P)PMC who is releasing them. > > > (3) We should be willing to provide guidance to podlings about which > requirements should be fully met first. We don’t need to define serious for > this. > > +1 > > > (4) We already have tracking in place in the Podling Status XML/YAML > about the dates where podlings have met various requirements with licensing > and copyright. If properly updated then we already providing for additional > DISCLAIMERs. > > I think those disclaimers would need to be in a more visible place, i.e. > in the release artefacts, so end users can see them. > > > (5) We should work to modernize (3) and (4) to properly discuss the > modern workflow using GitBox/GitHub. For example, at what point should a > podling stop making releases in their pre-Apache process and switch to an > Apache process and how should we handle repositories that are transferred > to the ASF. > > +1 > > > (6) The IPMC and Mentors should provide additional Status around the > current state of Incubation. See the clutch page and podling clutch > analysis for one place we can improve on policy “Status”. > > +1 > > > A simple checkbox list similar to what we have in the podling status > page. > > You mean like this but for all releases? [1] > > Thanks, > Justin > > 1. > https://cwiki.apache.org/confluence/display/INCUBATOR/Incubator+Release+Checklist > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [IMPORTANT] Board proposal on podling releases
Hi, > (2) We all know that for many incubating projects immediately requiring full > Release Policy compliance is too steep a slope. This is solved by allowing them to make non Apache releases out side of the ASF. We currently do this. However branding and release policy also need to be followed there. i.e. A (P)PMC can’t release unreleased materials outside the their development community, so they can’t be called Apache releases, and it’s not the (P)PMC who is releasing them. > (3) We should be willing to provide guidance to podlings about which > requirements should be fully met first. We don’t need to define serious for > this. +1 > (4) We already have tracking in place in the Podling Status XML/YAML about > the dates where podlings have met various requirements with licensing and > copyright. If properly updated then we already providing for additional > DISCLAIMERs. I think those disclaimers would need to be in a more visible place, i.e. in the release artefacts, so end users can see them. > (5) We should work to modernize (3) and (4) to properly discuss the modern > workflow using GitBox/GitHub. For example, at what point should a podling > stop making releases in their pre-Apache process and switch to an Apache > process and how should we handle repositories that are transferred to the ASF. +1 > (6) The IPMC and Mentors should provide additional Status around the current > state of Incubation. See the clutch page and podling clutch analysis for one > place we can improve on policy “Status”. +1 > A simple checkbox list similar to what we have in the podling status page. You mean like this but for all releases? [1] Thanks, Justin 1. https://cwiki.apache.org/confluence/display/INCUBATOR/Incubator+Release+Checklist - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [IMPORTANT] Board proposal on podling releases
Hi, > I agree with other respondents that 'serious' seems bad here. To me the > serious ones are the only ones they can't release with. So we just continue as is then? You have any suggests to what we change? > ReleaseBlocking: Has a LICENSE. Legally permitted to release and complies > with the license via some mechanism. We currently allow releases that are not strictly legal. This would be a step backwards. > GraduationBlocking: Everything else; including complying with the license > via our preferred mechanism (i.e. we might want the MIT license text in our > LICENSE file, but would accept it being in the source header of the files > themselves). We currently allow podlings to graduate with some issues as longs as the PPMC is dealing with them. This would be a step backwards. > I don't see a need to go to the board on this :) If we don’t want to change anything - sure there's no need to go to the board. >> issues have been fixed. The IPMC will add additional information to the > incubator DISCLAIMER to cover that podling release may not abide by all > > The IPMC? That sounds like a people scaling problem. The podling committee > should handle it. I mean just changing this page [1] , podlings can update their own disclaimers. > "This release still has the following issues that will need to be resolved > before the Foo Project can graduate to an Apache vetted Top Level Project” What about unknown issues? > Are the board lawyers? :) Until you have a well-defined list, I doubt > anything could be confirmed. I'd go with: "Conceptually what you describe > could lead to a situation where a PPMC releases a project fully compliant > with the ASF's expectations. “ I assume you mean “not fully compliant”? Thanks, Justin 1. https://incubator.apache.org/guides/branding.html#disclaimers - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [IMPORTANT] Board proposal on podling releases
Top Post. (1) We are losing track of the goal. The goal is to make it easier for incubating projects to begin to follow Foundation Release and Distribution Policies on their path to adopting the Apache Way, building a Community and graduating to become a TLP project. I think the IPMC has overcorrected and we emphasize Release Policy over Community Building. (2) We all know that for many incubating projects immediately requiring full Release Policy compliance is too steep a slope. (3) We should be willing to provide guidance to podlings about which requirements should be fully met first. We don’t need to define serious for this. (4) We already have tracking in place in the Podling Status XML/YAML about the dates where podlings have met various requirements with licensing and copyright. If properly updated then we already providing for additional DISCLAIMERs. (5) We should work to modernize (3) and (4) to properly discuss the modern workflow using GitBox/GitHub. For example, at what point should a podling stop making releases in their pre-Apache process and switch to an Apache process and how should we handle repositories that are transferred to the ASF. (6) The IPMC and Mentors should provide additional Status around the current state of Incubation. See the clutch page and podling clutch analysis for one place we can improve on policy “Status”. All that said inline with Henry below. > On Jun 9, 2019, at 12:34 AM, Hen wrote: > > Copying the proposal in so I have something to respond to :) > >> Proposal >> >> That the IPMC can allow releases with serious issues in them to be > released and distributed without IPMC or legal VP approval. When this > occurs > > I agree with other respondents that 'serious' seems bad here. To me the > serious ones are the only ones they can't release with. > > ReleaseBlocking: Has a LICENSE. Legally permitted to release and complies > with the license via some mechanism. I would add DISCLAIMER to this. > GraduationBlocking: Everything else; including complying with the license > via our preferred mechanism (i.e. we might want the MIT license text in our > LICENSE file, but would accept it being in the source header of the files > themselves). > > I don't see a need to go to the board on this :) Agreed as this is a main purpose to the Incubator. > >> podling will documents the issue as one blocking graduation and carry on > incubating. They will not be allowed to graduate until all serious release > > +1 to documenting it as BlocksGraduation :) Noting the 'serious' here > again. This would be my point (5) above > >> issues have been fixed. The IPMC will add additional information to the > incubator DISCLAIMER to cover that podling release may not abide by all > > The IPMC? That sounds like a people scaling problem. The podling committee > should handle it. This is part of a podling’s status and the IPMC should make it easy to report. > >> terms of the ALv2 and may contain code under an incompatible license. > > Incompatible is such a vague word. It's also very specific to one type of > GraduationBlocking issue. I would stick to: > > "This release still has the following issues that will need to be resolved > before the Foo Project can graduate to an Apache vetted Top Level Project" > (or some such; I really want to say Apache-Certified Community, but that's > a different argument. Exactly. Documenting where a particular podling’s product release is on the path to graduation can allow downstream users of the podling’s release to assess their risk. > >> All releases and podling web sites will be updated to include this where >> required. > > This is a given. I think that IPMC should provide a mechanism in addition to a directive. > >> >> Notes >> >> The IPMC will come up with a well-defined list of those serious issues > and distribute to mentors, IPMC members and podlings so that everyone's >> expectations are clear. This proposal does not change the need for an > IPMC vote on podling releases. > > Redefining "serious issues" to mean ones that block a release; they should > be writeable on the back of a couple of business cards. Taking serious > issues as ones that are not actually serious and only graduation blockers; > then +1. It should still be short, but a piece of paper seems good :) A simple checkbox list similar to what we have in the podling status page. > >> Can the board also confirm that the ASF's legal shield would cover people > making releases under this proposal? > > Are the board lawyers? :) Until you have a well-defined list, I doubt > anything could be confirmed. I'd go with: "Conceptually what you describe > could lead to a situation where a PPMC releases a project fully compliant > with the ASF's expectations. “ There are too many hypotheticals. We need a pan without hypotheticals. We need a holistic plan. Regards, Dave > > Hen > > > > > On Thu, Jun 6, 2019 at 11:45 PM Justin Mclean >
Re: [IMPORTANT] Board proposal on podling releases
Copying the proposal in so I have something to respond to :) > Proposal > > That the IPMC can allow releases with serious issues in them to be released and distributed without IPMC or legal VP approval. When this occurs I agree with other respondents that 'serious' seems bad here. To me the serious ones are the only ones they can't release with. ReleaseBlocking: Has a LICENSE. Legally permitted to release and complies with the license via some mechanism. GraduationBlocking: Everything else; including complying with the license via our preferred mechanism (i.e. we might want the MIT license text in our LICENSE file, but would accept it being in the source header of the files themselves). I don't see a need to go to the board on this :) > podling will documents the issue as one blocking graduation and carry on incubating. They will not be allowed to graduate until all serious release +1 to documenting it as BlocksGraduation :) Noting the 'serious' here again. > issues have been fixed. The IPMC will add additional information to the incubator DISCLAIMER to cover that podling release may not abide by all The IPMC? That sounds like a people scaling problem. The podling committee should handle it. > terms of the ALv2 and may contain code under an incompatible license. Incompatible is such a vague word. It's also very specific to one type of GraduationBlocking issue. I would stick to: "This release still has the following issues that will need to be resolved before the Foo Project can graduate to an Apache vetted Top Level Project" (or some such; I really want to say Apache-Certified Community, but that's a different argument. > All releases and podling web sites will be updated to include this where > required. This is a given. > > Notes > > The IPMC will come up with a well-defined list of those serious issues and distribute to mentors, IPMC members and podlings so that everyone's > expectations are clear. This proposal does not change the need for an IPMC vote on podling releases. Redefining "serious issues" to mean ones that block a release; they should be writeable on the back of a couple of business cards. Taking serious issues as ones that are not actually serious and only graduation blockers; then +1. It should still be short, but a piece of paper seems good :) > Can the board also confirm that the ASF's legal shield would cover people making releases under this proposal? Are the board lawyers? :) Until you have a well-defined list, I doubt anything could be confirmed. I'd go with: "Conceptually what you describe could lead to a situation where a PPMC releases a project fully compliant with the ASF's expectations. " Hen On Thu, Jun 6, 2019 at 11:45 PM Justin Mclean 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 > >
Re: [IMPORTANT] Board proposal on podling releases
Hi, > I think it would be a mistake to include the word serious in the > proposal that you are asking for board approval. That likely will > result in a 'no' response. As would any request that that board > approve anything that is illegal, like distributing code without > complying with the terms under which that code is licensed. Thanks for that feedback, I see if I can reword it in that way. > There may be some wiggle room in getting the board to approve letting > the incubator produce releases that are legal but may not comply with > ASF policy. The issue here is that is actually stricter that what we currently do. We allow podlings to make releases that are not legal reasonably often. Thanks, Justin
Re: [IMPORTANT] Board proposal on podling releases
On Fri, Jun 7, 2019 at 8:57 PM Justin Mclean 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. I think it would be a mistake to include the word serious in the proposal that you are asking for board approval. That likely will result in a 'no' response. As would any request that that board approve anything that is illegal, like distributing code without complying with the terms under which that code is licensed. There may be some wiggle room in getting the board to approve letting the incubator produce releases that are legal but may not comply with ASF policy in one or more ways, given that those deviations are documented, there exists a plan to fix those deviations, and that podling graduation is gated on the fixing of those deficiencies. > Thanks, > Justin - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [IMPORTANT] Board proposal on podling releases
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 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 > 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-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [IMPORTANT] Board proposal on podling releases
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 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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [IMPORTANT] Board proposal on podling releases
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
Re: [IMPORTANT] Board proposal on podling releases
Hi, > 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. Historically we have allowed such releases and they got +1 votes. If you look as several recent votes you see issues that would very likely be -1 votes on a TLP. > 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 agree. > 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. I think we’re close to be able to come up with a list that people can agree on. There's perhaps only one or two items that people don’t agree on. I think that would be useful no matter what the outcome of this proposal. But that leaves the issue that some people (including ex board members and podlings) have asked we should be more lenient than that. I don’t think the IPMC could do so without permission from the board, hence this proposal. Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [IMPORTANT] Board proposal on podling releases
Hi, > IMO, it all comes down to the definition of "serious issues". Some say that > the only real blockers should be legal issues about the right to distribute > some IP. Once way to define it would be to say any reason that a TLP release is likely to get a -1 vote on. Thanks, Justin
Re: [IMPORTANT] Board proposal on podling releases
IMO, there could be several kinds of scenarios under the category of "copyright violations". Such as: 1) Taking something under someone else's copyright and claiming it under a different copyright. 2) No mention of the copyright or the entity owning the IP at all anywhere in the release files. 3) Mentioning the entity owning the IP but not actually copying the Copyright notice 4) Same as #3, but the root problem is the entity owning the IP did not properly place their copyright. 5) Not following recommended practices for placing copyrights in LICENSE or NOTICE 6) Not copying an upstream Copyright in a NOTICE file into the release's NOTICE file And more. IMO, only #1 should hold up the release and only if the IP is not under some sort of Open Source license. Otherwise, I think I recall past discussion where the entity owning the IP will probably just ask for attribution in the next release and not sue anybody as a first reaction. After all they intended to share their code by putting it under an OS license. My 2 cents, -Alex On 6/7/19, 11:46 AM, "Sam Ruby" wrote: On Fri, Jun 7, 2019 at 2:00 PM Craig Russell 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. Drilling down by taking the contents of the draft incubator report: "Serious problems, such as; including GPL licensed software, including compiled code, or copyright violations, in a release is currently seen as a reason to vote -1 on a release." Picking them off one by one: 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. 2) Is it legal to include compiled code in releases? Yes. 3) Is it legal to include copyright violations in releases? No. > Craig - Sam Ruby > > On Jun 6, 2019, at 11:45 PM, Justin Mclean 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FINCUBATOR%2FJune2019data=02%7C01%7Caharui%40adobe.com%7C0e5f460f223c47b7cbde08d6eb787dcb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636955300076045986sdata=F1wBsJQ1%2F%2FFur6dk3DoiaZHehg77vK3mIw2R6G%2FuaGY%3Dreserved=0 > >
Re: [IMPORTANT] Board proposal on podling releases
On Fri, Jun 7, 2019 at 9:39 AM Bertrand Delacretaz < bdelacre...@codeconsult.ch> wrote: > Hi, > > On Fri, Jun 7, 2019 at 8:46 AM Justin Mclean > wrote: > > ...The proposal can be found in the draft board report. [1]... > > If I was on the Board I don't think I would accept making releases > "with serious issues in them" as mentioned there. > > Maybe I missed the discussion - what I would find acceptable is making > releases with minor issues, which are documented as such. > You did miss the discussion. And the "STOP THE RELEASE" is precisely the issue at hand. Leniency is the goal. So "I don't think I would accept" is antithetical to the discussion. -g
Re: [IMPORTANT] Board proposal on podling releases
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 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 > 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 > >
Re: [IMPORTANT] Board proposal on podling releases
On Fri, Jun 7, 2019 at 2:00 PM Craig Russell 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. Drilling down by taking the contents of the draft incubator report: "Serious problems, such as; including GPL licensed software, including compiled code, or copyright violations, in a release is currently seen as a reason to vote -1 on a release." Picking them off one by one: 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. 2) Is it legal to include compiled code in releases? Yes. 3) Is it legal to include copyright violations in releases? No. > Craig - Sam Ruby > > On Jun 6, 2019, at 11:45 PM, Justin Mclean 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 > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [IMPORTANT] Board proposal on podling releases
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 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
Re: [IMPORTANT] Board proposal on podling releases
On 6/7/2019 12:09 PM, Bertrand Delacretaz wrote: > Hi Kevin, > > On Fri, Jun 7, 2019 at 5:29 PM Kevin A. McGrail wrote: >> ... I would urge you to see the lengthy thread on the matter... > I won't - if the proposal implies disclaimers, tickets etc. those > conditions should be included in the proposal, such that a single URL > provides all the required information without having to read long > threads. > > Once again, if I was on the Board I would reject such a proposal > without a clear list of conditions, precautions etc...but I'm not > anymore, so if people think it will pass like that I'm fine. > > -Bertrand Fair enough. Justin, I'm happy to work with you on the proposal refinement this weekend. Craig had a great checklist that incorporated a lot of my thoughts. -- Kevin A. McGrail Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [IMPORTANT] Board proposal on podling releases
IMO, it all comes down to the definition of "serious issues". Some say that the only real blockers should be legal issues about the right to distribute some IP. My 2 cents, -Alex On 6/7/19, 8:29 AM, "Kevin A. McGrail" wrote: On 6/7/2019 11:26 AM, Bertrand Delacretaz wrote: > On Fri, Jun 7, 2019 at 5:22 PM Justin Mclean wrote: >> ...I assume from your response that you disagree with the proposal or want it modified? If so how?... > I don't think it's reasonable to allow releases with "serious" issues. > But let's see what the Board thinks. I would urge you to see the lengthy thread on the matter. There are some requirements that were discussed like: acknowledging the problem with a ticket, having a more descriptive disclaimer for incubating releases, making progress on issues, etc. that can allow more leniency. -- Kevin A. McGrail Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fin%2Fkmcgraildata=02%7C01%7Caharui%40adobe.com%7C4515751a25cc425ce81a08d6eb5cecc8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636955181672569755sdata=gLFvGUjqgRTUwYUGgMiLGshWG7gac%2F9VcU%2BhBNYZ1yM%3Dreserved=0 - 703.798.0171
Re: [IMPORTANT] Board proposal on podling releases
Hi Kevin, On Fri, Jun 7, 2019 at 5:29 PM Kevin A. McGrail wrote: >... I would urge you to see the lengthy thread on the matter... I won't - if the proposal implies disclaimers, tickets etc. those conditions should be included in the proposal, such that a single URL provides all the required information without having to read long threads. Once again, if I was on the Board I would reject such a proposal without a clear list of conditions, precautions etc...but I'm not anymore, so if people think it will pass like that I'm fine. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [IMPORTANT] Board proposal on podling releases
On 6/7/2019 11:26 AM, Bertrand Delacretaz wrote: > On Fri, Jun 7, 2019 at 5:22 PM Justin Mclean wrote: >> ...I assume from your response that you disagree with the proposal or want >> it modified? If so how?... > I don't think it's reasonable to allow releases with "serious" issues. > But let's see what the Board thinks. I would urge you to see the lengthy thread on the matter. There are some requirements that were discussed like: acknowledging the problem with a ticket, having a more descriptive disclaimer for incubating releases, making progress on issues, etc. that can allow more leniency. -- Kevin A. McGrail Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: [IMPORTANT] Board proposal on podling releases
On Fri, Jun 7, 2019 at 5:22 PM Justin Mclean wrote: > ...I assume from your response that you disagree with the proposal or want it > modified? If so how?... I don't think it's reasonable to allow releases with "serious" issues. But let's see what the Board thinks. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [IMPORTANT] Board proposal on podling releases
Hi, > Maybe I missed the discussion - what I would find acceptable is making > releases with minor issues, which are documented as such. Which we currently allow, but several people have suggested that we allow more than this this. There has been no objection to that as long as the board is in agreement and this is what the proposal asks. I assume from your response that you disagree with the proposal or want it modified? If so how? Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [IMPORTANT] Board proposal on podling releases
Hi, On Fri, Jun 7, 2019 at 8:46 AM Justin Mclean wrote: > ...The proposal can be found in the draft board report. [1]... If I was on the Board I don't think I would accept making releases "with serious issues in them" as mentioned there. Maybe I missed the discussion - what I would find acceptable is making releases with minor issues, which are documented as such. For example requiring an http://issues.apache.org/jira/browse/INCUBATOR ticket for such releases and pointing to a search of the "problematic-release" label there from the DISCLAIMER so that people can find out what's wrong with a specific release, if anything. But IMHO that can only work for minor issues, not "serious" ones. And it's probably good to keep a list of such acceptable minor issues if the proposal passes, for clarity. -Bertrand > 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
[IMPORTANT] Board proposal on podling releases
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
