Re: Podlings, the Incubator, relationships and Apache
On Sun, Jun 23, 2019 at 10:04 PM Greg Stein wrote: > I disagree. I see a number of people who think that podling releases are > TLP-level releases from the Incubator itself. I see people wanting > structure/policy/rules to ensure these TLP releases are done properly. And > that some want to "fix a few things" to make it easier for podlings to make > these releases. > Perhaps you are right, but it is not necessary to debate it. (The 'disagreement' is about what other people think; we can let them speak up and/or measure consensus or lack thereof in the usual ways.) The balls rolls forward by understanding the space of options, and then discussing it. (... the first part of which is happening on other threads.)
Re: Podlings, the Incubator, relationships and Apache
On Sun, Jun 23, 2019 at 11:55 PM Davor Bonaci wrote: > I wouldn't say that there are 2 camps. The IPMC seems to be overwhelmingly > in the "2nd camp", with its desire to be lenient with the releases and > rules. > I disagree. I see a number of people who think that podling releases are TLP-level releases from the Incubator itself. I see people wanting structure/policy/rules to ensure these TLP releases are done properly. And that some want to "fix a few things" to make it easier for podlings to make these releases. There are some that disagree with that outlook (the 2nd campers), and would like that "business decision" because the status quo is rough on podlings. I believe we do not have consensus on this shift in outlook/operation. Cheers, -g
Re: Podlings, the Incubator, relationships and Apache
+1 to 2nd camp. And even less requirements than have been suggested, I would offer. For example: if the tarball is missing a LICENSE or NOTICE file? Who cares. It's still a legal release. Just hard for downstream users to consume. But they *can*. Nothing stopping somebody from trying out the tarball. Cheers, -g On Sun, Jun 23, 2019 at 10:53 PM Dave Fisher wrote: > Thanks Roman! > > +1 to the 2nd camp! > > Regards, > Dave > > Sent from my iPhone > > > On Jun 23, 2019, at 8:25 PM, Roman Shaposhnik > wrote: > > > >> On Sat, Jun 22, 2019 at 3:31 PM Rich Bowen wrote: > >> > >> A couple of thoughts: > > > > And a couple of thoughts on top of that. > > > >> Podlings are not permitted to call themselves "Apache Foo" because they > are > >> not yet full Apache projects. > > > > Correct. The I way I see this thread is this: *when it comes to > > releases*, there's > > always been two camps in Incubator. One thinks that Incubator is a TLP > just > > like Apache Commons that happens to produce release artifacts that have > > nothing in common (just like Apache Commons' JXPath has very little to > do > > with Compress and). A second camp thinks that Incubator is actually a > special > > construct within a foundation (after all, if it was just like Apache > Commons why > > would we make them put DISCLAIMER into release tarballs?). > > > > It seems that David is closer to the 1st camp, and Rich and I are > > closer to the 2nd. > > > > Looking at the community benefits, I really think we should acknowledge > that > > Incubator is a special construct and optimize that special construct > > for a particular > > outcome: which is effectiveness of the graduation process. > > > >> While in the incubator we should expect podlibgs to fail at the rules. > >> They're new to them and many of them feel arbitrary, even capricious, to > >> those coming in from outside. We should make it safe to fail until they > are > >> ready to graduate. We should nurture them as long as they are moving > >> towards that goal. > > > > Yup. > > > >> I cannot disagree with your reading of our resolutions. But I wonder if > >> that reality is producing good citizen projects or a bunch of resentful > >> people following rules they don't understand or embrace because they > know > >> they have to. > >> > >> Zipkin is only the latest project which clearly didn't get it and has > left > >> angry. I would rather a project realize that they don't fit and be able > to > >> leave with their dignity without having also to leave hating what we > stand > >> for. > >> > >> I want our new graduates to love and understand the ASF not merely > tolerate > >> it. > >> > >> I want the incubator to respond to failure with gentle correction rather > >> than scoldings. > >> > >> Specifically I think podlings should be able to produce releases that > are > >> not asf complient and have them clearly labeled as such. Because they > are > >> not TLPs yet and so cannot be held to the same standard. This must be > >> accompanied by a movement towards being a TLP, not some eternal > incubation. > > > > With my IPMC member hat on -- huge +1 to the above. > > > > With my VP Legal hat on: I have no dog in this race. The IPMC needs to > make > > a *business* (well, community in this case) decision and then we can work > > with a risk profile of that decision. > > > > Like I said -- the decision to make is: 1st vs. 2nd camp. > > > > Thanks, > > Roman. > > > > - > > 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: Podlings, the Incubator, relationships and Apache
I wouldn't say that there are 2 camps. The IPMC seems to be overwhelmingly in the "2nd camp", with its desire to be lenient with the releases and rules. What I see is: [1] David is saying (correctly) how Incubator is structured right now. He hasn't expressed ~any opinions; it is just an interpretation of the facts from past resolutions and decisions made. I don't think anything said there is questionable as the current state of affairs. [2] Most of IPMC agrees that the current state of affairs is [1], and desires to relax it somewhat. [3] Hence, Justin is asking for clarification regarding IPMC's authority to depart from the current state of affairs described in [1]. The IPMC is capable of making the business decision; Justin is not asking for the decision to be made, but instead to better understand the IPMC's authority of possible decisions. On Sun, Jun 23, 2019 at 8:53 PM Dave Fisher wrote: > Thanks Roman! > > +1 to the 2nd camp! > > Regards, > Dave > > Sent from my iPhone > > > On Jun 23, 2019, at 8:25 PM, Roman Shaposhnik > wrote: > > > >> On Sat, Jun 22, 2019 at 3:31 PM Rich Bowen wrote: > >> > >> A couple of thoughts: > > > > And a couple of thoughts on top of that. > > > >> Podlings are not permitted to call themselves "Apache Foo" because they > are > >> not yet full Apache projects. > > > > Correct. The I way I see this thread is this: *when it comes to > > releases*, there's > > always been two camps in Incubator. One thinks that Incubator is a TLP > just > > like Apache Commons that happens to produce release artifacts that have > > nothing in common (just like Apache Commons' JXPath has very little to > do > > with Compress and). A second camp thinks that Incubator is actually a > special > > construct within a foundation (after all, if it was just like Apache > Commons why > > would we make them put DISCLAIMER into release tarballs?). > > > > It seems that David is closer to the 1st camp, and Rich and I are > > closer to the 2nd. > > > > Looking at the community benefits, I really think we should acknowledge > that > > Incubator is a special construct and optimize that special construct > > for a particular > > outcome: which is effectiveness of the graduation process. > > > >> While in the incubator we should expect podlibgs to fail at the rules. > >> They're new to them and many of them feel arbitrary, even capricious, to > >> those coming in from outside. We should make it safe to fail until they > are > >> ready to graduate. We should nurture them as long as they are moving > >> towards that goal. > > > > Yup. > > > >> I cannot disagree with your reading of our resolutions. But I wonder if > >> that reality is producing good citizen projects or a bunch of resentful > >> people following rules they don't understand or embrace because they > know > >> they have to. > >> > >> Zipkin is only the latest project which clearly didn't get it and has > left > >> angry. I would rather a project realize that they don't fit and be able > to > >> leave with their dignity without having also to leave hating what we > stand > >> for. > >> > >> I want our new graduates to love and understand the ASF not merely > tolerate > >> it. > >> > >> I want the incubator to respond to failure with gentle correction rather > >> than scoldings. > >> > >> Specifically I think podlings should be able to produce releases that > are > >> not asf complient and have them clearly labeled as such. Because they > are > >> not TLPs yet and so cannot be held to the same standard. This must be > >> accompanied by a movement towards being a TLP, not some eternal > incubation. > > > > With my IPMC member hat on -- huge +1 to the above. > > > > With my VP Legal hat on: I have no dog in this race. The IPMC needs to > make > > a *business* (well, community in this case) decision and then we can work > > with a risk profile of that decision. > > > > Like I said -- the decision to make is: 1st vs. 2nd camp. > > > > Thanks, > > Roman. > > > > - > > 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: Podlings, the Incubator, relationships and Apache
Thanks Roman! +1 to the 2nd camp! Regards, Dave Sent from my iPhone > On Jun 23, 2019, at 8:25 PM, Roman Shaposhnik wrote: > >> On Sat, Jun 22, 2019 at 3:31 PM Rich Bowen wrote: >> >> A couple of thoughts: > > And a couple of thoughts on top of that. > >> Podlings are not permitted to call themselves "Apache Foo" because they are >> not yet full Apache projects. > > Correct. The I way I see this thread is this: *when it comes to > releases*, there's > always been two camps in Incubator. One thinks that Incubator is a TLP just > like Apache Commons that happens to produce release artifacts that have > nothing in common (just like Apache Commons' JXPath has very little to do > with Compress and). A second camp thinks that Incubator is actually a special > construct within a foundation (after all, if it was just like Apache Commons > why > would we make them put DISCLAIMER into release tarballs?). > > It seems that David is closer to the 1st camp, and Rich and I are > closer to the 2nd. > > Looking at the community benefits, I really think we should acknowledge that > Incubator is a special construct and optimize that special construct > for a particular > outcome: which is effectiveness of the graduation process. > >> While in the incubator we should expect podlibgs to fail at the rules. >> They're new to them and many of them feel arbitrary, even capricious, to >> those coming in from outside. We should make it safe to fail until they are >> ready to graduate. We should nurture them as long as they are moving >> towards that goal. > > Yup. > >> I cannot disagree with your reading of our resolutions. But I wonder if >> that reality is producing good citizen projects or a bunch of resentful >> people following rules they don't understand or embrace because they know >> they have to. >> >> Zipkin is only the latest project which clearly didn't get it and has left >> angry. I would rather a project realize that they don't fit and be able to >> leave with their dignity without having also to leave hating what we stand >> for. >> >> I want our new graduates to love and understand the ASF not merely tolerate >> it. >> >> I want the incubator to respond to failure with gentle correction rather >> than scoldings. >> >> Specifically I think podlings should be able to produce releases that are >> not asf complient and have them clearly labeled as such. Because they are >> not TLPs yet and so cannot be held to the same standard. This must be >> accompanied by a movement towards being a TLP, not some eternal incubation. > > With my IPMC member hat on -- huge +1 to the above. > > With my VP Legal hat on: I have no dog in this race. The IPMC needs to make > a *business* (well, community in this case) decision and then we can work > with a risk profile of that decision. > > Like I said -- the decision to make is: 1st vs. 2nd camp. > > Thanks, > Roman. > > - > 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: Podlings, the Incubator, relationships and Apache
IMO, there's an actual test case going on right now. On 6/14, the Weex folks asked about an LGPL dependency which became LEGAL-464. Personally, I think it could be classified as a "runtime/platform" so that the CatX rules don't apply. But they have been held up for 9 days and counting. Who could/should make the call that they should just put their packages on dist.a.o assuming it is a runtime and over time fix things, or must they wait for a careful analysis? -Alex On 6/23/19, 8:26 PM, "Roman Shaposhnik" wrote: On Sat, Jun 22, 2019 at 3:31 PM Rich Bowen wrote: > > A couple of thoughts: And a couple of thoughts on top of that. > Podlings are not permitted to call themselves "Apache Foo" because they are > not yet full Apache projects. Correct. The I way I see this thread is this: *when it comes to releases*, there's always been two camps in Incubator. One thinks that Incubator is a TLP just like Apache Commons that happens to produce release artifacts that have nothing in common (just like Apache Commons' JXPath has very little to do with Compress and). A second camp thinks that Incubator is actually a special construct within a foundation (after all, if it was just like Apache Commons why would we make them put DISCLAIMER into release tarballs?). It seems that David is closer to the 1st camp, and Rich and I are closer to the 2nd. Looking at the community benefits, I really think we should acknowledge that Incubator is a special construct and optimize that special construct for a particular outcome: which is effectiveness of the graduation process. > While in the incubator we should expect podlibgs to fail at the rules. > They're new to them and many of them feel arbitrary, even capricious, to > those coming in from outside. We should make it safe to fail until they are > ready to graduate. We should nurture them as long as they are moving > towards that goal. Yup. > I cannot disagree with your reading of our resolutions. But I wonder if > that reality is producing good citizen projects or a bunch of resentful > people following rules they don't understand or embrace because they know > they have to. > > Zipkin is only the latest project which clearly didn't get it and has left > angry. I would rather a project realize that they don't fit and be able to > leave with their dignity without having also to leave hating what we stand > for. > > I want our new graduates to love and understand the ASF not merely tolerate > it. > > I want the incubator to respond to failure with gentle correction rather > than scoldings. > > Specifically I think podlings should be able to produce releases that are > not asf complient and have them clearly labeled as such. Because they are > not TLPs yet and so cannot be held to the same standard. This must be > accompanied by a movement towards being a TLP, not some eternal incubation. With my IPMC member hat on -- huge +1 to the above. With my VP Legal hat on: I have no dog in this race. The IPMC needs to make a *business* (well, community in this case) decision and then we can work with a risk profile of that decision. Like I said -- the decision to make is: 1st vs. 2nd camp. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podlings, the Incubator, relationships and Apache
On Sat, Jun 22, 2019 at 3:31 PM Rich Bowen wrote: > > A couple of thoughts: And a couple of thoughts on top of that. > Podlings are not permitted to call themselves "Apache Foo" because they are > not yet full Apache projects. Correct. The I way I see this thread is this: *when it comes to releases*, there's always been two camps in Incubator. One thinks that Incubator is a TLP just like Apache Commons that happens to produce release artifacts that have nothing in common (just like Apache Commons' JXPath has very little to do with Compress and). A second camp thinks that Incubator is actually a special construct within a foundation (after all, if it was just like Apache Commons why would we make them put DISCLAIMER into release tarballs?). It seems that David is closer to the 1st camp, and Rich and I are closer to the 2nd. Looking at the community benefits, I really think we should acknowledge that Incubator is a special construct and optimize that special construct for a particular outcome: which is effectiveness of the graduation process. > While in the incubator we should expect podlibgs to fail at the rules. > They're new to them and many of them feel arbitrary, even capricious, to > those coming in from outside. We should make it safe to fail until they are > ready to graduate. We should nurture them as long as they are moving > towards that goal. Yup. > I cannot disagree with your reading of our resolutions. But I wonder if > that reality is producing good citizen projects or a bunch of resentful > people following rules they don't understand or embrace because they know > they have to. > > Zipkin is only the latest project which clearly didn't get it and has left > angry. I would rather a project realize that they don't fit and be able to > leave with their dignity without having also to leave hating what we stand > for. > > I want our new graduates to love and understand the ASF not merely tolerate > it. > > I want the incubator to respond to failure with gentle correction rather > than scoldings. > > Specifically I think podlings should be able to produce releases that are > not asf complient and have them clearly labeled as such. Because they are > not TLPs yet and so cannot be held to the same standard. This must be > accompanied by a movement towards being a TLP, not some eternal incubation. With my IPMC member hat on -- huge +1 to the above. With my VP Legal hat on: I have no dog in this race. The IPMC needs to make a *business* (well, community in this case) decision and then we can work with a risk profile of that decision. Like I said -- the decision to make is: 1st vs. 2nd camp. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: LGPL dependency
Lets continue this discussion on https://issues.apache.org/jira/browse/LEGAL-464 please On Sat, Jun 22, 2019 at 2:18 PM Matt Sicker wrote: > > WebKit dates back to KHTML, an LGPL web engine from KDE. It sounds like > it’s some WebKit specific files that are BSD licensed. I haven’t inspected > the individual files, but I suspect that the header files are BSD licensed > to make linking less of a legal headache. > > On Sat, Jun 22, 2019 at 07:11, Craig Russell wrote: > > > The Webkit license page https://webkit.org/licensing-webkit/ says > > portions licensed under LGPL and BSD licenses. > > > > Usually this means it's the user's choice which license to use. > > > > We would choose the BSD License for the components that we use. > > > > Can you find anywhere a statement that the Webkit.so is licensed only > > under LGPL? > > > > Craig > > > > > On Jun 14, 2019, at 1:40 AM, 申远 wrote: > > > > > > As mentioned above, Webkit is under dual License(BSD and LPGL) and it's > > > almost impossible for us to figure out which function is a pure BSD > > > function. I don't know > > > Weex.apiA->Webkit.BSD.apiB->Webkit.BSD.apiC->Webkit.LGPL will happen or > > > not. Perhaps pure BSD header file will lead to pure BSD implementation. > > > Perhaps? > > > > > > As for alternative dependency, it's possible if we make some major > > changes > > > to Weex. But convenience binary of each Weex release includes Webkit.so, > > > how to solve that problem? Maybe publish two convenience binary, one > > named > > > Weex_WebKit.aar and the other named Weex_BSDKit.aar ? Not sounds like a > > > good idea to me. > > > > > > Best Regards, > > > YorkShen > > > > > > 申远 > > > > > > > > > Sheng Wu 于2019年6月14日周五 下午4:23写道： > > > > > >> Hi York > > >> > > >> I am not a C/C++ coder, so I could be wrong. > > >> > > >> But from I saw, Catalog X dependency required is not right. Like Hen > > said, > > >> alternative is an option. > > >> > > >> Such as > > >> Today’s another incubating project, ShardingSphere. > > >> When user wants to MySQL sharing, then they needs to accept MySQL Driver > > >> license first(or already accepted). > > >> But user could use ShardingSphere with PostgreSQL JDBC Driver. > > >> > > >> > > >> Sheng Wu > > >> Apache Skywalking, ShardingSphere, Zipkin > > >> > > >> > > >> > > >>> 在 2019年6月14日，下午4:15，Hen 写道： > > >>> > > >>> Assuming Weex requires Webkit and is unable to work with an > > alternative, > > >>> the issue here is that users of Weex would seem to have to permit > > reverse > > >>> engineering in their legal terms. Our position has been that that goes > > >>> beyond the scope of the Apache 2.0 license and would be an unpleasant > > >>> surprise for users. > > >>> > > >>> (seem to have to => this is how we've discussed the license; an > > actual > > >>> court may decide something completely different) > > >>> > > >>> Looking at Weex's website's description, it does not seem to be that a > > >> user > > >>> of Weex will already have agreed to the terms of Webkit; thus I believe > > >>> they would be unpleasantly surprised. > > >>> > > >>> Hen > > >>> > > >>> On Fri, Jun 14, 2019 at 12:49 AM 申远 wrote: > > >>> > > Hi, > > > > I am a PPMC member of Apache Weex. After serious reviewing of our > > dependencies, I found there some of the source code we copied from > > >> Webkit > > is actually under LGPL license(Category X) and our license format > > tools > > changed the license header of these files to Apache v2 incorrectly. > > I'd > > like to hear advice from incubator that whether our actions below > > would > > >> fix > > the Category X issue. > > > > First of all, License for Webkit is complicated, as it's said that > > >> "WebKit > > is open source software with portions licensed under the LGPL and BSD > > licenses available here." [1]. > > > > Now, Weex includes 1500 header files( .h files) from Webkit at > > compiling > > stage and around 150 of the are under BSD License. At runtime, Weex > > will > > dynamic links to the shared library of Webkit. > > > > After some major change, Weex could just include around 50 headers(.h > > files) at compiling stage and all of them are under BSD license. At > > runtime, Weex still needs to dynamic links to the shared library of > > >> Webkit > > as before. > > > > As Webkit is under dual license, and it's almost impossible for us to > > figure out whether there is an function call chain like > > Weex.apiA->Webkit.BSD.apiB->Webkit.BSD.apiC->Webkit.LGPL.apiD. I'd > > like > > >> to > > know our proposed change is enough to fix the Category X dependency. > > > > [1] https://webkit.org/licensing-webkit/ > > > > Best Regards, > > YorkShen > > > > 申远 > > > > >> > > >> > > >> - > > >> To unsubscribe, e-mail:
Re: [VOTE] (Re)Release Apache Flagon UserALE.js (Incubating) 1.0.0
Hi, +1 (binding) I checked the source release: - signatures and hashes good - incubating in name - disclaimer exists - LICENSE and NOTICE fine - all source files have ASF headers - no unexpected binary files There's one very minor issue in that LICENSE appendix includes " © Copyright 2018 The Apache Software Foundation.” this is incorrect. In your vote thread you state: "The community VOTE passes unanimously with +6, including 1 PPMC binding VOTE. The VOTE will now move to general@ to see if we receive the remaining +2 binding VOTEs to proceed with reRelease.” It actually has 5 PPMC and 1 IPMC votes that I can see. Given this is a very easy release to check, why have your mentors not voted on it? Do you need additional mentors? Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
