Re: Podlings, the Incubator, relationships and Apache

[Greg Stein]

On Fri, Jun 28, 2019 at 9:59 PM Justin Mclean 
wrote:
>...

> >   It appears there is general consensus that "right to distribute closed
> source" would be the main and potentially only blocker for podlings.
>
> That is not the case (re this is a blocker) I suggest you read that legal
> thread again. Also infra makes distribution policy.
>

*distribution*

Infra does not care about the contents. If a PMC says "we +1 the contents",
then Infra will not second-guess that. Leave out LICENSE, NOTICE, or do
those files wrong. Include jars, Cat X source. Whatever. We aren't going to
police that. Binaries in there? Knock yourself out. Legal might get on your
case, but that's Not Our Problem(tm).

If the IPMC says "here is a podling tarball that we will allow", then it
can be put into distribution. Use whatever rules you want for the contents,
or lack of rules. Infra just wants it placed into our distribution system
in a specific way, to ensure correctness, auditing, and resilience.

VP Infra has already stated the above. As an Officer of Infrastructure, I
concur and reiterate that position.

Regards,
Greg Stein
InfraAdmin, ASF

Re: Podlings, the Incubator, relationships and Apache

[Justin Mclean]

Hi,

> Recall that with other PMCs, the PMCs themselves are directly responsible for 
> the development of the code. Not so with the IPMC.

Where is this documented? Where has the board granted this? It’s not in the 
IPMC's policy or in it charter. IMO Until that happens it always going to be a 
cause of conflict in the IPMC.

> Incubation should be a... wait for it... 'safe space' (/me ducks) for 
> podlings to learn the ropes, to fail doing the "normal" things that a PMC 
> must do (including releases), because that is how people learn best. As long 
> as the outworld world is aware that podlings can not, and should not, be 
> expected to be "the same" as other PMCs, we are OK.

I don’t disagree that’s where we would like to be, but I fail to see how people 
outside the ASF would reach that conclusion. The DISCLAMER, for instance, says 
nothing about this.

Thanks,
Justin

Re: Podlings, the Incubator, relationships and Apache

[Justin Mclean]

Hi,

>  An "exception" would be a potentially permanent allowance of non-compliance.

Exceptions when given have been temporary and not permanent.

>   It appears there is general consensus that "right to distribute closed 
> source" would be the main and potentially only blocker for podlings.

That is not the case (re this is a blocker) I suggest you read that legal 
thread again. Also infra makes distribution policy.

Thanks,
Justin


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

[VOTE] Release Apache Flagon (Incubating) v2.0.0

[Joshua Poore]

Hi Folks,

Please VOTE on the Apache Flagon 2.0.0 Release Candidate # 2.

About Flagon: http://flagon.incubator.apache.org/ 


We require +2 binding votes from PMC to proceed with the release.

Our community and mentors have voted on this release with the following results:

[ 5 ] +1, let's get it released!!!
Joshua Poore
Laura Mariano
Rob Foley
Michael Schreiber
Dave Meikle*

[ ] +/-0, fine, but consider to fix few issues before...
[ ] -1, nope, because... (and please explain why)

see Apache Flagon community VOTE thread @lists: 
https://lists.apache.org/thread.html/488a0a3d686fd6b1948527f4e14c07f353365cdd56aa9b62f7327003@%3Cdev.flagon.apache.org%3E
 


This Major release includes a wealth of additional features beyond v1.0.0, 
notably:

1. Interval Logs
2. WebExtensionSupport for Chrome/Firefox
3. API support for filtering, mapping, and custom logs 
4. Overhauled Unit Tests

We solved 59 issues: 
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12343068&styleName=Text&projectId=12320621&Create=Create&atl_token=A5KQ-2QAV-T4JA-FDED%7Ceda9fbce2795c14b56345bf5daee2a8a893d249c%7Clin
 

 

Git source tag (909b531): 
https://github.com/apache/incubator-flagon-useralejs/releases/tag/2.0.0-RC2_06_26_2019
 


Staging repo: https://dist.apache.org/repos/dist/dev/incubator/flagon/ 


Source Release Artifacts: 
https://dist.apache.org/repos/dist/dev/incubator/flagon/apache-flagon-useralejs-incubating-2.0.0-RC2/
 


PGP release keys (signed using F9374FAE3FCADF6E): 
https://dist.apache.org/repos/dist/dev/incubator/flagon/KEYS 
 (new keys will 
be moved over to /release after ReRelease completes)

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 2.0.0

Re: Podlings, the Incubator, relationships and Apache

[Alex Harui]

On 6/27/19, 10:57 PM, "Justin Mclean"  wrote:

But VP legal said as much the other day. "we can NOT allow any relaxation 
of the ASF release policy for a TLP.”

 I interpret that to mean that a TLP must eventually get around to fixing 
non-compliance.  A TLP cannot stop attempting to find non-compliance before 
shipping a release as well.  An "exception" would be a potentially permanent 
allowance of non-compliance.  And since I think VP Legal said that the legal 
committee mainly does risk profiling of non-compliance and the "business 
decision" is up to the PMC, I think that gives the IPMC the ability to be give 
podlings even more time to deal with non-compliance about most things.  It 
appears there is general consensus that "right to distribute closed source" 
would be the main and potentially only blocker for podlings.

My 2 cents,
-Alex   


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

Re: LGPL dependency

[Myrle Krantz]

I've said it on dev@weex, and on private@incubator, but I wanted to make
sure and say it here too.  Weex should cut the release.  We'll figure out
the rest later.  The straw poll on private@incubator also confirms: you
have my support and the support of many of the mentors in the incubator.  I
apologize for us blocking you for so long.

Best Regards,
Myrle Krantz
PMC Member, Apache Incubator

On Thu, Jun 27, 2019 at 6:06 AM 申远  wrote:

> It looks like we have got result[1] from Legal VP, I will bring it here now
>
>1. It's fine if Weex only could include header files under 2-clause BSD
>license from Webkit at compiling time and has a dynamic link to
> Webkit.so
>at runtime.
>2. It's recommended that excluding Webkit.so from Weex convenience
>library. Users would include the code snippet below to include both weex
>and webkit.
>
> 
>
> weex_sdk
>
> 
>
> 
>
> webkit
>
> 
>
>
> The following is what I need to consult from Incubator:
>
> Google will ban all apps without 64 bit published in Google Play from 1st,
> August, 2019 [1]. Though it's a good idea of excluding Webkit.so from
> convenience library of Weex, Weex community needs to publish next release
> with 64-bit support ASAP to give users enough time to upgrade Weex. I'd
> like to remain webkit.so in convenience library of Weex only for next
> release.
>
> [1] https://issues.apache.org/jira/browse/LEGAL-464
> [2] https://developer.android.com/distribute/best-practices/develop/64-bit
>
> Best Regards,
> YorkShen
>
> 申远
>
>
> Roman Shaposhnik  于2019年6月24日周一 上午7:32写道：
>
> > 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
> 

Re: Podlings, the Incubator, relationships and Apache

[Jim Jagielski]

> On Jun 27, 2019, at 7:57 PM, Justin Mclean  wrote:
> 
> Hi,
> 
>> The Incubator itself is a PMC.
> 
> OK that's sorted.
> 
>> Now let's talk about podling releases... When the IPMC votes on accepting a 
>> podling release, and it passes, my opinion is that the Incubator takes on 
>> the resultant legal obligations associated w/ any PMC doing a release. Now 
>> the podling releases themselves are noted and described as "not GA" and "not 
>> official", et.al. but this is, again IMO, simply to make it clear to anyone 
>> who is downloading and using the software that the expectations normally 
>> associated with "regular" Apache releases do not apply, such that there 
>> could be some licensing issues, etc, that would be verboten in "official" 
>> releases, but may exist here. In other words: this is a podling release; 
>> expect issues and mistakes and churn.
> 
> Except it's not, as it seems the IPMC doesn’t need to abide by what other 
> PMCs need to abide by when making releases :-) (Which is ironic given the 
> IPMC is tasked with teaching and passing that knowledge on.) And that policy 
> exception is not documented anywhere. :-) Nor has the board, to my knowledge, 
> approved such an exception. Yay! So how is a voted on PMC release, an act 
> which make it official, is not an official release? Do you see how this might 
> be confusing or open to a board range of interpretations?
> 

Yes, I see how it can be confusing and open to a range of opinions.

Recall that with other PMCs, the PMCs themselves are directly responsible for 
the development of the code. Not so with the IPMC. The expectation w/ other 
PMCs is that they know how to do releases, and that their releases will be 
correct and valid. With podlings, the expectation is the reverse. It is 
expected that podling releases will have issues... in fact, iirc, somewhere 
along the line *making* a podling do a release was added as a required step to 
graduation, to make sure that upon graduation, they knew how to do it.

Incubation should be a... wait for it... 'safe space' (/me ducks) for podlings 
to learn the ropes, to fail doing the "normal" things that a PMC must do 
(including releases), because that is how people learn best. As long as the 
outworld world is aware that podlings can not, and should not, be expected to 
be "the same" as other PMCs, we are OK.

Maybe we should think of the podlings more as "Apprenticeship PMCs" ;)


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

Re: [VOTE] Apache Tuweni 0.8.0

[Jim Jagielski]

+1

> On Jun 27, 2019, at 5:04 PM, Antoine Toulme  wrote:
> 
> I’m not quite sure what to do. If I don’t hear by tomorrow I’ll close this 
> vote as passing.
> 
>> On Jun 27, 2019, at 10:42 AM, Greg Stein  wrote:
>> 
>> On Thu, Jun 27, 2019 at 12:34 AM Justin Mclean 
>> wrote:
>> 
>>> Hi,
>>> 
 I see a lot of "oh no. a bad file". What is the takeaway from that? "The
 IPMC thinks we should not release.”
>>> 
>>> Has anyone voted -1? Nope. And even if they did a -1 vote is not a veto.
>>> 
>> 
>> Great. Semantics. "But I didn't really say veto."
>> 
>> Your "not allowed" is read as a veto by any reasonably-minded person. If
>> you think it should NOT be read as -1, then put a +1 into your message.
>> That did not happen. So it is NOT read as +1 for the podling. I added my +1
>> as the third. Mostly to get it over with, and (honestly:) for some spite
>> about the whole process.
>> 
>> Look. Clearly this discussion is about rulesmithing to keep the status quo.
>> Carry on.
>> 
>> Maybe I should say you're being an ass about the whole process. :-)
>> 
>> -g
>> 
>> ps. per your rules [1], I put a smiley on that sentence, so it doesn't mean
>> anything.
>> [1]
>> http://mail-archives.apache.org/mod_mbox/incubator-general/201906.mbox/%3CA2A7580A-20DA-4894-9590-14D563C3D0E0%40me.com%3E
> 
> 
> -
> 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: [VOTE] Apache Tuweni 0.8.0

[Jim Jagielski]

This speech policing is starting to get quite on my nerves. Especially when it 
ignores the intent behind such things... 99% of the time the smiley is there to 
say "Yeah, I know that sounds harsh, but it's a little joke". It is an attempt 
to replicate in text what is natural in "real life"... when someone says 
something and then, to defuse the situation a little, smiles.

This is how people talk. This is how people communicate.

Let's all recall that one of the big tenets in 1984 is that if you can control 
how people talk, you can control how they think. Can we PLEASE not go there.

> On Jun 27, 2019, at 6:15 PM, Greg Stein  wrote:
> 
> On Thu, Jun 27, 2019 at 4:29 PM Craig Russell  wrote:
>> ...
> 
>> No. Smiley face doesn't count.
>> 
> 
> Apparently you missed the point when Justin did that to me. Hmm?
> 
> Of course it doesn't count. Why don't you go police th VP Incubator, okay?
> 
> -g


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