Re: [VOTE] (Re)Release Apache Flagon UserALE.js (Incubating) 1.0.0

[Joshua Poore]

Hi General,

Just a friendly reminder to Flagon Mentors and larger IPMC vote on the 
(Re)Release of Apache Flagon UserALE.js (Incubating) 1.0.0; we’re still short 
of +2 binding votes.

Thanks!


> On Jun 20, 2019, at 9:33 PM, Joshua Poore  wrote:
> 
> Hello,
> 
> On Jun 17th we posted an IPMC VOTE on the (Re)Release of Apache Flagon 
> UserALE.js (Incubating) 1.0.0, in accordance with a request by IPMC to 
> correctly annotate the release file names.
> 
> We did not receive any VOTEs from general@ within the 72 hour voting period. 
> Therefore, we are initiating another VOTE on general@, which will last for 72 
> hours.
> 
> Our community has voted in favor of this release by a majority of +7 in 
> favor, 0 in favor of additional development and, 0 against the release. This 
> tally includes +1 Binding Vote from PPMC. 
> 
> WE NEED +2 BINDING VOTES FOR THIS RELEASE VOTE TO PASS. 
> 
> 
> VOTE thread:
> https://lists.apache.org/thread.html/7a3c960ee54692cd6d88fb88b83c787244bb0e1b4a476050093d3b4a@%3Cdev.flagon.apache.org%3E
>  
> 
> 
> VOTE thread II (split accidentally to private):
> https://lists.apache.org/thread.html/83a96438bd60ea4c0aec2d5f103d68cbb430a44c72ef2d3d0cfe655f@%3Cdev.flagon.apache.org%3E
>  
> 
> 
> Please VOTE on Apache FLAGON UserALE.js 1.0.0 Release Candidate #3:
> 
> We solved 50 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12341550&styleName=Text&projectId=12320621&Create=Create&atl_token=A5KQ-2QAV-T4JA-FDED%7Cd2c9eccb98c0590b13b40b9d863a18bfc463546f%7Clin
>  
> 
> 
> Git source tag (d99ad9a2757fb5e412437227c6f9508d06c192e1):
> https://github.com/apache/incubator-flagon-useralejs/releases/tag/1.0.0r-RC3_06_12_2019
>  
> 
> 
> 
> Source Release Branch:
> https://github.com/apache/incubator-flagon-useralejs/tree/v1.0.0ReRelease 
> 
> 
> 
> Source Release Candidate Artifacts:
> https://dist.apache.org/repos/dist/dev/incubator/flagon/ 
> 
> 
> PGP release keys (signed with F9374FAE3FCADF6E):
> https://dist.apache.org/repos/dist/dev/incubator/flagon/KEYS 
> 
> 
> Vote will be open for 72 hours. Please VOTE as follows:
> 
> [ ] +1, let's get it released!!!
> [ ] +/-0, fine, but consider to fix few issues before...
> [ ] -1, nope, because... (and please explain why)
> 
> Thank you to everyone that is able to VOTE as well as everyone that
> contributed to Apache FLAGON 1.0.0 & 1.0.0r.
> 
> 
> 
>> On Jun 18, 2019, at 7:03 AM, Michael Schreiber 
>>  wrote:
>> 
>> +1
>> 
>> On Mon, Jun 17, 2019 at 9:35 PM Joshua Poore  wrote:
>> 
>>> Hello,
>>> 
>>> I am calling a VOTE to (re)Release Apache Flagon UserALE.js (Incubating)
>>> v1.0.0.
>>> 
>>> There are two reasons for this (re)Release:
>>> 
>>> 1. Original release artifacts were not properly annotated with
>>> (incubating) flag—IPMC asked us to regenerate the release with appropriate
>>> annotation.
>>> 2. Our name was officially changed from Apache SensSoft —> Flagon. This
>>> release bears our new project name.
>>> 
>>> We conducted a VOTE within our own community, resulting in +6 votes in
>>> favor of the (re)Release, including +1 binding vote from PPMC:
>>> 
>>> VOTE thread:
>>> https://lists.apache.org/thread.html/7a3c960ee54692cd6d88fb88b83c787244bb0e1b4a476050093d3b4a@%3Cdev.flagon.apache.org%3E
>>> <
>>> https://lists.apache.org/thread.html/7a3c960ee54692cd6d88fb88b83c787244bb0e1b4a476050093d3b4a@%3Cdev.flagon.apache.org%3E
 
>>> VOTE thread II (split accidentally to private):
>>> https://lists.apache.org/thread.html/83a96438bd60ea4c0aec2d5f103d68cbb430a44c72ef2d3d0cfe655f@%3Cdev.flagon.apache.org%3E
>>> <
>>> https://lists.apache.org/thread.html/83a96438bd60ea4c0aec2d5f103d68cbb430a44c72ef2d3d0cfe655f@%3Cdev.flagon.apache.org%3E
 
>>> 
>>> Please VOTE on Apache FLAGON UserALE.js 1.0.0 Release Candidate #3:
>>> 
>>> We solved 50 issues:
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12341550&styleName=Text&projectId=12320621&Create=Create&atl_token=A5KQ-2QAV-T4JA-FDED%7Cd2c9eccb98c0590b13b40b9d863a18bfc463546f%7Clin
>>> <
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12341550&styleName=Text&projectId=12320621&Create=Create&atl_token=A5KQ-2QAV-T4JA-FDED%7Cd2c9eccb98c0590b13b40b9d863a18bfc463546f%7Clin>
>>> <
>>> https://issues.apache.org/jira/secure/Rel

Re: Podlings, the Incubator, relationships and Apache

[Dave Fisher]

I find TVM concentrating on moving their community to Apache first to be very 
refreshing. I think that may allow an eyes wide open approach to Apache 
governance.

I think a soft approach to policy compliance will yield better, happier Apache 
communities.

The Incubator should celebrate the achievement of an Apache Release Policy 
compliant release via some PR or Press Release. The achievement should outside 
of and retrospective of the release process.

I’d like for Legal Policy to consider the prospective nature of an Incubating 
Community carefully.

Regards,
Dave

Sent from my iPhone

> On Jun 22, 2019, at 3:30 PM, Rich Bowen  wrote:
> 
> A couple of thoughts:
> 
> Podlings are not permitted to call themselves "Apache Foo" because they are
> not yet full Apache projects.
> 
> 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.
> 
> 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.
> 
> The incubator should be a mentor - an educator - not a jury.
> 
> 
>> On Fri, Jun 21, 2019, 01:04 David Nalley  wrote:
>> 
>> There's been a lot of discussion in various threads about bureaucracy,
>> whether podlings are part of the ASF, etc. As a result of that I've
>> spent a good deal of time reading resolutions and older discussions
>> and organizing those thoughts from a legal and community perspective.
>> I've also read a number of conversations from the more august members
>> of our body about this subject. Altogether it has somewhat changed
>> some of my opinions and assumptions. I've also sensed that there is a
>> community/business/legal disconnect in our conversations. We're using
>> the same words to mean very different things in each of those
>> contexts. That said I am but one member of the IPMC, but maybe this
>> will be helpful to someone else - I've tried to avoid my assumptions
>> in this.
>> 
>> The IPMC's first 'job'[1] is "accepting new products into the
>> Foundation" The second 'job' of the IPMC is to "provide guidance and
>> support to ensure that the Incubator's sub-projects[2] develop
>> products according to the Foundation's philosophy and guidelines". The
>> final 'job' is evaluating the products and determining whether they
>> should be abandoned, continue to receive guidance and support, or be
>> promoted to "full project status".
>> 
>> So there are several realizations I gained from this from the
>> Incubator perspective.
>> 1. Acceptance into the Incubator is acceptance of the product into the
>> Foundation.
>> 2. That product is then a sub-project of the Incubator.
>> 3. The IPMC has the "primary responsibility for the management of
>> those subprojects".
>> 
>> From the Foundation's perspective there are a number of things that
>> come to mind:
>> 1. We aren't a github/sourceforge/google code type platform where
>> random people can upload/post what they want.
>> 2. We do not have DMCA Safe Harbor protection - e.g. we are
>> responsible for everything that we publish or distribute. With the
>> exception of wikis and bug trackers anyone who can put something up on
>> an Apache property has some form of legal relationship with the
>> Foundation. This could be as simple as an ICLAs where you've
>> contractually said you won't contribute anything you don't have rights
>> to.
>> 3. Most of the project's who have come to us aren't entities in and of
>> themselves. E.g. the 'project' doesn't truly exist from a legal entity
>> perspective - and even those who do are at best an unincorporated
>> association of individuals. From a legal perspective - projects can't
>> make or distribute a release - they don't exist - only the ASF and the
>> individual(s) doing the work. Given that one of the explicit reasons
>> the Foundation was created was to[5]: "provide a means for individual
>> volunteers to be sheltered from legal suits"; we want 

Re: Podlings, the Incubator, relationships and Apache

[Rich Bowen]

A couple of thoughts:

Podlings are not permitted to call themselves "Apache Foo" because they are
not yet full Apache projects.

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.

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.

The incubator should be a mentor - an educator - not a jury.


On Fri, Jun 21, 2019, 01:04 David Nalley  wrote:

> There's been a lot of discussion in various threads about bureaucracy,
> whether podlings are part of the ASF, etc. As a result of that I've
> spent a good deal of time reading resolutions and older discussions
> and organizing those thoughts from a legal and community perspective.
> I've also read a number of conversations from the more august members
> of our body about this subject. Altogether it has somewhat changed
> some of my opinions and assumptions. I've also sensed that there is a
> community/business/legal disconnect in our conversations. We're using
> the same words to mean very different things in each of those
> contexts. That said I am but one member of the IPMC, but maybe this
> will be helpful to someone else - I've tried to avoid my assumptions
> in this.
>
> The IPMC's first 'job'[1] is "accepting new products into the
> Foundation" The second 'job' of the IPMC is to "provide guidance and
> support to ensure that the Incubator's sub-projects[2] develop
> products according to the Foundation's philosophy and guidelines". The
> final 'job' is evaluating the products and determining whether they
> should be abandoned, continue to receive guidance and support, or be
> promoted to "full project status".
>
> So there are several realizations I gained from this from the
> Incubator perspective.
> 1. Acceptance into the Incubator is acceptance of the product into the
> Foundation.
> 2. That product is then a sub-project of the Incubator.
> 3. The IPMC has the "primary responsibility for the management of
> those subprojects".
>
> From the Foundation's perspective there are a number of things that
> come to mind:
> 1. We aren't a github/sourceforge/google code type platform where
> random people can upload/post what they want.
> 2. We do not have DMCA Safe Harbor protection - e.g. we are
> responsible for everything that we publish or distribute. With the
> exception of wikis and bug trackers anyone who can put something up on
> an Apache property has some form of legal relationship with the
> Foundation. This could be as simple as an ICLAs where you've
> contractually said you won't contribute anything you don't have rights
> to.
> 3. Most of the project's who have come to us aren't entities in and of
> themselves. E.g. the 'project' doesn't truly exist from a legal entity
> perspective - and even those who do are at best an unincorporated
> association of individuals. From a legal perspective - projects can't
> make or distribute a release - they don't exist - only the ASF and the
> individual(s) doing the work. Given that one of the explicit reasons
> the Foundation was created was to[5]: "provide a means for individual
> volunteers to be sheltered from legal suits"; we want them to create
> and distribute releases as the Foundation.
> 4. Whether we like it or not - the Foundation is judged on the output
> from our projects and subprojects. We have a reputation of having
> clean IP, permissively licensed open source code, with clear
> provenance. Many people explicitly copy our standards, guidelines, and
> policies because they are the gold standard for good open source
> governance.
> 5. Disclaimers generally don't remove liability, and even if they did,
> our disclaimer talks about the maturity of our projects. - And it
> certainly doesn't remove the public's expectations from us - frankly -
> losing the publics trust is as scary as the potential legal liability.
> 6. The Board has delegated the responsibility of managing and ensuring
>

Re: LGPL dependency

[Matt Sicker]

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: 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
>
> --
Matt Sicker 

Re: No access to dist.apache.org

[Luciano Resende]

On Fri, Jun 21, 2019 at 1:45 PM leerho  wrote:
>
> 1) I asked INFRA how to setup the proper structures in dist.a.o.
> INFRA tells me that IPMC members create the proper folders in dist/dev and
> dist/release directories and once created the PPMC should have access.
>

Regarding the infrastructure requirements, this should be worked with
your mentors to get
this properly setup. Having said that, I went ahead and created the
two folders to help.

https://dist.apache.org/repos/dist/dev/incubator/datasketches/
https://dist.apache.org/repos/dist/release/incubator/datasketches/

> 2) There is also no "Staging Profile" in Apache Nexus Repository for
> datasketches.  When does that get set up?
>

I don't remember if this needs to manually be setup or not, but this
should be handled by infra.

>
>
> I have been held up for a full week now in making any progress in migrating
> to ASF.  I need to create the first Release Candidate artifact so that it
> can be referenced as a dependency by our other repositories.  I keep
> running into roadblocks where the basic infrastructure has not be set up
> that would allow me to make progress.
>
> I would be really grateful if someone could help guide me through this
> first "release" process steps.
>
> Specifically:
> a) Review our POM file for correct setup for a release to Apache (at least
> a release candidate)
> b) Guide me through the required Maven or command-line commands to get this
> first release created.
>
Getting your self familiar with the release policy and legal
requirement is part of learning the apache way in the incubator. There
are a few recent discussions on the general@ detailing some of these
steps and what is acceptable or not. But please follow up with your
mentors on more specific details in the context of datasketches
podling.

Apache release policy:
http://www.apache.org/legal/release-policy.html

Podling release guide:
http://incubator.apache.org/guides/releasemanagement.html

As for release steps (automated maven commands), this might be helpful
https://github.com/apache/bahir/blob/master/dev/release-build.sh





-- 
Luciano Resende
http://twitter.com/lresende1975
http://lresende.blogspot.com/

-
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

[ซ่อยค่อย ลืมเขาแน่]

ในวันที่ ศ. 21 มิ.ย. 2019 23:22 Alex Harui 
เขียนว่า:

> It all makes sense to me.  I think there are two key points that are
> driving all of this discussion:
>
> "5. Disclaimers generally don't remove liability"
>
> IANAL so I don't know if that's true or not.  For sure there are lots of
> disclaimers in the world.  I do not know the history of the current
> DISCLAIMER (and labeling of releases with -incubating).  What was the
> DISCLAIMERs original purpose?  Should it be modified to cover
> less-than-perfect podling releases, especially around CatX inclusions?  Who
> gets to make that call?
>
> " It's not perfect compliance vs. failure.
> IMO, the IPMC has been delegated the decision making process, and may
> often find themselves making the business decision that an imperfect
> release is better than a community stalled for months or years. Don't
> let the perfect be the enemy of the good."
>
> I think several "prominent" ASF members are saying this same thing, but
> nobody really wants to make it official.  The responsibility seems to have
> been passed around between IPMC, Board, and VP Legal.  How can the ASF get
> closure on this topic?
>
> My 2 cents,
> -Alex
>
> On 6/20/19, 10:04 AM, "David Nalley"  wrote:
>
> There's been a lot of discussion in various threads about bureaucracy,
> whether podlings are part of the ASF, etc. As a result of that I've
> spent a good deal of time reading resolutions and older discussions
> and organizing those thoughts from a legal and community perspective.
> I've also read a number of conversations from the more august members
> of our body about this subject. Altogether it has somewhat changed
> some of my opinions and assumptions. I've also sensed that there is a
> community/business/legal disconnect in our conversations. We're using
> the same words to mean very different things in each of those
> contexts. That said I am but one member of the IPMC, but maybe this
> will be helpful to someone else - I've tried to avoid my assumptions
> in this.
>
> The IPMC's first 'job'[1] is "accepting new products into the
> Foundation" The second 'job' of the IPMC is to "provide guidance and
> support to ensure that the Incubator's sub-projects[2] develop
> products according to the Foundation's philosophy and guidelines". The
> final 'job' is evaluating the products and determining whether they
> should be abandoned, continue to receive guidance and support, or be
> promoted to "full project status".
>
> So there are several realizations I gained from this from the
> Incubator perspective.
> 1. Acceptance into the Incubator is acceptance of the product into the
> Foundation.
> 2. That product is then a sub-project of the Incubator.
> 3. The IPMC has the "primary responsibility for the management of
> those subprojects".
>
> From the Foundation's perspective there are a number of things that
> come to mind:
> 1. We aren't a github/sourceforge/google code type platform where
> random people can upload/post what they want.
> 2. We do not have DMCA Safe Harbor protection - e.g. we are
> responsible for everything that we publish or distribute. With the
> exception of wikis and bug trackers anyone who can put something up on
> an Apache property has some form of legal relationship with the
> Foundation. This could be as simple as an ICLAs where you've
> contractually said you won't contribute anything you don't have rights
> to.
> 3. Most of the project's who have come to us aren't entities in and of
> themselves. E.g. the 'project' doesn't truly exist from a legal entity
> perspective - and even those who do are at best an unincorporated
> association of individuals. From a legal perspective - projects can't
> make or distribute a release - they don't exist - only the ASF and the
> individual(s) doing the work. Given that one of the explicit reasons
> the Foundation was created was to[5]: "provide a means for individual
> volunteers to be sheltered from legal suits"; we want them to create
> and distribute releases as the Foundation.
> 4. Whether we like it or not - the Foundation is judged on the output
> from our projects and subprojects. We have a reputation of having
> clean IP, permissively licensed open source code, with clear
> provenance. Many people explicitly copy our standards, guidelines, and
> policies because they are the gold standard for good open source
> governance.
> 5. Disclaimers generally don't remove liability, and even if they did,
> our disclaimer talks about the maturity of our projects. - And it
> certainly doesn't remove the public's expectations from us - frankly -
> losing the publics trust is as scary as the potential legal liability.
> 6. The Board has delegated the responsibility of managing and ensuring

Re: No access to dist.apache.org

[ซ่อยค่อย ลืมเขาแน่]

ในวันที่ ส. 22 มิ.ย. 2019 03:45 leerho  เขียนว่า:

> 1) I asked INFRA how to setup the proper structures in dist.a.o.
> INFRA tells me that IPMC members create the proper folders in dist/dev and
> dist/release directories and once created the PPMC should have access.
>
> 2) There is also no "Staging Profile" in Apache Nexus Repository for
> datasketches.  When does that get set up?
>
>
>
> I have been held up for a full week now in making any progress in migrating
> to ASF.  I need to create the first Release Candidate artifact so that it
> can be referenced as a dependency by our other repositories.  I keep
> running into roadblocks where the basic infrastructure has not be set up
> that would allow me to make progress.
>
> I would be really grateful if someone could help guide me through this
> first "release" process steps.
>
> Specifically:
> a) Review our POM file for correct setup for a release to Apache (at least
> a release candidate)
> b) Guide me through the required Maven or command-line commands to get this
> first release created.
>
> Thank you!
>
>
>
>
>
>
>
> On Fri, Jun 21, 2019 at 11:08 AM leerho  wrote:
>
> > 1) I am trying to create our first podling release candidate and need
> > access to dist.apache.org to record PGP keys, etc.  There is no listing
> > for our podling project datasketches and I have no write access to that
> > site.  How can I make progress?
> >
> > 2) I would like to create a temporary landing page for our website at
> > datasketches.apache.org.
> > How do I do that?
> >
> > Lee.
> >
>

Re: [VOTE] Release Apache Druid (incubating) 0.15.0 [RC2]

[ซ่อยค่อย ลืมเขาแน่]

ในวันที่ ส. 22 มิ.ย. 2019 04:21 Gian Merlino  เขียนว่า:

> > I'll leave that to others to decide, but if I were release manager, I
> > would fix them before release.
>
> Thanks for taking the time to inspect our release!
>
> I'm not the release manager here, but my thoughts are that for issues such
> as this, it makes sense to fix them for the next release rather than the
> current one. The reason is just that the cycle time is quite long for
> cutting RCs (72 hour vote on the project list + 72 hour vote on the
> Incubator list, the latter of which often takes longer than 72 hours due to
> IPMC folks being a busy bunch).
>
> On Fri, Jun 21, 2019 at 3:02 AM sebb  wrote:
>
> > On Fri, 21 Jun 2019 at 02:12, Jihoon Son  wrote:
> > >
> > > Thank you for your detailed review!
> > >
> > > We will address your comments on signing keys in the future votes.
> > >
> > > Regarding the commit id, "44c9323" is the correct commit id for the
> tag.
> > > Maybe the link is not valid.
> > > Is https://github.com/apache/incubator-druid/commits/44c9323 or
> > >
> >
> https://github.com/apache/incubator-druid/tree/druid-0.15.0-incubating-rc2
> > more
> > > valid one?
> >
> > The first one is immutable but not obvious, the second is not
> > guaranteed immutable.
> >
> > However you could use:
> >
> >
> https://github.com/apache/incubator-druid/tree/druid-0.15.0-incubating-rc2
> > (44c9323
> > <
> https://github.com/apache/incubator-druid/tree/druid-0.15.0-incubating-rc2(44c9323
> >
> > )
> >
> > > Finally, would you elaborate more on what looks wrong to you in NOTICE
> > and
> > > NOTICE.BINARY files?
> >
> > NOTICE files should contain only what is strictly required for the
> > files actually contained in the bundle to which they apply.
> > See:
> > [1]
> >
> http://www.apache.org/dev/licensing-howto.html#assembling-license-and-notice
> >
> > The header looks OK, but most of the rest looks unnecessary.
> >
> > No need to mention Apache Licensed code unless the bit you have copied
> > has a required notice in its NOTICE file.
> >
> > In the case of the other products, they may or may not require entries
> > in NOTICE.
> > That depends on their license.
> > As per [1], generally BSD and MIT code does not require an entry in
> NOTICE.
> >
> > The last section (JetS3t) does not make sense.
> >
> > Similar considerations apply to NOTICE.BINARY
> > In the case of commons-codec-1.7.jar, does the binary bundle actually
> > include the file
> > DoubleMetaphoneTest ? It seems unlikely -- if not present, the entry
> > is not required.
> >
> > The LICENSE file likewise is generally OK (assuming it corresponds
> > with the software that is in the source bundle). It's good that the
> > software versions are mentioned. However the license pointer is
> > missing for the Porter Stemmer. It can be guessed from the previous
> > entry, so that is not a blocker.
> >
> > > We will fix them if necessary for this release.
> >
> > I'll leave that to others to decide, but if I were release manager, I
> > would fix them before release.
> >
> > > Jihoon
> > >
> > > On Thu, Jun 20, 2019 at 9:46 AM sebb  wrote:
> > >
> > > > On Thu, 20 Jun 2019 at 03:39, Jihoon Son 
> wrote:
> > > > >
> > > > > Hi IPMC,
> > > > >
> > > > > The Apache Druid community has voted on and approved a proposal to
> > > > release
> > > > > Apache Druid (incubating) 0.15.0 (rc2).
> > > > >
> > > > > We now kindly request the Incubator PMC members review and vote on
> > this
> > > > > incubator release.
> > > > >
> > > > > Apache Druid (incubating) is a high performance analytics data
> store
> > for
> > > > > event-driven data.
> > > > >
> > > > > The community voting thread can be found here:
> > > > >
> > > >
> >
> https://lists.apache.org/thread.html/f4b1b708bcb7e6ec08e6a9cfcb2c0dfcb565fab353ccbb8c5f362218@%3Cdev.druid.apache.org%3E
> > > > >
> > > > > The release notes are available here:
> > > > > https://github.com/apache/incubator-druid/issues/7854
> > > > >
> > > > > The release candidate has been tagged in GitHub as
> > > > > druid-0.15.0-incubating-rc2 (44c9323), available here:
> > > > >
> > > >
> >
> https://github.com/apache/incubator-druid/releases/tag/druid-0.15.0-incubating-rc2
> > > >
> > > > I'm not sure that's the correct URL for the tag; it points to a
> couple
> > > > of archives.
> > > >
> > > > I would expect a pointer to the source code.
> > > > This should use the commit id that corresponds to the release
> > > > candidate tag, i.e. the commit id that corresponds to
> > > >
> >
> https://github.com/apache/incubator-druid/tree/druid-0.15.0-incubating-rc2
> > > > AIUI only commit ids are truly immutable
> > > >
> > > > The NOTICE and NOTICE.BINARY files look wrong to me; they have a lot
> > > > of superfluous text.
> > > >
> > > > > The artifacts to be voted on are located here:
> > > > >
> > > >
> >
> https://dist.apache.org/repos/dist/dev/incubator/druid/0.15.0-incubating-rc2/
> > > > >
> > > > > A staged Maven repository is available for review at:
> > > > 

Re: Incubator PMC report timeline for July 2019

[ซ่อยค่อย ลืมเขาแน่]

ในวันที่ ส. 22 มิ.ย. 2019 09:44 Justin Mclean 
เขียนว่า:

> Hi,
>
> Here’s the timeline for the next incubator report [1]
>
> Wed July 03 - Podling reports due by end of day
> Sun July 07 - Shepherd reviews due by end of day
> Sun July 07 - Summary due by end of day
> Tue July 09 - Mentor signoff due by end of day
> Wed July 10 - Report submitted to Board
> Wed July 17 - Board meeting
>
> Continuing on from last month and from this point on the report will be in
> markdown format.
>
> Thanks,
> Justin
>
> 1. https://cwiki.apache.org/confluence/display/INCUBATOR/July2019
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: LGPL dependency

[ซ่อยค่อย ลืมเขาแน่]

ในวันที่ ศ. 21 มิ.ย. 2019 15:37 申远  เขียนว่า:

> Sorry for my late reply, I have open a JIRA issue[1] for this problem.
>
> I'm really appreciated your help here, thank you all.
>
> [1] https://issues.apache.org/jira/browse/LEGAL-464
>
> Best Regards,
> YorkShen
>
> 申远
>
>
> 申远  于2019年6月18日周二 下午8:08写道：
>
> > Thanks for help.
> >
> > I will bring this to legal-jira this weeks later.
> >
> > Best Regards,
> > YorkShen
> >
> > 申远
> >
> >
> > Myrle Krantz  于2019年6月17日周一 下午8:07写道：
> >
> >> Thank you all,
> >>
> >> YorkShen, I think at this point the best thing to do is to open a
> "legal"
> >> ticket at this Jira (https://issues.apache.org/jira/browse/LEGAL).  I
> >> suspect that if you're only including the BSD-licensed headers, that
> Weex
> >> will only be dependent on BSD-licensed code.  It's possible that the
> >> "runtime" argument will work in this case too.
> >>
> >> But this discussion hasn't made me feel confident in either statement,
> and
> >> there are other Apache projects for which this question may be relevant.
> >> I'd like a final answer and the legal committee can provide that.
> >>
> >> Let me know if you need help formulating the ticket.
> >>
> >> Best Regards,
> >> Myrle
> >>
> >> On Fri, Jun 14, 2019 at 7:13 PM Alex Harui 
> >> wrote:
> >>
> >> > Some  things I don't think have been mentioned in this thread so far:
> >> >
> >> > 1) Even if you make Webkit optional by offering V8, I believe the ASF
> >> > criteria for "optional" includes "less than half of your users will
> use
> >> > that option" and so if Webkit offers better performance and most of
> the
> >> > users select Webkit over V8, it won't really qualify Webkit as
> optional.
> >> > 2) AIUI, the ASF does not care about the licensing of RUNTIMES (my
> >> > emphasis) your project's code runs on.  Otherwise, no ASF project
> could
> >> run
> >> > on Windows or OSX.  Apache Flex runs on Adobe Flash/AIR runtimes.
> >> > 3) I could not quickly find a direct quote for this, but I believe the
> >> ASF
> >> > does not care about the licensing of BUILD TOOLS (emphasis mine) used
> to
> >> > manipulate the source in the source release as long as the license of
> >> those
> >> > tools does not constrain usage of that code (like some non-commercial
> >> > restriction, or even a "no evil" restriction.
> >> >
> >> > AIUI, the whole purpose of these restrictions is to not place
> >> restrictions
> >> > on modifications to source or use of source when that source is
> >> eventually
> >> > executed (whether interpreted or compiled or other).
> >> >
> >> > So, if I've made that clear so far, the question I have for Weex is:
> >> How
> >> > is Webkit used in Weex?  Is it just a runtime and libraries for that
> >> > runtime?  If so, then I believe it is ok to have a dependency on LGPL
> >> > Webkit, but I would recommend that you find a way to not bundle Webkit
> >> in
> >> > the release artifacts.  Have it downloaded or make it a "prerequisite"
> >> just
> >> > like I think every ASF Java-based project says you must install a Java
> >> JDK
> >> > and don't bundle Java JDKs.
> >> >
> >> > Other questions to ask relative to whether Webkit is a runtime or
> build
> >> > tool:
> >> >
> >> > A) Will anybody realistically want to modify the Webkit sources in
> order
> >> > to use Weex?  If no, that's great, and another reason to not bundle
> >> those
> >> > header files with your sources.
> >> > B) Will use of the WebKit header files and other binaries you depend
> on
> >> > create a restriction on use?  If no, that's great as well, and I think
> >> if
> >> > the answer to A and B are both "no", the IPMC should consider Webkit
> to
> >> be
> >> > a runtime/build-tool dependency and let it go.
> >> >
> >> > HTH,
> >> > -Alex
> >> >
> >> >
> >> > On 6/14/19, 5:09 AM, "York Shen"  wrote:
> >> >
> >> > It depends on the definition of optional dependency. Weex targets
> >> iOS,
> >> > Android and Browser environment and Webkit header files and shared
> >> library
> >> > are only bundled for Android environment. As for other environments,
> >> the OS
> >> > or browser itself has exposed enough API for Weex.
> >> >
> >> > PS: I am pretty sure that the iOS system itself uses almost the
> same
> >> > code of Webkit as Weex does to build its WKWebView. It’s really
> strange
> >> > that’s ok for Weex iOS and not ok for Weex Android.
> >> >
> >> > > 在 2019年6月14日，19:17，Justin Mclean  写道：
> >> > >
> >> > > Hi,
> >> > >
> >> > >> Well, what if Weex copies some BSD header files in Webkit then
> >> run
> >> > on Webkit? IMHO, the Webkit is also an environment for Weex in this
> >> case.
> >> > >
> >> > > You still didi not answer if this is an optional dependancy? But
> >> > again either way I suggest you ask on legal discuss.
> >> > >
> >> > > Thanks,
> >> > > Justin
> >> > >
> >> > >
> >> > >
> >> > >
> >> -
> >> > > To unsubscribe, 

Re: LGPL dependency

[Justin Mclean]

Hi,

> 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.

Not quite actually it not dual licensed in the tradition l sense. It’s not 
licensed A or B but it’s licensed A and B as parts are A licensed and parts are 
B licensed.

Thanks,
Justin
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: LGPL dependency

[Craig Russell]

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: 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