Re: [DISCUSS] NuttX Proposal

[Alex Harui]

Might be less risk and disruption for a few experienced ASF folks to go "live 
amongst" the NuttX folks where they are now and verify that that the founder's 
authority and reputation will not result in a BDFL effect.

Just a thought,
-Alex

On 12/2/19, 12:48 PM, "Ted Dunning"  wrote:

Very well said.

I am optimistic.

On Mon, Dec 2, 2019 at 9:26 PM Gregory Nutt  wrote:

>
> > This is a good discussion to have had before entering the incubator, and
> I'm satisfied that the intent is good, and the podling can demonstrate
> during incubation that the founder will in fact step back and allow the
> project to move forward without the founder's undue influence.
> >
> > Note that it's fine for the founder to continue to work on the project,
> but in a different role.
>
> I have been standing back and not getting deeply involved with this
> discussion because it pertains too closely to me.  It is my intention to
> divest myself of total authority over the project just as stated in the
> Proposal.  Further, it is my intention to stay out of the initial
> formation of the project as much as possible, in partial fulfillment of
> Ted Dunning's "thought experiment."  I intend to vote 0 on all decisions
> before the PPMC -- unless, I suppose, I had some very strong opinion
> about some topic.  I cannot imagine what topic that might be, however.
>
> I will be available as needed for information needed by the others to
> accomplish this transition but for the most part, just consider me as on
> vacation in place.  I will help as much as needed and stay out of the
> way as much as possible.
>
> I suppose I should say a little more about my motivations in this.
> Without some understanding, is is reasonable to be skeptical.  Yes, the
> project is very dear to me and the result of many years of blood, sweat,
> and tears and years of work mostly done alone for crazy long hours.
> Being a "benevolent dictator" does not proper describe my past role
> because I was the ONLY person on the project.  I did everything.  I
> still do.
>
> There are two things that motivate me:  First, the workload has gotten
> to be far too much for one person.  I dispose of around 60-100 changes
> per week and really have no personal life left.  It is more than I can
> do (and much more than I can do well).  The only real way to solve that
> is to open the project up to others working as equals.  The second, and
> more important, motivation is the I am closing in on 70 years old now.
> I retired 8 retires ago and I cannot realistically control this project
> long into the future.   For my personal health and sanity, I really need
> to detach and let the project take a life of its own that does not
> depend on me in any way.
>
> I would see the biggest risk to a new PPMC would not be me, but rather
> the sheer volume of work that the PPMC is stepping into.  I am prepared
> for some initial chaos and perhaps a missed release cycle.  But I have
> come to accept that that is a reasonable price to pay for a clean
> knife-edge hand-off.
>
> Greg
>
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Podlings & IP Clearance

[Alex Harui]

IIRC, the main thing that matters is that all incoming code that was developed 
outside the ASF gets cleared.  For podlings, there is frequently one big code 
donation that eventually gets turned into a release.  The podling gets to put 
the code in a repo and then clear it.  I believe that's mainly to help get the 
community going with the least delay.  Podlings often do that one release and 
then graduate to TLP.

But once you have clean code in your repo, before you mix a bunch of other code 
into it, it is advised to clear it before mixing that code.  The IP Clearance 
process is the main way to do that and the Incubator is the central log of 
these big donations being cleared.

I don't think Weex had to go through IP Clearance if the mentors felt they 
could inspect and clear the code, but it doesn't hurt to ask for more eyes on 
it.

At least, that's how I remember it from my podling days.  Flex received several 
donations before and after graduation.

My 2 cents,
-Alex

On 10/4/19, 12:36 AM, "申远"  wrote:

Hi

As a PPMC member of Weex, I didn’t find any documentation about the IP
clearance process for Podlling project, so I just followed what other PPMC
did after asking in this mailing list [4]. I am Ok to do it in another way
if it’s written in the documentation clearly.

IMO, the problem here is that we don’t have an IP clearance process for
podllings, so podllings have no other way but follow the standard IP
process of TLP project.

[4]

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail-archives.apache.org%2Fmod_mbox%2Fincubator-general%2F201909.mbox%2F%253cDAEE7CD2-C05A-4A09-867C-37F1C1B19DF8%40classsoftware.com%253edata=02%7C01%7Caharui%40adobe.com%7Cb9f970fbe1274b9a4d5608d7489da1b4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637057714181342086sdata=Ak%2BXNWhu2ltjgGm7vksfmzyyxcbWHhwHNyUnuv8FjB4%3Dreserved=0

Dave Fisher 于2019年10月4日 周五13:18写道：

> Hi -
>
> > On Oct 3, 2019, at 9:12 PM, Justin Mclean 
> wrote:
> >
> > Hi,
> >
> >> The recent vote from Weex [1] made me think about the IP Clearance
> >> process.  Per [2], podlings should not follow this process and instead
> are
> >> directed to look at [3].
> >
> > I always assumed that that was advised about the initial codebase and
> don’t see an issue with following [2] past that. It certainly could be 
made
> clearer.
>
> I’ve always considered it to be the mentor’s job to assure IP was
> considered for podlings donations.
>
> A greybeard told me recently that the board added IP clearance to the IPMC
> for TLPs
>
> Regards,
> Dave
>
> >
> > Thanks,
> > Justin
> > -
> > 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
>
> --
Best Regards
York Shen
申远

Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

[Alex Harui]

IMO, the key change as already been made:  There is now a WIP-disclaimer.

AFAICT, the rest of this thread has been an attempt to create an objective 
process around a subjective topic (in this case risk).  The better use of time 
may be to just launch an experiment by making the one change suggested by Greg: 
 That Infra and the board will allow a podling to put packages containing the 
WIP-disclaimer on dist.a.o as long as those packages also include "-incubating" 
or "-incubator" in the package name.

IMO, if that can be agreed to by the stakeholders, those stakeholders are 
agreeing that any risks to the foundation and RMs posed by Justin are worth 
taking and we can hopefully just move on and find out what happens.

Ideally, the WIP-disclaimer makes the IPMC vote:
1) optional
2) helpful
3) advisory

...instead of "potentially blocking".

This new disclaimer should allow mentors to allow the podlings to publish 
packages for their users the way they probably did before entering incubation.  
The podlings will have the option to push the packages to dist.a.o and then, if 
they want the legal shield protection, call for a vote from the IPMC if they 
don't have 3 mentor votes.  The key risk here is whether the WIP disclaimer 
will help ward off possible legal action by a user of the package.  IOW, is it 
too risky that something really awful will be missed by the mentors and PPMC in 
these packages?  I doubt it.  There might be GPL or proprietary code that needs 
to be replaced eventually.  But the new disclaimer helps and I just think folks 
aren't going to try to sue the ASF or a podling RM during this transition 
period.

If a podling is lucky enough to have 3 mentors review the packages, then that 
should make those packages an official ASF release and thus protect the RM.  If 
there aren't 3 mentors reviewing the packages, then the podling will have a 
reason to call for an IPMC vote to get the 3 votes.  The new disclaimer should 
greatly reduce the chances of a -1 vote.  Instead, issues found will be logged 
in the podling's bug tracker.

If the 3 mentors are certain enough of their review of the packages, then the 
podling can go on its merry way towards graduation.  Otherwise, the podling 
should call for additional IPMC reviews of their packages in order to avoid 
major surprises before graduation.  They just don't need to do it prior to 
publishing their packages, which makes the IPMC review helpful and advisory 
instead of potentially blocking.  Yeah, there is a risk that a published 
package will be so awful it needs to be pulled in spite of the new disclaimer, 
but IMO, there is always a chance we've missed something.  Practically 
speaking, if Justin is one of the 3 mentors, the podiing is probably in good 
shape heading towards graduation, of not, it probably is a good idea to get 
Justin to review the packages at some point.

IMO, it shouldn't take a special team of Greg/Ross/David to do this experiment. 
 As long as podlings can publish before the vote/review, and the new disclaimer 
makes the chance of pulling something back almost zero, every podling can 
choose this new route and the IPMC vote will rarely if ever be a gate.  It was 
this late gate which was stricter with the old disclaimer that was the problem 
for Zipkin.

HTH,
-Alex

On 8/14/19, 8:50 AM, "Sam Ruby"  wrote:

On Wed, Aug 14, 2019 at 1:24 AM Justin Mclean  
wrote:
>
> Hi,
>
> >> This is because of ASF bylaws i.e only PMC votes are binding on 
releases.
> >
> > That is not in the Bylaws. Stop making stuff up.
>
> That the way it’s been explained to me, several times, by experienced ASF 
people, that only PMC votes are binding on releases and podlings are not 
mentioned in the ASF bylaws. Bylaw wise see section 6.3.  But you're right, it 
would be more precise to say, it's a combination of 6.3 of the bylaws of the 
ASF and the ASF's policy on voting on releases. [1]

Concrete suggestion, and an offer to help.

The ASF bylaws contain a lot of curiosities such as "each member of a
Project Management Committee shall serve on such committee for a
period of one year or until his or her successor is elected and
qualified or until his or her earlier resignation or removal", and
have been interpreted as the board is the one that determines
membership of PMCs.  Over time, that understanding has evolved, and is
currently implemented as a notification requirement[2].

Perhaps something similar can be made to work here.  Outline of
proposed process:

1) Concurrent with the start of a release vote by a PPMC, the IPMC is
to be notified that that vote is happening.  IPMC members are
encouraged to participate in the vote process on the PPMC list where
it is happening.

2) If anybody on the IPMC calls for a IPMC vote on the release before
the release occurs, then the release is blocked from happening until
this 

Re: New disclaimer text

[Alex Harui]

Suggestion:  The DISCLAIMER references a detached copy of the DISCLAIMER at 
dist.a.o/releases/incubator/project and that detached copy is the one that gets 
updated with late breaking stuff.

Re-rolling required re-GPG-signing, new hashes, etc.

-Alex

On 7/3/19, 2:08 PM, "Daniel Shahaf"  wrote:

Dave Fisher wrote on Wed, 03 Jul 2019 12:16 -0700:
> This only works for issues known before a release is cut. It does NOT 
> WORK if the issue is discovered during the release vote. Why? Because we 
> are trying to allow the release to go through without redoing it and 
> this would require reworking the release.
> 
> I would rather do it outside of the release. Policing the actual 
> DISCLAIMER is not easily feasible and decreases the burden.

I recommend to put the information in DISCLAIMER.  Yes, that means bugs
in DISCLAIMER require re-rolling, but:

1. Bugs in DISCLAIMER should be found before the first artifact is
   rolled.  It's simply an audit and it can be done directly on the
   source tree in version control.

2. Re-rolling shouldn't be an expensive step that should be avoided. It
   should be "Edit DISCLAIMER, commit, run script to roll" followed by
   everyone diffing the old artifact to the new one and re-casting their
   votes based on the work they already did to review the old artifact.
   (And yes, it's still some effort, about which, see #1.)

3. Artifacts should state their exact license terms — accurately,
   completely, and (de facto standard) in-band.

Daniel

-
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

[Alex Harui]

FWIW, I reconcile it as:

Incubator is a PMC and must record a business decision to call something an ASF 
release in order to place that release under the legal protection of the ASF.  
ASF releases may have policy non-compliance issues.  No TLP can decide on its 
own to never comply with policy.  But the business decision of the costs of 
delaying a release to correct non-compliance vs risks of distributing a release 
with any non-compliance is up to the TLP.  VP Legal will assert a risk profile 
for any non-compliance and VP Legal or any ASF Member or PMC Member should try 
to stop a release if a TLP decides to distribute something highly risky.   But 
it is up to any TLP.  Including the IPMC.  And so the Incubator can do whatever 
it wants within limits.  Any of us should protest if the IPMC starts allowing 
releases with high risk.  But with the disclaimer and -incubating suffixes, the 
risk of many non-compliance issues are low, even CatX and binary inclusions.

Whether the incubator needs to have a secondary vote is not required by the 
above.  IPMC members could drop in on the podling vote thread.  Podlings with 3 
active mentors that vote on the podling's vote thread could be deemed 
sufficient.

My 2 cents,
-Alex

On 6/30/19, 12:11 PM, "Davor Bonaci"  wrote:

I do -not- have a problem where this is all tracking towards and believe it
is right, but I do have a problem with how it is justified and explained.

People say: "Incubator is a PMC/TLP", "Incubator takes on the resultant
legal obligations associated w/ any PMC doing a release", "we can NOT allow
any relaxation of the ASF release policy for a TLP", and then conclude that
Incubator can do ~whatever it wants. This logic does not pass the
consistency test.

So... if you want that [new] people in the future don't trip on this, it is
*necessary* to break this logic somehow.

On Fri, Jun 28, 2019 at 8:31 PM Greg Stein  wrote:

> 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

[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: Podlings, the Incubator, relationships and Apache

[Alex Harui]

While you've been going through the history and other docs:  Does it actually 
say somewhere that a true ASF release MUST NOT contain any non-compliance of 
policy?  Or is it possible that the communities must fix some non-compliance 
issues right away and can fix others later?  Then it isn't about relaxing 
policy or exceptions to policy, it is just acceptance that not all policy 
non-compliance issues are "must fix now".

Sebb just reported that something like 3 TLPs have releases that are not 
compliant with the NOTICE file policy.  I don't think the legal shield has been 
damaged nor will the board shut down those projects.  I imagine they will 
simply take note and fix it in their next release.  They may not even have to 
drop everything there are currently working on and push out a release with the 
fix.

Again, the restaurant food handling codes allow the restaurant owners to fix 
some non-compliance issues over time.

HTH,
-Alex

On 6/27/19, 4:58 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?

Thanks,
Justin
-
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

[Alex Harui]

On 6/24/19, 9:12 AM, "Roman Shaposhnik"  wrote:

> What kinds of policy violations truly affect the legal shield if the 
non-compliance:

You're asking the wrong question. You're still asking the TLP question.

I'm asking the TLP question to understand how big the difference is between TLP 
and Podlings.  If we allow podlings the ability to make releases with certain 
kinds of issues until they eventually get one release right, the question still 
remains that once they graduate and add some new dependency and make some (what 
I consider minor) non-compliance, will they be required to consider all 
non-compliance a release-blocker?  That would be a big cliff to jump off of and 
probably make for some unhappy newly-minted TLPs.

If you are saying that the TLPs get to make a "business decision" that sounds 
good to me.  IMO, it would be nice to have some sort of risk profile assessment 
associated with each release policy to help TLPs make better business decisions.

My 2 cents,
-Alex


-
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

[Alex Harui]

But, IMO, the reason the question went to VP Legal is that it doesn't really 
matter what the IPMC thinks if their "business decision" will have an impact on 
the "Legal Shield" and the insurance premiums that go with it.  So I think the 
question got lost on legal-discuss.  The "space of options" should probably be 
constrained by the "Legal Shield".

What kinds of policy violations truly affect the legal shield if the 
non-compliance:
1) is actually released
2) released but noted in RELEASE_NOTES or DISCLAIMER
3) released but not corrected in the next release

Ted, Roy, Hen, seem to say that only "no rights to distribute" and "CatX" 
should not be released by TLPs but "CatX" should be ok for podlings.  My 
takeaway from Roman is that all policy non-compliance issues are release 
breakers and Incubator should either be granted special status or not.  But I'd 
like to see the first question be answered so we can understand how special the 
Incubator status would have to be.  How different would it be from TLP releases 
and what risks to the foundation would that pose and could a DISCLAIMER or 
other means mitigate that risk?  Without knowing how the Legal Shield works, it 
is hard to know what the options truly are.

HTH,
-Alex

On 6/23/19, 10:43 PM, "Davor Bonaci"  wrote:

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

[Alex Harui]

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

[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
adherence to policies and guidelines to the IPMC. I don't see this
responsibility as boolean. It's not perfect compliance vs. failure.
IMO, the IPMC has been delegated the decision making 

Re: Incubation Pain Points

[Alex Harui]

, but things like "no downstream constraints" were a bit
too vague. And some mostly kind of sort of accepted Apache ideas like votes
should mostly be used to record consensus rather than make decisions are
definitely too vague.

OK. So we learned that lesson. And the maturity model was created. And
documentation was done.

One very clear sub-lesson is the unwritten rules really don't work when
there are a large number of new people. Peoples' understanding changes or
varies even when there is apparent consensus. Unwritten rules are also just
not visible enough and can't be passed from one newbie to another.

And here we are. Folks are now saying that we need to be a lot looser. That
there is a lot of leeway in how projects interpret the traditions we have.
That we should just specify abstract invariants.

A lot of that involves some good ideas. But we need to not just circle back
to the exact same place we started.

We can damp the pendulum a bit by the following going to a middle ground:

1) *Add* the abstract principles (aka invariants) to an introduction to our
documentation.

2) Use the maturity model. But add a statement that a project could
negotiate an alternative maturity model during incubation as long as the
IPMC agrees and it meets the invariants.

3) allow some non-conforming podling releases with special approvals.
    
    

On Tue, Jun 18, 2019 at 9:32 AM Alex Harui  wrote:

>
>
> On 6/18/19, 5:03 AM, "Jim Jagielski"  wrote:
>
>
>
> > On Jun 18, 2019, at 7:42 AM, Bertrand Delacretaz <
> bdelacre...@codeconsult.ch> wrote:
> >
> > On Tue, Jun 18, 2019 at 1:18 PM Jim Jagielski 
> wrote:
> >> ...prepping the existing community regarding what "moving to the
> ASF means" is the job of the Champion, no?...
> >
> > I agree but it has to be based on written docs, not oral tradition 
as
> > that does not scale.
> >
>
> Of course... but lack of it being on written docs does not make it
> invalid nor not policy.
>
> Just trying to follow these threads, it isn't clear there is agreement,
> even among the "old-timers", as to what the invariants really are whether
> written or oral.
>
> For example, I'm a bit surprised that none of the old-timers disagreed
> that there is an Apache Culture and that incubation is about assimilating
> into that culture.  I thought I read many times on various ASF lists that
> the ASF is comprised of many projects each with their own culture.  And
> that the only common ground is a "Way" not a "Culture".  But then various
> folks try to define the "Apache Way" and other folks disagree with their
> definition.
>
> At least in the US, there are many places where the residents have formed
> or retained their own culture.  Folks immigrating to the US are not
> required to assimilate into any particular aspect of US culture.  They are
> only asked to obey certain laws.  And even then, the strictness of law
> enforcement is somewhat influenced by the local culture and context.
>
> What really are the invariants at the ASF that require strict inflexible
> immediate enforcement?  I think there are really only a relatively small
> number of them:
>
> 1) No closed source in a release
> 2) No CatX in a release
> 3) No corporation owns decision making
> 4) Majority vote on releases
> 5) No advertising the general availability of non-releases.
> 6) A protocol for handling security issues.
> 7) ASF does not pay developers
> 8) Don't violate US Non-Profit rules
>
> A podling could be granted more flexibility around #2 and #5 with the
> additional requirement of DISCLAIMER and -incubating labels.
>
> Could everything else really be seen as goals for a community?  Then it
> would be "Community over Code and Policy except these 8 things".
>
> My 2 cents,
> -Alex
>
> -
> 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
>



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

Re: Incubation Pain Points

[Alex Harui]

On 6/18/19, 5:03 AM, "Jim Jagielski"  wrote:



> On Jun 18, 2019, at 7:42 AM, Bertrand Delacretaz 
 wrote:
> 
> On Tue, Jun 18, 2019 at 1:18 PM Jim Jagielski  wrote:
>> ...prepping the existing community regarding what "moving to the ASF 
means" is the job of the Champion, no?...
> 
> I agree but it has to be based on written docs, not oral tradition as
> that does not scale.
> 

Of course... but lack of it being on written docs does not make it invalid 
nor not policy.

Just trying to follow these threads, it isn't clear there is agreement, even 
among the "old-timers", as to what the invariants really are whether written or 
oral.

For example, I'm a bit surprised that none of the old-timers disagreed that 
there is an Apache Culture and that incubation is about assimilating into that 
culture.  I thought I read many times on various ASF lists that the ASF is 
comprised of many projects each with their own culture.  And that the only 
common ground is a "Way" not a "Culture".  But then various folks try to define 
the "Apache Way" and other folks disagree with their definition.

At least in the US, there are many places where the residents have formed or 
retained their own culture.  Folks immigrating to the US are not required to 
assimilate into any particular aspect of US culture.  They are only asked to 
obey certain laws.  And even then, the strictness of law enforcement is 
somewhat influenced by the local culture and context.

What really are the invariants at the ASF that require strict inflexible 
immediate enforcement?  I think there are really only a relatively small number 
of them:

1) No closed source in a release
2) No CatX in a release
3) No corporation owns decision making
4) Majority vote on releases
5) No advertising the general availability of non-releases.
6) A protocol for handling security issues.
7) ASF does not pay developers
8) Don't violate US Non-Profit rules

A podling could be granted more flexibility around #2 and #5 with the 
additional requirement of DISCLAIMER and -incubating labels.

Could everything else really be seen as goals for a community?  Then it would 
be "Community over Code and Policy except these 8 things".

My 2 cents,
-Alex

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

[Alex Harui]

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




-
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 Harui]

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

[Alex Harui]

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

[Alex Harui]

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

[Alex Harui]

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

[Alex Harui]

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: Podling releases and release policy

[Alex Harui]

Given that [1] says "may" and not "will" and that Roy has said that if it isn't 
illegal and better than the last release it is ok to ship a release candidate, 
maybe the ASF should adopt the approach that every release policy issue that 
isn't about the legal right to distribute some IP can be addressed in the next 
release if a TLP, and by graduation if a podling.

My 2 cents,
-Alex

On 6/4/19, 8:00 PM, "Justin Mclean"  wrote:

Hi,

Thanks Sam for the advice.

> Been lurking.  Before I proceed, I will note that you have two members
> of the board and one infrastructure representative participating.
> Each has either explicitly or implicitly supported the idea of the
> incubator setting direction for podlings.

Set direction sure, but does that include ignoring board policy? While we 
do currently for minor issues, I’m reasonably sure the board is OK with that, 
well none have complained. I’m not sure if doing that for serious issues is 
overstepping the mark or not.

See, for example, "why a foundation wide policy is needed”:  [1]
"Deviations from this policy may have an adverse effect on the legal 
shield's effectiveness, or the insurance premiums Apache pays to protect 
officers and directors, so are strongly discouraged without prior, explicit 
board approval”

> Now my observation.  My experience is that when a PMC comes to the
> board with an open ended question asking for advice, the responses are
> not crisp.

Understood. I was asked by a board member to ask the question in the next 
report, although they may not of been wearing that hat at the time.

> An approach I have found much more successful: come up with a
> proposal.  Often times it will get approved.  Some times you will be
> asked to make changes. 

OK I've written down what we currently do and that some have expressed an 
opinion that podling should be able to ignore distribution policy up until 
graduation in the current report. There is some support for it and no strong 
objection if that is OK by the board which is I think close to consensus.

If I am mistaken there please speak up.

Personally I don’t really care either way other than A) if I vote on or am 
a release manger for a release do I have the ASF legal protection (even if that 
release has serious issues) and B) it’s clearer when podlings need to fix 
issues.

I’m happy to change what I’ve written in the report into a proposal with 
the view that, from now on that IPMC will allow serious issues in podling 
releases, so the board only needs to say yes/no either explicitly or implicitly 
rather than choose from a list of options a sit currently worded.

If permission is given, then we’ll modify documentation and the DISCLAIMER 
to cover this and you’ll see fewer -1 votes. Podlings will be expected (as 
before) to fix all issues before graduation, so this may potentially block some 
podlings from graduation.

If they say no then we'll refine the list of serious issues we vote -1 on 
and communicate that to podlings. I think we can reasonably agree on that list 
with perhaps one possible exception (compiled code in binaries).

If anyone disagrees with this approach, or has an alternative suggestion, 
please speak up.

Thanks,
Justin

1.  
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23whydata=02%7C01%7Caharui%40adobe.com%7Cbc987bf1219d42bfa17e08d6e961fdd1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636953004417339794sdata=6yunnE%2BTZmQrD1mYiDpmgMRblswB4D1FX3NIYIrvX%2Fk%3Dreserved=0


-
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: Podling status Copyright section

[Alex Harui]

Hi Matt,

I'm not sure what "add" means, but there have been several past discussions 
where it appears that new code was brought in under a CCLA without an SGA.

https://lists.apache.org/thread.html/d77183d7efd5faf331534edf7ee2de993e908cffa4feb7454f9a6ab1@%3Cgeneral.incubator.apache.org%3E
https://issues.apache.org/jira/browse/LEGAL-236
https://lists.apache.org/thread.html/2814bd99f77325f80c6bfbf1156debd22bf556bfd4b9786996c9217c@1423476452@%3Cgeneral.incubator.apache.org%3E
http://s.apache.org/YPe

It is also my understanding (from Roy) that in some cases existing code can 
come in under an ICLA.

HTH,
-Alex

On 5/15/19, 4:27 PM, "Matt Sicker"  wrote:

You can add a software grant to a CCLA concurrently, but not vice versa.

On Wed, May 15, 2019 at 03:28, sebb  wrote:

> On Wed, 15 May 2019 at 06:55, Alex Harui  wrote:
> >
> > I do not like the words "transfer rights".  It could be interpreted as
> transfer of copyright.  Copyright of existing code is not transferred to
> the ASF, AIUI.  How about "Check to make sure that an SGA or CCLA has been
> received."
> >
> > I don't like hypotheticals, but I can imagine some individual starting a
> project on GitHub, has only a few files already under ALv2, and gets a
> project going at the ASF?  Wouldn't we accept those few files under his
> ICLA and not require an SGA or CCLA?
> >
> > I'd suggest dropping the second sentence ("it is necessary to transfer
> rights...").  AIUI, it is only necessary to grant a perpetual license to
> the ASF.
>
> Also, the CCLA is not required, and is not an alternative to the SGA
> -- as may perhaps be inferred by some from the phrase "(SGA or CCLA)"
>
> 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.apache.org%2Flicenses%2Fcla-faq.html%23cclas-not-requireddata=02%7C01%7Caharui%40adobe.com%7C7b354edcc5b244d70e7c08d6d98ced18%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636935596691256488sdata=xS2K8uFmOV367uU65bfbmB6XR5IGsdY8OirvNAiyNO4%3Dreserved=0
>
> > I like your third sentence.
> >
> > HTH,
> > -Alex
> >
> > On 5/13/19, 5:28 PM, "Craig Russell"  wrote:
> >
> > The Copyright section of the podling status page says "Check and
> make sure that the papers that transfer rights to the ASF been received. 
It
> is only necessary to transfer rights for the package, the core code, and
> any new code produced by the project.".
> >
> > I'd propose a change:
> >
> > "Check to make sure that the papers that transfer rights to the ASF
> been received (SGA or CCLA). It is necessary to transfer rights for any
> existing package and core code. Any new code produced by the project must
> be covered by ICLA."
> >
> > This change is proposed because it might not be obvious to everyone
> what "the papers that transfer rights" are. And new code produced must be
> committed by a person who has filed an ICLA.
> >
> > Patches welcome.
> >
> > 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
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
> --
Matt Sicker 



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

Re: Podling status Copyright section

[Alex Harui]

I do not like the words "transfer rights".  It could be interpreted as transfer 
of copyright.  Copyright of existing code is not transferred to the ASF, AIUI.  
How about "Check to make sure that an SGA or CCLA has been received."

I don't like hypotheticals, but I can imagine some individual starting a 
project on GitHub, has only a few files already under ALv2, and gets a project 
going at the ASF?  Wouldn't we accept those few files under his ICLA and not 
require an SGA or CCLA?

I'd suggest dropping the second sentence ("it is necessary to transfer 
rights...").  AIUI, it is only necessary to grant a perpetual license to the 
ASF.

I like your third sentence.

HTH,
-Alex

On 5/13/19, 5:28 PM, "Craig Russell"  wrote:

The Copyright section of the podling status page says "Check and make sure 
that the papers that transfer rights to the ASF been received. It is only 
necessary to transfer rights for the package, the core code, and any new code 
produced by the project.".

I'd propose a change:

"Check to make sure that the papers that transfer rights to the ASF been 
received (SGA or CCLA). It is necessary to transfer rights for any existing 
package and core code. Any new code produced by the project must be covered by 
ICLA."

This change is proposed because it might not be obvious to everyone what 
"the papers that transfer rights" are. And new code produced must be committed 
by a person who has filed an ICLA.

Patches welcome.

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: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check (was: .... introduce "[DISCUSS]" threads for podling ... release candidates))

[Alex Harui]

As a peanut, IMO, it could be that the root problem is that the drive-by folks 
are discussing topics that are too subjective at a critical time (to get a 
release out), not the number of folks who can drive-by.  I'm not even in the 
IPMC, and I can still follow general@ and offer opinions.

Podlings would have their lives improved if there were more folks available to 
help in little increments if the help was consistent.  It would be a stronger 
community if more people could help pound a nail or fix a flat tire.  It would 
take the load off the folks in charge.  More people would get more done with 
less burnout.

In some ways, Roy's suggestion to stop having an IPMC vote as a gate for a 
podling release can help by making it less critical to get someone official to 
rule on something "now".  Just ship it, note it in the bug tracker, and get to 
it when you can find someone to help you or take your time resolving it, 
gathering different opinions and coming up with a solution, even a temporary 
one.  Not all issues need to be addressed before graduation, IMO.  Some issues 
just aren't stop-ship and won't ruin the legal shield or put the ASF in legal 
jeopardy.  Policy issues are not always legal issues.  In fact, I think most 
aren't.

Maybe we should try to reduce subjectivity by getting more consensus on what 
issues are really important and which ones aren't.  That might get more 
consistency from the drive-bys.  But some of these issues are judgement calls 
and folks will have different opinions and podlings might be better served by 
being advised to get second opinions.

Reducing the number of volunteers and holding them to a higher standard seems 
anti-volunteer.  It is why I've never asked to join the IPMC.   I can pound a 
nail and fix a flat tire, though.  Finding ways to reduce the size of the tasks 
and requirements on the timing seems like it would attract more volunteers and 
be more helpful.  Instead of having to review an entire release in order to 
cast a binding vote on it, maybe I could spend 5 minutes to just run RAT on it 
and if it finds a binary, open a ticket asking why.

HTH,
-Alex

On 3/2/19, 3:55 AM, "Greg Stein"  wrote:

On Sat, Mar 2, 2019 at 5:17 AM sebb  wrote:

> On Sat, 2 Mar 2019 at 10:49, Greg Stein  wrote:
> >
> > On Sat, Mar 2, 2019 at 2:50 AM sebb  wrote:
> >
> > > On Sat, 2 Mar 2019 at 03:45, Justin Mclean 
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > > I agree that it's not ideal but it is not a symptom of a big
> problem
> > > either. We have inactive IPMC members who might become active again
> later
> > > if a community wants to join the incubator but it's a hassle to leave
> and
> > > then join again.
> > > >
> > > > Some context, over 300 projects have gone through the incubator, 50
> are
> > > there currently, each requires a champion and 3 mentors at the start
> (all
> > > IPMC members), even with some mentors working on multiple podling it's
> not
> > > surprising the IPMC is 300 people or so. Nor should it be that a large
> > > number of them are inactive as most of the projects they were involved
> in
> > > have graduated (or retired).
> > >
> > > +1
> > >
> > > > But despite this some still think it is an issue so we IMO we should
> > > address it, unless they change their minds, and say so here.
> > >
> > > Personally, I don't think that is a reason to reduce the IPMC count.
> > > I think it needs to be established WHY it is thought to be an issue
> first.
> > >
> >
> > It encourages drive-by bikeshedding. "I'm an IPMC Member from a few 
years
> > back. I see $foo, and OMG need to comment on it."
> >
> > Did anybody stop and read the concerns recently raised to the Board? 
Much
> > of the focus on that email was about such drive-by commenting.
> >
> > Thus, reduce the opportunity for drive-by.
>
> Since the general@ list is public, I don't think reducing the IPMC
> will stop comments.
>

So? It is to reduce the number of people who feel empowered to meddle into
everything every podling does. You want to fix general@ ??, then go ahead.
I want to see people who choose not to *participate* in the IPMC [by
subscribing to private@] dropped from the roster. The whole world can chat
on general@. But if you want to be *part* of the IPMC, and want a binding
vote, and want to really throw-in on Incubator matters, then you damned
well better subscribe.

The basic structure of 200+ people all having "merit" to jump into a
podling's pond is a priori broken. We have *specific* feedback that this is
true. Not a guess. Not some survey. A "letter" signed by numerous
individuals that this is the case. So until the Incubator decides its basic
structure is Wrong(tm), and stops pushing back against that 

Re: Welcome Wagon

[Alex Harui]

Hi Dave,

IMO, the Incubator is the "welcome wagon".  Unfortunately, it often greets new 
neighbors with a huge list of policies which is not welcoming.  That makes the 
incubator more iike a bad Homeowner's Association from a movie.  Or maybe a 
Boot Camp where only the tough survive and everyone else washes out.  When I 
think of the word Incubator, I think of baby incubators in hospitals where 
staff goes out of their way to help each baby survive and then thrive, not one 
where the goal is selection of a few.

-Alex

On 2/25/19, 11:48 AM, "Dave Fisher"  wrote:

Hi -

There has been mentions about lack of documentation, not being able to find 
documentation, not being responsible for a policy, and not including the 
rationale for a policy.

This morning I remembered something that happened some 49 years ago when I 
was a child and we moved to the suburbs of Chicago. A nice lady came over to 
the house from a group that called themselves the “Welcome Wagon”. She provided 
goodies and all kinds of information about both the local subdivision and the 
village.

I wonder if this is something that the Incubator could help build and 
disseminate?

An Incubator Welcome Wagon could be a Guide of Guides and include 
introductory information about:

(0) Onboarding
(1) Community Development
(2) Infrastructure and Builds
(3) Legal Policy
(4) Release Policy
(5) Press
(6) Foundation Structure

This information would come from the definitive committee and the mentors 
and podlings could provide feedback to the appropriate committees.

I think something like this would help the Incubator and Mentors be more 
facilitator and less police.

Regards,
Dave
-
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: Binary jars in the source release which are only for testing

[Alex Harui]

Or, can you change your build script to download the jar instead of packaging 
it in the source release?

On 2/23/19, 6:02 PM, "Ted Dunning"  wrote:

Willem,

This issue of embedded binaries for testing purposes has come up before.
Examples include network intercepts for testing malware detection or class
files for a byte code manipulator. The network files can't easily be
recreated since they were observed in the wild and the class files might
have been produced by a specific (possibly broken) compiler version that
isn't widely available.

The key question is whether these binaries are derived from some source
that could be compiled instead of distributing the binary objects. Failing
that, can the provenance and justification for the binary object be
described?




On Sat, Feb 23, 2019 at 6:49 PM Willem Jiang  wrote:

> Hi
>
> Thanks Justin for the clarification.  I guess the policy imply the
> source materials cannot have any binary.
> But what if the binary is only for testing, which cannot be part of
> the released software.
> From my point of view, we don't need to modify the source materials
> testing binary to do the software release as it is not a part of the
> binary release of the software.
>
> Any thoughts?
>
> Regards,
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Sat, Feb 23, 2019 at 2:41 PM Justin Mclean 
> wrote:
> >
> > Hi,
> >
> > > 
[1]https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23whatdata=02%7C01%7Caharui%40adobe.com%7Cf5a610c610a847bf492408d699fc1ad8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636865705492422828sdata=aLOPz6UB1Fz4oNJYUYf6LZKwNeTkGhfNC1Q9Nmq6vok%3Dreserved=0
> >
> > It’s explained in that link there i.e.  "The Apache Software Foundation
> produces open source software. All releases are in the form of the source
> materials needed to make changes to the software being released”.
> >
> > Thanks,
> > Justin
> > -
> > 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: licenses and copyrights of dependencies

[Alex Harui]

IIRC, we use the food allergy analogy for these situations.  AIUI, the goal is 
for the top-level LICENSE to make it convenient for someone to see what the 
ingredients are, because some folks are "allergic" to certain licenses.  I 
think you can still use "pointers" instead of copying full texts of licenses, 
but having people open jar files to read the licenses seems to defeat the 
"convenience" of reading the ingredients.  If your packaging can extract a 
LICENSE from each jar you could point to those files.

My 2 cents,
-Alex

On 11/7/18, 8:07 AM, "Jonas Pfefferle"  wrote:

Hi Vincent,


At least right now we have the source code part covered since we do not 
ship 
any third party code/jars etc. with it. However, as you pointed it is a 
concern for the binary release. We just want this to be easy to  manage. At 
the moment we have 80+ jars that we ship as dependencies in the binary 
release. As pointed out before all of them have the license at least 
mentioned in the pom or have a license file in META-INF. Best case scenario 
we could just list all jars in the LICENSE file and refer to their license 
in the jar instead of copying everything. This makes it much easier to 
add/remove dependencies or change versions...
Does this make sense?

Thanks,
Jonas

  On Wed, 7 Nov 2018 15:56:45 +
  "Vincent S Hou"  wrote:
> Hi Jonas,
> 
> I totally understand your situation right now, because I have just 
>gone through the release process for my project Apache OpenWhisk as 
>well.
> 
> Regarding whether you should add the copyright, to me, it depends on 
>the source code release or the binary release.
> If you only care about the source code release, you can only focus 
>on the "SOURCE CODE". For example, if one or some of your SOURCE CODE 
>come from another library with a certain copyright, you should add it 
>into your LICENSE file. If your code depends on jar or any other 
>packages shipped by other parties, you do not need to add their 
>copyright into your LICENSE, because your source code release do not 
>and should not include any jar or packages. You can document 
>somewhere that these jars or packages are dependencies to run your 
>code.
> 
> If you come to binary release, and all the dependencies play a role 
>in order to compile your source code, you need to have the LICENSE 
>file with all the copyright for the dependencies.
> 
> In a nutshell, source code release is relatively easier to edit your 
>LICENSE, but binary release may be a hassle. 
> 
>For folks with different comments, welcome to chime in.
> 
> 
> Best wishes.
> Vincent Hou (侯胜博)
> 
> Advisory Software Engineer, OpenWhisk Contributor, Open Technology, 
>IBM Cloud
> 
> Notes ID: Vincent S Hou/Raleigh/IBM, E-mail: s...@us.ibm.com,
> Phone: +1(919)254-7182
> Address: 4205 S Miami Blvd (Cornwallis Drive), Durham, NC 27703, 
>United States
> 
> -"Jonas Pfefferle"  wrote: -
> To: "general@incubator.apache.org" 
>From: "Jonas Pfefferle" 
> Date: 11/07/2018 07:35AM
> Subject: licenses and copyrights of dependencies
> 
> Hi all,
> 
> 
> We are just preparing a new release and are wondering how and what 
>is 
> required for licenses and copyrights of components shipped with an 
>artifact. 
> According to the release 
> policy 

>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23distribute-other-artifactsdata=02%7C01%7Caharui%40adobe.com%7C22616922cce64b8fc10a08d644cb21ff%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636772036594764319sdata=5MSLi36WDsEVlzgZxdUpPmUmFP0PIh0upgPgVsRmJnU%3Dreserved=0
> 
> we need to include licenses of all components shipped in an 
>artifact. The 
> example just appends all licenses to the LICENSE file including the 
> copyrights. Is the copyright required? Shouldn't the copyright be 
>appended 
> to the NOTICE file instead?
> 
> Also we found that some artifacts have contradicting or missing 
>licenses 
> e.g. in the pom of one artifact a BSD clause 2 license is mentioned 
>but no 
> LICENSE files are shipped in the jars, however the source contains a 
>BSD 
> clause 3 license.
> 
> Thanks,
> Jonas
> 
> 
> -
> 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: How to review so-called "binary releases"?

[Alex Harui]

Hi Greg,

I think the fact that LICENSE policy that Justin linked to applies to 
convenience binaries creates confusion about reviewing binaries.

My 2 cents,
-Alex

On 10/25/18, 6:39 PM, "Greg Stein"  wrote:

On Thu, Oct 25, 2018 at 12:25 PM Julian Hyde  wrote:

> Jim, you’re re-iterating the premise of my question. In the context of my
> question, it doesn’t matter what these things are called. But we need to
> know how reviewers are to handle them.
>
> Since I asked the original question, I have found the following policy[1]:
>
> > COMPILED PACKAGES
> >
> > The Apache Software Foundation produces open source software. All
> > releases are in the form of the source materials needed to make
> > changes to the software being released.
> >
> > As a convenience to users that might not have the appropriate tools to
> > build a compiled version of the source, binary/bytecode packages MAY
> > be distributed alongside official Apache releases. In all such cases, 
the
> > binary/bytecode package MUST have the same version number as the
> > source release and MUST only add binary/bytecode files that are the
> > result of compiling that version of the source code release and its
> > dependencies.
>
> This policy clarifies what these things may contain. I still need
> clarification on what is the responsibility of a reviewer.


It has been repeated several times already. There is no such thing as
"reviewer" since these are not official releases. So they certainly
shouldn't be voted upon. They are just some binaries hanging out on our
server.

I propose:
>
> 1. Reviewers have no way to verify the contents of the binaries and
> therefore they have to trust that the release manager has built them
> according to the documented release process.
>

And this is exactly why they are unofficial.

-g

Re: How to review so-called "binary releases"?

[Alex Harui]

Julian,

Since binaries are provided as a convenience with no official standing, it 
doesn't matter if the "binaries" are "verified" or not.  They could contain a 
virus or other malware.  Users take the risks.

However, folks have used the policy you reference to come up with several 
checks such as:

1) Does the binary run (and pass tests)?
2) Is the list of files the same as the results of building the source package?
3) Do the LICENSE and NOTICE contain the required information from bundled 
binaries?
4) Do the JAR files contain the correct LICENSE and NOTICE files for the 
content of the JARs.

HTH,
-Alex

On 10/25/18, 10:25 AM, "Julian Hyde"  wrote:

Jim, you’re re-iterating the premise of my question. In the context of my 
question, it doesn’t matter what these things are called. But we need to know 
how reviewers are to handle them.

Since I asked the original question, I have found the following policy[1]:

> COMPILED PACKAGES
>
> The Apache Software Foundation produces open source software. All
> releases are in the form of the source materials needed to make
> changes to the software being released.
>
> As a convenience to users that might not have the appropriate tools to
> build a compiled version of the source, binary/bytecode packages MAY
> be distributed alongside official Apache releases. In all such cases, the
> binary/bytecode package MUST have the same version number as the
> source release and MUST only add binary/bytecode files that are the
> result of compiling that version of the source code release and its
> dependencies.

This policy clarifies what these things may contain. I still need 
clarification on what is the responsibility of a reviewer. I propose:

1. Reviewers have no way to verify the contents of the binaries and 
therefore they have to trust that the release manager has built them according 
to the documented release process.

2. Reviewers should check that the binaries contain LICENSE and NOTICE 
files compatible with that is believed to be in the binaries.

Julian

[1] 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23compiled-packagesdata=02%7C01%7Caharui%40adobe.com%7C335f6f5bcaeb4f46779008d63a9ee1f6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636760851402047786sdata=scRmJjXdyQCGA2ymR3H4M4dnx6OKuuF3tMnUv64Kf%2FQ%3Dreserved=0

> On Oct 25, 2018, at 4:48 AM, Jim Jagielski  wrote:
> 
> +1. That distinction is important. The ASF, and our projects, release 
source code.
> 
>> On Oct 25, 2018, at 6:39 AM, Greg Stein  wrote:
>> 
>> Those are "convenience binaries" ... not "binary releases".
>> 
>> On Thu, Oct 25, 2018 at 2:25 AM Luciano Resende 
>> wrote:
>> 
>>> While I agree that binary artifacts are for convenience purposes, if one
>>> searches  our dist folder they will find lots of projects with binary
>>> releases.
>>> 
>>> When reviewing binary archives we need to make sure that the license 
file
>>> is updated with the shiped dependencies licenses appropriately and that
>>> they are all compatible with the Apache License (notice file might also
>>> need to be updated).
>>> 
>>> 
>>> On Thu, Oct 25, 2018 at 05:38 Greg Stein  wrote:
>>> 
 On Wed, Oct 24, 2018 at 10:25 PM Julian Hyde  wrote:
> ...
 
> As a reviewer, how am I to vote on this release candidate?
 
 
 You do NOT vote on binary artifacts. Since you cannot release binaries,
>>> you
 should not put the Foundation's imprimatur on those artifacts (and as 
PMC
 Member, that is what your vote represents).
 
 
> Should I vote -1 because the RC contains binaries?
 
 
 Vote on the source artifacts only. Clarify that your vote does not 
apply
>>> to
 the binaries.
 
 Cheers,
 -g
 
>>> --
>>> Sent from my Mobile device
>>> 
> 
> 
> -
> 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: Does Zipkin need to sign a SGA ?

[Alex Harui]

I may be mis-remembering, but I thought that an SGA wasn't required for ALv2 
code.  OpenZipkin appears to be ALv2.  The licenses in the SGA are pretty much 
the same as in ALv2.
I thought that for ALv2 code, we mostly cared that the community documented 
that it was willing to make the move from wherever the code is now to the ASF, 
and it wasn't super important to get approval from folks with minor 
contributions as long as we were confident their contributions were under ALv2.

Once the community has approved the move to the ASF, any copyright holder or an 
agent can replace the headers with the ASF header.

Of course, I could be wrong...
-Alex

On 9/18/18, 7:00 PM, "Adrian Cole"  wrote:

Hi, John

Thanks for the input. So, I would hazard a guess that Twitter folks
would like to help with this. I'm not sure who would want to hunt
through the management chain to find someone to reverse-own a decision
made 3 years ago, though! Regardless, on my part, I'll see if I can
find a champion inside Twitter to resurrect and SGA.

Best,
-A
On Wed, Sep 19, 2018 at 9:36 AM John D. Ament  wrote:
>
> Thanks Adrian.  Some comments/banter below.
>
> Migrating a repository from one org to another does not require an SGA.  
If
> it did, we would not be able to have code living in our repos that had
> headers other than the ASF standard headers (e.g. BSD licenses, or Apache
> License w/ different copyright statements).  The SGA is used to replace 
the
> headers with the standard ASF headers.  We should not block migrating the
> repositories over while the SGA/ICLA is worked out.
>
> Resolving the SGA/ICLA situation would block graduation - we should ensure
> that the provenance is in place, which is part of the incubation process.
> This doesn't need to be solved on day 1, but by the time the podling is
> ready to graduate.
>
> With that said, from a pure foundation standpoint it would be ideal to
> receive a SGA from Twitter.  Even if the current code doesn't match the
> code at the time of Twitter's conversion, it gives us a better IP history
> for the codebase to answer questions and deal with any potential problems
> that may come up along the way.  However, to be realistic I believe if we
> receive an ICLA from the primary contributors based on [1], that should
> satisfy enough providence of the codebase, in addition to the contribution
> process that Adrian has pointed out below.
>
> Thoughts?
>
> John
>
> [1]: 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenzipkin%2Fzipkin%2Fgraphs%2Fcontributorsdata=02%7C01%7Caharui%40adobe.com%7Cb6688cfbd5c643fd589d08d61dd3a1dd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636729192122171615sdata=uM8FYSSrTEoprQjlxBn7CaGMUUKN1q5kFIKZbwJK5OI%3Dreserved=0
>
> On Tue, Sep 18, 2018 at 9:25 PM Adrian Cole  
wrote:
>
> > There was a process involved at Twitter when we first moved it to the
> > openzipkin organization. It was 100% clear that this was an act for
> > the community to control the code.  Senior management were involved
> > 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsg%2Fzipkin-user%2FfbOgEZpuQx4%2FbWH1-__EmCoJdata=02%7C01%7Caharui%40adobe.com%7Cb6688cfbd5c643fd589d08d61dd3a1dd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636729192122171615sdata=zCuH4RUT5mF8O8%2FuE1Q2LF7ug6XxieKzTY%2FixIPnupo%3Dreserved=0
> >
> > After that, all the repositories had contributing files like the below
> > indicating that all changes we to be redistributable under ASL
> >
> > 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenzipkine%2Fzipkin%2Fblob%2Fmaster%2F.github%2FCONTRIBUTING.md%23licensedata=02%7C01%7Caharui%40adobe.com%7Cb6688cfbd5c643fd589d08d61dd3a1dd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636729192122171615sdata=KUQH3PeI%2FQvQ2dzs1CYdGZVtSRCS0wOnJaPIYAvbMYs%3Dreserved=0
> > 

> >
> > There was no collection of contributor agreements beyond this. Most of
> > the code except save some UI assets have been completely rewritten
> > since the migration to OpenZipkin a few years back.
> >
> > Hope these details help,
> > -A
> > On Wed, Sep 19, 2018 at 9:09 AM Craig Russell 
> > wrote:
> > >
> > > Hi Mick,
> > >
> > > tldr; with my Incubator PMC hat on, "all that needs to be done" is to
> > establish that all of the copyright owners sign either a Software Grant 
or

Re: Who has the experiences to assemble NOTICE file?

[Alex Harui]

Writing code is error prone too.  Just like code, make a good effort, let
the code reviewers catch things, make more changes, review it again.

The key thing is to do the work and get the reviews in a timely fashion
instead of at release vote time.  No big deal if you miss something.
That's why there are reviewers and at least 2 other people have to ok it.

My 2 cents,
-Alex

On 3/30/18, 7:29 AM, "Ying Chun Guo"  wrote:

>Hi, friends
>
>I'd like to learn from people who has the experience to assemble the
>legal NOTICE file before. I need to do this for Apache OpenWhisk repos. I
>find manually assembling NOTICE is a complex and error-prone task
>especially for a non-legal person like me. Is there a tool to help on
>that ? Does anyone share any experiences on that?
>
>Best regards
>Ying Chun Guo (Daisy)
>
>
>-
>To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>For additional commands, e-mail: general-h...@incubator.apache.org
>

Re: License headers on test data (was Re: [VOTE] Release Apache NetBeans 9.0 Beta (incubating) rc2)

[Alex Harui]

FWIW,  some build and test processes have a "generate-sources" and/or
"generate-test-sources" step.  Have you considered having a step in your
test processes copy the source test files into a temporary folder and
remove the headers as part of that step?   Then you may not need to change
the test harness and expected result set.

HTH,
-Alex

On 1/23/18, 5:46 AM, "Geertjan Wielenga"
 wrote:

>OK, makes sense, thanks for these insights and ideas.
>
>Gj
>
>On Tue, Jan 23, 2018 at 2:40 PM, Bertrand Delacretaz
> wrote:
>> Hi,
>>
>> On Tue, Jan 23, 2018 at 2:35 PM, Geertjan Wielenga
>>  wrote:
>>
>>>...
>>> 
>>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.
>>>com%2Fapache%2Fincubator-netbeans%2Fblob%2Fmaster%2Fnbbuild%2Fbuild.xml&
>>>data=02%7C01%7Caharui%40adobe.com%7C0a91dd1e925e467c4bed08d56267bfbc%7Cf
>>>a7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636523120091967780=flP%2
>>>BmQUSLXLED3puYUrZzALhDD3adb%2F%2BSkgekR07mOQ%3D=0
>>> This is what line 2105 says:
>>>   ...
>>
>> Maybe grouping those exclusions by families would make it easier for
>> reviewers to understand them: first the ones which are not creative,
>> then those where a header would cause tests to fail etc.
>>
>>> ...You're saying the comment isn't needed in the README...
>>
>> What I'm saying is that it shouldn't be duplicated - have the README
>> point to that build.xml file,or as discussed a file that just has RAT
>> exclusions, and add the comments next to the exclusions, pointing to
>> apache.org docs where useful.
>>
>>> ...can NETBEANS-306 be closed as resolved?...
>>
>> I suggest grouping the exclusions that fall in that family and adding
>> a pointer to the Apache docs that mention that the header is not
>> required if it causes tests to fail.
>>
>> You then get links from README -> commented RAT exclusions -> Apache
>> documentation which provide a clear justification.
>>
>> -Bertrand
>>
>> -
>> 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] Do not accept software grants with conditionals or exclusions

[Alex Harui]

I don't have a vote here, but I"m now confused about what problem is being
solved.  Is it, as Stian says, that an entity is being lazy and did not
attempt to review the contents of the grant before donating?  I thought
the goal is to just keep folks from bothering us with additional language
on these grants.

I would think it is still required of the receiving project to review the
contents assuming the donor made a good faith attempt to review the
contents as well.  But as I think Stian is saying (and I'm saying since I
experienced it), mistakes are going to happen and things that shouldn't
have been donated will be accidentally listed in exhibit A.  Do our legal
advisors think that some conditional or exclusion for accidents is built
into the grant wording already or should some language about that be added
to software-grant.txt ?

What is the protocol if, even after IP clearance/grant acceptance, that
something is found in the included files that shouldn't be in there?  I
assume Apache takes the friendly approach of "Oops, that probably
shouldn't have been in there" and just deletes that file?

Thanks,
-Alex

On 9/7/17, 2:51 AM, "Stian Soiland-Reyes"  wrote:

>+1
>
>
>However it should be OK (and perhaps even encouraged) for the archive
>to list in NOTICE or similar that some of the files are not legally
>owned by the donating entity, for instance other open source files
>that have been used – legally they can’t be part of the IP grant
>(unless the donating entity have gained shared copyright after further
>modifications - but their upstream license would still apply).
>
>
>This does not mean the donated archive has to be fully IP cleared
>before donation.. of course the opposite could be true – the grant
>donates some code, which the podling later chooses not to keep – for
>instance by discovering an LGPL-licensed file from outside.
>
>
>What is not OK is as you suggest, to include files which ARE owned by
>the donating entity, but which are somehow not included in the grant.
>
>
>On 7 September 2017 at 09:32, Ted Dunning  wrote:
>> +1
>>
>>
>> On Sep 7, 2017 10:11, "Jacques Le Roux" 
>> wrote:
>>
>>> +1 (not binding, not part of IPMC)
>>>
>>> Jacques
>>>
>>>
>>> Le 07/09/2017 à 10:07, Bertrand Delacretaz a écrit :
>>>
 Hi Incubator PMC.

 We recently received a software grant pointing to an archive file for
 the code donation, but mentioning that some material contained in that
 archive might not be donated.

 This was discussed on the PMC private list and it looks like we have
 consensus for rejecting such grants in the future: software donations
 should only include the files that are donated, without conditionals
 or exclusions. Anything else puts an unnecessary burden on our
 podlings and mentors, for sorting out what's donated or not.

 This is a vote to formalize the decision to reject such grants in the
 future.

 This majority vote is open for at least 72 hours.

 Here's my +1.

 -Bertrand

 -
 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
>>>
>>>
>
>
>
>-- 
>Stian Soiland-Reyes
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Forcid.org%
>2F-0001-9842-9718=02%7C01%7C%7C4ccc95b5bed04f674d6c08d4f5d61513%7
>Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636403747211522975=RAK%2
>FkockH7FRLShyGRSaXCQuTDyDEXgXUrjfsC9xS8w%3D=0
>
>-
>To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>For additional commands, e-mail: general-h...@incubator.apache.org
>

Re: Urgent: Regarding Java package name change to org.apache.*

[Alex Harui]

OK, so to summarize a more refined recommendation:

1) package names with reverse domains MUST be renamed before graduation or
have an IPMC approved plan for renaming
2) Projects who expect that their future users outnumber current users are
highly encouraged to rename packages
3) Other projects are not required to rename packages and backward
compatibility is sufficient reason to not rename packages.

Or should #2 also be a MUST?

-Alex

On 8/3/17, 8:34 AM, "Andy Seaborne" <a...@apache.org> wrote:

>
>
>On 03/08/17 15:51, Julian Hyde wrote:
>> It rarely comes down to the IPMC or the Board dictating how a project
>>names its java classes (does anyone recall an instance?), so it’s mainly
>>the project’s discretion. In my opinion, where the project is on its
>>adoption curve is an important consideration.
>
>+1
>
>> Most projects that enter the incubator are early on the adoption curve.
>>Their future users outnumber their current users. The earlier these
>>projects make the change to org.apache, the fewer people they will
>>ultimately impact. It seems that gobblin is in this category.
>> 
>> A few projects, such as Flex, are already near the top of their
>>adoption curve. The cost/benefit of renaming is not as compelling.
>
>Jena was not early on the adoption curve. Long term compatibility has
>been, and is, a major element of the project culture.  Importantly,
>there are active users who answer questions (here, elsewhere), external
>web tutorials, books etc referring to the pre-ASF API.  We have a
>responsibility to them as well.
>
>"add an API" is more stuff that a small set of volunteer contributors
>(Jena has had no paid contributors working on) could not have coped
>with.  If a project has the capacity, sure. Not all project will.
>
>Set the expectations too high and it is implicitly a filter for a
>certain kind of project in size and structure.
>
> Andy
>
>
>> 
>> Julian
>> 
>> 
>>> On Aug 3, 2017, at 7:37 AM, Alex Harui <aha...@adobe.com.INVALID>
>>>wrote:
>>>
>>>  From the peanut gallery:
>>>
>>> Does the PPMC get to decide what constitutes a "very good reason" or
>>>does
>>> the IPMC and after graduation, the board?
>>>
>>> Flex has not changed its packages in the 5 years at Apache.  We felt
>>> backward compatibility was and is a "very good reason".  It was way
>>>more
>>> important to not require folks to alter their code in order to move to
>>>the
>>> Apache versions of Flex.  Also, we are not using Java/Maven so there
>>>isn't
>>> really a shading option.
>>>
>>> On the other hand, it seems like it could be confusing for Apache
>>>projects
>>> to have packages starting with "com.".  Flex's packages start with
>>>"mx" or
>>> "spark" (the component set names).
>>>
>>> Seems like a more refined guidance would be that:
>>> 1) packages starting with "com" (and maybe
>>>org.somethingOtherThanApache)
>>> should be changed as soon as possible/practical
>>> 2) there is no recommendation for other package prefixes
>>>
>>> My 2 cents,
>>> -Alex
>>>
>>> On 8/3/17, 5:42 AM, "Shane Curcuru" <a...@shanecurcuru.org
>>><mailto:a...@shanecurcuru.org>> wrote:
>>>
>>>> John D. Ament wrote on 8/2/17 9:13 PM:
>>>>> On Wed, Aug 2, 2017 at 8:54 PM Roman Shaposhnik
>>>>><ro...@shaposhnik.org>
>>>>> wrote:
>>>>>
>>>>>> On Wed, Aug 2, 2017 at 5:40 PM, Abhishek Tiwari <a...@apache.org>
>>>>>> wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> In regards to the recently incubated project - Gobblin, we were
>>>>>>> wondering
>>>>>>> about the policy around renaming Java package names to
>>>>>>>org.apache.* Is
>>>>>> it a
>>>>>>> mandatory requirement or good to have?
>>>>>>>
>>>>>>> The reason to ask this is that while we see many projects have
>>>>>>> migrated
>>>>>> to
>>>>>>> use org.apache.* package name for their Java source files, the
>>>>>>>Kafka
>>>>>>> project uses kafka.* for Scala sources and org.apache.kafka.* for
>>>>>>>Java
>>>>>>> sources.
>>>>>>>

Re: Urgent: Regarding Java package name change to org.apache.*

[Alex Harui]

From the peanut gallery:

Does the PPMC get to decide what constitutes a "very good reason" or does
the IPMC and after graduation, the board?

Flex has not changed its packages in the 5 years at Apache.  We felt
backward compatibility was and is a "very good reason".  It was way more
important to not require folks to alter their code in order to move to the
Apache versions of Flex.  Also, we are not using Java/Maven so there isn't
really a shading option.

On the other hand, it seems like it could be confusing for Apache projects
to have packages starting with "com.".  Flex's packages start with "mx" or
"spark" (the component set names).

Seems like a more refined guidance would be that:
1) packages starting with "com" (and maybe org.somethingOtherThanApache)
should be changed as soon as possible/practical
2) there is no recommendation for other package prefixes

My 2 cents,
-Alex

On 8/3/17, 5:42 AM, "Shane Curcuru"  wrote:

>John D. Ament wrote on 8/2/17 9:13 PM:
>> On Wed, Aug 2, 2017 at 8:54 PM Roman Shaposhnik 
>> wrote:
>> 
>>> On Wed, Aug 2, 2017 at 5:40 PM, Abhishek Tiwari 
>>>wrote:
 Hi all,

 In regards to the recently incubated project - Gobblin, we were
wondering
 about the policy around renaming Java package names to org.apache.* Is
>>> it a
 mandatory requirement or good to have?

 The reason to ask this is that while we see many projects have
migrated
>>> to
 use org.apache.* package name for their Java source files, the Kafka
 project uses kafka.* for Scala sources and org.apache.kafka.* for Java
 sources.

 Please let us know as soon as possible, because we are in process of
 renaming the  packages but if not mandatory we would want to keep
>>> gobblin.*
 package name and avoid the cost of downstream migrations and backwards
 incompatibility.
>>>
>>> You don't have to do it right away, but it is a requirement unless you
>>> have a really,
>>> really, really good reason of why you can't do that.
>>>
>>>
>> I'm not aware of any requirement around Java package naming.  IN fact,
>>last
>> time it came up it was clear that its a best practice only, and doesn't
>> have any actual naming requirements.
>
>John: Do you have a link to that discussion?  I'm of the mind that it's
>an expected best practice, unless you have a really, really good reason
>otherwise.
>
>Abhishek: Can you describe in more detail what these packages do in the
>context of your software product?
>
>In general, yes, I'd echo Roman's point strongly for the primary
>external API that most users would call:
>
>>> Or to put it a different way: during your eventual graduation this
>>> question will be
>>> asked and you better have a really, really good explanation if you're
>>> still using
>>> something other than o.a.
>
>That is, supporting packages, or things that are standards, or things
>that are specific plugins that integrate with external code - those I
>could understand staying with a non-a.o package name for compatibility
>or other reasons.
>
>But the main program that users run in the JVM, or the primary Gobblin
>classes that users integrating the code into their application?  That
>should be in an org.apache.gobblin.* package.
>
>Simple "backwards compatibility for users" as an argument is only
>suitable if you're deprecating and have a plan to switch in the
>reasonably-near future after graduation.  Not for the long term.
>
>Thanks for raising the question early!
>
>>>
>>> Thanks,
>>> Roman.
>
>-- 
>
>- Shane
>  
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.apach
>e.org%2Ffoundation%2Fmarks%2Fresources=02%7C01%7C%7Cef18c5e74b0141378
>79a08d4da6d0e5c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6363736093056
>90124=OyrEoidSvoONvFJksGYjhhz%2FatAd4b%2FyjmHcfoGeI%2B0%3D=
>0
>
>-
>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: ASF hosted binaries collecting user data without an explicit opt-in

[Alex Harui]

Is the use of Google Analytics also prohibited by #4?

-Alex

On 6/5/17, 8:16 PM, "shaposh...@gmail.com on behalf of Roman Shaposhnik"
 wrote:

>On Mon, Jun 5, 2017 at 8:02 PM, Julian Hyde  wrote:
>> Thanks for the explanation, Roman. I had no idea that policies for
>>hosted binaries
>> were stricter than for source code (other than the obvious effect on
>>licensing when you bundle in dependencies).
>
>Btw, this one is serious enough that I'd like us to update our release
>policy based on the
>learnings here.
>
>So far it seems that there's an agreement on that having this type of
>capability...
>   1 ... in the source code disabled by default -- totally OK
>   2 ... in the source code enabled by default -- questionable, but OK
>   3 ... in the binary hosted by ASF disabled by default -- OK
>   4 ... in the binary hosted by ASF enabled by default -- NOT OK
>
>#4 can get nuanced if we want to invest in ASF managed infrastructure
>that is
>responsible for update tracking and user data collection. With my ASF hat
>on,
>I'd say that INFRA should probably stay away from user data
>collection/retention.
>
>That still leaves a possibility of a a ping/pong API that only
>consumes a name of ASF
>project and its version and returns a JSON object of some kind as per
>PMC choice.
>
>
>Thanks,
>Roman.
>
>-
>To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>For additional commands, e-mail: general-h...@incubator.apache.org
>

Re: Airflow voting on release artifacts

[Alex Harui]

On 5/1/17, 2:00 PM, "Bolke de Bruin"  wrote:
>
>In Python we are used to install through so called source distributions
>“sdist”. Package managers (e.g. pip) use the filename to determine
>whether to download a new package and if they do they examine the
>contents of the package to find out it they need to install the package.
>They do this by examining the version contained inside the package. Thus
>while a different filename will trigger a new download, it might not
>install updated parts of the package. This is different from your example
>as no installer is examining both the name of the tar ball and the
>contents of your javascript files for a version identifier.
>
>But maybe you have a point. We could just do a "git clone”, update the
>version (not push it to git until final release), tar it. We then ask
>people to vote on it. Then we could provide the convenience package (that
>everyone will use) next to it. Or if we consider the “sdist” a binary
>release officially we vote on that one as well after the first vote. Two
>downsides to this are: if only option 1) nobody would user the tar, as
>the sdist is essentially the same and works with the package managers.
>Might be a bit excessive? 2) that would be a 2+2 vote again.
>
>Option 1 could work, it isn’t ideal, but will satisfy the procedure.

Many projects produce two packages: the actual sources, and something most
customers want to use.  The main reason ASF projects focus on the source
is because we are an "Open Source" foundation, but also because you can
verify that a source package isn't infected by a virus more easily than
reviewing other kinds of files.  AIUI, there are customers who are
concerned enough about the safety of a release that they only work with
source packages and compile everything from source.  So, whatever you call
your "source" package that is officially voted on must meet this criteria.

The customer package can be collection of files, but it must meet certain
requirements like having a LICENSE and NOTICE and detached signature that
the voters verify.

Many release examiners want to verify the source package against a Git
hash or SVN tag. That isn't a "must do", but a good thing if you can do
it.  So, I'm not sure delaying pushing the tag is a good idea.  What we do
in our project is pick whatever hash is the point in history for the
release and tag is as RC1, then when the vote passes, tag whatever hash
finally passes with the release tag.

So, if an sdist is entirely source, IMO, you can just make two sdist
packages (one for customers and one with "RC1" appended to the version
number) and offer both to the voters.  If the voters can easily validate
that the RC1 version they test is essentially the same as the other
package, then I think you are good to go.

HTH,
-Alex

Re: Airflow voting on release artifacts

[Alex Harui]

On 5/1/17, 11:44 AM, "Bolke de Bruin" <bdbr...@gmail.com> wrote:

>
>> On 1 May 2017, at 17:36, Alex Harui <aha...@adobe.com> wrote:
>> 
>> 
>> 
>> On 5/1/17, 7:44 AM, "Hitesh Shah" <hit...@apache.org> wrote:
>> 
>>> Hi Justin,
>>> 
>>> Currently, the podling has been modifying the contents and hence this
>>> discussion.
>> 
>> I agree with Justin and others that modification after the vote is not a
>> good thing.  So my assumption was that if you add your 2a step and
>>modify
>> the binary before the vote, it will be acceptable.  IMO, all you need
>>is a
>> way to verify that the binary the voters test is essentially the same as
>> the binary you want to actually release.
>> 
>> -Alex
>> 
>> 
>
>Hi Alex,
>
>As mentioned earlier this is not possible in a clean way. Version
>information is contained within the source package and it is required by
>specification to be. Installation happens from this source package. There
>are no “binaries”.
>
>We understand the need to vote on the artefacts, however the way it is
>required to work put us between a rock and a hard place: either our users
>can end up with an outdated pre-release while reporting they have the
>release installed or we need to vote 2+2 times (PMC+IPMC).
>
>We are looking to optimize this process either technically or
>procedurally, but until so far haven’t been able to distill anything that
>really helps.

Well, I'm quite confused now.  Hitesh seems to say there are binaries.
And I have proposed a couple of ideas where you create different artifacts
for voters vs. customers that I think get around all of these issues.
AFAIK, nobody on this list has objected to those proposals.

Maybe there is something about Python I don't understand, but if I had to
ship a set of Javascript files with an embedded version number in one of
those files, I would use what I proposed.  AFAICT, there is no obligation
to make your customers (not your voters) consume the source package, it
just has to be possible to generate what the customers use from the source
package.

HTH,
-Alex

Re: Airflow voting on release artifacts

[Alex Harui]

On 5/1/17, 7:44 AM, "Hitesh Shah"  wrote:

>Hi Justin,
>
>Currently, the podling has been modifying the contents and hence this
>discussion.

I agree with Justin and others that modification after the vote is not a
good thing.  So my assumption was that if you add your 2a step and modify
the binary before the vote, it will be acceptable.  IMO, all you need is a
way to verify that the binary the voters test is essentially the same as
the binary you want to actually release.

-Alex

Re: Airflow voting on release artifacts

[Alex Harui]

I'm not on the IPMC, so I don't have an official vote, but for me, it
would be ok if you include step 2a and the voters have a way to validate
that the 1.8.1rc1 binary they tested is "the same"=="identical except for
version numbers" as the 1.8.1 binaries you want to distribute to customers.

Also, I believe the source package build script must be able to reproduce
the 1.8.1 binary you want to distribute to customers.

So if you can do that I would hope the IPMC would approve.

-Alex

On 4/27/17, 3:57 PM, "Hitesh Shah" <hit...@apache.org> wrote:

>Hi folks,
>
>Given that the source bits are the official release, would it be okay if
>the community as a whole decided on say the following approach:
>
>1) Bundle source with version set to 1.8.1
>2) Bundle binary convenience artifacts built using version set to 1.8.1rc1
>3) Publish source and binary bits to dist.a.o/dev for vote
>4) If vote passes, publish the source tarball that was voted upon and
>"modified" binary convenience artifacts built with version set to 1.8.1
>
>The implication here is that the release manager is being trusted by the
>PMC to release the modified convenience artifacts from the voted-upon
>source without a new vote.
>
>If it helps, there are a couple of variations of the above which could be
>applied to reduce the no. of total votes:
>
>2a) Create 2 binary sets for the vote - one with version 1.8.1rc1 and
>other
>with version 1.8.1 ( with only 1.8.1 being published on a successful vote)
>
>OR
>
>4a) After PPMC vote passes, use the original source and modified binaries
>for the IPMC vote and therefore the IPMC vote is on the final bits being
>published.
>
>Any comments?
>
>thanks
>-- Hitesh
>
>
>On Tue, Apr 25, 2017 at 9:02 PM, Alex Harui <aha...@adobe.com> wrote:
>
>>
>>
>> >
>> >3. There is no “separate” build script. Pip will just install a binary
>> >(“wheel”) or uses the source package (as shown above). Both are used
>> >interchangeable by users. We only distribute source packages at the
>> >moment.
>> >
>> >@Alex: I have to think a little bit more about what you wrote, but it
>>is
>> >currently confusing the hell out of me :). Furthermore, I am not sure
>>if
>> >it applies considering the above #3.
>>
>> It could still apply.  You would just have to add a build script that
>> renames the package and metadata.
>>
>> Let's say I wanted to release a single file that reported the version
>> number.  Forgive me that I don't know Python so I just grabbed what I
>> think it would look like from the internet.
>>
>> ---MyRelease.py---
>> print("I am version 1.2.3.")
>>
>> Let's assume this is what your "customers" want to use.
>>
>> I am proposing that the Apache Source Package also contain the following
>> file:
>>
>> ---BuildScript.sh---
>> # creates Customer Package in out folder.
>> mkdir out
>> sed s/1.2.3/1.2.3$1/ < MyRelease.py > out/MyRelease$1.py
>>
>> Voters would run:
>>
>>BuildScript.sh RC1
>>
>> That would result in:
>>
>> ---out/MyReleaseRC1.py---
>> print("I am version 1.2.3RC1.")
>>
>> And this version would be tested by the voters.  The source package
>>being
>> voted on contains the original MyRelease.py and BuildScript.sh.  The
>> release manager would also run:
>>
>>
>> BuildScript.sh
>>
>> That would result in:
>>
>> ---out/MyRelease.py---
>> print("I am version 1.2.3.")
>>
>> In our project, the RM posts the source package in the RC folder and
>> creates a folder called "binaries" for the compiled source.  You could
>> call the folder something else, but let's keep the names for now.  The
>>RM
>> would copy a zip of MyRelease.py and BuildScript.sh (and LICENSE,
>>NOTICE,
>> README) into the RC folder and out/MyRelease.py to the "binaries"
>>folder.
>> Along with signatures and checksum files.
>>
>>
>> Voters would download the zip, expand it, run "BuildScript.sh RC1" and
>> test with their out/MyReleaseRC1.py.  They would examine the zip to make
>> sure it is compliant with Apache release policy.  This is what all other
>> voters on all other projects generally do.  But they would perform one
>> different step, which is, instead of testing the MyRelease.py in the
>> "binaries" folder, they would simply diff their MyReleaseRC1.py against
>> the MyRelease.py in the "binaries" folder.  If the only diffs are the
>> version, they should feel satisfied that the resulting "customer"
>>packages
>> is ok for release.
>>
>> Of course, I could be wrong...
>>
>> HTH,
>> -Alex
>>
>>


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

Re: Airflow voting on release artifacts

[Alex Harui]

>
>3. There is no “separate” build script. Pip will just install a binary
>(“wheel”) or uses the source package (as shown above). Both are used
>interchangeable by users. We only distribute source packages at the
>moment.
>
>@Alex: I have to think a little bit more about what you wrote, but it is
>currently confusing the hell out of me :). Furthermore, I am not sure if
>it applies considering the above #3.

It could still apply.  You would just have to add a build script that
renames the package and metadata.

Let's say I wanted to release a single file that reported the version
number.  Forgive me that I don't know Python so I just grabbed what I
think it would look like from the internet.

---MyRelease.py---
print("I am version 1.2.3.")

Let's assume this is what your "customers" want to use.

I am proposing that the Apache Source Package also contain the following
file:

---BuildScript.sh---
# creates Customer Package in out folder.
mkdir out
sed s/1.2.3/1.2.3$1/ < MyRelease.py > out/MyRelease$1.py

Voters would run:

   BuildScript.sh RC1

That would result in:

---out/MyReleaseRC1.py---
print("I am version 1.2.3RC1.")

And this version would be tested by the voters.  The source package being
voted on contains the original MyRelease.py and BuildScript.sh.  The
release manager would also run:


BuildScript.sh

That would result in:

---out/MyRelease.py---
print("I am version 1.2.3.")

In our project, the RM posts the source package in the RC folder and
creates a folder called "binaries" for the compiled source.  You could
call the folder something else, but let's keep the names for now.  The RM
would copy a zip of MyRelease.py and BuildScript.sh (and LICENSE, NOTICE,
README) into the RC folder and out/MyRelease.py to the "binaries" folder.
Along with signatures and checksum files.


Voters would download the zip, expand it, run "BuildScript.sh RC1" and
test with their out/MyReleaseRC1.py.  They would examine the zip to make
sure it is compliant with Apache release policy.  This is what all other
voters on all other projects generally do.  But they would perform one
different step, which is, instead of testing the MyRelease.py in the
"binaries" folder, they would simply diff their MyReleaseRC1.py against
the MyRelease.py in the "binaries" folder.  If the only diffs are the
version, they should feel satisfied that the resulting "customer" packages
is ok for release.

Of course, I could be wrong...

HTH,
-Alex

Re: Airflow voting on release artifacts

[Alex Harui]

On 4/25/17, 1:43 AM, "Bolke de Bruin"  wrote:

>Hi Bertrand,
>
>> On 25 Apr 2017, at 09:04, Bertrand Delacretaz
>> wrote:
>> 
>> Hi,
>> 
>> On Mon, Apr 24, 2017 at 10:18 PM, Chris Riccomini
>> wrote:
>>> ...Hitesh recently raised the issue that the artifact that passes the
>>>vote
>>> MUST be the one that we actually release...
>> 
>> Yes in terms of having the same binary digests and signatures, but
>> renaming the files is fine IMO, especially for removing an -rc suffix
>> which makes total sense. I would just add that step to your release
>> process documentation to make it clear.
>> 
>>> ...Rename/rebuild after final vote (This is what Airflow is doing, and
>>>Beam
>>> does this, I believe)...
>> 
>> I'd say rename yes but rebuild no, in order to keep the same digests
>> and signatures.
>> 
>
>As mentioned earlier, that seems not to be possible. The metadata
>(filename) and version information inside the package need to be in sync.
>This how the python build tools and python ecosystem works.

I'm not familiar with Python, but is it possible to have a command line
option that adds the "-rc" suffix in the right places?

IMO, there are two "audiences".  One is the voters, and one is your
customers.  The customers should not be using the RC until after it is
approved unless they are volunteering to be a voter.  Voters are primarily
supposed to examine a source artifact, but if you also release a
"convenience binary" artifact, there are some examinations of that
"binary" artifact required.  For many projects this "convenience" artifact
is the one that the vast majority of customers consume.  AIUI, Python
doesn't have binaries, but IMO, there is no requirement that this
"convenience" artifact actually contains binaries.  A "convenience"
artifact is just supposed to be the source artifact processed by a build
script since many of your customer may not have, or may not want to
configure their machines to run whatever build script engine you choose
for your project.  Further, there is no requirement that I know of that
voters must test the "convenience" artifact by actually running it.  It
just makes sense to do so in most cases.  But if Python is interpreted
source, you may be able to use this to your advantage.

So, your source package should consist of the source and build script
required to build this "customer"/"convenience" package, and the build
script should allow a command line option to add the "-rc" suffix.  Then
voters would be instructed to download the source package, and to test it,
build a "customer" package with the "-rc" suffix and test the results.
And voters would also be instructed to download the "customer" package
that doesn't have the -rc suffix.  But in order to test it, they only have
to diff that package against the "customer" package they built from the
source package.  It should be the same except for the metadata.

We'll see if others can find a problem with this plan, but IMO, that would
be good enough for me as an PMC voter.

HTH,
-Alex

Re: [IP CLEARANCE] Software grant for Ratis (incubating)

[Alex Harui]

On 2/24/17, 4:40 PM, "Enis Söztutar"  wrote:
>
>On a separate note, I wish there was a fast-track for these kind of
>projects which can start internally in Apache without too much of a
>hassle.

Check the archives for "Straight to TLP" discussions.  I thought it was
possible these days.

-Alex

Re: [VOTE] Release Apache Traffic Control 1.8.0-incubating (RC9)

[Alex Harui]

On 2/15/17, 4:37 PM, "John D. Ament"  wrote:

>Dan,
>
>So here's my point of view.  Justin's provided some more context on how to
>shape licenses.  If you feel very strongly that the release should go out
>the door, the way it is, then I am OK with changing my vote to a +1.  If
>however, you're like me, and would prefer accuracy over speed, I think its
>worth your time to fix the remaining license issues, package up a CR10,
>and
>see that the IPMC votes +1 without reservations (it gives better
>confidence
>that you can cut an ASF release).
>
>I'm even willing to help you rewrite your license file for accuracy.

Here's another possible way to think about it:  A podling really should be
trying to graduate ASAP.  My project only cut one release before
graduating.  If you are pretty certain you are going to cut another
release before graduating, I would ship RC9 and fix it for the next
release.  And even if you aren't going to cut another release before
graduating, since the point of incubation is education, unless anybody in
the IPMC thinks you haven't learned enough, I'd say you have.

That's because to me, an even more important aspect than choosing
"accuracy over speed" is whether your community and RM has the time and
energy to go through another RC after 9 RCs so far.  Sometimes it is
better to ship and take a break from the RC train, especially if you are
sure you are going to cut another release while in incubation.  The
foundation probably isn't at risk here.  Community over code.

My 2 cents
-Alex

Re: [VOTE] Release Apache Traffic Control 1.8.0-incubating (RC9)

[Alex Harui]

On 2/15/17, 7:40 AM, "Dan Kirkwood"  wrote:

>Thanks,  John..   I'm confused on this.   According to
>http://www.apache.org/dev/licensing-howto.html#permissive-deps :
>
>`In LICENSE, add a pointer to the dependency's license within the
>distribution and a short note summarizing its licensing:`
>
>Is MIT a special case in this regard?  And in that case,  do we need a
>separate full license entry for each MIT-licensed component we use?
>Is this RC acceptable other than the license issues you pointed out?

AIUI, a "pointer" is the text from that web page:

This product bundles SuperWidget 1.2.3, which is available under a
MIT license.  For details, see deps/superwidget/LICENSE.txt.

Your build/packaging should copy the dependency's MIT License into a file
in the release package.  MIT-licensed projects are supposed to have their
own copy of the MIT license in their release distributions with a
project-specific copyright.  The pointer isn't supposed to be a
third-party URL since URLs are not stable, although I would have probably
advised you to fix that in the next release.  IMO, it isn't a major flaw
for an incubating release.

Instead of a "pointer" you can copy whole license files into LICENSE, but
many prefer "pointers" to keep the LICENSE file shorter.

Of course, I could be wrong...

-Alex


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

Re: Binary file inclusion (was [VOTE] Apache Toree (incubating) 0.1.0-rc4 as 0.1.0)

[Alex Harui]

On 1/23/17, 9:51 AM, "John D. Ament"  wrote:
>>
>> The gradle wrapper and similar are also not permitted. Build processes
>> need to bootstrap it.
>>
>>
>I would like to understand why, from a legal standpoint, these are not
>allowed.

I don't think it is a legal issue.  It is an ASF policy that the ASF only
officially releases source materials.

As Marvin has mentioned many times already, you can't easily audit
compiled code to be sure there isn't something wrong with it.

For folks in the incubator, IMO it would be to their advantage to take the
time to eradicate compiled code from the source package before proposing
to release it.  It makes the IPMC reviewers job much more efficient.

My 2 cents,
-Alex


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

Re: [DISCUSS] Significance of Artifact Names

[Alex Harui]

Sorry for top-posting.

It's always been interesting to me that the ASF says that it only releases
source code, but still has policy about the contents of convenience
binaries such as [6].  So, I suppose the ASF could dictate naming of
binary packages.

I know very little about Maven, but in my mind, the -incubating suffix is
supposed to help warn the customer or cover the ASFs butt or both.  I
don't know if anybody actually points to a source artifact from Maven, but
if the downstream user is being careful enough to work from sources, it
makes sense to me to put in an additional warning by adding the
-incubating suffix to the source package. It says that these source
packages are not like other ASF source packages without having to open the
package.

But for a binary artifact, given that the ASF already thinks it isn't
audit-able and thus not an official release, does the customer care that
the artifact may not be ASF-grade (especially if the artifacts were
already considered open before entering Apache)?  Do they really need
early warning?  Would it really affect the ASF if something bad was later
found in a binary artifact?

IMO, the answer to all 3 questions is no.  I don't know how hard it is to
suffix the source artifact with -incubating but not for the binary
artifacts.  But if it is hard, could the next version of Maven do it?

Also, if someone is concerned enough about the licensing of the artifacts
they depend on to go digging through all of the poms of their binary
dependencies, wouldn't they check the  section of each POM?
According to [7] there is a comments section there.  Could incubating
podlings be required to make it clear in the  section that this
thing may not be fully ASF compliant instead of having to add a suffix to
the version of their binary artifacts?

My 2 cents,
-Alex

[6] https://www.apache.org/legal/src-headers.html#faq-binaries
[7] https://maven.apache.org/pom.html#Licenses

On 1/3/17, 7:19 PM, "John D. Ament"  wrote:

>All,
>
>This is a follow up to recent threads, purposely made a bit broader to
>encourage more discussions.  First to set down some facts about what's
>been
>established:
>
>1. Incubator policy [1] states that a podling's release meets two
>requirements, include "incubating" in the release archive's file name and
>the standard disclaimer within the documentation or README.
>
>2. The foundation policy on a valid release [2] seems to indicate that the
>elements that make up a valid release includes properly licensed source
>code, ICLAs on file, IP clearance and grants.
>
>3. Back in 2008 [3] it was established that incubator released are
>endorsed
>while the podlings themselves are not endorsed.  This means that while the
>podling may not fully be developed in an open way, all releases produced
>are expected to comply with ASF policies.
>
>So why am I harping on this problem?  The incubator has a series of
>guides,
>which are partially treated as policy and partially treated as advice.
>Many of these guides remain with large notions of being draft only, not
>finalized, I want to try to get these draft documents finalized so that
>we're able to provide better guidance to podlings coming in.
>
>I also think its important to keep our policies and guides as light as
>possible.  There shouldn't be a lot different in the incubator than a TLP
>would go through, or else this makes the eventual transition to TLP harder
>since many things previously done are now different.
>
>One of the distinguishing marks within the incubator is the use of maven.
>The incubator has a best practice that says if your build tool is maven,
>if
>and when you publish a convenience binary, that convenience binary must
>include either incubator or incubating in the version string [4].  Its not
>clear why maven is singled out, probably because it was the first of its
>kind, other tools didn't exist.  One of the key notes I can find is that
>the downstream redistribution channels are operated outside the ASF [5].
>So while Maven is an apache project, maven central is not an ASF managed
>resource but we are attempting to enforce our internal concerns to an
>outside party.
>
>So I move that we cannot apply our policies on third parties, and
>artifacts
>distributed in maven central from our release archives need not comply
>with
>our policies.
>
>John
>
>[1]: 
>http://incubator.apache.org/incubation/Incubation_Policy.html#Releases
>[2]: http://www.apache.org/dev/release-publishing.html#valid
>[3]:
>https://lists.apache.org/thread.html/0b6c065a908c5f9ec39fa78c31b39c83a6fea
>29eb34fada0ee070413@1222432864@%3Cgeneral.incubator.apache.org%3E
>[4]:
>http://incubator.apache.org/guides/release-java.html#best-practice-maven
>[5]: http://www.apache.org/dev/release-distribution.html#channels


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

Re: [DISCUSS] Concur for Apache Incubator

[Alex Harui]

On 11/23/16, 6:19 AM, "Stian Soiland-Reyes"  wrote:

>On 23 November 2016 at 11:40, Roman Shaposhnik 
>wrote:
>> FIWI: these were my thoughts exactly. In fact, for a second there I
>>thought
>> that SAP was donating Concur codebase.
>> In the spirit of bikeshedding I propose Apache Thor (or Heyerdahl) 'cuz
>> you know: raft ;-)
>
>As Norwegian I should not really disagree on that name -- but Thor is
>already the name of lots of things, including at least two EU projecst
>https://project-thor.eu/ (Open Research interoperability)
>http://www.eu-thor.eu/ (Oceanography!)
>
>
>Apache Heyerdahl..?

Thor Heyerdahl wrote a book about a raft trip from South America to the
South Pacific.  His first book is titled "Kon-Tiki".  There is already an
Apache Tika, so maybe Apache Tiki wouldn't work, but maybe Apache ConTiki.
 Not sure if we could use the book title in the project name.

Just painting the bike shed,
-Alex


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

Re: [DISCUSS] China Contribution.

[Alex Harui]

Educate, trust and verify.

IMO, there shouldn't be a rule that you can't write in non-English on dev@
or user@.  You just have to understand the impact of doing so.  Sometimes
it will make sense to do so, other times, not.  You have to know who in
your community knows what languages.  In Seattle, airport signs are in
English and Japanese, in San Diego, they are in English and Spanish.

If you trust that committers and PMC members have been educated on how to
grow a community, they will choose the right words.  You probably have to
educate folks that the ASF Board all know English so decisions need to be
recorded in English.

But for sure, not "everything" has to be on dev@.  Only decisions and some
final discussion leading to those decisions.  Lots of English discussions
happen off-list inside companies with too many committers as employees.
Or at Hackathons, or in chat rooms.  And sometimes folks on dev@ are left
out but they aren't supposed to be.  Whether English or Chinese or
something else was used doesn’t matter.

So far, just about every decision ends up with a lot of English keywords
on commits@.  I don't know of any popular programming languages that don't
use English keywords.  So watching commits@ is one way to verify.  And if
something happened you don't like, you start a discussion and figure out
what language to use to communicate most efficiently.  When I've visited
development centers in India, China and Japan and had development teams
visit me in the US from Romania, I can guarantee they discussed among
themselves in native languages and then summarized for me in English.  No
big deal.  I trust them to include me at some point and they do, in
English, since that's the language we have in common.

Projects coming to the ASF without a desire to draw people who don't speak
a non-English language probably aren't a good fit at the ASF.  Projects
coming to the ASF must understand that they must record decisions and
report progress in English.  Other than that, choose the words that will
bring in the most people.  But you can use more than one language.

My 2 cents,
-Alex

On 11/11/16, 12:47 PM, "Woonsan Ko"  wrote:

>On Fri, Nov 11, 2016 at 3:17 PM, Gunnar Tapper 
>wrote:
>> Hi,
>>
>> Copy/paste into a Translator, which detected the language
>>automatically: In
>> practice, the question of the language to use from a list of diffusion
>>is
>> specious. English it the lingua franca of the 21st century.
>>
>> Du kan göra precis samma sak med ett minoritetsspråk som svenska. Språk
>>är
>> inte längre ett hinder.
>>
>> Take a look at how the Minecraft generation (I'm blessed with one)
>> operates. They have no issues to jump onto servers that use languages
>>they
>> don't understand and then communicate using Translators. It's pretty
>> awesome. Real-time translators are coming. See Skype Translator for an
>> example.
>>
>> So, I'd argue that lingua franca is already becoming a thing of the
>>past as
>> people get more comfortable with the idea of using them in everyday
>>life.
>> Heck, just take a look at how people interact on Facebook these days --
>>the
>> translate function is extremely cool.
>>
>> You can view language as a barrier to community building or you can use
>> technology to remove the barrier.
>>
>> Based on this discussion, I am going to add a new section to the main
>> project page that discusses communication in different languages
>> encouraging people to write questions in the own language if they're not
>> comfortable with English -- I rather have the question than no
>>interaction.
>>
>> I'll tell them that the community uses translator software when needed
>>and
>> that responses is likely to be in English so that they can translate
>>back
>> as needed. A smalll first step but an important one.
>
>I guess you mean that in the user@ lists. That should be fine in my
>understanding from the discussions here and there.
>But as Shane and others pointed out, dev@ lists should be using
>English or Globish-like for good reasons. I would encourage committers
>to do so.
>
>Just my two cents,
>
>Woonsan
>
>>
>> Thanks,
>>
>> Gunnar
>>
>>
>>
>> On Fri, Nov 11, 2016 at 12:30 PM, Emmanuel Lécharny
>>
>> wrote:
>>
>>> En pratique, la question de la langue à utiliser sur une liste de
>>> diffusion est spécieuse. L'anglais est la Lingua Franca du 21ème
>>>siècle.
>>>
>>>
>>> And if you haven't understood what I wrote in my native language, which
>>> is understood by around 500 million people around the globe, I guess
>>>you
>>> get my implicit point ;-)
>>>
>>>
>>> More seriously, it's not about how good are developpers in english :
>>> many of the Apache developpers are not english native speakers, and we
>>> do many mistakes. That does not matter too much : nobody will blame
>>> anyone for that. At some point, code is not in english, but in C, Java,
>>> Scala, etc... If you work as an IT person, you already have to face
>>> 

Re: Radical proposal: no initial list of committers

[Alex Harui]

On 9/27/16, 8:38 AM, "gch...@gmail.com on behalf of Greg Chase"
 wrote:

>In Apache Geode, we are trying to be liberal about bringing in new
>committers. Anyone who shows an interest, and a series of well formatted
>pull requests that follow are code guidelines are pretty quickly nominated
>to become committers.
>
>This would make it very easy for emeritus contributors to become active
>again, as well as new diverse community members.

To me, it didn't seem right that if you had proven you could contribute
good code before the code was moved to Apache but weren't on the initial
list that you had to go through the "series of pull requests" gauntlet and
then a 72 hour vote in order to get your commit bit.  I think that's why
we grind so much on the initial list: if you are not on it, lots of folks
want you to "re-earn" your merit inside the ASF.  The quick-add path might
still take 72 hours for a vote, but at least you don't need to wait for a
series of pull requests to be accepted, while some other person who did
make the list can just start committing.

Since there can be a culling of the list at graduation time, there is
little risk to streamlining the commit bit for folks the community already
knows from before.  All that person has to is actually show up with
something to commit and an ICLA, then there should be a vote where folks
say "oh yeah, that person has been a productive contributor" and then that
person gets an account and can commit their change.

-Alex


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

Re: Radical proposal: no initial list of committers

[Alex Harui]

It is an interesting idea.  I thought that the initial committers list
provided the set of people who could define the merit to approve other new
committers.  The mentors may not be familiar enough with the technology
and people to make the decision with the "Flavor" the community wants.

The only sticking point I ran into in incubation was that folks felt the
need to be "fair" and require anybody not on the initial list to provide a
series of patches to show their commitment before voting them in.  I'd
rather have a "quick-add" for folks who have been past contributors.  Then
you could say the initial committers list should be 3 to 8 people, and
they could just add someone who shows up with something they want to
commit if that person is already in the commit history of the imported
code without having to make them submit a patch and wait 72 hours or more
for the vote.

My 2 cents,
-Alex

On 9/27/16, 7:44 AM, "Gregory Chase"  wrote:

>Having been through this with Apache Geode, I like the idea of paying
>homage to emeritus committers in the proposal and history of the
>technology.  If you start with a rule of providing committer privileges to
>those who have directly committed to the project in the last two or three
>years, and a liberal policy of granting new committer privileges as
>needed,
>I think you should be ok.  Does an emeritus committer need commit
>privileges today? Only if they start committing again.
>
>And for those that want prestige - the prestige rests in being an active
>evangelist of the project. One does not ever need to be a committer to
>achieve prestige.
>
>On Tue, Sep 27, 2016 at 7:03 AM, Emmanuel Lécharny 
>wrote:
>
>> Le 27/09/16 à 13:25, Greg Stein a écrit :
>> > The NetBeans proposal (among many others in the past) has
>>demonstrated a
>> > significant "problem" with trying to establish an appropriate list of
>> > initial committers. There are many people that want to be on, for
>>various
>> > reasons. Because they are committers, recent or historic. Or they want
>> the
>> > "prestige" to be there. Some people believe they "deserve" to be on
>>the
>> > list. etc etc
>> >
>> > Establishing the list is particularly difficult for large and old
>> > communities.
>> >
>> > But. What if we just said "no such list" ?
>> >
>> > This will shift the initial voting of committers upon the
>> Champion/Mentors
>> > who will construct the entirety of the PPMC. But hey: aren't they
>> supposed
>> > to be involved? Aren't they supposed to demonstrate how to earn merit,
>> and
>> > the committership that results?
>> >
>> > This would also solve the problem of initial committers that have not
>> > established any merit whatsoever. We've had many situations where
>>people
>> > simply add themselves to the list. Why? Cuz they chose to do so. It is
>> sort
>> > of silently allowed for IPMC members to add themselves. "I wanna
>>join!"
>> > BAM. It happens.
>> >
>> > So yeah. Radical thought: NO initial list. The PPMC is just the
>>Champion
>> +
>> > Mentors. They will build the committers and PPMC according to merit.
>> (note:
>> > this could be *very* fast for a particular few highly-engaged with
>> bringing
>> > the project to the ASF)
>> >
>> > ???
>> >
>> > Cheers,
>> > -g
>> >
>> Well, that's tempting...
>>
>>
>> OTOH there is no problem with having an initial list, even with people
>> who want to see their name on the web site for teh sake of their own ego
>> : it's easy to demote committer in the long run (moving them to an
>> emeritus status).
>>
>>
>> We have so many dormant committers in so many projects anyway !
>>
>>
>> My take is the initial list is just a curtesy made to the involved
>> people, and a few more. Nothing less, nothing more. The PPMC list, OTOH,
>> is critical.
>>
>>
>> My 2 cts.
>>
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>
>
>
>-- 
>Greg Chase
>
>Global Head, Big Data Communities
>http://www.pivotal.io/big-data
>
>Pivotal Software
>http://www.pivotal.io/
>
>650-215-0477
>@GregChase
>Blog: http://geekmarketing.biz/


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

Re: [VOTE] Apache BatchEE 0.4-incubating

[Alex Harui]

On 9/26/16, 1:53 AM, "Mark Struberg"  wrote:

>
>No, we didn't get an official grant, but the RI is ALv2 and we actively
>asked the IBM devs/managers and they are perfectly fine with it.

AIUI, IBM could give you or one of their employees who participate in your
project permission to move their (c) to NOTICE without it being a "grant".
 I don't think that makes a difference as to the validity of the release,
just whether scanning tools pick up such things in the future.

-Alex

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Alex Harui]

IMO, the only things to consider for the initial committers list are:

If you leave someone off the list:
- it takes bit longer to get their next commit into the repo.
- that person may be have hurt feelings as to why some other person is on
the list.
(so don't leave off the person who can quickly fix important security bugs)

If you put someone on the list:
- They may never contribute what they said they might contribute
- More administrative work for the ASF secretary.
- You clean up the deadwood at graduation.

As Apache Flex entered the incubator, we had a 40 person initial committer
list which was considered quite large at the time.  Only one person
besides me is still active almost five years later.  About 12 never showed
up because with the move to Apache their paid job role changed and they
ran out of time to commit anything.  If I had to do it again, I would
probably still have the same 40 people.  So what if there was deadwood.
We cleaned some up at graduation, and then over 4 years after graduation,
folks faded away and new folks came in.

But if you are thinking 100 people, I'd try to get it down to 40-ish.

My 2 cents,
-Alex


On 9/24/16, 11:59 PM, "John McDonnell"  wrote:

>Hi All,
>
>
>I am a netbeans user that has been following this thread since the
>proposal was announced and I am a little fascinated with this whole
>process, it seems rather interesting...
>
>Although this initial committer list seems to be a sticking point, but
>from reading this page:
>https://www.apache.org/foundation/how-it-works.html#committers I'm not
>sure why it is...
>
>I have contributed defect fixes for JClouds in the past, and from what
>I see on this project is that there's an GitHub repo that allows
>people to contribute PR's, but theres also a ASF repo, which the
>contributors actually merge in the PRs from GitHub into the "hidden"
>ASF repo...   Is this how every ASF project runs? and is this how
>Apache Netbeans would run?  Because if so, do you want to give a wide
>list of committers initially?
>
>I would have thought it would make sense to keep the number to a group
>of trusted people that Netbeans/GJ trust up front to commit PRs into
>the main repo, and to make short term decisions.  Then if a
>developer/contributor shows themselves to be a useful part of the
>community then you can quickly vote to change their status...
>
>Anyways I'm going to go back to lurking in the background...
>
>Regards
>
>John
>
>
>On 25 September 2016 at 07:40, Jochen Theodorou  wrote:
>> On 24.09.2016 15:10, Geertjan Wielenga wrote:
>>>
>>> On Sat, Sep 24, 2016 at 2:59 PM, Jochen Theodorou
>>>
>>> For me the problem is that without plugins you have only the bare
>>> plattform

 and no IDE.
>>>
>>>
>>>
>>> No, that's not true at all. The NetBeans plugins are of various kinds.
>>> There are plugins that are listed in the Plugin Manager by default,
>>>these
>>> are the standard functionalities of NetBeans IDE, i.e., these are all
>>>from
>>> the NetBeans source code and will be part of the Apache donation.
>>
>>
>>
>> ok, wrong knowledge on my side. From hat I have seen in the repository
>>it
>> should be fine then. I have also seen some possibly license critical
>>stuff
>> there, but that is for during incubation to sort out
>>
>>
>> bye Jochen
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>
>
>
>-- 
>John
>
>-
>To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>For additional commands, e-mail: general-h...@incubator.apache.org
>

Re: Licensing requirement for binary artifacts without transitive deps

[Alex Harui]

On 9/20/16, 11:50 AM, "Donald Szeto"  wrote:

>Hi all,
>
>I am preparing my first Apache release and am wondering if I need to check
>licenses of all transitive deps if the release contains:
>
>- a single source tarball;
>- a few binary JAR artifacts on Nexus that contain no transitive deps in
>either binary or source form.

An official Apache release only contains source.  It cannot contained
compiled binaries.

Official Apache releases may be accompanied by a "convenience binary
package" that contains the result of running the build contained in the
source script.  It could bundle third-party jars.

The LICENSE file in the source package may be different from the LICENSE
in the "convenience binary" if the convenience binary contains a bundled
third-party jar.  The LICENSE files must reflect the contents of its
containing package.

>
>Would it be sufficient to make sure the licenses of all sources comply
>with
>Apache policy in this case? Do I need to check transitive deps in this
>case?

You must chase down transitive deps in the package.  If the source package
doesn't contain any non-ASF code then there isn't anything to chase for
the source package.  If the binary does contain third-party jars, then you
have to chase transitive deps on those jars.

HTH,
-Alex

[1] http://www.apache.org/dev/licensing-howto.html
[2] http://www.apache.org/dev/release.html#what

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Alex Harui]

On 9/19/16, 11:12 PM, "Mark Struberg"  wrote:

>Status update from the import:
>
>du -hs .git
>3.6G
>
>
>Could not import to github due to:
>
>Delta compression using up to 4 threads.
>Komprimiere Objekte: 100% (659268/659268), Fertig.
>remote: fatal: pack exceeds maximum allowed size
>fatal: The remote end hung up unexpectedly
>error: pack-objects died of signal 13
>
>
>Trying to look for checked in binaries and temp compile results and
>git-filter it as next step.

You win the award for patience.  I did a quick search for the "fatal" and
found [1] where it suggests:

git config --global http.postBuffer 


HTH,
-Alex

[1] 
https://bitbucket.org/site/master/issues/3578/cannot-push-fatal-the-remote-
end-hung-up

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Alex Harui]

On 9/19/16, 8:55 AM, "shaposh...@gmail.com on behalf of Roman Shaposhnik"
 wrote:

>On Mon, Sep 19, 2016 at 8:51 AM, Mark Struberg
> wrote:
>>But we don't yet know what is part of the hg repo and what is part of
>>the Oracle contribution.
>>
>> What would happen if someone e.g. did commit some GPL licensed jar to
>>the repo a few years ago?
>> It's easy to catch such things if they are still in the latest version.
>> But what if they got added and later removed? Do we need to filter them
>>out?
>
>No we don't. What ASF stands behind is a release (which is a source
>tarball and optional
>binary convenience artifacts) that we distribute via our own
>infrastructure. While we try
>to keep our repos clean, we are not forced to have them at the same
>level of IP hygene
>that we need for our official releases.
>
>Case in point: Apache Geode (incubating). We entered incubation (and
>ingested the source)
>with a known LGPL dependency embedded in our tree. Getting rid of if
>via refactoring was
>a pre-requisite for our first release, but you can still find history
>in our Git repo of it being
>there before the first release was done.

I agree that the repos don't have to be as clean.  IMO, Oracle has an
incentive to submit a tar ball or import data that is ASF-ready.  This
doesn't mean they have to clean up a GPL add-and-remove, but Oracle might
want to consider scrubbing the donation for that and other things.  At
Adobe, our QA team often used test images that weren't ok to donate such
as pictures of famous people.  The test media never got released so it
didn't matter until donation time.  I think we attempted to scrub out some
traces of how security issues were handled as well.  They could choose to
scrub-and-replace author names for commits as well.

Adobe Flex came in via Subversion before going to Git, so I don't know how
Git import works, but blame works just fine, it just blames "Adobe Import"
instead of some Adobe employee and I think does include the commit
message.  Yes, sometimes knowing who did it helps you understand why, but
most of the time it doesn't matter.

-Alex

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Alex Harui]

On 9/19/16, 8:13 AM, "Wade Chandler" <m...@wadechandler.com on behalf of
cons...@wadechandler.com> wrote:

>> On Sep 19, 2016, at 11:04, Alex Harui <aha...@adobe.com
>><mailto:aha...@adobe.com>> wrote:
>> 
>> 
>> 
>> On 9/19/16, 6:16 AM, "Mark Struberg" <strub...@yahoo.de.INVALID
>><mailto:strub...@yahoo.de.invalid>> wrote:
>> 
>> 
>>> We also need to check whether the author and contributor flags are
>>> properly moved over by the import. We don't like to loose any IP
>>> provenance... Etc, etc.
>> 
>> Isn't IP provenance reset by the SGA?  It was for Adobe Flex.  Only a
>> couple of committers came in with the 10 year old code base.  Everyone
>> else had moved on, but because all were employees of Adobe, it didn't
>> matter.  The log just says that someone from Adobe made a commit, not
>>who.
>> 
>
>Sorry…sent first from wrong email alias...
>
>NB has a contributor agreement too, and so to contribute we all had to
>sign one assigning IP to Oracle (same for Sun when they were around).

I assume Oracle legal has confirmed that the CA allows for donation
without signature?  That was the case for Adobe's CA, but wasn't the case
for some code Adobe picked up via an acquisition and we had to execute
more paperwork.  Assuming the CA allows donation, I would think the
signing of the SGA resets provenance.  Oracle is saying they own every
line and authorize its donation.  At that point, exactly which human
actually wrote the code becomes moot from a provenance standpoint, AIUI.
"Mr. Oracle" contributed every line.

Of course, I could be wrong...
-Alex

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Alex Harui]

On 9/19/16, 6:16 AM, "Mark Struberg"  wrote:


>We also need to check whether the author and contributor flags are
>properly moved over by the import. We don't like to loose any IP
>provenance... Etc, etc.

Isn't IP provenance reset by the SGA?  It was for Adobe Flex.  Only a
couple of committers came in with the 10 year old code base.  Everyone
else had moved on, but because all were employees of Adobe, it didn't
matter.  The log just says that someone from Adobe made a commit, not who.

-Alex


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

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Alex Harui]

On 9/17/16, 8:54 AM, "Jochen Theodorou"  wrote:

>On 17.09.2016 10:23, Geertjan Wielenga wrote:
>> Nightly builds is all that's needed, indeed, no one needs to announce
>>them,
>> they should simply be available. Agreed it's important to distinguish
>> between nightly builds and official releases, that's exactly how
>>NetBeans
>> works currently. The #1 requirement here is that there should be nightly
>> builds and that is supported, from your response here.
>
>may I ask for whom and what the nightly builds are in your case? If it
>is for developers only there should be no problem.

Where "developers" is the folks contributing to the code in Apache, not
users of the code.
IIRC, there are also restrictions on how folks find out about the
"nightly" builds.  It can't be listed in the release info on the web site,
for example.

-Alex


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

Re: What goes in the NOTICES file?

[Alex Harui]

On 9/2/16, 12:08 PM, "John D. Ament"  wrote:

>All,
>
>I was wondering if someone can point me to a resource that clearly
>identifies what goes into the NOTICES file for a source and binary
>release?  I've seen Justin's video, but would be great to also have it
>written down.

I assume you've seen this:
http://www.apache.org/dev/licensing-howto.html#mod-notice

The "fun" part is in interpreting what is written down.

-Alex


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

Re: Dual-licensed logo PNG (CC-BY 3.0, LGPL 3.0)? [TAVERNA]

[Alex Harui]

Since Common Workflow code appears to be under ALv2, it might be worth
contacting that community and asking them to re-license the logo under
ALv2 as well and explain how the current logo licensing makes ALv2
consumption more difficult if they want their logo included in downstream
releases.

My 2 cents,
-Alex

On 8/27/16, 4:23 AM, "Shane Curcuru"  wrote:

>Indeed, I find it wholly unthinkable that we'd include any LGPL bits in
>an Apache product release, even if it's an ambiguous choice of licenses.
> There is no ambiguity in what types of licenses are allowed in Apache
>releases.
>
>The only way to do this (IMO, I'm not VP, Legal) is to make clear that
>we are licensing the unmodified graphic as CC-SA in our release.  If
>someone wants to include a note elsewhere in the release pointing to the
>original source of the PNG, that's fine.
>
>Please be sure this is noted on your project lists so your mentors can
>track it as well.
>
>- Shane
>
>Niclas Hedhman wrote on 8/26/16 10:25 PM:
>> Hi,
>> 
>> I would recommend that we only license that under CC-SA, but you might
>>want
>> to point out that the media files are also available under LGPL3. The
>> downstream user can re-apply (or swap with) the LGPL3 if they want to,
>>as
>> those media files are unmodified and we lay no additional claims.
>> 
>> 
>> Cheers
>> Niclas
>> 
>> On Fri, Aug 26, 2016 at 9:41 PM, Stian Soiland-Reyes 
>> wrote:
>> 
>>> Hi,
>>>
>>> Our GSOC student wants to include a PNG for a CWL logo (for
>>> representing CWL services within Apache Taverna), but the original
>>> logo is dual-licensed:
>>>
>>> From https://github.com/common-workflow-language/logo/blob/
>>> master/LICENSE.md
>>>
 The Common Workflow Language Logos are (C) Copyright 2016 the Common
>>> Workflow Language Project and are released under the terms of the GNU
>>> Lesser General Public License, version 3 or any later version, or, at
>>>your
>>> option, of the Creative Commons Attribution-ShareAlike 3.0 Unported
>>>License.
>>>
>>>
>>> https://www.apache.org/legal/resolved#cc-sa says:
>>>
 Unmodified media under the Creative Commons Attribution-Share Alike
2.5
>>> and Creative Commons Attribution-Share Alike 3.0 licenses may be
>>>included
>>> in Apache products, subject to the licenses attribution clauses which
>>>may
>>> require LICENSE/NOTICE/README changes. For any other type of CC-SA
>>>licensed
>>> work, please contact the Legal PMC.
>>>
>>>
>>> So I guess our best option is to use it under CC-SA 3.0 - but as LGPL
>>> 3.0 in this case is not effectively incompatible with ASF license
>>> either direction (it's easy to replace a PNG file in a JAR) - I don't
>>> see a reason why we have to remove that dual-license choice for
>>> downstream users?
>>>
>>> That is - my question is - are we fine in NOT specifying which of the
>>> two licenses we choose to distribute the PNG under?
>>>
>>> (This would allow for instance a GPL 3.0 downstream project to embed
>>> our code AND the logo without re-sourcing it from upstream)
>>>
>>>
>>>
>>> Here's our student's proposed modifications to append to our project's
>>> LICENSE:
>>>
>>> https://github.com/apache/incubator-taverna-common-
>>> activities/pull/21/files
>>>
>>>
>>> I assume we don't need to also modify our NOTICE file?  Am I correct
>>> in this understanding? Or should we do something more, e.g.
>>> cwl-logo-header.txt file next to the PNG or adding to the README?
>>>
>>>
>>>
>>> BTW - I have raised an issue upstream about the attribution as "Common
>>> Workflow Language Project" does not seem to be a legal copyright
>>> holder:
>>>
>>> https://github.com/common-workflow-language/logo/issues/2
>>>
>>> ..I guess for now we should respect their current (C) statement.
>>>
>>>
>>> Any feedback?
>>>
>>>
>>> --
>>> Stian Soiland-Reyes
>>> Apache Taverna (incubating), Apache Commons
>>> http://orcid.org/-0001-9842-9718
>>>
>>> -
>>> 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: Ease of release process and exit criteria

[Alex Harui]

On 8/20/16, 11:16 PM, "Christopher" <ctubb...@apache.org> wrote:

>By "source package must be able to build itself", are you suggesting that
>simple projects must create scripts inside the source itself to execute a
>simple tar/zip command (for example), instead of just documenting those
>lines? That seems a bit frivolous to me.

If by "simple projects" you mean those that simply package a tar/zip of a
repo, then I'm sure they could be an exception/degenerate-case/whatever.

But for any packaging that isn't simply a tar/zip of a repo, it might
force the scripting such that there isn't as much RM magic that can get
lost if key folks leave.

Just a thought,
-Alex

>
>On Sun, Aug 21, 2016 at 1:59 AM Alex Harui <aha...@adobe.com> wrote:
>
>> One more thought on this:  Right now the 'requirement' is for PMC
>>members
>> to be able to take the source package and build the binary before voting
>> +1.  What if the 'requirement' became that the PMC members must be able
>>to
>> take the source package and build both the binary and the source
>>package?
>> IOW, a source package must be able to build itself.
>>
>> Thanks,
>> -Alex



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

Re: Ease of release process and exit criteria

[Alex Harui]

One more thought on this:  Right now the 'requirement' is for PMC members
to be able to take the source package and build the binary before voting
+1.  What if the 'requirement' became that the PMC members must be able to
take the source package and build both the binary and the source package?
IOW, a source package must be able to build itself.

Thanks,
-Alex

On 8/20/16, 12:59 PM, "Mark Thomas"  wrote:

>All,
>
>It seems there is general consensus that this is a good idea. I'm
>therefore going to do the following.
>
>1. Draft some text to add to
>   http://incubator.apache.org/guides/graduation.html#releases
>   and bring that back to this list for discussion
>
>2. Start a thread on dev@community about adding an item to the project
>   maturity model.
>
>3. Identify somewhere to put all the good suggestions for, and links to
>   examples of, smooth release processes and then pull all the links
>   and suggestions from this thread to that place. I have a vague
>   recollection of seeing such a thing previously. I'll need to do some
>   digging to see it I can find it. Any hints?
>
>Mark
>
>
>On 19/08/2016 21:41, Dave Fisher wrote:
>> I know of a podling like that where the release manager gave me push
>>back until I told him I could not vote +1 without build instructions I
>>could at least follow on my own local.
>> 
>> That was some years ago. The podling graduated. The instructions were
>>not updated. The RM left. Now there is a bind.
>> 
>> A requirement is a good idea, but it is no guarantee that the
>>instructions remain up to date.
>> 
>> Suggestions:
>> 
>> Is this info for the maturity model?
>> Should there be special and higher standards to make binary releases
>>"official"?
>> 
>> Regards,
>> Dave
>> 
>> Sent from my iPhone
>> 
>>> On Aug 19, 2016, at 8:41 AM, Dennis E. Hamilton
>>> wrote:
>>>
>>> +1 to this, including the posts from Mark and Bertrand.
>>>
>>> I know of a project where this would have made a serious difference
>>>for graduation and subsequent sustainability.
>>>
>>> - Dennis
>>>
 -Original Message-
 From: Shane Curcuru [mailto:a...@shanecurcuru.org]
 Sent: Friday, August 19, 2016 07:08
 To: general@incubator.apache.org
 Subject: Re: Ease of release process and exit criteria

 Bertrand Delacretaz wrote on 8/19/16 5:57 AM:
> Hi Mark,
>
> On Fri, Aug 19, 2016 at 11:23 AM, Mark Thomas 
 wrote:
>> ...I'm thinking of a graduation criteria long the lines of:
>> "Is the release process clearly documented to the point that someone
 new
>> to the project could produce a release build?"...

 +1, this is a critical point to include.  We continue to see projects
 struggling with releases when early volunteers leave and no-one else
 really understands releases.

 ...snip...
> How about also adding an RE50 item to
> https://community.apache.org/apache-way/apache-project-maturity-
 model.html
> about a repeatable release process? That's a discussion for
> community.a.o but what's your opinion?

 +1, this is both important to include philosophically as well as
 practically.  I.e. it's an important reminder that project technical
 procedures need to be understandable by the *whole* community, not
just
 the first few developers who created the project.

 - Shane

 -
 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
>>>
>> 
>> 
>> -
>> 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: Ease of release process and exit criteria

[Alex Harui]

On 8/19/16, 7:08 AM, "Shane Curcuru"  wrote:

>Bertrand Delacretaz wrote on 8/19/16 5:57 AM:
>> Hi Mark,
>> 
>> On Fri, Aug 19, 2016 at 11:23 AM, Mark Thomas  wrote:
>>> ...I'm thinking of a graduation criteria long the lines of:
>>> "Is the release process clearly documented to the point that someone
>>>new
>>> to the project could produce a release build?"...
>
>+1, this is a critical point to include.  We continue to see projects
>struggling with releases when early volunteers leave and no-one else
>really understands releases.

So would graduation require that at least one IPMC member (not already in
the podling) can complete the release steps without getting an error?
Otherwise, there is a risk that folks point to a web page full of
instructions but nobody can actually get them to work.

-Alex

Re: [VOTE] Apache HAWQ (incubating) 2.0.0.0-incubating Release

[Alex Harui]

To be concrete:  up thread was mention of shm.c

I found two shm.c files in the HAWQ repo.  It says it came in as part of
the SGA.  I looked in PostGreSQL's repo, but didn't find shm.c in the same
paths.  So where did HAWQ's shm.c come from?  I think that's what Justin
is asking.

On 8/9/16, 4:32 PM, "Justin Mclean"  wrote:

>Hi,
>
>> Why? It would be perfectly fine for PG project to include, lets say an
>>MIT
>> source code.
>
>That would be compatible with our license. But what if they included GPL
>or CDDL licensed software?
>
>> That's why I don't feel comfortable putting the overall PG  licensed
>>header there on my own.
>
>Nor should you if the files are not licensed that way.
>
>> I think we're talking slightly past each other -- I told you I do KNOW
>>that they
>> are licensed under the different ALv2 compatible license.
>
>The package as a whole is licensed that way. But you stated you didn’t
>not know how that file is licensed it may be ALv2 or it may be something
>else. Just as it has different copyright owner it also likely is under a
>different license, whose terms are very likely to be APv2 compatible, but
>may not be.
>
>Thanks,
>Justin
>-
>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 HAWQ (incubating) 2.0.0.0-incubating Release

[Alex Harui]

On 8/9/16, 3:10 PM, "Justin Mclean"  wrote:

>Hi,
>
>> AIUI, if it is 3rd party and otherwise unmodified, modification of the
>> headers is not an option.
>
>Even when the files are missing header or missing the license that they
>were originally under?

IANAL, but in my mind, yes.  The header is just a convenience.  It isn't a
legal requirement.  Not having a header doesn't change the licensing of
the lines in the file.  Having 3rd party files in our repos or a release
package is just a convenience to avoid having to download them separately,
so I wouldn't make them different from the the "original".  As long as the
LICENSE file mentions that there are files not under ASF control that
should be sufficient for a release.  I wouldn't hold up a release for
missing headers on 3rd party files.

-Alex

Re: [VOTE] Apache HAWQ (incubating) 2.0.0.0-incubating Release

[Alex Harui]

On 8/9/16, 1:46 PM, "shaposh...@gmail.com on behalf of Roman Shaposhnik"
<shaposh...@gmail.com on behalf of ro...@shaposhnik.org> wrote:

>On Tue, Aug 9, 2016 at 1:39 PM, Alex Harui <aha...@adobe.com> wrote:
>>
>>
>> On 8/9/16, 1:27 PM, "shaposh...@gmail.com on behalf of Roman Shaposhnik"
>> <shaposh...@gmail.com on behalf of ro...@shaposhnik.org> wrote:
>>
>>>On Mon, Aug 8, 2016 at 8:27 PM, Justin Mclean <jus...@classsoftware.com>
>>>wrote:
>>>> Hi,
>>>>
>>>>> This is why we're relying a great deal on RAT's exclusion file to
>>>>>mark
>>>>> the files that came from PG even though their license headers could
>>>>>look weir enough.
>>>>
>>>> Would’t be better to fix/add the headers?
>>>
>>>For things where we diverged from the upstream with producing sizable
>>>changes
>>>to the existing code -- absolutely and some of your findings may as
>>>well fit in that
>>>category. For the code that is kept pristine, I'd like to avoid
>>>modifying the headers.
>>
>> Did the code owners (original authors of these files) actually sign an
>>SGA
>> to donate these files to Apache?
>
>No. I though it was implicit in my original email, but thanks for
>calling attention to it.

AIUI, if it is 3rd party and otherwise unmodified, modification of the
headers is not an option.

>
>> If not, these files are technically not
>> part of a code donation and should be treated as you would any 3rd party
>> code.  AIUI, you can't grant code you don't own, even if it was
>> accidentally included in an SGA.
>
>Correct for the pristine, unmodified sources. For source originally
>coming from PG
>where Pivotal (and companies prior to it) added/modified to it the
>line get blurry.
>
>Personally, I feel like those types of files definitely need to be
>included in the SGA.
>After all, Pivotal did own the modifications on top of the pristine PG
>source and it is
>important for the company to explicitly signal donation of that code.

AIUI, files containing IP owned by the SGA signors should be listed in the
SGA.  It is helpful to have clear documentation in the files and LICENSE
as to what is under ASF control and what is 3rd party.  I think some folks
use two headers (ASF then original), but I haven't seen that as required.
Sure, non-standard headers makes RAT checking harder, but IMO if the
LICENSE provides sufficient warning that you might find 3rd party code in
certain locations that should be good enough.

-Alex

Re: [VOTE] Apache HAWQ (incubating) 2.0.0.0-incubating Release

[Alex Harui]

On 8/9/16, 1:27 PM, "shaposh...@gmail.com on behalf of Roman Shaposhnik"
 wrote:

>On Mon, Aug 8, 2016 at 8:27 PM, Justin Mclean 
>wrote:
>> Hi,
>>
>>> This is why we're relying a great deal on RAT's exclusion file to mark
>>> the files that came from PG even though their license headers could
>>>look weir enough.
>>
>> Would’t be better to fix/add the headers?
>
>For things where we diverged from the upstream with producing sizable
>changes
>to the existing code -- absolutely and some of your findings may as
>well fit in that
>category. For the code that is kept pristine, I'd like to avoid
>modifying the headers.

Did the code owners (original authors of these files) actually sign an SGA
to donate these files to Apache?  If not, these files are technically not
part of a code donation and should be treated as you would any 3rd party
code.  AIUI, you can't grant code you don't own, even if it was
accidentally included in an SGA.

-Alex

Re: [VOTE] Fluo Parent POM 1-incubating (rc2)

[Alex Harui]

On 8/1/16, 6:52 PM, "Christopher"  wrote:

>> My recommendation is that fluo.io be donated to the ASF and a new domain
>> name chosen for the non-ASF community backed site.
>>
>
>We'll need to discuss this further, but I think our preferred option is
>going to be (in order of preference):
>
>1. Get approval from TM about continued use of the fluo.io domain as an
>unaffiliated community site.
>2. Choose a new name for the podling project.
>3. Your recommendation above.

From the peanut gallery:

My understanding is that there are "strong" marks and "weak(er)" marks,
that, AIUI, is related to how much usage of the TM is already out there,
how many were actually approved, and to what degree un-approved mark usage
was pursued by the mark holder.

Flex, for example, is a "weaker" mark.  When Adobe donated the Flex TM to
Apache, there were dozens of domains with 'flex' in it both related to
Adobe Flex and other things like cars, delivery services, even other
software like lexers.  I'm pretty sure neither Apache nor Adobe went
around to all of the flex domains related to Apache Flex and made them get
permission to continue using their domain name, but Adobe did redirect
flex.org to Apache (although I just noticed it isn't responding).  AIUI,
if we find out that someone is using flex.biz, flex.us, or any other
flex.* domain, even if they are helping to promote Apache Flex, we are
supposed to ask them to use something else.  But I believe there is more
flexibility around using flex as part of the domain name.

So, IMO, I will be surprised if fluo.io gets approved for non-ASF usage.
I think, though, that fluo.io could redirect to a page on the podling site
that explains that why fluo.io doesn't do what it used to do, and even
have a link to what was at fluo.io but with a new domain name, maybe
fluo-tools or tools-for-fluo.io.  AIUI, you can link to web sites that
aren't under ASF-friendly licensing as long as there are disclaimers on
your page.

HTH (but of course, I could be wrong),
-Alex


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

Re: [VOTE] $podling.apache.org is the same as $podling.incubator.apache.org

[Alex Harui]

On 6/29/16, 9:13 AM, "Shane Curcuru"  wrote:
>
>> 
>> Hmmm not a bad idea.  I'd still like to see us re-double the effort on
>> resolving branding issues on the websites.  Ultimately I'd like for
>>mentors
>> to own it, but that doesn't seem to happen due to mentor availability.
>
>It's clear there's too wide a variability in mentor, ahem, attention
>span to rely on mentors for all podlings.  Volunteers and ideas on how
>to do this better appreciated.

Doesn't Whimsy have a report review tool?  Maybe it could popup the
podling's website in a separate window.  And if you don't see the word
Disclaimer/Incubating above the fold...

-Alex

Re: Request to review updated License (Re: [VOTE] Release Apache Ranger 0.5.3 (incubating))

[Alex Harui]

IMO, http://www.apache.org/dev/licensing-howto.html#permissive-deps
says the blurb about JQuery goes in LICENSE, not NOTICE.


On 6/20/16, 12:14 PM, "John D. Ament"  wrote:

>Lines like this are contents for the notice file, not license file:
>
>
>This product includes jQuery (http://jquery.org - MIT license), Copyright
>©
>2014, John Resig. license file should include the various licenses
>covering
>these works.
>On Mon, Jun 20, 2016 at 3:07 PM Velmurugan Periasamy 
>wrote:
>
>> Hi Justin:
>>
>> I would like to get your feedback on updated LICENSE.txt for Ranger.
>> https://github.com/apache/incubator-ranger/blob/master/LICENSE.txt
>>
>> Please see below answers to your questions. Ranger dev community is
>> getting prepared for the next major release, so getting your feedback
>>and
>> approval on license would be critical. Thanks for your help.
>>
>> <<
>> Minor issues:
>> LICENSE is missing MIT licensed Search Icon CSS copyright Nicolas
>> Gallagher bundled in (1)
>> Added PURE CSS GUI ICONS to LICENSE.txt
>> Is the copyright on this files correct? (2)(3) if so what projects did
>> they come from? (may effect content of NOTICE file)
>> (2) -> Added Jisql license.
>> (3) -> This file comes with Spring Security. Added that to LICENSE.txt
>> LICENSE is missing MIT licensed es5-shim copyright Kristopher Michael
>> Kowal bundled in (4)
>> Added to LICENSE.txt
>> LICENSE is missing SIL licensed FontAwesome (9)
>> Added to LICENSE.txt
>> LICENSE is missing reset.css. (7) Note this version bundled may not be
>> public domain unlike this one (8) so you may need to sort that out.
>> Added a note in LICENSE.txt
>> LICENSE is missing MIT licensed sizzle.js bundled in several files (10)
>> Added to LICENSE.txt
>> LICENSE is missing MIT license javascript diff engine in (11)
>> File was not used, removed the file.
>> I think handle bars require plugin is not WTFPL but MIT or BSD? (12) May
>> require further investigation.
>> Added a note in LICENSE.txt
>> LICENSE is missing public domain json2.js (13)
>> Added to LICENSE.txt
>> LICENSE is missing BSD licensed easing equations from Robert Penner (15)
>> in this file (14)
>> Added a note in LICENSE.txt
>> This is a more serious concern (and has been asked before):
>> How is this file licensed? (5) or this one? (6)
>> These files are not used, removed the files.
>> 1.
>> 
>>./apache-ranger-incubating-0.5.3/security-admin/src/main/webapp/libs/bowe
>>r/backgrid-filter/css/backgrid-filter.css
>> 2.
>> 
>>./apache-ranger-incubating-0.5.3/jisql/src/main/java/org/apache/util/sql/
>>Jisql.java
>> 3.
>> 
>>./apache-ranger-incubating-0.5.3/security-admin/src/test/java/org/apache/
>>ranger/service/PasswordComparisonAuthenticator.java
>> 4.
>> 
>>./apache-ranger-incubating-0.5.3/security-admin/src/main/webapp/libs/othe
>>r/backgrid/backgrid.js
>> 5.
>> 
>>./apache-ranger-incubating-0.5.3/security-admin/src/main/webapp/libs/bowe
>>r/globalize/generator/HijriCalendar.js
>> 6.
>> 
>>./apache-ranger-incubating-0.5.3/security-admin/src/main/webapp/libs/bowe
>>r/globalize/generator/UmAlQuraCalendar.js
>> 7.
>> 
>>./apache-ranger-incubating-0.5.3/security-admin/src/main/webapp/libs/othe
>>r/visualsearch/css/reset.css
>> 8. http://meyerweb.com/eric/tools/css/reset/reset.css
>> 9.
>> 
>>apache-ranger-incubating-0.5.3/security-admin/src/main/webapp/fonts/fonta
>>wesome/FontAwesome.otf
>> 10. ./security-admin/src/main/webapp/libs/bower/jquery/js/jquery.js
>> 11.
>> 
>>./security-admin/src/main/webapp/libs/bower/globalize/test/qunit/qunit.js
>> 12.
>> 
>>/security-admin/src/main/webapp/libs/bower/require-handlebars-plugin/js/h
>>bs.js
>> 13.
>> 
>>./security-admin/src/main/webapp/libs/bower/require-handlebars-plugin/js/
>>json2.js
>> 14.
>> 
>>./security-admin/src/main/webapp/libs/other/jquery-ui/js/jquery-ui-1.10.3
>>.custom.js
>> 15 http://robertpenner.com/easing/
>> >>
>>
>> Thank you,
>> Vel
>>
>> On May 20, 2016, at 11:25 AM, Velmurugan Periasamy 
>>wrote:
>>
>> > Thank you so much Justin. I’ll do the below.
>> >
>> > 1] Initiate another RC for 0.5.3.
>> > 2] Track these issues in
>> https://issues.apache.org/jira/browse/RANGER-964 and target to address
>>in
>> 0.6.0
>> >
>> > Regarding your question on [5] and [6] below, I believe these files
>>are
>> covered under jquery globalize license. I will double check and resolve
>>it
>> as needed in next release.
>> >
>> >> This is a more serious concern (and has been asked before):
>> >> - How is this file licensed? [5] or this one? [6]
>> >
>> >
>> > Thank you for your help,
>> > Vel
>> >
>> > On May 19, 2016, at 8:11 PM, Justin Mclean 
>> wrote:
>> >
>> >> Hi,
>> >>
>> >> Still needs some work IMO but if a JIRA was raised to fix these
>>issues
>> in a later release I’d vote +1 on a new RC without these fixes. Just as
>> long as it’s all sorted before graduation.
>> >>
>> >> Minor issues:
>> >> - LICENSE is missing MIT licensed Search Icon CSS copyright 

Re: Toree's One Release Constraint

[Alex Harui]

On 5/20/16, 9:32 AM, "Edward Capriolo"  wrote:

>Yes if you are using a feature specific to a specific product it is
>obvious
>even if you wrap cruft around it. however when I see something that uses
>"rabbit mq" i generally think to wrap an interface around it so I can
>replace with Apache Kafka :).I am wondering if the same be done here.

Interface abstraction might be a good engineering design decision, but it
won't affect the perceived LPGL dependency if a significant number of your
users must bring down an LPGL dependency in order to have a satisfactory
solution.  It isn't whether they "can" replace RabbitMQ with Apache Kafka,
it is whether they will.

-Alex

Re: Toree's One Release Constraint

[Alex Harui]

On 5/20/16, 8:57 AM, "Edward Capriolo"  wrote:

>" You could argue that it makes the dependency optional"
>Yes that is what I am saying. Like in a JDBC application you may be
>connecting to postgres or mysql you are not concerned how those are
>licensed because you are linked to the shim/driver. You could even bring
>in
>the Microsoft SQL server as a jar in this case.

Right.  Then, AIUI,  the test is about "will" not "could".  What "will"
the majority of your customer do?  If reality is that they will bring down
the LGPL implementation you have not truly passed the "optional" test.
The uber goal is to get away from having customers of Apache products
worry about LGPL and other unfriendly licenses ending up on their system.

-Alex


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

Re: Toree's One Release Constraint

[Alex Harui]

On 5/20/16, 7:23 AM, "Edward Capriolo"  wrote:

>Would it be acceptable to develop a shim layer toree can link to that and
>the provider is dropped in at runtime like the jdbc interface?

AIUI, a shim doesn't break the dependency chain.  You could argue that it
makes the dependency optional, but then the test becomes whether the
majority of your users will end up downloading the LPGL version anyway.
IMO, the mentors should help you advocate for a second exception to the
rule.

HTH,
-Alex

Re: [VOTE] [FINERACT] 0.1.0.incubating for release

[Alex Harui]

On 4/14/16, 12:49 AM, "Adi Raju"  wrote:

>We cannot even depend on cat-x licensed libraries?

IMO, it depends on what you mean by "depend".  There are some exceptions
discussed here [1]

HTH,
-Alex

[1] http://www.apache.org/legal/resolved.html


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

Re: LICENSE info for ALv2, not ASF

[Alex Harui]

On 3/7/16, 2:38 PM, "Craig Russell"  wrote:

>>>Agreed.  Sebb's recommendation, AIUI, was to simply mention in LICENSE
>>> that there is a non-ASF AL bundle without copying the entire LICENSE.
>
>That’s what I was objecting to. LICENSE is for licenses. If notice is
>required, then use NOTICE.

Hmm.  It feels like maybe folks aren't actually reading the first link I
provided [1].  In it, sebb approves a patch to the how-to [2].  The how-to
currently recommends not placing 3rd party licenses in the LICENSE file
and instead using a template like:

This product bundles SuperWidget 1.2.3, which is available under a
"3-clause BSD" license.  For details, see deps/superwidget/.


In [1], the proposed patch is to use a similar template for non-ASF ALv2
bundles.  The text being added is, AIUI, not stuff we are supposed to put
in NOTICE.

Justin is technically correct that [2] does not clearly state to list
non-ASF ALv2 bundles using the template but it would if the patch had been
applied.  The patch would create a section that reads:

"Assuming once again that that the bundled dependency itself contains no
bundled subcomponents under other licenses and thus the ALv2 applies
uniformly to all files, there is no need to add another copy of the ALv2
license, but if the dependency is third-party, the LICENSE file should
include:

'Includes Foo V1.2 under the Apache License 2.0'"


I've been hoping someone braver than me would apply the patch, but now it
appears that Marvin is going to refresh the whole document, so maybe it
will finally get settled when his revision comes up for review.

Thanks,
-Alex

[1] http://s.apache.org/qDa
[2] http://www.apache.org/dev/licensing-howto.html


>
>Craig
>
>>> 
>>> -Alex
>> 
>> Got it. Thanks Alex & Craig for the clarifications.
>> 
>> -Steve
>> 
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>> 
>
>Craig L Russell
>Architect
>craig.russ...@oracle.com
>P.S. A good JDO? O, Gasp!
>
>
>
>
>
>
>-
>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: LICENSE info for ALv2, not ASF

[Alex Harui]

On 3/7/16, 12:26 PM, "Craig Russell"  wrote:

>As I understand it, LICENSE is for licenses. Period. If advertising is
>required, the NOTICE file is used.

Sorry, I should have been more clear.  When I said "consider NOTICE" I
meant that any NOTICE for the non-ASF AL dependency may have content that
needs to into the NOTICE and not LICENSE.

>
>If there are third party works included in a distribution that use the
>same Apache 2.0 license as any Apache components, the license file
>already contains the appropriate license.

Agreed.  Sebb's recommendation, AIUI, was to simply mention in LICENSE
that there is a non-ASF AL bundle without copying the entire LICENSE.

-Alex

Re: LICENSE info for ALv2, not ASF

[Alex Harui]

On 3/7/16, 11:21 AM, "Steve Varnau"  wrote:

>Hi,
>
>
>
>I’m compiling information for LICENSE file for a binary distribution.  We
>(Trafodion) have a bundled dependency that is Apache-2.0 license, but not
>part of ASF.  Do we need to call these out in the license file, or only
>call out the things that are non-Apache-2.0?

>
Sebb says yes in [1], but IMO, it isn't wrong either way.  Make sure you
consider the NOTICE file though.  Hopefully Marvin will nail this down one
way or the other in the next revision of the how-to.

HTH,
-Alex

[1] http://s.apache.org/qDa




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

Re: [IP CLEARANCE] Apache Brooklyn - CLI

[Alex Harui]

Thanks Craig.  Richard, I would take Craig's answer as authorization to
proceed.

-Alex

On 3/7/16, 9:43 AM, "Craig Russell" <craig.russ...@oracle.com> wrote:

>A software grant can only grant rights that are owned by the grantor.
>
>If there was a(n innocent) mistake in the file referenced by the grant,
>no big deal IMHO.
>
>Clearly, bundled dependencies cannot be included in a grant since the
>grantor has no rights to them. The fact that they were included in a file
>referenced by the grant has no relevance. Including them was just a
>mistake.
>
>No action needed IMHO since the intent is clear.
>
>Craig
>
>> On Mar 7, 2016, at 9:34 AM, Alex Harui <aha...@adobe.com> wrote:
>> 
>> 
>> 
>> On 3/7/16, 6:05 AM, "Richard Downer" <rich...@apache.org> wrote:
>> 
>>> Alex, Justin, all,
>>> 
>>> Thank you for your comments. With your comments in mind, I will make
>>> this statement for the record:
>>> 
>>> Regarding the subject of the Software Grant Agreement, download link:
>>> 
>>>https://github.com/brooklyncentral/brooklyn-cli/archive/b8b39e54ecbb7c12
>>>f4
>>> 828783f07bec978a76b7be.zip
>>> SHA1: 5b5ef46c56adfff8ca86cca04694d5abc10ec447
>>> SHA256: 
>>>0cfaac11df7075c723bfb982ed5852d790fa195dcfe67c9bbbd545f34df71770
>>> 
>>> The folder 
>>>brooklyn-cli-b8b39e54ecbb7c12f4828783f07bec978a76b7be/br/Godeps
>>> is *excluded* from the code grant; this folder contains bundled
>>> dependencies licensed by 3rd parties using the MIT and BSD licenses.
>>> 
>>> With this folder removed from the ZIP file using the command zip -d
>>> FILENAME.zip 
>>> brooklyn-cli-b8b39e54ecbb7c12f4828783f07bec978a76b7be/br/Godeps\*,
>>> the hashes become:
>>> SHA1: 91fda2ca20c4b171985e1f5bb545ed8a236123dd
>>> SHA256: 
>>>4de28b308ad09f0e5642b4cefdd54b1c91b255fecd00184763a7d260bf8ec12d
>>> 
>>> I am updating the IP Clearance record with this same statement.
>>> 
>>> Is this sufficient notice for the record to address your comments?
>> 
>> I would hope it is sufficient, but I am not the person who can make the
>> call.  Other more senior folks may be able to make the call, but if you
>> want to be more sure, I would ask on legal-discuss if this is a
>>sufficient
>> way to update an SGA.
>> 
>> -Alex
>> 
>> 
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>
>Craig L Russell
>Secretary, Apache Software Foundation
>c...@apache.org http://db.apache.org/jdo
>
>
>-
>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: [IP CLEARANCE] Apache Brooklyn - CLI

[Alex Harui]

On 3/7/16, 6:05 AM, "Richard Downer"  wrote:

>Alex, Justin, all,
>
>Thank you for your comments. With your comments in mind, I will make
>this statement for the record:
>
>Regarding the subject of the Software Grant Agreement, download link:
>https://github.com/brooklyncentral/brooklyn-cli/archive/b8b39e54ecbb7c12f4
>828783f07bec978a76b7be.zip
>SHA1: 5b5ef46c56adfff8ca86cca04694d5abc10ec447
>SHA256: 0cfaac11df7075c723bfb982ed5852d790fa195dcfe67c9bbbd545f34df71770
>
>The folder brooklyn-cli-b8b39e54ecbb7c12f4828783f07bec978a76b7be/br/Godeps
>is *excluded* from the code grant; this folder contains bundled
>dependencies licensed by 3rd parties using the MIT and BSD licenses.
>
>With this folder removed from the ZIP file using the command zip -d
>FILENAME.zip 
>brooklyn-cli-b8b39e54ecbb7c12f4828783f07bec978a76b7be/br/Godeps\*,
>the hashes become:
>SHA1: 91fda2ca20c4b171985e1f5bb545ed8a236123dd
>SHA256: 4de28b308ad09f0e5642b4cefdd54b1c91b255fecd00184763a7d260bf8ec12d
>
>I am updating the IP Clearance record with this same statement.
>
>Is this sufficient notice for the record to address your comments?

I would hope it is sufficient, but I am not the person who can make the
call.  Other more senior folks may be able to make the call, but if you
want to be more sure, I would ask on legal-discuss if this is a sufficient
way to update an SGA.

-Alex

Re: [VOTE] Apache Kudu (incubating) 0.7.0 RC3

[Alex Harui]

On 3/1/16, 5:22 PM, "Todd Lipcon"  wrote:

>On Tue, Mar 1, 2016 at 4:05 PM, Justin Mclean  wrote:
>
>> Hi,
>>
>> > I seem to recall reading some place or another that pointers
>> > to licenses in the forms of URLs or textual references are frowned
>>upon,
>> > because licenses may change over time, or the links may break
>>
>> Correct. Also most licenses say you much include the full text of the
>> license in your distribution.
>>
>>
>OK. In the case that we've incorporated code, we could switch to doing:
>
>"""
>src/kudu/gutil/valgrind.h: Hybrid BSD (half BSD, half zlib)
>src/kudu/util (some portions): 3-clause BSD license
>src/kudu/util (HdrHistogram-related classes): public domain
>src/kudu/util/{random-util.cc},{random.h}: some portions adapted from
>WebRTC project (modules/video_coding/main/test/test_util.cc) under a
>3-clause BSD license.
>
>  For full license text of the above licenses, please refer to the license
>headers at the top of the respective files.
>"""
>
>...and then make sure that those files contain the full text of the
>license, instead of copy-pasting the text into LICENSE.txt. Does that
>sound
>like the best path forward?

I haven't been following carefully, but isn't there a BSD header in these
files?  If so, couldn't your LICENSE refer people to the headers in those
files?

-Alex

Re: [IP CLEARANCE] Apache Brooklyn - CLI

[Alex Harui]

On 3/1/16, 12:18 PM, "Justin Mclean"  wrote:

>Hi,
>
>> Sorry if I'm missing something, but it sounds like Justin found these
>> files in the zip referenced by the Grant.
>
>The files are clearly marked as BSD/MIT licensed and who the copyright
>owner is IMO (but I could be wrong) I don’t think the grant needs to be
>redone as it’s clear what would be under the ASF license. It would also
>be relatively easy to remove the files from the zip and resubmit.

I don't know if there is an official protocol for a scenario like this.
All I think is needed is an email trail that indicates that the Grant
needed some modifications and what the modifications were.  The grant
document contains a SHA hash for the zip so if you change the zip the
grant may need the SHA hash updated.  But hopefully it will be ok for
folks to find an updated SHA hash in an email in the archives or maybe in
the IP Clearance record itself.

Thanks,
-Alex


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

Re: [IP CLEARANCE] Apache Brooklyn - CLI

[Alex Harui]

On 3/1/16, 1:36 AM, "Richard Downer"  wrote:

>Justin,
>
>On 29 February 2016 at 22:36, Justin Mclean 
>wrote:
>>> See http://incubator.apache.org/ip-clearance/brooklyn-cli.html
>>>
>> I notice the code contains MIT and BSD licensed code and crypto code.
>>[1] Was this intended?
>
>MIT/BSD: yes this is intended - they are embedded dependencies, in a
>similar way that jquery might be embedded in a web app. (Bundling
>dependencies like this, I'm told, is normal for Go 1.5 - Go 1.6 makes
>it possible to link to dependencies without bundling and this is
>something that the community would like to look into.)

Sorry if I'm missing something, but it sounds like Justin found these
files in the zip referenced by the Grant.  If these files are dependencies
(not owned by the signers of the grant, no other paperwork authorizing the
grant signers to donate on behalf of the owners, and no intention for the
"home" for future development of these files to be at the ASF), then these
files should not be in the grant.  For sure, Jquery files should never be
in an grant to the ASF (unless the Jquery project decided to donate Jquery
to the ASF).

If there is a lot, you might want to re-do the Exhibit A (new zip and MD5
and update the grant document).  If it is a few, you might want to check
with legal-discuss or get advice from more senior people on this list, but
I would just explicitly list those few files in an email on this list
and/or your dev list so there is permanent record that you are making an
unofficial addendum to the grant and keep on going.

Of course, I could be wrong...
-Alex

Re: Must name and copyright of bundled (other) ASF artifacts be attributed in NOTICE file?

[Alex Harui]

On 2/6/16, 8:29 AM, "Marvin Humphrey"  wrote:

>
>So the question is, what parts of NOTICE pertaining to Apache projects
>must we
>propagate, and what portions can we omit?  I'd say that the name of the
>Apache
>project and the copyright statement ought to be bubbled up.
>
>And this interpretation is consistent with the guidance in the Licensing
>How-To:
>
>http://www.apache.org/dev/licensing-howto#bundle-asf-product
>
>It is not necessary to duplicate the line "This product includes
>software
>developed at the Apache Software Foundation...", though the ASF
>copyright
>line and any other portions of NOTICE must be considered for
>propagation.

I don't disagree with your logic, but just for the sake of argument, I
assume we are talking about these two lines:

  Apache [PRODUCT_NAME]
  Copyright [] The Apache Software Foundation


I would argue that the copyright of an ASF dependency, if it follows this
template, does not need to be propagated because it is a collective
copyright and the dependency is now part of a larger collective copyright
which is going to be the 2nd line of the NOTICE for the actual
distribution.  And by doing so, you make the NOTICE one line shorter for
every dependency and avoid duplicate copyright lines with varying year
ranges.  If the copyright notice is not from this template, then the
decision might depend on those differences.

And I would argue that we should change the rules for LICENSE and put all
bundled dependencies, ASF or non-ASF, in the LICENSE so there is one place
to look and avoid propagating the product name from NOTICE and save
another line per dependency.

Thanks,
-Alex

Re: Confusion over NOTICE vs LICENSE files

[Alex Harui]

On 2/4/16, 3:54 PM, "Justin Mclean"  wrote:

>A fair number of non ASF Apache software is usually missing a NOTICE file
>or has other issues. What do we do when you bundle a non ASF Apache
>license software that is missing a NOTICE file? Nothing or be a little
>more polite or assume a minimal NOTICE file and add that to ours?

When I saw this topic in the past, the answer was "nothing" [1] or work
with that software community so they put a NOTICE in their future releases
[2]

HTH,
-Alex

[1] 
https://mail-archives.apache.org/mod_mbox/www-legal-discuss/201406.mbox/%3c
CAM1oqKqL+1A90=wkqda-gjyqto5gah+ep3wvitrmf9etiai...@mail.gmail.com%3e

[2] 
https://mail-archives.apache.org/mod_mbox/www-legal-discuss/201508.mbox/%3c
CAM1oqKp-iimxUS4+b11WTt6FuoDwLxL_vQjCio=xrx34jsd...@mail.gmail.com%3e


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

Re: [DISCUSS] Apache Dataflow Incubator Proposal

[Alex Harui]

On 1/28/16, 3:26 AM, "Jean-Baptiste Onofré"  wrote:

>I prefer Beam ;)

I like the name and the logic behind choosing it.  Some concerns are that
a Google search of "Beam Software" turned up [1] and [2] among others,
which might mean that Apache Beam won't work as a TLP name.  "Beam" is a
good stem word so maybe you can add something to the front: "FlowBeam",
"DataBeam", etc.

-Alex

[1] http://www.beamsoftware.com
[2] https://earth.esa.int/web/sentinel/-/beam

Re: Confusion over NOTICE vs LICENSE files

[Alex Harui]

On 1/26/16, 12:07 AM, "Justin Mclean"  wrote:

>Hi,
>
>> In this email [4], Sebb recommends mentioning non-ASF Apache-licensed
>> bundled dependencies in LICENSE.
>
>I think you are misrepresenting Sebb here but I'll let him clarify if
>need be.
>
>The case you refer to the file in question was a binary file whose
>license wasn’t obvious. When adding one (or more) source files they would
>have an Apache header naming the copyright owner so there is no
>requirement to list them in LICENSE. Adding them to LICENSE is not an
>error but it is not required. If it was required then there would be many
>Apache releases with incorrect licenses.

Here's a related link where sebb seems to be saying it applies to source
packages as well:
http://s.apache.org/7mq


-Alex

Re: Confusion over NOTICE vs LICENSE files

[Alex Harui]

On 1/25/16, 6:19 PM, "Todd Lipcon"  wrote:

>Hey folks,
>
>I'm working on tidying up the source for Apache Kudu (incubating) in order
>to prepare for our first ASF release, and ran into a couple bits of
>confusion:
>
>1) In the case that we've borrowed code from another Apache 2.0 licensed
>project, the licensing howto[1] says that there is no need to modify
>LICENSE unless it transitively has dependencies with such a requirement.
>Is
>this true even if the original dependency carries a copyright? For
>example,
>we bundle Twitter's Bootstrap library and currently have attribution in
>our
>LICENSE file[2] indicating the copyright (even though it's also at the top
>of the relevant files). Not necessary? We can just entirely ignore such
>dependencies in LICENSE and NOTICE so long as the original header's
>maintained?

In this email [4], Sebb recommends mentioning non-ASF Apache-licensed
bundled dependencies in LICENSE.  So that's what I've been doing with
LICENSEs for release I manage.  I'm not a fan of including text of the
licenses, I prefer the "pointer" text as mentioned in [1].  IOW: "This
product bundles SuperWidget 1.2.3, which is available under a
"3-clause BSD" license.  For details, see deps/superwidget/."

>
>2) In other cases we've bundled MIT or BSD-licensed source. The license
>says that redistributions must retain the text of the license. Is it
>sufficient that that text be only in the source code, or should we also
>duplicate it into LICENSE.txt as we've done for code derived from
>AsyncHBase? [3]

Again, I prefer "pointer text" vs copying entire licenses, but AIUI, MIT
and BSD bundled dependencies must be mentioned in LICENSE.

>
>3) We have many thirdparty dependencies which are not "bundled" in the
>source release. Instead, our build process has a script which downloads
>them from the internet, unpacks, and compiles them. So, despite not being
>part of the artifact itself, they are required components for the build
>(and in most cases become static-linked into the binary). We currently
>list
>all of these dependencies and their licenses in LICENSE.txt. Is this
>necessary, or should we move these into a separate file?

AIUI, only bundled dependencies should be mentioned in LICENSE, so
non-bundled dependencies should not be mentioned in LICENSE.  In releases
I manage, I put mention of those non-bundled dependencies in the README.

The reason I prefer pointers is that I like keeping this file short so
folks can read it more easily/quickly.  The text of these licenses are
easy to find elsewhere.

In my simple mental model, the LICENSE is the list of suppliers.  The ASF
is one supplier, every other supplier in the package is mentioned.  NOTICE
is legal stuff required by that list of suppliers.  README is for other
stuff like the list of other external dependencies (e.g. "batteries not
included", or "tools required to assemble this furniture")

HTH,
-Alex

>
>[1] http://www.apache.org/dev/licensing-howto
>[2]
>https://git1-us-west.apache.org/repos/asf?p=incubator-kudu.git;a=blob;f=LI
>CENSE.txt;h=347de4f88b5e6240f6e560b2b1208364d6042c55;hb=HEAD#l424
>[3]
>https://git1-us-west.apache.org/repos/asf?p=incubator-kudu.git;a=blob;f=LI
>CENSE.txt;h=347de4f88b5e6240f6e560b2b1208364d6042c55;hb=HEAD#l553

[4] http://s.apache.org/qDa

Re: [DISCUSS] Apache Dataflow Incubator Proposal

[Alex Harui]

On 1/22/16, 10:58 AM, "Frances Perry"  wrote:

>Crunch started as a clone of FlumeJava, which was Google internal. In the
>meantime inside Google, FlumeJava evolved into Dataflow. So all three
>share
>a number of concepts like PCollections, ParDo, DoFn, etc. However,
>Dataflow
>adds a number of new things -- the biggest being a unified batch/streaming
>semantics using concepts like Windowing and Triggers.

And somewhere in there might be your new podling name.  WinTrig or
Wintrigue or something like that.

-Alex

Re: [VOTE] Release Apache FreeMarker 2.3.24-rc01 (incubating)

[Alex Harui]

On 1/21/16, 11:52 PM, "Daniel Dekany"  wrote:

>Friday, January 22, 2016, 1:08:36 AM, Justin Mclean wrote:
>
>> If may be (but unlikely IMO) that this applies [1]. Best to ask on
>> legal discuss to confirm.
>
>I have red the related ASF documents back then, and I don't understand
>how can this lead to any legal problem since:
>- These binaries were contributed directly to the project
>- Their origin is clarified in the NOTICE file.
>- As a side note, obviously, there can be images and such in a source
>  release, which are also binaries.
>
>But yes, I will ask this on legal if it isn't settled here pretty
>soon.

IMO, this isn't a legal issue as much as a policy, convention and
usability issue.  AIUI, ASF releases should be the "raw" sources required
to implement some functionality so that
1) it is easy to examine and determine it is safe to use (no viruses or
trojans, licensing is as expected)
2) it is easy to modify files in the release and submit patches in order
to invite more community involvement and recruit new committers

A jar, even one that just compresses text files, doesn't quite fulfill
those goals, so I would take the time to alter the packaging scripts so
that the source package has a folder of the text files that went into the
jar but no jar file itself, and the build script that creates the
convenience binary packages those text files into a jar.  In fact, I did
just that when working on a recent code donation to a project that
originally contained zip files.

And that's why some binaries like GIF, PNG, JPG files are ok since they
are also the "raw" sources that invite folks to contribute patches and are
considered safe since the aren't known to contain executable code.

A nit: AIUI, the NOTICE file isn't so much about origin of individual
artifacts as it is about required notices like copyrights that have been
swapped out from their original homes in various files, and other
requirements from the licenses for bundled dependencies.  Since the jar
was apparently part of a larger software donation, the standard "Initial
Developer" line would cover all of the code in that donation and not
address the jar specifically.  Of course, this is all moot once you've
replaced the jar in the source package with the text files it contains.

Of course, I could be wrong...
-Alex


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

Re: [DISCUSS] Apache Joshua Incubator Proposal - Machine Translation Toolkit

[Alex Harui]

External is good news.  I'm not sure how much leeway there is in the
following quote from [1], but what percentage of your users are currently
using an all-ASF-compatible set of projects?
 
The question to ask yourself in this situation is:
* "Will the majority of users want to use my
   product without adding the optional components?"

-Alex

[1] http://www.apache.org/legal/resolved.html


On 1/20/16, 7:17 AM, "Matt Post"  wrote:

>The dependencies can be split into two kinds: ones required for building
>new models, and ones needed by the decoder to translate new sentences
>with a pre-built model (i.e., black-box translation with the language
>packs).
>
>1. For building new models, you need a way to align the words between
>sentences in parallel text. Both the aligners used by Joshua (GIZA++ and
>the Berkeley aligner) are GPL of some form. These can be implemented as
>external dependencies, or can be replaced with another aligner, like
>fast_align (https://github.com/clab/fast_align), which is
>Apache-licensed. There are many other options, in fact. So this should
>not be a worry.
>
>2. For doing black-box translation, one needs to represent the language
>model, which is very large. The best tool for this is KenLM
>(github.com/kpu/kenlm), which is LGPL 2.1. There is also BerkeleyLM,
>which is just as good for practical purposes and is Apache-licensed.
>KenLM is C++ and is loaded via the JNI, whereas BerkeleyLM is written in
>Java. I have moved to including BerkeleyLM in language packs, because I
>can then include the Joshua-runtime, and people can translate without
>even having to compile anything.
>
>So in short, there are no hard dependencies on unfavorably-licensed
>external projects.
>
>matt
>
>
>
>
>> On Jan 20, 2016, at 10:08 AM, Mattmann, Chris A (3980)
>> wrote:
>> 
>> Hey Hen,
>> 
>> Matt Post who I believe is monitoring this list and who has
>> been one of the key Joshua developers and I have discussed this
>> and we believe that potentially GPL/LGPL dependencies can:
>> 
>> 1. be replaced with category-A or category-B alternatives. Matt
>> mentioned one already to me which has slipped my mind.
>> 2. be made in such a way that they are external tools and the
>> bindings exist in Joshua to call those external tools (aka runtime
>> deps akin to depending on a C compiler, etc.)
>> 
>> Cheers,
>> Chris
>> 
>> ++
>> Chris Mattmann, Ph.D.
>> Chief Architect
>> Instrument Software and Science Data Systems Section (398)
>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>> Office: 168-519, Mailstop: 168-527
>> Email: chris.a.mattm...@nasa.gov
>> WWW:  http://sunset.usc.edu/~mattmann/
>> ++
>> Adjunct Associate Professor, Computer Science Department
>> University of Southern California, Los Angeles, CA 90089 USA
>> ++
>> 
>> 
>> 
>> 
>> 
>> -Original Message-
>> From: Henri Yandell 
>> Reply-To: "general@incubator.apache.org" 
>> Date: Tuesday, January 19, 2016 at 7:38 PM
>> To: "general@incubator.apache.org" 
>> Subject: Re: [DISCUSS] Apache Joshua Incubator Proposal - Machine
>> Translation Toolkit
>> 
>>> License-wise, any expectation of problems from the GPL and LGPL
>>> dependencies?
>>> 
>>> On Mon, Jan 18, 2016 at 9:58 PM, Mattmann, Chris A (3980) <
>>> chris.a.mattm...@jpl.nasa.gov> wrote:
>>> 
 Great Hen, we’d love to have you on board as a mentor! Please
 add yourself to the proposal on the wiki.
 
 Anyone else have interest in Machine Translation? Any OpenNLP folks,
 Hadoop folks, Tika, or Lucene folks? CC’ing the dev lists for
visibility
 please feel free to reply to general@i.a.o.
 
 I’ll leave the DISCUSS thread open for a few more days.
 
 Cheers,
 Chris
 
 ++
 Chris Mattmann, Ph.D.
 Chief Architect
 Instrument Software and Science Data Systems Section (398)
 NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
 Office: 168-519, Mailstop: 168-527
 Email: chris.a.mattm...@nasa.gov
 WWW:  http://sunset.usc.edu/~mattmann/
 ++
 Adjunct Associate Professor, Computer Science Department
 University of Southern California, Los Angeles, CA 90089 USA
 ++
 
 
 
 
 
 -Original Message-
 From: Henri Yandell 
 Reply-To: "general@incubator.apache.org"

 Date: Monday, January 18, 2016 at 7:57 PM
 To: jpluser ,
 

Re: Post mortem request for the handling of the Corinthia podling (was Re: FYI, I have subscribed to this list and to your private list)

[Alex Harui]

Probably too late, but some comments in-line.

On 1/15/16, 6:55 AM, "Peter Kelly"  wrote:
>
>However, one important factor which really killed things for us was the
>inability to use Qt.
>
>The desktop app was the main priority, however.
>
>To do a cross-platform desktop app, and to do it properly, it’s necessary
>to use a suitable UI toolkit which provides all the necessary
>functionality. As it turns out, the only viable candidates we were able
>to identify (Qt and GTK, with wxWidgets and fltk as less desirable
>fallback options) are all licensed under the LGPL. For most open source
>projects, this would be no problem - LGPL and ASLv2 are compatible with
>each other, in the sense that you can distribute software combining the
>code from the two licenses without problems; doing so just means that
>users of the software are bounds by the terms of both licenses.

It appears that Qt is no longer under LGPL and now just GPL? [1]  That
could limit the number of commercial users which is one reason why the ASF
has the CategoryX restriction.

>
>We very quickly settled on Qt as the toolkit of choice, on technical
>grounds. It seemed to us to be the most mature, feature-rich, and best
>designed library of the available choices, and some of us had already
>used it on other projects in the past. However, even if we had chosen one
>of the other libraries, the outcome would have been the same.

FWIW, Apache Flex and Apache Cordova can create cross-platform desktop
apps.  I think these are pretty mature projects.

>
>The ticking time bomb, as we discovered several months in, was the
>disconcertingly-named “Category X list”, described at
>http://www.apache.org/legal/resolved.html (under "Which licenses may not
>be included within apache products?”). This lists several licenses,
>including the LGPL, regarding which it states:
>
>"The LGPL is ineligible primarily due to the restrictions it places on
>larger works, violating the third license criterion. Therefore,
>LGPL-licensed works must not be included in Apache products.”
>
>When I (and some others) on the project read this, we did not see it as a
>problem. We were not distributing any LGPL-licensed code, but merely
>writing an application conforming to an API whose only currently-existing
>implementation is licensed under the LGPL (there are commercially-licened
>versions of the library as well, for those who want them).
>
>It all hinges on the phrase “included within” - I do not consider a
>third-party library, that is not distributed as part of an ASF release,
>to fit within that definition, according to my understanding of the
>English language (and I’m a native speaker). However, the relevant ASF
>policy makers have a different interpretation. It’s extremely subtle -
>basically the policy equivalent of an OpenSSL bug.

I don't know how Qt is packaged, but AIUI, the CategoryX restriction does
not apply to build tools and runtimes.  But whether you package it or
download it, if using it places restrictions on your customers than that's
a problem.
 
>
>For what we were trying to achieve, and the ways in which we were going
>about it, it turned out that ASF was not an appropriate choice of venue.
>There were several other things I felt were unreasonable - the inability
>to accept pull requests from anyone without first asking them to sign a
>CLA, the prohibition against binary distributions of support libraries
>for convenience of building, and the constant deference to the
>pseudo-religious “Apache Way” (which I still haven’t seen a coherent
>explanation of, despite the very long “What is the Apache Way?” thread on
>this list just a few months ago).

IMO, the ASF way of open source is a pseudo-religion.  So is the FSF/GNU
way.  The ASF says you must not scare away people who want to make money
by selling software.  The FSF says you cannot make money selling software.
 When you become an ASF project, then potential customers who want to make
money don't have to dig through your licensing to figure out if they can.
If you don't need that advantage, then yes, the ASF may not be a good fit.
 But it sounds like you are choosing to not want for-profit customers.  I
hope that's really what your community wants.

-Alex

[1] 
http://www.qt.io/qt-news/qt-open-source-licensing-changed-product-structure
-updated-strengthen-community-extend-adoption/

Re: Request for advice on code donation

[Alex Harui]

AIUI, copyrights never get re-assigned.  There is a collective copyright
for the collective work, but each line of code is still owned by some
entity/person that contributed it.

Copyright law apparently only allows the copyright owner or a person they
authorize to muck with copyright statements in headers, and since Apache
prefers that copyright notices go in the NOTICE file, it is a good thing
if every copyright owner is a committer so they can muck with the header
themselves.  But for sure, in one case, I have gotten permission from the
copyright holder to make the changes since they did not want to be a
committer.

The SGA grants permission for the code to be licensed under ALv2, so is
not fully required when the donated code base is already under ALv2.  In
such a case it sort of provides a paper trail that the code base
participants/community are ok with moving the "home" of the code to ASF
repos.  There is a recent thread on that.

So, IMO, the only gotchas in this case are if the headers have this
individual's copyright in it and we want it moved to NOTICE.  And if this
individual or his employer somehow tries to argue that they did not intend
to allow the contributions to be under ALv2 in the first place, or doesn't
want the ASF to be the new home for this code, which seems unlikely.

HTH,
-Alex

On 1/15/16, 5:21 AM, "Josh Elser" <josh.el...@gmail.com> wrote:

>Thanks, Greg.
>
>I thought the whole point of this part of the process was that we could
>assign the copyright from the original contributors to the ASF - the thing
>that licenses wouldn't be covering. That's great that this isn't a
>sticking
>point, I'm just honestly a bit confused.
>On Jan 15, 2016 12:15 AM, "Greg Stein" <gst...@gmail.com> wrote:
>
>> Exactly ... just bring the work into the ASF under its ALv2 license. You
>> don't need permission from (all) contributors to use the software under
>> that license. That's *why* we have licenses!
>>
>> Rewriting the headers is a little trickier, though. I'd suggest a two
>>step
>> process:
>>
>> 1) bring in the code, but don't (yet) touch any of the license/copyright
>> headers in there
>> 2) ask legal-discuss what to do with the headers
>>
>> Cheers,
>> -g
>>
>> ps. I'd think: for any file jbnote touched, keep/push the existing
>>header
>> down and prepend the standard ASF header; all other untouched files,
>> replace any header with ours.
>>
>>
>> On Thu, Jan 14, 2016 at 1:37 PM, Alex Harui <aha...@adobe.com> wrote:
>>
>> > Looks like the repo was placed under the Apache License long before
>>this
>> > individual contributed.  So, IMO, if you are convinced this individual
>> and
>> > his employer knew his contributions were placed under the Apache
>>License
>> > you could gamble and accept his contributions.  If you get an
>>objection
>> > later, you can delete and re-implement the contributions.
>> >
>> > My 2 cents,
>> > -Alex
>> >
>> > On 1/14/16, 10:45 AM, "Josh Elser" <els...@apache.org> wrote:
>> >
>> > >Hi all,
>> > >
>> > >(with my podling member hat on)
>> > >
>> > >We have a bit of a problem over in Slider with a code donation. Full
>> > >details can be found at
>> https://issues.apache.org/jira/browse/SLIDER-977
>> > >
>> > >In short, an app-package (a modular chunk of code that Slider runs on
>> > >Apache Hadoop's YARN ) for Kafka was offered to be included in
>>Slider.
>> > >Slider would love to accept it. We've gotten IP clearance from all
>>but
>> > >one party who contributed to it.
>> > >
>> > >To the best of my knowledge, this individual contributed code to this
>> > >Kafka app-package and his company could also lay claim to his
>> > >contribution. He already had an ICLA on file, but no CCLA from his
>> > >company.
>> > >
>> > >Two months later, multiple pings on JIRA and even a personal email,
>>this
>> > >person seems to be AWOL. Given my understanding of the rules, we
>>can't
>> > >proceed because we don't have the ability to prove all potential
>> > >previous ownership of this codebase has been granted to the ASF.
>> > >
>> > >Any advice on how we could try to move this forward?
>> > >
>> > >Thanks.
>> > >
>> > >- Josh
>> > >
>> > >-
>> > >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: Milagro trademark

[Alex Harui]

I would recommend asking this on trademarks@a.o.

I would also recommend two separate transactions.  IIRC, the SGA language
is not the right language for the trademark assignment.  Some other
template should be used.  Also, I believe it is in the best interests of
the Milagro trademark owner to make sure the podling is going to graduate
before assigning the trademark, and the software needs to come in long
before graduation.

-Alex

On 1/15/16, 5:58 PM, "toki"  wrote:

>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>
>
>On 15/01/2016 23:24, Nick Kew wrote:
>
>> Would it make sense to append the trademark assignment to a forthcomin
>g software grant?
>
>My recommendation would be to do the trademark assignment as one grant,
>and the software assignment as a second grant.
>
>My rational is that the trademark assignment gets filed with USPTO.
>Maek things simple for the USPTO, and only list the items that they
>(USPTO) maintain in their trademark database.
>
>I am not a lawyer.
>It should be obvious that this is not legal advice.
>
>jonathon
>-BEGIN PGP SIGNATURE-
>Version: GnuPG v2.0.22 (GNU/Linux)
>
>iQIcBAEBAgAGBQJWmaPEAAoJEKG7hs8nSMR7u9gP/23YHikoQUbrUTsIUd2Q/nx/
>d974osVhaNe6L6MpJkExHXwn0jrawb9wzYFx+qvBL65LGPuHxI+EknEs0m2zsTxg
>Ymrq34zTZcH7oiTKPcoDp63u+8a1lbTPgg7SmjrRvsSYSb+aiKYgN8fd3mc8VhEm
>L4cZNLyZThxK5F5HSDa+Js6yl3lFTPI+3md0r/7N6xWpmfycUhvwuPlpv4agjMmf
>ZJ0jjWq1zb2Ev0EYGhjqEFSwbpw8UuWKTtPoEg7mCu4eY25MY9tOB8RPyhR0iS3w
>T1+ryYngU5SkZj7NdFG04ePURUzy/UHYwnRLver4fRqrGXSJ29TCowfl9Kxf/2EO
>ElNzBrKnKTQDcIxDTl4znHxd1VWqc8Vlx/8MQ94avv2NuLvI5Mrjw/INNSGqYCFJ
>CUS7XxSCg4QM+RWq+bXxW+efpb3KwrJ/x6/DDYuaS0u70DZK6HVCUtP2yywFMC5H
>UMbJdKjBPTfl40WcGNuxPmyaBAN0GRc4HCplpQsSCGsmYkJR/lT2g3zi2cjaGeFE
>Pf9kY359FzOyoZhkOrJP3SooPsRdfeFs+Pms6T+hkKshEzC37oOZbmYedQMSw/B5
>ZfQiDyyM4QYsD68xooYXDeD/Xk5mp9GbxbmWleQJD7SCwHKuMDBLRsZuHae+d0fM
>gBZGwbdNkEsqi83ofOGa
>=kPKa
>-END PGP SIGNATURE-
>
>-
>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: Request for advice on code donation

[Alex Harui]

Looks like the repo was placed under the Apache License long before this
individual contributed.  So, IMO, if you are convinced this individual and
his employer knew his contributions were placed under the Apache License
you could gamble and accept his contributions.  If you get an objection
later, you can delete and re-implement the contributions.

My 2 cents,
-Alex

On 1/14/16, 10:45 AM, "Josh Elser"  wrote:

>Hi all,
>
>(with my podling member hat on)
>
>We have a bit of a problem over in Slider with a code donation. Full
>details can be found at https://issues.apache.org/jira/browse/SLIDER-977
>
>In short, an app-package (a modular chunk of code that Slider runs on
>Apache Hadoop's YARN ) for Kafka was offered to be included in Slider.
>Slider would love to accept it. We've gotten IP clearance from all but
>one party who contributed to it.
>
>To the best of my knowledge, this individual contributed code to this
>Kafka app-package and his company could also lay claim to his
>contribution. He already had an ICLA on file, but no CCLA from his
>company.
>
>Two months later, multiple pings on JIRA and even a personal email, this
>person seems to be AWOL. Given my understanding of the rules, we can't
>proceed because we don't have the ability to prove all potential
>previous ownership of this codebase has been granted to the ASF.
>
>Any advice on how we could try to move this forward?
>
>Thanks.
>
>- Josh
>
>-
>To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>For additional commands, e-mail: general-h...@incubator.apache.org
>

Re: File headers for third party utility code

[Alex Harui]

On 1/4/16, 3:02 PM, "shaposh...@gmail.com on behalf of Roman Shaposhnik"
 wrote:
>
>> 2) In the cases that we've made non-trivial changes to the source, we
>> should additionally add the ASF copyright notice at the top of the file,
>> and amend the original copyright statement with the words "Some
>>portions"
>> as we've done for example in cache.cc[7].
>
>I don't think you need to do that, but you do need an ASF license header.
>
>I don't think ASF encourages "Portions Copyright ... ASF" statements
>on individual files.
>
>> 3) In all files (regardless of whether we've made changes), we should
>>add
>> the Apache license header above any existing license headers, while
>> maintaining the existing one.
>
>Correct and it should also solve #2

Doesn't #3 from http://www.apache.org/legal/src-headers.html#3party
contradict this?


0. The term "third-party work" refers to a work not submitted directly to
the ASF by the copyright owner or owner's agent.
1. Do not modify or remove any copyright notices or licenses within
third-party works.
2. Do ensure that every third-party work includes its associated license,
even if that requires adding a copy of the license from the third-party
download site into the distribution.
3. Do not add the standard Apache License header to the top of third-party
source files.
4. Minor modifications/additions to third-party source files should
typically be licensed under the same terms as the rest of the rest of the
third-party source for convenience.
5. Major modifications/additions to third-party should be dealt with on a
case-by-case basis by the PMC.

Thanks,

-Alex


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

Re: File headers for third party utility code

[Alex Harui]

On 1/4/16, 3:41 PM, "Todd Lipcon"  wrote:
>
>Right, I guess I'm not sure what qualifies minor vs major. In some cases,
>we've done trivial edits like putting things in a "kudu" namespace or
>removing some portability code. In other cases, we've made more
>substantial
>alterations to fit our codebase (eg
>https://github.com/cloudera/kudu/commit/0ee3218b9edcd7e5e9d450307bc22d0ead
>fb53be
>) but still kept the overall API/design. At what point do we go ahead and
>add the Apache License header?

The way I think of it is that every line of code has a home.  The home for
3rd-party code is not in the ASF repo or the source package you downloaded
from Apache, so we want to warn folks that more care is needed when
mucking in a particular file/folder.  When there are lines of code whose
home is the ASF mixed with code whose home is not at the ASF, IMO, that
still needs to be pointed out in LICENSE until the amount of non-ASF code
is reduced to the point where mucking with that code isn't going to matter
to the home community.

The uber ASF license in the LICENSE file grants permission to all lines
whose home is the ASF regardless of what the header looks like.  I would
put annotations in the source code about what code in a mixed file does
have a home at the ASF if I thought it would be helpful.  I would not add
all of that information to the LICENSE.

An attorney for my employer said that these headers are just sign posts
provided as a convenience to the consumer.  The code is owned and has a
home regardless of header.  The header and any other annotations in a
source file are just to save the consumer time in figuring out who owns
what and where the "canonical copy" lives.  The LICENSE file is IMO, also
a sign post.

So, when grabbing a release for use, LICENSE ought to give me a quick idea
of the ingredients (which is why I prefer pointers to 3rd party licenses
vs whole copies of licenses).  Then if I feel the need to go change some
source code, the headers and other annotations in that file give me a
warning that the contents may not all have a home at the ASF.  After that
it is a judgement call as to whether it is worth making the file more
bloated at the line-level to define the boundaries of the mixing or make
it an exercise of the consumer to figure it out.  But at least they've
been warned.

My 2 cents,
-Alex


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

Re: apache-website-template git commit: Add LICENSE and NOTICE files

[Alex Harui]

Hi Roberta,

Can you ask this on your other thread and include more information about
whether this is a file that has been donated to the ASF or is third-party?

On 12/3/15, 8:40 AM, "Roberta Marton"  wrote:

>I have a question regarding the NOTICE and LICENSE file as it pertains to
>an
>MIT or BSD license.
>If I, for example, have a source file with a copyright notice followed by
>MIT license text, can't I just put the copyright notice in the LICENSE
>file
>with a pointer to the MIT license text (or actually include the text)?
>Do I need to add anything in the NOTICE file?  In
>http://www.apache.org/legal/src-headers.html#header-existingcopyright
>seems
>to imply that the copyright should be added to the NOTICE file.
>
>When I look at other projects LICENSE and NOTICE files; everyone seems to
>do
>it differently, even with the same copyright details.
>
>Regards,
>Roberta
>
>-Original Message-
>From: Marvin Humphrey [mailto:mar...@rectangular.com]
>Sent: Thursday, December 3, 2015 6:16 AM
>To: general@incubator.apache.org
>Cc: lrese...@apache.org
>Subject: Re: apache-website-template git commit: Add LICENSE and NOTICE
>files
>
>On Thu, Dec 3, 2015 at 5:17 AM, sebb  wrote:
>> PING
>
>I'd also like to see this addressed.  Licensing documentation for
>Incubator
>sample code should adhere to best practices.
>
>> On 28 November 2015 at 22:59, sebb  wrote:
>>> On 28 November 2015 at 16:26,   wrote:
>
 +The following components included on this website are distributed
under
 MIT license :
 +
 +- Jekyll
 +- Jekyll Bootstrap
 +- Bootstrap
 +- jQuery
 +
 +The MIT License (MIT):
 +
 +Permission is hereby granted, free of charge, to any person
 +obtaining a copy of this software and associated documentation
 +files (the "Software"), to deal in the Software without
 +restriction, including without limitation the rights to use, copy,
 +modify, merge, publish, distribute, sublicense, and/or sell copies
 +of the Software, and to permit persons to whom the Software is
 furnished to do so, subject to the following conditions:
 +
 +The above copyright notice and this permission notice shall be
 +included in all copies or substantial portions of the Software.
 +
 +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
 +EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
 +MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
 +NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
 +BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
 +ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
 +CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
 SOFTWARE.
 +
 +
>>>
>>> The LICENSE looks OK.
>
>+1, it's OK, though I'd make one suggestion.
>
>The addition of the MIT license text minus the copyright notice (the
>intent
>is clearly to generalize so that it applies to 4 different dependencies)
>is
>a bit irregular.  The copyright notice is an integral part of the MIT
>license -- it's actually a license template and is only completed when the
>copyright notice has the owner filled in.
>
>http://opensource.org/licenses/MIT
>
>To addresss the irregularity, I'd suggest either prepending the template
>line `Copyright (c)  ` -- or simply omitting the
>text of the MIT license, instead including filepath pointers to where the
>deps can be found in the distro.
>
 http://git-wip-us.apache.org/repos/asf/apache-website-template/blob/
 9e881e24/NOTICE
 
 --
 diff --git a/NOTICE b/NOTICE
 new file mode 100644
 index 000..a4fed15
 --- /dev/null
 +++ b/NOTICE
 @@ -0,0 +1,11 @@
>>>
>>> The ASF Copright header is missing
>>>
>>> See http://www.apache.org/legal/src-headers.html#notice
>>>
>
>+1
>
>Just the copyright notice, i.e. this:
>
>  Apache [PRODUCT_NAME]
>  Copyright [] The Apache Software Foundation
>
>Actually, what should "[PRODUCT_NAME]" be in this case?
>
 +This product includes software developed at The Apache Software
 +Foundation (http://www.apache.org/).
 +
>>>
>>> That paragraph is OK
>>>
 +This product uses Jekyll software (http://jekyllrb.com/) Copyright
 +(c) 2008-2015 Tom Preston-Werner
 +
 +This product includes Boostrap software (http://getbootstrap.com/)
 +Copyright (c) 2011-2015 Twitter, Inc
 +
 +This product includes jQuery software (http://jquery.com/)
 +Copyright jQuery Foundation and other contributors,
 +https://jquery.org/
>>>
>>> AFAICT these 3 attributions are NOT necessary for MIT licensed code,
>>> see
>>>
>>> http://www.apache.org/dev/licensing-howto.html#permissive-deps
>
>+1, those should definitely be removed.
>
>Marvin Humphrey
>

Re: [VOTE] Accept Metron into Apache Incubator

[Alex Harui]

Are any of the GitHub contributors to OpenSoc still at Cisco?  That might
help.

-Alex

On 12/3/15, 10:18 AM, "Owen O'Malley"  wrote:

>On Thu, Dec 3, 2015 at 10:04 AM, Debo Dutta (dedutta) 
>wrote:
>
>> Would like to know who in Cisco was asked actually. I am from Cisco and
>> can help.
>
>
>Debo,
>   If you can help get an SGA signed that would be great. I don't have any
>contacts in Cisco, so I didn't have anywhere to ask.
>
>.. Owen


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

Re: Adopting non-ASF AL projects (was Re: [DISCUSS] Kudu incubator proposal)

[Alex Harui]

OK, next draft below.  Some comments first:

On 11/29/15, 6:25 AM, "Ted Dunning" <ted.dunn...@gmail.com> wrote:

>Alex,
>
>Here are a couple of comments, mostly kind of independent:
>
>a) this is a good start. Very sound directionally.
>
>b) are you just re-inventing the ICLA?

In my mind, the ICLA represents your formal pledge to be part of an ASF
community and continue to contribute.  It has to be recorded by the
secretary and reads like legal-ese   I am trying for a hopefully quicker
and easier informal adoption. I really don't expect the past contributors
to join this new family (i.e. work on this code at the ASF).  The ones who
want to truly join will have to sign an ICLA and be voted in as a
committer.

>
>c) is there a need to mention disbanding the original community?  Could
>that be framed more positively as "We would love to have you come be part
>of the Apache Flex if you are interested in making further contributions".

Ok, took out the disbanded part in #4 and added the above sentence to #5.

Thanks,
-Alex

 Draft 2 -

[Friendly intro]

A major contributor of XXX has indicated a desire to have the Apache
Software Foundation's Apache Flex project be the new home of future
development of the XXX code.  Normally, this is called a "donation" and
requires a bunch of legal paperwork, but because this code base is already
licensed under Apache License 2.0, your contributions may be donated to
the ASF by replying to this email to affirm that:

1) You agree that the code you wrote is licensed under Apache License 2.0
2) You understand that under the Apache License 2.0, you retain the
copyright of the code you wrote.  You are only granting  a license to not
only the Apache Software Foundation (the ASF), but to anyone else as well.
3) You understand that if we cannot get enough affirmative emails from
enough contributors to this code base, the "donation" may be abandoned.
4) You understand that if this "donation" is completed, future downloads
should come from, and changes applied to, the code base in an
ASF-controlled code management and distribution system, and discussion
about the code base should happen on Apache Flex mailing lists.
5) You understand that if you are not already an Apache Flex Committer and
wish to have continued involvement in changes to this code base, we can
discuss separately the steps to become a Committer.  We would love to have
you come be part of Apache Flex if you are interested in making further
contributions.

Thanks,
Alex Harui, for the
Apache Flex PMC.
- End Draft 2 -

Re: Adopting non-ASF AL projects (was Re: [DISCUSS] Kudu incubator proposal)

[Alex Harui]

On 11/28/15, 6:58 PM, "Marvin Humphrey" <mar...@rectangular.com> wrote:

>On Fri, Nov 27, 2015 at 11:16 AM, Alex Harui <aha...@adobe.com> wrote:
>
>> On 11/27/15, 7:34 AM, "Marvin Humphrey" <mar...@rectangular.com> wrote:
>>
>>>Having a TLP take over a codebase *without* the explicit consent of all
>contributors isn't a common case, and there are both legal and social
>risks.
>I don't think we need a general solution for that problem, other than
>"Don't
>do this without consulting the Board first."

I can live having to bother the Board for each code base, but just so you
know, I may not be done after these two.  The fact is that there are lots
of little Flex-related libraries getting dusty on the shelves of
googlecode/github.  It seems like Flex is going to have to go through an
almost complete blood transfusion: we entered with a very large list of
initial committers and I believe that I am the only one on that list still
committing on a regular basis, and one other person shows up on occasion.
All other activity is coming from new blood.  These old Flex libraries are
in a similar bind, and I believe that bringing them to the ASF allows
invites new blood to work on it.

IMO, I would much rather be taught what the board is going to be worrying
about and maybe provide notification instead of asking for permission, but
if you really need me to keep asking, I will.

Anyway, my takeaway so far is that folks have slightly questions for the
past contributors of these two code bases.  I've picked up on two of them:
1) Did you really intend to license your work as AL, and 2) Are you ok
with the Apache Flex being the community for your code?

So, below is a draft of what I would send to them (for AS3Commons, I would
have the PMC vote to accept the donation before sending this out to the
contributors).  I still want to get a better sense for what our options
are if we don't get 100% positive responses, and whether IP Clearance is
required.  IMO, even if we did get every line under SGA/ICLA, and IP
clearance passes there is still a chance that something is not right in
the code base, so I think if we can get the major contributors to respond,
we can look at what lines haven't been permitted and decide whether those
lines can be at any more risk than the lines that have been signed for,
and what the impact would be if we had to kick those lines out later.  And
the lines of code we do decide to take, whether signed for or not, we will
put through IP Clearance.

Thoughts?
-Alex

- Draft ---

[Friendly intro]

A major contributor of XXX has indicated a desire to have the Apache
Software Foundation's Apache Flex project be the new home of future
development of the XXX code.  Normally, this is called a "donation" and
requires a bunch of legal paperwork, but because this code base is already
licensed under Apache License 2.0, your contributions may be donated to
the ASF by replying to this email to affirm that:

1) You agree that the code you wrote is licensed under Apache License 2.0
2) You understand that under the Apache License 2.0, you retain the
copyright of the code you wrote.  You are only granting  a license to not
only the Apache Software Foundation (the ASF), but to anyone else as well.
3) You understand that if we cannot get enough affirmative emails from
enough contributors to this code base, the "donation" may be abandoned.
4) You understand that if this "donation" is completed, it means that
whatever group of developers that existed around this code base should be
disbanded.  We would want you to encourage all future downloads to come
from, and changes applied to, the code base in an ASF-controlled code
management and distribution system once the transfer is complete.
5) You understand that if you are not already an Apache Flex Committer and
wish to have continued involvement in changes to this code base, we can
discuss separately the steps to become a Committer.

Thanks,
Alex Harui, for the
Apache Flex PMC.
 
- End Draft -


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