Re: License for text content

[Shane Curcuru]

(Moving general@incubator and dev@community to BCC since this is really 
a legal question about ASF licensing)


tison wrote on 5/1/24 11:25 PM:

Hi,

IIUC, the Apache License 2.0 is mainly to license code and related stuff 
that constructs the final software.


However, projects may also create text content like documents. Is it 
appropriate to use Apache License 2.0 for them (since quite a few terms 
may not be applicable)? Or what licenses shall we use?


The ASF uses the Apache-2.0 license for our projects' own content that 
is put into any releases, immaterial of type of content:


https://apache.org/legal/src-headers.html#faq-docs

Using a single license reduces complexity, and makes it simpler for 
users to understand the issues around re-using ASF products.


--
- Shane
  Member
  The Apache Software Foundation


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

Trademarks and incubation (was: [DISCUSS] Graduate Apache AGE Incubating as a Top Level Project)

[Shane Curcuru]

Question: where did the incubation process fail in this case?  How can 
we prevent something like this from happening again?


On 2021/12/20 22:50:13 Eya Badal Abdisho wrote:

Hello Justin,

Thank you for your feedback. Please find more information following:


...snip...> - There are some minor trademark issues on the Bitnine site 
e.g [2] → All

will be fixed in a day.


One issue today is that both the Bitnine site advertises several 
software products with names that start with "AGE...", including a 
graph-based tool.  The other issue is that AgeDB is a company using 
similar names and branding as Apache Age.


These issues clearly weren't fixed, nor do they appear to really have 
been seriously addressed in the past two years.


  https://bitnine.net/
  https://agedb.io/

...snip...

- I notice one person who replied to this thread had a agedb.io email
address - what is it relationship with the project?

Agedb is a US startup (incorporated in California May this year) and is
affiliated with Bitnine Global, who contributed the original AGE source
codes to the Apache Software Foundation. The purpose of Agedb is not yet
clearly defined but it is expected to be to provide graph database
solutions and related services.


I definitely appreciate our Incubator mentors, who do an incredible job 
in their volunteer time.  Helping build communities is hard work, and is 
to be celebrated.


How can we improve documentation, education, or training so that the 
below sentence would leap out at any mentor as a "You can't do that!"


"purpose of Agedb is ... provide graph database solutions and related 
services"


Given we were trying to incubate Apache AGE as a graph database, the 
above sentence is literally describing trademark infringement!  How can 
we make it easier to ensure podlings and their donating organizations 
actually take trademark transfer seriously?


--
- Shane
  Member
  The Apache Software Foundation

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

Re: New project invitations

[Shane Curcuru]

Craig Russell wrote on 3/21/24 12:20 AM:
...snip...

We really can do better, but we have to have better documentation.


Some folks have started working on improving the actual emails or links 
we use for onboarding at various steps of the process.  So if we're 
updating this step, folks might want to look at some of the other steps 
too, which are listed here:


https://cwiki.apache.org/confluence/display/COMDEV/Proposal%3A+Improving+Onboarding+Experiences

A separate question for committer invitation process is: each PMC/PPMC 
is responsible for some of the steps themselves.  How can we make 
simple/easy enough tools so that the experience for a new committer on 
any project or podling is at least similar?  It's pretty clear some 
projects have different ways of doing the welcoming process, some 
better, some not as good.



--
- Shane
  Member
  The Apache Software Foundation


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

Re: covid-19 project initiative

[Shane Curcuru]

Maziar Siami wrote on 2020-3-22 3:03PM EDT:
> Hi All,
> I am not sure if this email list is the relevant one. But hope it is close 
> enough.
> I believe Apache foundation could launch projects to leverage volunteers and 
> technology in addressing  covid-19 outbreak.There can be different innovative 
> ideas,  e.g., A mobile apps to help with tracking the places a covid-19 
> positive patient visited, to warn others if they were in the vicinity. Etc.

The ASF is about supporting our project communities.  So it's up to
projects or individual committers to start doing the work.

One note: as geeks, we often want to build a new tool to do X.  Running
a local mutual aid site in my hometown, I did just that to coordinate
different volunteer groups.  The technology isn't the hard problem - the
hard problem is (always) people.

Getting volunteers to do the organizing, leafleting, actually checking
on neighbors or actually sewing hospital-accepted masks is hard.  So
anytime you see a group of organized volunteers, what they need is help,
not some new tool.  The hardest thing is figuring out how to help
improve their *existing* tools and processes.

For example, I cringe every time I see a new mutual aid group spring up
based on a set of complex Google Docs, because the URLs are impossible
to remember (for trading with neighbors), and Google Docs performance
has nosedived for me lately.  But that's not important: what's important
is the core volunteers actually doing the local work are comfortable
with Google Docs.

If you do have specific ideas, please do bring them up, to see if you
can get some more folks interested!

-- 

- Shane
  Committer - The Apache Software Foundation
  Organizer - https://mutualaidarlington.org/tech?asf

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

How to subscribe (was: Incubator PMC members not subscribed to private list)

[Shane Curcuru]

Reminder: this Whimsy tool for committers can subscribe/unsubscribe you
from almost any list that you're allowed to subscribe to (i.e. including
PPMC lists or private@ if you have permissions for them)

  https://whimsy.apache.org/committers/subscribe

Justin Mclean wrote on 2020-1-9 7:47PM EST:
> Hi,
> 
> A number of IPMC members are not subscribed to teh Incubator private list. 
> This also includes some current mentors. I’ve just sent out a friendly email 
> to those not subscribed asking them to subscribe.

If Justin's still volunteering for this (thanks!), I suggest sending one
last reminder to people not subscribed (with the above link), wait a
week, and then remove those still not subscribed from the IPMC.  If they
aren't on private@, they're not actively providing oversight.

-- 

- Shane
  IPMC & Member
  The Apache Software Foundation

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

Re: [MENTORS] Board report submitted, a few missing mentor sign-offs

[Shane Curcuru]

Related question: the incubator report says "The board has motions for
the following: Apache Rya, Apache SINGA" but I don't see the vote for
SINGA having completed or any note to the board to add a resolution.

Given the late timing, I'd personally suggest adding the SINGA
resolution for next month.

Justin Mclean wrote on 2019-9-11 5:40PM EDT:
> Hi,
>
> Several mentors have not signed off their reports, and currently two
projects have no sign-offs.They are:
> SDAP
> Spot
Yes, please, it's important for directors to see mentor signoffs on
reports.  That's a key organizational need and a big part of what
mentors should be (I'd hope) be doing.  Thanks to all the mentors who do
signoff and provide comments on their podlings' health.

> The board report has been submitted so you’ll need to sign it off
here. [1]
>
> Thanks,
> Justin
>
> 1.https://whimsy.apache.org/board/agenda/2019-09-18/

-- 

- Shane
  Director & Member
  The Apache Software Foundation

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

Re: Board@ subscriptions

[Shane Curcuru]

To make Dave's answer specific to your question: Yes, as chair of Apache
Drat (a TLP) you are expected to follow board@ "to ensure that [you] are
aware of Foundation level issues that may affect their project":

  https://www.apache.org/dev/pmc.html#chair

Podling or IPMC folk do *not* need to subscribe (and unless they're
Members, they can't subscribe to board@).

Personally, I expect TLP Chairs to ensure quarterly reports are
submitted and that their project replies to all direct board questions
(typically the "Board feedback on..." emails) in a timely manner.
Reading *all* of the rest board@ is not something I personally think
plenty of chairs do, which I certainly understand the past month or so.

Ted Dunning wrote on 2019-7-21 1:44PM EDT:
> Tom,
> 
> We need to fix board@. You are correct that it isn't usable currently. Not
> for you. Not for the board.

+1, Ted is spot on.  The directors are working on improvements, but need
thoughtful ideas and feedback.

> Can you make suggestions about what levels of moderation / social
> enforcement would make the mailing list tolerable for you but (from your
> understanding) would be acceptable?
> 
> 
> 
> On Sun, Jul 21, 2019 at 9:37 AM Tom Barber  wrote:
> 
>> Hello
>>
>> Quick protocol question as the board isn’t fit for purpose and I’m fed up
>> of it clogging up my inbox. Do incubating project chairs for incubating
>> projects have to be subscribed to board@?
>>
>> If so I’ll start the process of replacing myself as DRAT chair. If not I’ll
>> just unsubscribe.
>>
>> Thanks
>>
>> Tom

-- 

- Shane
  Director & Member
  The Apache Software Foundation

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

Re: Generating + formatting the Board report from the website?

[Shane Curcuru]

Bertrand Delacretaz wrote on 5/22/19 6:09 AM:
> On Wed, May 22, 2019 at 11:46 AM Justin Mclean  
> wrote:
>> ...It’s still unclear to me how Whimsy will render this, guess we find out 
>> when we submit it?..
> 
> I think the core of the Board agenda is the text file in svn, that's
> what needs to be clean AFAIK.

Yup - the entire board agenda is in SVN; you can either hand-edit, or
use Whimsy to post/edit a single report at a time.  Whimsy has logic
about what buttons are presented to take actions, but the end result of
Whimsy actions is to simply checkin that change to the SVN file.

Key Whimsy takeaways:

- Never allow a line of exactly 41 '-' dash characters in your report,
because Whimsy uses that as an attachment (report) separator.  See code:

https://issues.apache.org/jira/browse/WHIMSY-265?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel=16845155#comment-16845155

- Whimsy likes 80 column linewraps.  It will only rewrap the current
report if you push the rewrap button and then commit.  It doesn't ever
wrap long URLs.   The linebreak/wrap logic code is here:

https://github.com/apache/whimsy/blob/7e00fb38fec3437635b531751cbc1c4644e4bd41/www/board/agenda/views/pages/report.js.rb#L103

- As a UI display feature *only*: Whimsy attempts to display with a
yellow highlight any lines that it thinks are too long.  This yellow
highlight is only a UI artifact, and does not change any data.


-- 

- Shane
  Whimsy PMC
  The Apache Software Foundation

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

Re: Generating + formatting the Board report from the website?

[Shane Curcuru]

Justin Mclean wrote on 5/20/19 9:04 AM:
...snip...>> Or we can improve the script or maybe even move to Markdown
for the
>> input to have more control, if you think this would help.
> 
> Markdown might help the board in reviews (but not 100% sure about that), but 
> it would be more work for the podlings and some may be reluctant about this 
> imposition placed upon them. It does sort of seem a all or nothing sort of 
> scenario? Even if the report template contained markdown it can also be quite 
> easy to break. From memory it doesn’t support bare links which could be an 
> issue? (Although Asciidoctor does.)

Markdown certainly allows bare links, although I suppose depending on
the rendering engine they might or might not be clickable - which isn't
really that important in our case IMO.

For an example of what Whimsy tooling already supports for free
(outputting either text or markdown from plaintext source data):

  https://whimsy.apache.org/roster/orgchart/ (try vp-brand or secretary)

I agree the first step is figuring out how the IPMC can improve their
process and the end result of the report, since that's the biggest
userbase to make changes with.  Then we can focus on what would be easy
- and pretty - for the board to consume.

Thanks for the ideas and progress!

-- 

- Shane
  Director & Member
  The Apache Software Foundation

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

Re: board report duplication

[Shane Curcuru]

Sam Ruby wrote on 4/12/19 9:48 PM:
> On Fri, Apr 12, 2019 at 2:42 PM Sam Ruby  wrote:
>>
>> 3) Somebody uses the whimsy board agenda tool to update the incubator
>> report, and it dutifully strips out the previous report (up to said
>> row of dashes) an inserts a new report.
> 
> Here is the regular expression in question:
> 
> https://github.com/apache/whimsy/blob/00d8c5d473beae972138e6c1b3bac2633b6ea342/www/board/agenda/views/actions/post.json.rb#L118

Thus, a key short term solution is to never put lines of 40 dashes in
the Incubator report, right?

It sounds like the long term solution is being discussed already, in
terms of either using the new wiki or possibly building a new Whimsy
tool to edit the incubator report.

-- 

- Shane
  Whimsy PMC
  The Apache Software Foundation

It's using JS parsing, but close enough to explain:
  https://regexr.com/4c7e9

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

USPTO links (was: [Cava] Suitable name search - choosing a name)

[Shane Curcuru]

Kevin A. McGrail wrote on 2/28/19 7:58 PM:
...snip...
> Note: From the USPTO TESS: "*BAVA*" is an Italian word that means
> "slobber" or "drool".  Not sure if this will permalink:
> http://tmsearch.uspto.gov/bin/showfield?f=doc=4804:rx7o71.2.7

No, most links from the USPTO website don't work, sadly.  I've updated
the trademark docs to note the only reliable way to share a link there:

  https://www.apache.org/foundation/marks/naming#regsearch

Click through to a specific trademark page, then click the TSDR blue
button, which provides a stable URL, like this for sparkling wine:

https://tsdr.uspto.gov/#caseNumber=87442162=SERIAL_NO=statusSearch

-- 

- Shane
  Ex-VP Brand
  The Apache Software Foundation

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

Re: [PROPOSAL] Changing requirements for IPMC

[Shane Curcuru]

Great ideas, thanks Justin!

Justin Mclean wrote on 11/6/18 3:20 AM:
> Hi,
> 
> I looked at the board resolution for the creation of the IPMC [1] and it says 
> nothing about how IPMC members should be added so from that I take it that 
> the IPMC can decide how it wants to do that.

The IPMC is a PMC just like any other PMC.  How the PMC decides to
choose new PMC members to recommend for a board ACK is up to the PMC, as
long as it's documented clearly.

> Currently the IPMC can vote people in (which is not so common) or an ASF 
> member can request it. I’m not sure where the ASF member requirement came 
> from and wasn’t able to find the discussion about this on the incubator list. 
> (If anyone knows please point me to it.)

IMO the "ASF Members can request recommendation without vote" is because
of two factors: experience and oversight.  We (hope) Members have the
skills as you note as well.  Separately, since the IPMC is overseeing a
wide range of communities with an eye to inviting them to become an
official Apache project, we should allow Members to formally join the
IPMC to help oversee this process, since

...snip...
> Then they can ask the IPMC to join to IPMC by sending an email to private@ 
> listing what they have been involved in. The IPMC would VOTE on them, and 
> there’s a chance they could be rejected, but given it’s a private vote I 
> don’t think any harm is done if that happens. Also people could nominate 
> other people who fit into this above group.

+1, having a clear criteria as you list (to ensure it's people who
really have productively helped, and not just people status-seeking) and
an explicit call to "this is how you can *ask* to get voted into the
IPMC" is a great idea.  I agree, we definitely need a larger pool of
mentors for podlings, and helping committed non-Members be able to do
this is a great thing.


-- 

- Shane
  Director & Member
  The Apache Software Foundation

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

Re: How widely read is the incubator report?

[Shane Curcuru]

Justin Mclean wrote on 11/2/18 6:38 PM:
> Hi,
> 
> I would guess goes that PPMC that report for that month may read it or 
> possibly only check their bit? 

I read the entire report every month.  Then again, I'm a director so I'm
supposed to.  8-)  I'd bet most PPMC members never read the report as
submitted; only look at their own part of the report.

> Quite often issues that affect one podling apply to/help other podlings but 
> they don’t seem to be aware of it despite it appearing in the report several 
> times. It seems to me that having each podling PMC read each monthly report 
> could be of benefit to them and that it might be a good idea to it to all 
> email it to all PPMC each month? What do others think?

Sending the whole report to all podlings monthly is overbearing.  It
would do them good to read the other reports (both for comments as well
as how reports are written), but that's putting a bunch of burden on new
community members at Apache, and they'll likely wholly ignore it.

One thing that feels useful would be a post-board meeting meta-summary,
kind of like Phil now does as Chairman.  Phil has taken part of the
Chairman's report and made it about common issues between projects, or
even just which projects wrote great reports and why.  Something like
that is hard to produce - extra work for our few IPMC report organizing
volunteers - but could be high-impact since it's short enough with
focused commentary that PPMCs might read and learn from it.

Definitely a good idea you have in some way!

-- 

- Shane
  Director & Member
  The Apache Software Foundation

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

[jira] [Created] (INCUBATOR-223) Website build fails with jbake 2.6.2

[Shane Curcuru (JIRA)]

Shane Curcuru created INCUBATOR-223:
---

 Summary: Website build fails with jbake 2.6.2
 Key: INCUBATOR-223
 URL: https://issues.apache.org/jira/browse/INCUBATOR-223
 Project: Incubator
  Issue Type: Bug
  Components: site
Reporter: Shane Curcuru


OSX 10.x, jbake 2.6.2 from Homebrew fails to build the website.  Tips from 
anyone who's built the website locally on Mac appreciated, especially if there 
are ruby or jbake version limitations.

jbake seems to parse a number of pages with some complaints, but then dies with:



10:12:51.910 INFO org.jbake.app.Crawler - Processing 
[/Users/curcuru/src/g/incubator/pages/past_podlings.ad]... : new 
10:12:52.039 ERROR o.a.internal.JRubyAsciidoctor - org.jruby.RubyNoMethodError
10:12:52.041 INFO c.o.orient.core.Orient - Orient Engine is shutting down...
10:12:52.043 INFO c.o.orient.core.Orient - - shutdown storage: cache...
10:12:52.328 INFO c.o.orient.core.Orient - OrientDB Engine shutdown complete
An unexpected error occurred: org.jruby.exceptions.RaiseException: 
(NoMethodError) asciidoctor: FAILED: : Failed to load AsciiDoc document 
- undefined method `start_with?' for nil:NilClass
org.asciidoctor.internal.AsciidoctorCoreException: 
org.jruby.exceptions.RaiseException: (NoMethodError) asciidoctor: FAILED: 
: Failed to load AsciiDoc document - undefined method `start_with?' for 
nil:NilClass
 at org.asciidoctor.internal.JRubyAsciidoctor.render(JRubyAsciidoctor.java:341)
 at org.asciidoctor.internal.JRubyAsciidoctor.render(JRubyAsciidoctor.java:448)
 at 
org.jbake.parser.AsciidoctorEngine.processAsciiDoc(AsciidoctorEngine.java:158)
 at org.jbake.parser.AsciidoctorEngine.processBody(AsciidoctorEngine.java:152)
 at org.jbake.parser.MarkupEngine.parse(MarkupEngine.java:118)
 at org.jbake.app.Parser.processFile(Parser.java:44)
 at org.jbake.app.Crawler.crawlSourceFile(Crawler.java:193)
 at org.jbake.app.Crawler.crawl(Crawler.java:112)
 at org.jbake.app.Crawler.crawl(Crawler.java:65)
 at org.jbake.app.Oven.bake(Oven.java:137)
 at org.jbake.launcher.Baker.bake(Baker.java:32)
 at org.jbake.launcher.Main.run(Main.java:97)
 at org.jbake.launcher.Main.run(Main.java:83)
 at org.jbake.launcher.Main.main(Main.java:56)
Caused by: org.jruby.exceptions.RaiseException: (NoMethodError) asciidoctor: 
FAILED: : Failed to load AsciiDoc document - undefined method 
`start_with?' for nil:NilClass
 at 
RUBY.parse_section_title(uri:classloader:/gems/asciidoctor-1.5.7.1/lib/asciidoctor/parser.rb:1734)
 at 
RUBY.initialize_section(uri:classloader:/gems/asciidoctor-1.5.7.1/lib/asciidoctor/parser.rb:1564)
 at 
RUBY.next_section(uri:classloader:/gems/asciidoctor-1.5.7.1/lib/asciidoctor/parser.rb:290)
 at 
RUBY.parse(uri:classloader:/gems/asciidoctor-1.5.7.1/lib/asciidoctor/parser.rb:96)
 at 
RUBY.parse(uri:classloader:/gems/asciidoctor-1.5.7.1/lib/asciidoctor/document.rb:565)
 at RUBY.load(uri:classloader:/gems/asciidoctor-1.5.7.1/lib/asciidoctor.rb:1361)
 at 
RUBY.convert(uri:classloader:/gems/asciidoctor-1.5.7.1/lib/asciidoctor.rb:1473)
 at RUBY.convert(

Re: Request for advice: name search for subproject

[Shane Curcuru]

Kenneth Knowles wrote on 10/10/18 11:13 PM:
> Hello!
> 
> Apache Beam [1] is welcoming a donation [2] of the Euphoria DSL [3]. As PMC
> chair I am doing IP clearance. I would like advice on the process for a
> name/trademark search for a subproject like this. Is this the right venue
> to ask? Can anyone give me a pointer?

Branding comes under trademarks, and the official scoop is here:

  https://www.apache.org/foundation/marks/naming

The trademarks@ team would be happy to take input on 1) ensuring that's
easy to find and 2) patches to make the steps clearer for podlings or
TLPs alike.

> Kenn (Beam PMC Chair)
> 
> [1] https://beam.apache.org/
> [2] https://github.com/apache/beam/pull/6601
> [3] https://github.com/seznam/euphoria
> 


-- 

- Shane
  Director & Member
  The Apache Software Foundation

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

Re: [PROPOSAL] Zipkin for Apache Incubator

[Shane Curcuru]

Adrian Cole wrote on 8/17/18 5:29 AM:
> I would like to propose Zipkin as an Apache Incubator project.
> 
> The text of the proposal can be found below as well as on the Incubator wiki:
> 
> https://wiki.apache.org/incubator/ZipkinProposal

Glad to see this come through!

One thing I'd like to point out is the thoughtful process OpenZipkin
went through in deciding to make the proposal.  Adrian led the community
through really figuring out what the community needed, and evaluated
either coming to the ASF, going to CNCF, or staying independent:

  https://github.com/openzipkin/openzipkin.github.io/issues/51

This is the kind of thing that would be great to write a blog post about
(from anyone, really) that the IPMC could point to as an example of how
different communities decided to come to the ASF.

-- 

- Shane
  Director & Member
  The Apache Software Foundation

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

Re: Help wanted about the license of the theme for building SkyWalking's website.

[Shane Curcuru]

Can you provide a link to the specific theme?

On first look, I don't see how this can be appropriate for building any
major part of an Apache project's web presence.  The licenses there
would seem to prevent other people from forking any of the website,
which would not be appropriate.  For example, the License FAQ:

"8. You can’t re-distribute the Item as stock, in a tool or template, or
with source files. You can’t do this with an Item either on its own or
bundled with other items, and even if you modify the Item. You can’t
re-distribute or make available the Item as-is or with superficial
modifications. These things are not allowed even if the re-distribution
is for Free."

That seems to say that you couldn't put the theme files in a public SVN
repository, which means... other project committers couldn't build the
website.

Reminder: it's a good idea to get feedback here on general@, but if the
feedback you get doesn't have a definitive answer, then head over to the
Legal Affairs Committee to get a specific answer.


-- 

- Shane
  IPMC & Member
  The Apache Software Foundation

peng-yongsheng wrote on 7/25/18 10:34 AM:
> Hello Incubator PMC’ers,
> 
> I purchased a WordPress theme from the site of https://themeforest.net,
> and this theme's license is a regular license.  
> 
> This license description is: 
> 1. You are licensed to use the Item to create one single End Product for
> yourself or for one client (a “single application”), and the End Product
> can be distributed for Free.
> 2. You can create one End Product for a client, and you can transfer
> that single End Product to your client for any fee. This license is then
> transferred to your client.
> 
> 
> And the ThemeForest say something can't do with the theme: 
> 1. You can’t Sell the End Product, except to one client. (If you or your
> client want to Sell the End Product, you will need the Extended License.)
> 2. You can’t re-distribute the Item as stock, in a tool or template, or
> with source files. You can’t do this with an Item either on its own or
> bundled with other items, and even if you modify the Item. You can’t
> re-distribute or make available the Item as-is or with superficial
> modifications. These things are not allowed even if the re-distribution
> is for Free
> 3. You can’t use the Item in any application allowing an end user to
> customise a digital or physical product to their specific needs, such as
> an “on demand”, “made to order” or “build it yourself” application. You
> can use the Item in this way only if you purchase a separate license for
> each final product incorporating the Item that is created using the
> application.
> 4. Although you can modify the Item and therefore delete unwanted
> components before creating your single End Product, you can’t extract
> and use a single component of an Item on a stand-alone basis.
> 
> The detail of regular license:
> https://themeforest.net/licenses/terms/regular/2.2%20(Copy)
> 
> 
> *Can we use this theme for building SkyWalking's website?*
> *
> *
> *The attachment is the authorization file of the theme.
> *

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

Re: [DISCUSS] Absent mentors

[Shane Curcuru]

Jim Jagielski wrote on 4/1/18 10:19 AM:
> Would it be possible to generate a short list of all current
> mentors for all current podlings to see how many podlings
> each mentor is signed up for? That would be a good metric
> to know.

Presuming podlings.xml is kept updated:


https://svn.apache.org/repos/asf/incubator/public/trunk/content/podlings.xml

That now sorts by @status first, so current podlings are on top.  That's
separate from whimsy cross-checks of what's listed in board reports and
actual signoffs.

-- 

- Shane
  Director & Member
  The Apache Software Foundation

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

Re: Thoughts on Trademarks / Existing Domains on Podling Proposals / Reports

[Shane Curcuru]

Thanks for the excellent question and Mark's thoughtful replies.

Mark Thomas wrote on 2/13/18 4:27 AM:
> On 12/02/18 23:24, Dave Fisher wrote:
>> Hi -
>>
>> I think that the Incubator should adjust the proposal process when a project 
>> comes in that has registered trademarks.
>>
>> There are a few impacts to consider some of which may need to be private.
>>
>> (1) PODLINGNAMESEARCH may not be needed.
> 
> Maybe. I'm not so sure. The view of the ASF as to what is an acceptable
> name in terms of potential conflicts with other products may be
> different to the entity that registered the mark. For example:
> 
> - the registering entity may have considered a narrower geographic area
>   whereas the ASF tends to look globally;
> 
> - there may have been a conflict that was acceptable to the registering
>   entity that would not be acceptable to the ASF.
> 
> I think we probably need to keep this.

Yes, we need to keep PODLINGNAMESEARCH.  It's irresponsible to host a
software project without doing our own due diligence to ensure the name
we plan to use isn't stepping on someone's existing name.

> 
>> (2) The IPMC and trademarks@ should want to understand what will need to be 
>> transferred and what the timing of the transfer(s) will be - either during 
>> onboarding or at graduation. We should be clear about what happens to the 
>> trademark if Incubation fails either with or without a release.
> 
> As far as I am aware the standard process is to transfer them prior to
> graduation and that this is a required step before graduation. There is
> normally a clause in the transfer agreement to the effect that if
> graduation fails, the transfer doesn't happen.

The current *requirement* is that trademark rights are legally
transferred before the board votes for creating the new TLP.

That is purposefully under-specified, because different organizations
donating projects in the past have had different expectations.  Also,
the ASF does not need to do the paperwork until the podling's about to
graduate.  However I'm happy to sign paperwork earlier if the donor
wants to. [1]

> 
>> (3) Existing domains are also something that should be on a proposal along 
>> with if these need to be continued or should be redirected. We need to be 
>> clear about what happens to domains if incubation fails.
> 
> My expectation is that these would be treated the same way as
> trademarks. Generally, we would redirect but of there are a lot of them
> we might opt to let some lapse.

Correct.  If there is a major product user-facing portal, or if there
are domains that are baked into URLs within the code, the ASF would take
them on and maintain them for the life of the project.  We'd also expect
to redirect all of them to the proper project.a.o domain.  Any other
domains we would consider taking for a short term transition period
(just a redirect), but we would let lapse.

Domains are easier to manage than trademarks - they merely require the
transfer code, rather than officer's legal signatures.  But yes, we'd
give them back on a failed graduation if they had been transferred.

> 
>> (4) I think these items would add some additional sections to the podling 
>> report.
> 
> Do you mean adding a brand section?
> 
> What about an additional section on the proposal template? Or would it
> make more sense under 'Source and Intellectual Property Submission
> Plan'? Maybe call out in the template that this is the place to list
> trademarks, domains, etc.

Yes, a podling proposal should have an explicit section that lists:

- Registered trademarks and their owner(s)
- Any domain names the project uses
- Any other brand elements - like logos or alternate brand names - that
the project intends to donate (or, that the project is *not* donating).

Separately, I think it would be a good idea for the podling quarterly
report template to have a section or checkbox that shows their progress
to complying with the project branding policy:

  https://www.apache.org/foundation/marks/pmcs

-- 

- Shane
  https://www.apache.org/foundation/marks/resources

[1] This is a factor of our volunteer-led organization, and the strength
of the APACHE brand.

- Since we rely on volunteers to manage this whole process, the
*requirement* is the minimum the ASF needs: trademark rights for TLPs.
While it would be great to have more detailed process - and volunteers
who can *reliably* and *knowledgeably* work on this as soon as a podling
proposal is accepted, we haven't had that in the past.

- Trademark assignment agreements are mostly boilerplate, and thus, easy
for counsel to review.  Trademark assignments with clawback (i.e.
returning the trademark rights if a podling fails to graduate) are...
unique to the ASF, and take more volunteer time and counsel time to
draft and review.

- From a risk management perspective, waiting until graduation nears to
force the matter is not that bad.  Any organization that has spent the
time and thought to donate a codebase and a 

Re: Update README for retired podlings?

[Shane Curcuru]

Dave Fisher wrote on 11/2/17 11:13 PM:
>> On Nov 2, 2017, at 7:06 PM, John D. Ament  wrote:
>>> On Thu, Nov 2, 2017 at 6:17 PM Dave Fisher  wrote:
> On Nov 2, 2017, at 3:08 PM, sebb  wrote:

> On 2 November 2017 at 21:07, Dave Fisher  wrote:
...snip...
>> I'm not even sure I agree with deleting the websites.  It was a project.
>> Now it's not.  That doesn't mean the information should no longer be
>> available.  But not sure the resources need to be covered.
> 
> Either the IPMC should review the policy or we should ask the board to 
> set/confirm the policy for “retired” podlings.

Podlings in incubation are not Apache projects - by definition.  They
are podlings effectively managed within the incubator.  So it would be
best for the IPMC to come up with a specific policy or plan for this,
vote on it, and then just let the board know "Hey, here's how we're
going to formally handle retiring podling assets".

Personally, I think it depends on how long the podling was around (i.e.
how many likely other people were attempting to use the project) and
what the state of it's IP clearance is.  In particular, if IP clearance
weren't complete, I would vote for deleting the repos, just to ensure
that we're not distributing (even via source control) IP that the ASF
isn't assured of having under our license.

-- 

- Shane
  https://www.apache.org/foundation/marks/resources

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

Re: [DISCUSS] Proposed resolution to graduate the PredictionIO podling

[Shane Curcuru]

Andrew Purtell wrote on 10/3/17 5:59 PM:
> I think we can proceed to a vote as soon as Shane confirms we are good on
> the PredictionIO trademark transfer. Should we ping him?

The trademark assignment is signed, so you're all set to vote for
graduation recommendation!

Note that the ownership of the trademark in the USPTO's system will take
a while to file the paperwork to show the change of ownership (sometimes
a while...) but that doesn't matter for graduation.

-- 

- Shane
  https://www.apache.org/foundation/marks/resources

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

Re: [PROPOSAL] PageSpeed

[Shane Curcuru]

Jukka Zitting wrote on 9/26/17 10:23 AM:
> Let's start a VOTE tomorrow if nobody has big concerns or issued they'd
> want to clarify before the vote.
> 
> The way I see it, the biggest items to look at during incubation is
> completing the transition from a Google-driven project to an independent,
> diverse community and doing a license review of the various dependencies
> PageSpeed has. I don't expect big issues with either, just noting that
> these will require some effort.
> 
> There's also an existing PageSpeed trademark for  "computer programs for
> use in newspaper layout and composition", so we'll need to work with the
> branding team to figure out how much of an issue that is.

PAGESPEED is a registered trademark in the US:

https://tsdr.uspto.gov/#caseNumber=73818548=SERIAL_NO=statusSearch

Trademarks are about ensuring that new users aren't confused when
looking for a specific product - that is, when they search and review
websites, knowing only the name and what they want the product to do,
would the user likely be confused as to which PageSpeed is which?

In any case, we can worry (but not much) about details like that when
the time comes.  Thanks for noting the issue!

-- 

- Shane
  https://www.apache.org/foundation/marks/resources

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

Re: Podlings & Apache Project Maturity Model (was RE: [DISCUSS] Graduate Apache RocketMQ from podling to TLP)

[Shane Curcuru]

Bertrand Delacretaz wrote on 9/4/17 4:54 AM:
> Hi John,
> 
> On Fri, Aug 25, 2017 at 9:11 PM, John D. Ament  wrote:
>> ...Its unfair for us to put some stake in the ground expecting podlings to
>> match up 100% on the questions.  Many of the questions are subjective - is
>> the code easy to discover? respond to bug reports in a timely manner?...
> 
> Ok, I think I understand your reluctance now: you don't want us to set
> a gate for graduating podlings that many TLPs might not pass.
> 
> I agree with that, and although I'm a strong supporter of the Maturity
> Model (having initiated it that's understandable ;-) I'm totally ok
> with podlings graduating without fullfilling all of its requirements.
> 
> In my view the model is:
> 
> 1) A good tool to help discover areas that podlings might have neglected.
> 
> 2) A good tool to help podlings look at where they stand, and what
> they might still need to improve after graduation.
> 
> 3) A good tool to express our ideal way of doing things, in a concise
> way, and evolve that definition over time.
> 
> Based on this I will continue to push for podlings to come to
> graduation with a self-assessment based on that model.
> 
> OTOH I'm fine with us clarifying that it's not a requirement.

Proposal: It should be a *requirement* for the podling to self-document
their maturity model answers in the [DISCUSS] thread before IPMC
graduation vote.  The requirement is having done it, not passing it.

It's *very* helpful to have podlings consider their growth using some
form of structured and consistent criteria, so IPMC (and board) can
consider how different podlings see themselves compared to past podling
history.

It doesn't mean every podling has to say "Yes 100%" to every question,
just that they've considered each point and can describe their situation
there if not.  I'd expect plenty of podlings would have some missing or
"we're not completely here" on some points, but still be healthy and
well-self-governing communities ready to graduate.


-- 

- Shane
  https://www.apache.org/foundation/marks/resources

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

Re: [DISCUSS] Apache Distributed Release Audit Tool (DRAT)

[Shane Curcuru]

Greg Stein wrote on 8/10/17 8:44 AM:
> On Thu, Aug 10, 2017 at 6:46 AM, Shane Curcuru <a...@shanecurcuru.org> wrote:
> 
>> (note mixed private/public lists)
...snip...
>> - Has the Apache Creadur project been consulted about the new project
>> proposal, and in particular do they have any comments on using DRAT as
>> the name, which subsumes their popular Rat name?
>>
> 
> These are not the same communities. The Foundation should not "force" them
> to work together.
> 
> They might logically make sense together, but the *communities* are
> disjoint. There is zero reason for those communities to be lumped together.
> In fact, it was the disjoint communities under an umbrella project that
> spearheaded the Foundation's "blow up umbrellas" campaign a decade ago.
> 
> Communities define groupings. Not topic.

You bring up the community issue, which I agree with you on.  I bring up
the *name* issue, which I imagine I disagree with you on.

> And does the DRAT acronym really impose on what the Creadur people are
> doing with their Rat tool? Meh. That's a stretch.

Given that Rat is used reasonably widely - perhaps not as a major tool,
but there's still good awareness of it - I thought it would be nice if
someone asked their community if they minded having their name subsumed
by a completely new project.

It seems rude to directly copy the name of another Apache project
without even asking.  And if these two projects were hosted at different
organizations, there would definitely be a likelihood of confusion.

-- 

- Shane
  https://www.apache.org/foundation/marks/resources

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

Re: [DISCUSS] Apache Distributed Release Audit Tool (DRAT)

[Shane Curcuru]

John D. Ament wrote on 8/10/17 7:50 AM:
> Just curious, but how do we know which marks the ASF actually owns?  Rat
> isn't a TLP so I'm a bit surprised we own "Apache Rat", or is it simply
> implicit?

We claim that all Apache software *product* names are ASF trademarks:

  https://www.apache.org/foundation/marks/list/

In the US, once you are publicly offering a product using a consistent
name/logo, you can claim it as your trademark, no paperwork needed.  The
most important things are to have a consistent name, and to put the ™
symbol up or otherwise let the world know you claim it as a trademark.

Most projects are common law trademarks, which you can just claim as
your marks by doing so.  Some projects have registered (or applied-for)
trademarks, which give us far more rights but takes months of waiting
for the application process (and requires the PMC to ask).

As for "owns", that's a question that needs more clarification.  We
claim project names as our trademarks - so we own them.  But common law
trademarks have limited rights of control.  Trademarks only apply in
similar classes or kinds of goods, so saying "Apache Rat™" doesn't mean
that we could prevent everyone from having a software product called Rat
- only that they can't have a Rat software that would *be likely to
confuse users as to the source of the product*.

Does that make sense?

- Shane

> 
> John
> 
> On Thu, Aug 10, 2017 at 7:46 AM Shane Curcuru <a...@shanecurcuru.org> wrote:
> 
>> (note mixed private/public lists)
>>
>> General questions, since... we haven't actually had any discussion yet.
>>
>> - Is there a particular hurry to bring this to pTLP faster than the
>> traditional general@incubator discussion period is?
>>
>> - Has the Apache Creadur project been consulted about the new project
>> proposal, and in particular do they have any comments on using DRAT as
>> the name, which subsumes their popular Rat name?
>>
>> - It's awesome to see ™ included in a proposal (most people forget), but
>> they're mixed up.  Apache should be ® (when needed; when talking about
>> individual project names it's usually not needed) and most project names
>> should be ™.  So it would be either Apache® Rat™ or Apache Rat™.
>>
>> Thanks for filling out the rest of the proposal.
>>
>> - Shane
>>
>> Chris Mattmann wrote on 8/10/17 1:59 AM:
>>> Hi Everyone,
>>>
>>> Just as an FYI I've added a resolution to establish DRAT to the agenda.
>>>
>>> On item - 2 of the proposed PMC includes members without an Apache
>> account. What to do in this situation? If they start only as committers,
>> that's fine, but then we would create an account for them after the fact.
>> Is this the desire? If so I will update the resolution and we can VOTE them
>> in as PMC after the project is establish should the Board agree to do so.
>>>
>>> Thanks,
>>> Chris
>>>
>>>
>>> On 2017-08-02 10:35, Chris Mattmann <mattm...@apache.org> wrote:
>>>> Hi Board-Chat@,
>>>>
>>>> CC/Incubator@
>>>>
>>>> We are proposing to bring DRAT (Distributed Release Audit Tool) to the
>> ASF.
>>>> DRAT is a parallelized version of Apache RAT that uses OODT, Solr and
>> Tika to
>>>> compute, visualize and interact with interesting statistics on code
>> auditing as
>>>> output by RAT and Tika. With DRAT you can:
>>>>
>>>> • Audit large code repositories (has been tested in 100s of M of
>> lines of
>>>> code, and 1000s of projects)  where RAT fails to complete – an
>> example of running it across all of Apache
>>>> SVN is here: http://drat.dyndns.org:8080/dratviz/ You can also see its
>> output
>>>> for a very large set of NSF funded geosciences code repositories here:
>>>> http://drat.dyndns.org:8080/dratontoviz/
>>>> • Visualize and interact with the output from RAT and Tika in a
>> dynamic fashion
>>>> • Get incremental status from code auditing
>>>> • Audit individual code repos and integrate the results into your
>> project
>>>>
>>>> DRAT was funded by DARPA, NASA, the NSF and other government entities.
>>>>
>>>> We have prepared a preliminary proposal here:
>> https://wiki.apache.org/incubator/DRATProposal
>>>>
>>>> We are working on flushing it out more, should be done by this weekend.
>> We propose
>>>> DRAT to be a straight to TLP (pTLP). I will add a resolution into the
>> Board agenda for August 2017

Re: [DISCUSS] Apache Distributed Release Audit Tool (DRAT)

[Shane Curcuru]

(note mixed private/public lists)

General questions, since... we haven't actually had any discussion yet.

- Is there a particular hurry to bring this to pTLP faster than the
traditional general@incubator discussion period is?

- Has the Apache Creadur project been consulted about the new project
proposal, and in particular do they have any comments on using DRAT as
the name, which subsumes their popular Rat name?

- It's awesome to see ™ included in a proposal (most people forget), but
they're mixed up.  Apache should be ® (when needed; when talking about
individual project names it's usually not needed) and most project names
should be ™.  So it would be either Apache® Rat™ or Apache Rat™.

Thanks for filling out the rest of the proposal.

- Shane

Chris Mattmann wrote on 8/10/17 1:59 AM:
> Hi Everyone,
> 
> Just as an FYI I've added a resolution to establish DRAT to the agenda.
> 
> On item - 2 of the proposed PMC includes members without an Apache account. 
> What to do in this situation? If they start only as committers, that's fine, 
> but then we would create an account for them after the fact. Is this the 
> desire? If so I will update the resolution and we can VOTE them in as PMC 
> after the project is establish should the Board agree to do so. 
> 
> Thanks,
> Chris
> 
> 
> On 2017-08-02 10:35, Chris Mattmann  wrote: 
>> Hi Board-Chat@,
>>
>> CC/Incubator@
>>
>> We are proposing to bring DRAT (Distributed Release Audit Tool) to the ASF.
>> DRAT is a parallelized version of Apache RAT that uses OODT, Solr and Tika to
>> compute, visualize and interact with interesting statistics on code auditing 
>> as
>> output by RAT and Tika. With DRAT you can:
>>
>> • Audit large code repositories (has been tested in 100s of M of lines of
>> code, and 1000s of projects)  where RAT fails to complete – an example of 
>> running it across all of Apache
>> SVN is here: http://drat.dyndns.org:8080/dratviz/ You can also see its output
>> for a very large set of NSF funded geosciences code repositories here: 
>> http://drat.dyndns.org:8080/dratontoviz/ 
>> • Visualize and interact with the output from RAT and Tika in a dynamic 
>> fashion
>> • Get incremental status from code auditing
>> • Audit individual code repos and integrate the results into your project
>>
>> DRAT was funded by DARPA, NASA, the NSF and other government entities.
>>
>> We have prepared a preliminary proposal here: 
>> https://wiki.apache.org/incubator/DRATProposal
>>
>> We are working on flushing it out more, should be done by this weekend. We 
>> propose 
>> DRAT to be a straight to TLP (pTLP). I will add a resolution into the Board 
>> agenda for August 2017
>> for its consideration. I am CC’ing the Incubator so that we can 
>> potentially attract new contributors
>> both seasoned and junior to the project. We also welcome any contributors 
>> from Creadur interested
>> in learning more about OODT, Solr, Tika, etc. Also any Wicket gurus – we 
>> are using Wicket for one of
>> DRAT’s key user interfaces, Proteus.
>>
>> OK, thanks!
>>
>> Cheers,
>> Chris
>>
>>
>>
>>
>>
>>
>> -
>> 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
> 


-- 

- Shane
  https://www.apache.org/foundation/marks/resources

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

[Shane Curcuru]

John D. Ament wrote on 8/4/17 7:59 AM:
> On Fri, Aug 4, 2017 at 7:17 AM Shane Curcuru <a...@shanecurcuru.org> wrote:
...snip...
>> - Other reverse domain names *really* should change to org.apache;
>> otherwise it's just confusing.
>>
>>
> Agreed.  The one caveat to all this is the implementation of javax.
> namespace which is typically required and managed by the Geronimo TLP
> (typically).
...snip...

Good point - any package names where there's a well-known technical
standard that specifies package names takes precedence for naming.
That's what a normal user would expect, and they also (typically)
understand there's a difference between the standard API names and the
actual implementation of the API they've downloaded.

-- 

- Shane
  https://www.apache.org/foundation/marks/resources

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

[Shane Curcuru]

Andy Seaborne wrote on 8/4/17 5:00 AM:
> On 03/08/17 23:20, John D. Ament wrote:
>> Which must's do you see greg?
>>
>> On Aug 3, 2017 1:09 PM, "Greg Trasuk"  wrote:
>>
>>> Does this actually need to be policy?  What’s the harm to the foundation
>>> if a project continues to use a non-Apache package name, assuming
>>> that the
>>> code was donated appropriately?

Because in some cases, the donating company may continue to market
around the name, leading existing or completely new users to assume that
the company still runs the project.  When a project comes to Apache,
it's an *Apache* project.

That's obvious to those of us who read this list.  It's not obvious to
the average developer (i.e. potential future contributor), nor to the
average CTO or other manager who decides if their employees are allowed
to contribute to FOSS project X or if they're going to buy support from
the original donating company.

So the answer is: "it depends" on how the package name will be used in
code examples or common use cases, and seen by new developers evaluating
use of this software product.

 1) package names with reverse domains MUST be renamed
 before graduation or have an IPMC approved plan for renaming
> 
> SHOULD
> (i.e. it needs a justification but isn't absolutely prohibited)

It depends.  Trying to start thinking about what matters from a brand
perspective:

- Renaming is a MUST if the reverse domain name starts with com.*

- Renaming is a MUST if the domain name is not being legally transferred
to the ASF before graduation.

- Renaming is a MUST if parts of the domain name are still claimed as
trademarks by the donating party.

- Other reverse domain names *really* should change to org.apache;
otherwise it's just confusing.

-- The criteria should be applied strictly for the packages that are the
"main" class or the primary API programming interface for the most
common functionality of the product.  All other packages (utilities,
shims, standards, etc.) have more freedom in keeping existing names.

- Functionality-derived package names - that's up to the community; I
can definitely see it making sense to stick with existing names.

...snip...

-- 

- Shane
  https://www.apache.org/foundation/marks/resources

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

[Shane Curcuru]

Alex Harui wrote on 8/3/17 10:37 AM:
> 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).

This is the only significant point for me.  I would be -1 on TLPs
continuing to ship a com.company.* package for the primary code for the
project

*If* there is a long history of use and expectations of compatibility,
and *if* the package names are not reverse-domains but are just
component names, then that's fine to keep the package 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

Any packages that use the reversed domain name prefix.

> 2) there is no recommendation for other package prefixes

It's still a best practice to use org.apache.*, unless the package
prefix is long-used and is based on component or functionality names.


-- 

- Shane
  https://www.apache.org/foundation/marks/resources

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

[Shane Curcuru]

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://www.apache.org/foundation/marks/resources

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

Re: ZeroMQ licensing in Apache MXNet

[Shane Curcuru]

Greg Stein wrote on 7/6/17 4:01 AM:
> On Thu, Jul 6, 2017 at 1:23 AM, Henri Yandell  wrote:
>> ...
> 
>> I'd like to ask on legal-discuss@ for an exception (one year?) to continue
>> using ZeroMQ, with prominent documentation, in MXNet given the trend
>> towards MPL 2.0.
>>
> 
> I'm not super cozy with the idea of explicit exceptions to licensing
> issues. Forward progress mitigates that a bit.

I'm not cozy either.  And you've confirmed crystal-clear that the
exception is clearly valid in this use case and that users won't somehow
believe (or need to act) as if the reciprocal clauses in the Zero*
software would apply to the podling's release?
> 
> Are there other libraries that could be used, should ZeroMQ *not* get
> itself relicensed? In other words, could there be a simultaneous move
> towards two options: new library, or a relicensed zeromq?
> 
> 
>> Any concerns before I do so?
>>
> 
> I'd say: no graduation, until solved, regardless of whether an exception is
> provided.

Agreed.  Including LGPL code in any Apache product release is not a good
idea immaterial of any explicit exceptions.  Merely because the
exception may technically make it legally compliant is not the point;
end-users will be surprised to see anything *GPL* in Apache products.

> 
> Cheers,
> -g
-- 

- Shane
  https://www.apache.org/foundation/marks/resources

-
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

[Shane Curcuru]

Roman Shaposhnik wrote on 6/7/17 4:20 PM:
> On Wed, Jun 7, 2017 at 10:56 AM, Mark Thomas  wrote:
>> On 07/06/17 17:53, Roman Shaposhnik wrote:
>>> On Wed, Jun 7, 2017 at 8:32 AM, Sean Busbey  wrote:
 On 2017-06-06 11:59 (-0500), Roman Shaposhnik  wrote:
> On Mon, Jun 5, 2017 at 8:25 PM, John D. Ament  
> wrote:
>> While these are all great discussion points, I don't believe they're
>> relevant to incubator only and probably should have remained on the
>> legal-discuss list.  Ignite graduated ~2 years ago.  The incubator 
>> probably
>> doesn't have an opinion about this, but it's good to know that the policy
>> may change (and I do personally have an opinion on said types of 
>> software).
>
> The reason I'm bringing it on the IPMC mailing list has nothing to do
> with how long
> ago Ignite graduated and everything to do with the following two points:
>1. It can be very useful to the future podlings
>2. I honestly don't know any other forum where I can meaningfully
> discuss changes to release policy
>
> I'll take advice on #2, of course.


 Who owns release policy? I presume it's VP Legal, which would suggest 
 legal-discuss.
>>>
>>> I would really be surprised if VP Legal actually *owned* it. This
>>> feels someplace between
>>> INFRA, ComDev and Legal, but it still doesn't answer the question
>>> who's a single throat
>>> to choke.
>>
>> Consider yourself surprised then. V.P. Legal owns the release policy.
> 
> Is legal-discuss then the appropriate forum to actually build the consensus?
> I surely hope V.P. Legal won't play a BDFL with our release policy, will he?

Huh?  Only the board and specifically authorized officers can set policy
like the release policy that all PMCs MUST follow.  So yes, VP Legal is
the final determiner of release policy updates, not anyone else.

legal-discuss@ is the best place to bring any specific requests from
project(s) to change the actual policy itself.  But first it would be
useful to get some rough consensus on some of those specific requests
here from the IPMC or from ComDev.  Having specific changes backed up by
actual *needs* from one or more PMCs is the best way to start.

Note that ComDev is a PMC itself, and has no authority to set *policy*
for other PMCs.  But they do provide a lot of good docs and best
practices, and dev@community is becoming quite a good cross-project
discussion area, so it's a good place to get other feedback on a proposal.

> Thanks,
> Roman.

-- 

- Shane
  https://www.apache.org/foundation/marks/resources

-
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

[Shane Curcuru]

While there may be technical issues out there, the policy issues can
have time for a thorough discussion before we make policy updates.

Alex Harui wrote on 6/5/17 11:25 PM:
> Is the use of Google Analytics also prohibited by #4?

That sounds like a different issue, unless a project is shipping docs
inside a release with GA code *in* the html docs that are then run when
a user installs the docs locally.  That would not be a good idea, BTW.

As Bertrand notes elsethread, GA on *.apache.org websites is fine as
long as the PMC is sure to comply with the ASF privacy policy:

  https://www.apache.org/foundation/policies/privacy.html

Separately, we have one example of auto-update checking which is OK:

  https://wiki.openoffice.org/wiki/Update_Service

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

-- 

- Shane
  https://www.apache.org/foundation/marks/resources

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

Re: Images in source code.

[Shane Curcuru]

Mike Drob wrote on 6/4/17 3:12 PM:
> Project logos are Apache Licensed, but cannot be used for "any purpose" I
> thought? They're specifically called out and most uses of trademark logos
> need to be approved by VP Brand.

Correct, although not quite exact.  The Apache license itself explicitly
*excludes* trademark rights [1]:

  https://www.apache.org/licenses/LICENSE-2.0.html#trademarks

So users are free to reuse our icons and logos and what-not almost
anyway they like, but *not* in ways that would infringe on our existing
trademarks for software products.

Users can take the nutty Apache Flink squirrel logo and use it to refer
to Apache Flink itself.  They could also use it as part of an art
collage, or in a presentation about squirrels, or mash it up with logos
of dogs or any other sort of non-trademark uses.  They can't use it (in
general cases) to refer to a different software product than Flink.

The reporting guide has some steps for thinking about "Is this
$somebody's use of an Apache logo OK or not?"

  https://www.apache.org/foundation/marks/reporting#kinds

-- 

- Shane
  https://www.apache.org/foundation/marks/resources

[1] Protip: no OSI-approved software license gives users any trademark
rights - even if "trademarks" never appears in the license.  FOSS
licenses are only *copyright* licenses, not trademark licenses.

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

Re: My Slides from... any ApacheCon/BigData talks

[Shane Curcuru]

John D. Ament wrote on 5/18/17 11:12 AM:
> All,
> 
> I've had a couple of people ask where my slides are for the talk I gave
> this week at Apachecon.  I also expect the video to be published soon.  The
> slide deck can be found at https://s.apache.org/jda_acna_2017

Reminder: speakers can upload slides to the producer's CFP management
site using the Linux Foundation ID you submitted your CFP to:

  https://events.linuxfoundation.org/cfp/dashboard

> Slide Due Date
> ===
> We will be contacting speakers as we get closer to the event but
> please note that your presentation slides, in 16:9,  are due on
> Tuesday, May 2. These can be submitted (in .PDF format only) through
> the CFP manager by logging into the site here. As soon as you submit
> your slides, they will automatically be available to view on the
> event website.

http://events.linuxfoundation.org/events/apachecon-north-america/program/slides

http://events.linuxfoundation.org/events/apache-big-data-north-america/program/slides

Also: if your slides are easily re-useable and are about a larger
community topic (i.e. not just about one project) feel free to add them
to the ComDev speaker resources page:

  https://community.apache.org/speakers/slides.html




> I hope everyone enjoyed it, glad seeing so many podlings and potential new
> projects present!

Yay! There was a lot of good content and feedback at sessions in Miami!

> 
> John
> 


-- 

- Shane
  https://www.apache.org/foundation/marks/resources

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

Re: Incubator Governance Change

[Shane Curcuru]

Pat Ferrel wrote on 4/22/17 11:46 AM:
> Probably the wrong place for this but…
> 
> What do people think about a governance change for approving releases
> through the IPMC to wit:
> 
> A week of no vote activity over the release proposal of a podling
> should be considered a passing vote. In other words the IPMC is to
> become a vetoing group.

No, because as noted in this thread the board and Legal Affairs
Committee already have a policy for Apache software releases:

  https://www.apache.org/legal/release-policy.html#policy

This is the spot where all the little legal bits of having a corporation
intersects with the Incubator's ability to mentor new podlings in how to
effectively run projects in the Apache Way.  However that legal policy
in particular is not going to change IMO.

Personally, I support any proposals that help ensure podling mentors are
more actively engaged, and can better serve as the formal IPMC votes for
podling releases.  Great to see some serious discussion about that in
this thread and the upcoming IPMC chair election.  The incubator has
been getting better organized as a whole over the past few years, and
keeps improving, which is great to see.

> I propose this for 2 reasons: 1) lack of votes or attention from the
> IPMC seems all too prevalent and puts an undo drag on the energy and
> velocity of community involvement. 2) the release has already been
> voted on and checked by at least 3 PMC members of the podling (which
> has ASF mentors in most all cases) so a veto role by the IPMC seems
> to have minimum danger to the ASF system of checks and balances.>

Yes, but the whole point of Incubation is that a podling is not yet a
project.  Only Apache PMCs have the authority to make a release, thus
only IPMC votes count.  On one hand this must feel incredibly annoying.
On the other hand, it is the #1 reason we have the ASF as a corporation
- to prevent the individual release manager from potentially getting
sued *personally* for problems with the release.

The fact that we have these documented policies, and that the board and
IPMC enforces them means that legally, releases are acts of the
Foundation.  Thus if anyone ever were to sue, they'd sue the Foundation
(which has insurance and legal counsel) and not individual committers.

-- 

- Shane, IPMC Member
  https://www.apache.org/foundation/marks/resources

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

Re: Podling Press Kit

[Shane Curcuru]

Good questions.  My thoughts:

Daniel Dekany wrote on 4/14/17 5:32 AM:
> The page says that the "Official Incubator Logo" "is to be used on ALL
> podling pages during the incubation process". But I guess the intent
> was to allow using the "Red-On-White Version of Logo" or
> "Black-On-White Version of Logo" or "White-On-Black Version of Logo"
> instead as well.

Yes, I'd think podlings should be able to choose the variant that best
fits their own design.

> Also I'm not sure what the intended usage of the ``Standalone "Powered
> By" Apache Incubator Logo`` is. Since the rectangular official logo
> must be displayed (according the press kit), it sounds unlikely that
> someone will show the circular variation as well. So maybe the intent
> was to allow using that *instead* of the rectangular one?

Good question, does Sally or anyone else working on Incubator branding
overall have an opinion?  Personally I'd vote for using the official
square logo in general for podling branding, but if someone wants to
talk about the Incubator project as an overall process, the circular
logo might make sense.

> 
> The press kit doesn't tell where on the page the logo can be shown, so
> I assume even showing it in the page footer is fine.

Since a number of current projects feature the incubator disclaimer and
logo in the footer, yes, that should still be fine.

> Also I'm not sure that by "used on ALL podling pages" you really mean
> all of them, like even JavaDoc generated pages. (It's doable
> technically, just asking.)

No, javadoc pages don't need the branding, although it's nice.  Branding
MUST be applied on homepage, any major landing pages (i.e. where you
send out links to answer questions from), and on download related pages.
 Branding should be on all the main pages of the website; i.e. ones
where we are crafting the content (as opposed to purely generated API or
similar docsets like javadoc).

> Well, I guess these will be added to
> http://incubator.apache.org/incubation/Incubation_Policy.html
> eventually. Only if we are to implement this at certain podling now,
> it would be good to know what the options are.

The high level goal is to have your project complying with the Apache
TLP project branding policy by the time you graduate (modulo the
incubating disclaimer, etc..  It's supposed to be a process, so as long
as a podling is making progress, it should be good.

  https://www.apache.org/foundation/marks/pmcs

- Shane
> 
> 
> Thursday, April 13, 2017, 4:01:29 AM, John D. Ament wrote:
> 
>> All,
>>
>> In conjunction with the new incubator logo, Sally has prepared material to
>> help podlings incorporate incubator branding into their logos.  I plan to
>> link this page
>> http://incubator.staging.apache.org/guides/press-kit.html from
>> the main website page to help build logos specific for podlings, in
>> addition to our standard banner logo.  Podlings would have the option of
>> choosing which they prefer.
>>
>> Please review - I plan to distribute to all podlings tomorrow evening.
>>
>> John
> 


-- 

- Shane
  https://www.apache.org/foundation/marks/resources

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

Re: Help with Dependency Licensing

[Shane Curcuru]

Nick Couchman wrote on 4/11/17 10:26 AM:
> Hello, everyone,I'm currently working on the Guacamole incubator
> project, and am developing an extension for the project that has
> dependencies on binaries (JARs via Maven) that are licensed under
> Category-X licenses.  We've already determined that we cannot
> distribute a binary version of this extension, but, since it is an
> extension (and not core to the functionality of the product), we
> should be able to distribute the source code with build instructions
> for the users. 

It's not completely clear from your description what specific bits of
code are going where, so a more detailed description might help.  But my
first guess would be no.  The CatX policy is pretty clear: don't include
Category X code in Apache repos or releases:

  https://www.apache.org/legal/resolved.html#category-x

The reasoning for this is twofold:

- Legal issues.  We obviously want to carefully comply with how everyone
else's licenses, so GPL or any similar kind of code is inappropriate to
use in any Apache work.

- Policy issues.  Immaterial of caselaw or potential legal rulings, the
ASF only wants to incorporate third party works in ways that respect the
intent of third party licenses.  The JSON license is an example here,
since it's unspecific call for 'Good, not Evil' is incompatible with our
policy that our users can use the software for whatever they want.

In any case, it sounds like your PPMC needs to provide a more detailed
description of the issue, and open a Legal JIRA to get a definitive answer:

  https://www.apache.org/legal/resolved.html#asking-questions


> The question I have is how we should deal with license
> bundling in this scenario?  In the rest of this project, including
> other extensions, we bundle a src/licenses directory that has all of
> the dependency licenses for the extension.  When the binary is built,
> a resulting file has not only the binary for the extension, but also
> all of the dependency licenses.  Since we're not distributing a
> binary, is there any reason/need for us to package up dependency
> licenses? Let me know if this needs more clarification - I know this
> might be a bit vague, but I'm in new territory, here, and am happy to
> provide any further information that might help someone help me :-). 
> Thanks,Nick
> 


-- 

- Shane
  https://www.apache.org/foundation/marks/resources

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

Re: Revisit policy that all IPMC members have commit privs to all incubator repositories.

[Shane Curcuru]

John D. Ament wrote on 4/6/17 6:57 AM:
> This solution describes one of the many reasons I feel the incubator itself
> is broken.  We're trying to rewrite policy, as a means to work around some
> awkward setup sitting around, instead of just treating podlings as regular
> projects, with some restrictions in place.

+1.  The restrictions on podlings are in terms of branding and
mentoring.  We don't *need* any technical restrictions, other than those
which make maintaining the branding & mentoring easier.

> Create something in ldap that is org.apache.incubator.$podling.  When
> secretary processes new accounts, they're being added into this area,
> instead of the incubator area.
> 
> IPMC members have access to execute something that adds committers to
> podlings.  It could be a special ou for mentors, which VP incubator has
> access to.

IPMC members should be able to fill out a form to request commit for any
podling.  Mentors should be automatically added to podlings they are
working on, to make it seamless if they do need to help out (especially
on websites).

> This has to net less maintenance from infra to make podlings more like TLPs.
> 
> The one thing Sam misses in this email, there is a way to fix your
> notification scheme easily in github -
> https://github.com/settings/notifications - uncheck "Automatically Watch
> Repositories"

Yes, but I don't want to *have* to set this to just opt-out of getting
stuck on all new podlings.  8-)

> 
> John
> 
> On Thu, Apr 6, 2017 at 1:07 AM Sam Ruby  wrote:
> 
>> Background, from https://issues.apache.org/jira/browse/INFRA-13804
>>
>>> With this feedback and review, I believe we're still operating as
>> expected.
>>>
>>> * Per current policy, IPMC members have commit privileges on all
>> Incubator repositories.
>>> * The above is effected through the use of a private GitHub Team
>>> * According to users' GitHub preferences, they will Watch new
>> repositories
>>> * GitHub is sending notifications of changes, per Watch selections
>>>
>>> The "answer" here is to Unwatch repositories, as appropriate, and/or
>>> to alter the GitHub user account preference for auto-Watching new
>>> repositories.
>>
>> Here's my case:
>>
>> I believe that asking all IPMC members that request access to *any* ASF
>> github repository to get notification emails on *all* incubator projects
>> that participate in the gitbox experiment is unreasonable.
>>
>> I believe that asking all IPMC members to individually unwatch each and
>> every repository as they are created is unreasonable.
>>
>> I believe that asking all IPMC members to uncheck "Automatically watch"
>> is unreasonable as it (a) will result in people being notified for new
>> repositories that they should be watching, and (b) presumes that people
>> are not participating/watching in other non-ASF GitHub repositories.
>>
>> Accordingly, Since I do believe that it is reasonable for every ASF
>> member to get email on all ASF repositories that they have commit
>> privileges to, I am asking that the IPMC revisit the current policy that
>> all IPMC members have commit privileges on all Incubator repositories.
>>
>> I believe that the alternative is technically feasible: have each
>> podling manage a list of committers for that podling:
>>
>> https://whimsy.apache.org/roster/ppmc/
>>
>> - Sam Ruby
>>
>>
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>
> 


-- 

- Shane
  https://www.apache.org/foundation/marks/resources

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

Re: Where to edit a podling's data for whimsey?

[Shane Curcuru]

Stack wrote on 3/24/17 6:18 PM:
> I am having trouble finding where to edit to fix a podling's whimsey view?
> Pointers appreciated.
> Thanks,
> St.Ack

Which specific data and/or which Whimsy URL do you need to update?

Whimsy URLs that might be relevant:

https://whimsy.apache.org/public/

https://github.com/apache/whimsy/blob/master/www/incubator/podlings/by-age.cgi

https://github.com/apache/whimsy/blob/master/www/roster/public_podlings.rb


-- 

- Shane
  https://www.apache.org/foundation/marks/resources

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

Re: New Incubator Logo Selection Results

[Shane Curcuru]

Looks amazeballs great!

John D. Ament wrote on 3/17/17 8:53 PM:
> Yeah, sorry about that.  Was going to send out more direct links when
> I had the website updates almost ready.  Anyways here they are.
> 
> 1. The new logo, in a more web-ready format: 
> http://incubator.staging.apache.org/images/incubator_feather_egg_logo_sm.png
>
> 2. An example of the new header - http://incubator.staging.apache.org/
> 
> I'm worried that its a bit busy.  thoughts?

Great graphic.  Keeping the eggs warm until they're ready to hatch, and
when they graduate, the tip of their feather bends to the right to
become the regular feather.

Nicer layout and styles, definitely.

The font for * bullet lists seems odd next to the body text.  Dunno if
you've gotten to that stage yet.

Given this is the Incubator, I'd be happy with both the ASF and
Incubator logos in the top row as long as the sizes look complimentary.
Incubator is all about multiple communities becoming Apache, so that
kind of makes sense.



Feature request: tables of contents in some pages.  Now that the site is
easier read, scanning a podling page, there's a lot of headers that end
up far, far down the page that you might never see (especially the
chunky tables with status items).  Having a TOC at the top of the page
would help people see the progression of items along the page.

...getting inspired to come work on incubator docs once this work is
checked in!

-- 

- Shane
  https://www.apache.org/foundation/marks/resources

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

Re: [DISCUSS] Podling report format changes

[Shane Curcuru]

John D. Ament wrote on 1/24/17 8:15 PM:
> All,
> 
> The Incubator PMC has received feedback from the board that changes may
> need to be made to the structure of our report.  Specifically, there is
> confusion from the board members over how podlings get classified.  There
> is also a request to increase and improve mentor feedback on podling
> reports.  Based on this input, I would like to propose the following
> changes to our report format.  I would like to try to implement this for
> the March report, if not before then.
> 
> 1. Eliminate the podling summary section of the report.  It shouldn't be on
> the report manager to classify each podling.  We have begun leveraging a
> maturity model for podlings, while its not required to fulfill it serves as
> an equivalent to this section.  The list of podlings who failed to report
> shall remain.

+1, if this simplifies work it's fine.

> 
> 2. Add a "Podling Maturity Assessment" to the individual podling reports.
> This would give a clear opportunity for each podling to describe how they
> are doing, perhaps compared to the maturity model or our classic categories.

+1, with a general encouragement to start each with a simple category.
That is, when scanning the whole report, it would be very helpful to see
one of "Ready to Graduate", "Some Community Growth", "No Release" and
"Still Getting Started" or a similar set of values.  Any additional
description is great, but having fairly consistent markers really helps
get a sense of progress across the whole incubator.

Personally I like the maturity model, so using that is great, but I do
understand that we may not always have cycles to use it.

> 
> 3. Change the mentor sign off section to include a per-mentor comment.
> E.g. instead of the current:
> 
>   [ ](podling) mentor1
>   [ ](podling) mentor2
>   [ ](podling) mentor3
> 
> It would be:
> 
>   [ ](podling) mentor1
>   Comments:
>   [ ](podling) mentor2
>   Comments:
>   [ ](podling) mentor3
>   Comments:
> 
> And rename Shepherd/Mentor notes: to just "Shepherd notes:"

Big +1.  Having even a sentence for most mentors with their thoughts is
a huge improvement if we can get it.

> 
> Thoughts?
> 
> John

Thanks, John!

- Shane


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

Re: Trademark registration

[Shane Curcuru]

Legally the ASF could register the trademarks for podlings, once we have
the source code in our repo, but as a public charity it's not
appropriate for us to do so given the cost and fact that a podling may
fail to graduate[1].

Some podlings coming from companies have existing registrations, which
the donor must formally transfer to the ASF before graduation; we will
then maintain the registrations ourselves for that TLP.

Trademark rights in the US and some countries come from use in commerce:
publicly using the name or logo in association with software for
download means you can use ™ on the trademark and claim it.  Registering
gives you other abilities, but is not required.

We have a comprehensive list of trademark resources, many of which are
useful for any FOSS project:

  https://www.apache.org/foundation/marks/resources

In particular see "How To: Request Registration of Your Project Name".

- Shane

[1] This is an issue of both cost and trademark ownership.  Registered
trademarks are legal assets; as a US non-profit 501C3 organization we
can't really give assets like that away except to another 501C3 in most
cases.  For unregistered trademarks it doesn't much matter; if a podling
fails to graduate we don't keep any claim over the trademark.

Greg Stein wrote on 11/30/16 5:14 AM:
> Podlings are not part of the Foundation (yet), so cannot get trademark
> registrations.
> 
> The Trademark/Brand peeps will assist with looking at the future
> possibility, post-graduation.
> 
> On Wed, Nov 30, 2016 at 4:00 AM, Stian Soiland-Reyes 
> wrote:
> 
>> On 30 November 2016 at 09:51, Ian Dunlop  wrote:
>>> I saw the following on trademark registrations
>>> http://www.apache.org/foundation/marks/register#register and wondered if
>>> this was possible for incubator projects or only for those which have
>>> graduated. Any ideas?
>>
>> I think it makes most sense for graduated projects; a podling project
>> is not guaranteed to graduate from the Incubator and might choose to
>> say move to a GitHub-only model.  This could then require a project
>> rename beyond removing "Apache", as ASF would have the trademark
>> registration and there might not be a new legal entity to move the
>> trademark to.
>>
>> But that said, I don't think there's anything stopping such a
>> registration for podlings - not sure if policy-wise that would need to
>> include "(incubating)", which perhaps would look odd in a trademark.
>>
>>
>> --
>> Stian Soiland-Reyes
>> 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: [DISCUSS] Documentation

[Shane Curcuru]

Bertrand Delacretaz wrote on 11/11/16 9:37 AM:
> On Fri, Nov 11, 2016 at 8:46 AM, Gunnar Tapper  
> wrote:
>> ...Talking with other contributors, there's a clear preference to use Apache
>> OpenOffice for documentation
> 
> *for some people*, right? I think many of us are big fans of creating
> documentation using structured text in version control repositories.

Yes, using AOO is very hard on version control, since it's normally
stored as a blob not a diff.

There are many different structured documentation tools in various
projects at Apache, and both PDFBox, Cocoon, and Forrest (and probably
others) can be used to translate various kinds of structured docs
(asciitext, markdown, xml, whatever) into PDFs for reading if desired.

>From the peanut gallery, I'd suggest researching some of the other doc
tools in use at Apache projects - perhaps ask on
d...@community.apache.org as well for ideas.  But in the end, the
decision is up to whoever's actually writing the docs *for that
project*.  If your contributors really will prefer AOO over other tools,
then use that.

- Shane


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

Re: [DISCUSS] China Contribution.

[Shane Curcuru]

(note mixed private/public lists)
Julian Hyde wrote on 11/11/16 8:31 AM:
> I like the way that Reynold is coming at this.
> 
> I am aware of the rule mandating English for discussions. But in the
> interests of having no more rules than are strictly necessary, is it
> not sufficient to tell PMCs (and PPMCs): "Do whatever you believe
> will engage the largest possible community."

For user@ lists and places where a project is helping end users solve
problems, that makes sense, as long as it's archived.

For the development side of the project (making decisions
collaboratively, equitably deciding on new committers, not favoring
vendors, etc.), how can the ASF provide proper oversight of that
project, given that we don't have sufficient Chinese language skills
across our Membership, officers, or our board?

My first reaction is that Apache is a great place - but it's not the
right place for every project.  On the big picture I definitely would
love to see more well-run open source in China.  But I wonder if we as
an organization have the governance capacity to be effective at doing
this directly.  (I.e. there are plenty of individual Members who are
helping there; just not sure that means these should be Apache projects
yet).

Does that make sense?  This also would be a great topic for the
Community Development project to work on for a while: what other,
general ways can we help non-English language communities better learn
about effective open source governance?

- Shane

> 
> Most PMCs will choose English. Some won’t. Times they are a
> changing.
> 
> Julian
> 
> 
>> On Nov 10, 2016, at 11:42 PM, Reynold Xin  wrote:
>>
>> Background: I have no tie to RocketMQ. I didn't even know about it until
>> today and I don't know any of the people associated with the project. I am
>> Chinese but living in the US. I'm purely playing devil's advocate about a
>> meta-point here and don't know if it applies to RocketMQ or not.
>>
>> I definitely agree with Jeff's point that "my thoughts about community
>> would be getting as many people and users involved as possible".
>>
>> That said, for a project started in China, it is unclear switching the
>> primary development language from Chinese to English would help with
>> accomplishing that goal. While lowering the bar for non-Chinese speakers to
>> participate, it will limit the efficacy of its original developers, and
>> increases the bar for more Chinese developers, which are the more natural,
>> immediate expansion targets for the community.
>>
>> If we as a community want to enforce the usage of English as the standard,
>> we should just explicitly say that.
>>
>> I'd avoid using the argument that English will bring more users, as it is
>> not defensible and risk being interpreted as western arrogance. Afterall,
>> three out of the six largest Internet companies (by market cap) are
>> currently in mainland China, and they all have enormous daily active users
>> even though they are targeting primarily Chinese.
>>
>>
>> On Thu, Nov 10, 2016 at 11:14 PM, Jeff Genender 
>> wrote:
>>
>>> I would think that English is generally used because its the most
>>> international language, not because its the most used in the world.  Thus
>>> it helps cross borders for communication.  At the end of the day, I think
>>> you need to look at your community and ask if you want it to cross borders
>>> or not.  Do you want worldwide contribution (and adoption)?  I can tell you
>>> that I glean a lot of information from the mail lists when I run into
>>> problems or issues using Apache software.  If the discussions are in
>>> Chinese, you may miss a lot of people who can be a part of the discussion
>>> from outside of China.  I think you really need to think about who you want
>>> your users to be and how you want your product adopted.
>>>
>>> In addition, this is an incubated project.  AFAICT, the champion doesn’t
>>> speak Chinese, and I am wild-guessing maybe 2 of the mentors do.  This
>>> means the other mentors may have a difficult time steering the project when
>>> they are needed.  It makes it difficult for the champion to asses any
>>> problems without having someone notify him of a translated issue.  In the
>>> unlikely event that the project requires input from the incubation PMC or,
>>> the board for that matter, it would be very difficult to get a proper
>>> insight into the issues without have solid knowledge of the language.
>>>
>>> I personally don’t know of any rule or regulation that locks down a
>>> language and perhaps a board member can chime in on that.  But my .02 is
>>> that if I were bringing a project to Apache, my thoughts about community
>>> would be getting as many people and users involved as possible.  If you
>>> don’t use a more cross-border/international language, then I believe that
>>> you may ultimately be hindering your project beyond your borders.  I think
>>> that would be a shame.  OTOH, maybe your desire is to 

Re: [Proposal] Move Wiki Access Requests somewhere

[Shane Curcuru]

Are most requesters already committers, or no?

If so, then *cough* whimsy tool *cough*.  That's a place we can create
simple AUTH'd request tools that channelize things; even as a front end,
it would ensure the requests have a specific which-wiki, who is the
username, etc. that you don't always get from emails.

Just a crazy idea I can't help with yet.  But agree: finding ways to
reduce non-interesting threads here would help people follow the
interesting discussions or votes.

- Shane

Benjamin Young wrote on 10/5/16 10:22 AM:
> The incubator list is pretty popular. ;) Not less so these days with
> the NetBeans discussions, etc.
> 
> I’d like to propose (fwiw) that a mailing list be setup to ask for
> wiki access (perhaps wiki@incubator.a.o) and that it be used
> primarily for that purpose. If possible, the list could be setup to
> receive emails from anyone (without prior subscription) to avoid the
> need to “hang around” on that list if all you needed was to make an
> edit somewhere.
> 
> Alternatively, perhaps a web form could be setup to mail the IPMC
> directly.
> 
> Or, the much harder alternative, moving to Confluence, which I think
> avoids this request need / has it’s own more automated way of
> handling such things (maybe).
> 
> The hope is just to reduce the signal to noise ratio here—which is
> already quite high due to so many projects talking in one general
> space.
> 
> Thanks for considering this idea! Benjamin
> 
> -- http://bigbluehat.com/ http://linkedin.com/in/benjaminyoung
> 


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

Re: MySQL FOSS License Exception

[Shane Curcuru]

Donald Szeto wrote on 9/29/16 6:13 PM:
> Hi all,
> 
> I have searched around the Internet and haven't seen this discussed
> (appreciate pointers if I missed any existing discussion).
> 
> The exception: https://www.mysql.com/about/legal/licensing/foss-exception/
> 
> I am curious how Apache view this exception. Is it okay for Apache source
> code to depends on it? What about binaries? Appreciate any input. Thanks!

My bet is no, because it doesn't meet Apache's license criteria:

  https://www.apache.org/legal/resolved.html#criteria

In particular, the ASF's intent is that third parties may take Apache
software releases and use or redistribute a variety of works based on
them without any additional restrictions other than the permissive
Apache license.  This is intended to apply for further redistributions
as well, where the third party's licensing would permit it.

That is, our policy explicitly tries to avoid special cases that the
*ASF* might be able to take advantage of, but that a *redistributor* of
a larger work including our Apache released software might not be able
to take advantage of (because they use a different or commercial license
for some of the work).

- Shane


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

Re: Netbeans expectations (Was: Re: ASF doing too much? (Was: Re: TAC))

[Shane Curcuru]

(Please note the mixed public/private lists)

As a little bit of context: NetBeans is not only a large project with a
complex history, community, and infrastructure, but it's also coming at
a time when the ASF is trying to improve our internal operations,
infrastructure team and systems, and our budgeting situation so that we
can more reliably and efficiently provide the services that our projects
need.

So while we certainly do need the additional infra team work with the
NetBeans donors to let us plan infra capacity, some of the extra
scrutiny that you might have seen here in the Incubator is because
internally we're trying to better plan for, and set more detailed
expectations for, all our future podlings.

I can see there will be a lot of work - and changes - to NetBeans in the
next year or so, but it's all eminently doable if the community comes
together to work in the Apache Way.  And it will definitely be nice to
have our own developer tooling here!

- Shane


Roman Shaposhnik wrote on 9/27/16 6:39 PM:
> On Tue, Sep 27, 2016 at 3:27 PM, Jim Jagielski  wrote:
>> I would have assumed that if Netbeans stakeholders had any issues
>> or question, or requests for clarification, they would have
>> pinged either their champion or one of their proposed mentors.
>>
>> As it is, it is only on this thread, and not on any Incubator/vote
>> thread that I can see that this even came up, and even then
>> it could easily have been overlooked.
>>
>> To be clear: "Netbeans stakeholders" had serious and misleading
>> information about what Apache provided and it was only brought
>> out via some backchannel discussion with someone not involved
>> in the Netbeans proposal (from the Apache side) at all...
> 
> I am actually offended by your categorization of me as the one who
> is "not involved in the Netbeans proposal (from the  Apache side) at all..."
> 
> Putting aside the amount of personal time I've spent on the phone,
> online, etc. trying to help this community calibrate their expectations
> about transition to ASF, I must say this: if you're telling a very active
> member of IPMC (myself) that somehow I'm not involved in the
> proposal just because my name isn't of the freaking list as a mentor
> I can only say one thing back to you: way to go crushing any desire
> I had to help. Way to go, Jim!
> 
> Thanks,
> Roman.
> 
> P.S. And for the record -- I was invited to be a mentor. I declined.


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

Re: Preliminary NetBeans cost findings

[Shane Curcuru]

Geertjan Wielenga wrote on 9/25/16 6:05 PM:
> On Sun, Sep 25, 2016 at 11:58 PM, Rich Bowen wrote:
> 
> 
>> Having a third party run a service under an Apache brand requires working
>> with VP Brand.
> 
> 
> Indeed, this is something we're going to need to do. I.e., there will be
> existing NetBeans services that Apache will not be hosting. The clearest
> case of this will be plugins.netbeans.org. That is a service that one or
> more individual contributors will take on, making use of the infrastructure
> of an organization they work for.

These are all solvable questions, but the podling will need to work
closely with your mentors and others at the ASF to ensure they're done
in a way that still allows the future Apache NetBeans project to operate
fully independently of specific corporate influence.

  http://community.apache.org/projectIndependence.html

We don't need to go through the details on this discuss thread, but both
*who* will be hosting these specific services as well as *how* they're
portrayed to the world will be things the podling needs to track.

It needs to be clear that development decisions on the podling are done
by the individual committers doing the work on the podling.  We also
need to ensure that if any external provider decides to drop the
service, that we have some way to keep the committer community working
on the NetBeans code itself still moving forward.

>From how the various NetBeans folks are describing things, this will be
complicated, but we should definitely be able to figure it all out
during the incubation process.  I'm also expecting that it will take
work on the image side to show the world that Oracle truly is giving up
control to the community, but again, it certainly sounds like you've got
the right people here to make that happen.

- Shane

> 
> I.e., if Apache is not going to host one or more services currently hosted
> by Oracle, and if those services are needed by NetBeans, something will
> need to be done to resolve the situation, which will be that the service
> will be hosted by someone else. An individual contributor could host
> plugins.netbeans.org on their own private server, of course, though an
> organization volunteering this service is a more likely and stable
> scenario. I am sure other Apache projects have similar arrangements and
> this will not be new for Apache in any way.
> 
> Gj
...

-
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

[Shane Curcuru]

toki wrote on 9/24/16 8:04 PM:
> On 22/09/2016 05:18, Roman Shaposhnik wrote:
>> had a non-trivial amount of commits to then Sun NetBeans between 2002-2008. 
>> He then drifted away from the
>> project but would be interested, potentially, re-engaging.
> 
> Is it possible to create a "master list' of everybody who has
> contributed, when they contributed, and roughly how much they contributed?
> 
> If so, then:
> * send everybody on that list an ICLA to fill out and return;
> * Include that list as an appendix to the Incubation Paperwork. Call it
> _Individuals who, on request will be considered to be part of the
> Initial Committer List_, once the appropriate paperwork has been signed
> and submitted;
> * The _Initial Committer List_ consists of people who have signed and
> submitted the appropriate paperwork, and requested to be on the list;

My advice is to leave the initial committer list as-is, and then wait to
see who actually shows up to do work on the project during the
incubation process.

Part of what the IPMC looks for during incubation is can the podling
community self-govern, a large part of which is voting in new committers
in an appropriate fashion.

Separately, when a podling is ready to graduate, and the IPMC votes to
recommend graduation to the board, the actual committer and PMC lists
for the top level project sometimes change versus the whole committer
list during incubation.  People who never show up to actually work on
the podling probably should not be left on the committer list for the
future top level project.

- Shane


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

Re: Preliminary NetBeans cost findings

[Shane Curcuru]

Excellent cliff notes, and I'm really glad to see us surfacing the
issues - and costs - of incubating such a large podling.

Question: do you have a rough forecast of how long this expense/extra
infra burden will last?  I.e. is this likely something we'll bear for
3-4 years and then we'll have migrated everything to a better home, or
is this a long-term cost due to how big it all is?

- Shane

Daniel Gruno wrote on 9/24/16 6:17 AM:
> Hi folks,
> 
> I've been going over the requirements for NetBeans infrastructure, it's
> ballpark costs, bandwidth, machines needed and so forth, and the cliff
> notes are as follows:
> 
> - 40-50TB/month in traffic required (mostly downloads+plugins)
> - 8-13 machines/VMS are required
> - Ballpark hardware costs are between $3k and $10k per year, depending
>   on how much we can move to existing infrastructure and how close we
>   come to the original setup. The most likely figure we are working with
>   is $4.9k, but we should be prepared for a larger cost, just in case.
> - The maintenance will be split between infra (downloads, web site, CI,
>   new build machines) and the project (services, plugins, statistics),
>   which will undoubtedly incur additional costs in terms of infra time
>   spent on this, possibly to the tune of $10-20k in the initial phase.
> 
> Certain services like the plugins hosting will rely on Legal giving the
> go-ahead for it, otherwise we'll have to find other people willing to
> host this.
> 
> Other items like downloads may be offset by CDN providers offering their
> assistance, but we should be prepared for this not being the case from
> the beginning, thus the 40-50TB/month. Likewise, some machine costs
> may be offset by cloud providers offering services for free.
> 
> Thus, I would submit to the IPMC that they consider asking the board for
> a budget of roughly $10k per year for the NetBeans project, as well as
> the additional time required of Infrastructure to implement this into
> the existing ASF infra. As we may be able to pool resources and utilize
> the new hardware for multiple projects, the cost may go down in the
> coming years, but this is the baseline I suggest we consider when
> approving NetBeans as a new podling.
> 
> With regards,
> Daniel.
> 
> 
> -
> 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] Apache NetBeans Incubator Proposal

[Shane Curcuru]

Good questions all.

Emilian Bold wrote on 9/24/16 5:18 AM:
> I assume there is a reason the list is called initial. It doesn't have to
> be perfect.

Correct.  The whole point of Incubation at Apache is to show that the
community can learn to self-govern by following Apache processes - and a
key point of self-governance is responsibly adding new committers.

In my experience, it's far better to just start incubation at this point
rather than worrying about getting the *initial* list perfect.

> 
> We should differentiate between a contributor and a committer.

Within an Apache project, anyone can be a contributor by submitting some
code (docs, tests, etc.) for review.  But *only* committers have write
access to any Apache source repositories.

To contribute small changes (via email or a bug), a committer can take
your work and just check it in (presumably giving you credit somehow).

To contribute large changes - if they're accepted by the project -
Apache will ask you to sign our ICLA confirming that you're licensing
this IP to the ASF with sufficient rights so that an Apache project can
then ship that change under our Apache license.

You *must* sign an ICLA before you can get your commit bit.  So part of
the process is ensuring the initial committers all sign the ICLA before
they actually have commit access.

> 
> A lot more people contributed patches via bugzilla than actually committed
> them in the Mercurial repository themselves.

I keep hearing one important thing in this discussion - "contributed".
As in, the past tense of contributions, done in the past.

Merit in the past is nice, but does not count directly (IMO) for current
committership.  I believe the initial committer list should be made up
from individuals who have both contributed meaningful work in the past,
and who have clearly shown an interest in helping the community to grow
during Incubation with their meaningful work.

Being an Apache committer isn't about status, it's about actively
working on the project today and in the near future.

> 
> The reason being it was not a very common thing to get committer access.
> 
> Furthermore, while I am a contributor and do have commit access and the
> Oracle CLA on file most of my contributions don't show up under my name.
> They show up under the name of the Sun / Oracle employee that got assigned
> to the Bugzilla issue where I posted my patch.
> 
> Considering how large NetBeans is I assume we will not have a short
> incubation so there will be plenty of time to add committers.

More to the point, any healthy Apache top level project (TLP) is always
working to find new helpful contributors and vote them in as committers.

- Shane

> 
> Pe sâmbătă, 24 septembrie 2016, Mark Struberg  a
> scris:
> 
>>
>>
>> Consider you did contribute 300 important patches to NetBeans over the
>> years. Wouldn't it hurt your feelings that you are not enlisted on the
>> initial committers list?

P.S. To be blunt: that's not the point.  If you're looking at this as a
popularity game, that's immaterial.  Is someone *currently* working on
the project, and do they intend to keep helping?  If so, yes, put them
on the list.  If not - no matter how much work they did long ago - then
they probably shouldn't be on the list.

I expect that during the Incubation process a number of past NetBeans
contributors will show up and re-engage.  That's great!  Once the
podling sees that these contributors are really doing some new work -
not just talking on the mailing lists - then the PPMC should vote them
in as committers.

>>
>>
>> But otoh the initial list of committers is not important for the ASF _if_
>> the PPMC makes a good job.
>> Because if such a person comes knocking then some of the 'old' NetBeans
>> lords will hopefully recognise the person and any other PPMC member
>> will at least check the commit history for his/hers contributions.
>>
>> And if someone shows up who already contributed lots of good things in the
>> past and would like to become active again, then it's just a matter of 72h
>> (VOTE time) to get him on board.
>>
>> BUT: we must clearly communicate that we start with a limited committer
>> list simply because WE fail to compose a correct one from the very start.
>> But people should know that we will fix this list over time.
>>
>>
>> LieGrue,
>> strub
>>
>>
>>
>>
>>> On Saturday, 24 September 2016, 7:46, Emilian Bold <
>> emilian.b...@gmail.com > wrote:
 So on one hand the initial commiters list is not something so
>> important and
>>> we should realy just be careful about the PPMC then vote more commiters
>>> during incubation.
>>>
>>> On the other hand the initial commiters list is super important.
>>>
>>> Is there some actual incubation documentation clearing this up?
>>>
>>> I think it's a big administrative task to compile a perfect list. It's
>>> not
>>> only about who has commit rights on the current repository, there are
>> also
>>> many that 

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Shane Curcuru]

Jochen Wiedmann wrote on 9/22/16 1:43 AM:
> On Thu, Sep 22, 2016 at 7:18 AM, Roman Shaposhnik  
> wrote:
> 
>> Still, the question remain -- for somebody like that, what would be a 
>> criteria
>> to be added as a committer after the project enters incubation?
> 
> Projects decision.

Exactly so.  This would be a podling just like every other podling, and
the IPMC would expect the PPMC to start operating like an Apache
project.  That is, when new people come to the podling and contribute
work, and help the work of the podling, that after a time the PPMC will
discuss them, then vote them in as new committers.

Past merit (i.e. past contributions) is a great help to a new
contributor to a project, both because it's easier to get started, and
because the community already has a feel for how they act and can help.
But it in no way IMO directly leads to current merit.  Old contributors
normally would be voted in as committers only once they actually start
doing new work on the project.

- Shane


-
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

[Shane Curcuru]

Mitch Claborn wrote on 9/15/16 11:07 AM:
> I'm very new in this type of thing. I have zero experience with ASF,
> etc, so if this is out of line, please forgive and I'll keep silent.
> 
> I've seen a lot of discussion about the HOW in terms of moving NetBeans
> to the Apache project, but not much/any discussion about WHY. I'm not a
> NetBeans coder/contributor, but simply someone who uses it 8+ hours per
> day in my normal job.
> 
> My main question is: will moving NetBeans to Apache result in a better
> product for people like me? If so, what particular aspects of moving
> will make that happen? Are there other projects that have made a similar
> move and experienced higher quality as a result?

As Bertrand noted else-thread: the move is because the actual people
planning to *work on the code* want to make the move (and obviously
Oracle is happy to help with the IP donations).

Apache is here to help communities of individual contributors build
software products for the public good.  We welcome any community that
wants to use the Apache Way of open, collaborative decision making, and
that will use our license and other structures.  The existing people
actually coding NetBeans are making the proposal, and the Apache
Incubator is happy to review it to see if it will fit here (seems like
it will, albeit with plenty of licensing and infrastructure changes).

Many people believe that in the long run it *will* make for a better
product for users, because becoming an independently governed project at
the ASF will draw in more code (and test, doc, plugin, etc.)
contributors from new places to help improve the product.

Does that make sense?

- Shane


-
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

[Shane Curcuru]

David Nalley wrote on 9/15/16 11:28 AM:
> On Thu, Sep 15, 2016 at 8:15 AM, Bertrand Delacretaz
>  wrote:
>> Hi Incubator PMC,
>>
>> On Tue, Sep 13, 2016 at 9:40 AM, Geertjan Wielenga
>>  wrote:
>>> ... https://wiki.apache.org/incubator/NetBeansProposal ...
>>
>> At this point I ask anyone with concerns or questions that haven't
>> been addressed so far and would prevent us from voting on this
>> proposal to chime in.
>>
> 
> Yes, please don't start a vote just yet. There's still plenty of
> questions that need to be answered from an infrastructure perspective.
> This is a large project with lots of moving parts potentially moving
> into the ASF - 2 days really isn't enough discovery yet.

+1.  Although it's clear there's an organized proposal and the authors
are actively helping to research questions, I really expect that the
IPMC would allow a significantly longer discuss thread on such a large,
complex, and long-historied project before voting.

- Shane

-
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

[Shane Curcuru]

Greg Stein wrote on 9/14/16 7:40 PM:
> On Wed, Sep 14, 2016 at 4:14 PM, Shane Curcuru <a...@shanecurcuru.org> wrote:
>> ...
> 
>>>> I think the question is more along the lines of what else would be
>>>> required to produce a "canonical"
>>>> release of Apache Netbeans. If everything that is required is being
>>>> donated -- I think we're good.
>>
>> Indeed - and remember, I'm not a regular NetBeans user.  But when I
>> google "NetBeans", I see lots of links of bundled JDK downloads and
>> various plugins that do all sorts of cool Java stuff.  My question is:
>> does producing a fully working core NetBeans require running any TCKs?
>>
> 
> It's just an application. Not a library. No TCKs involved.
> 

That's what I'd guess too, but a quick google finds this class, so I
figured I'd ask:

http://bits.netbeans.org/html+java/1.3/org/netbeans/html/json/tck/JavaScriptTCK.html

- Shane

-
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

[Shane Curcuru]

Trying to answer two questions:

Geertjan Wielenga wrote on 9/14/16 3:49 PM:
> I can't wait for that to happen! In the meantime, can we call NetBeans by
> its real name: NetBeans, with an uppercase N and an uppercase B? Shall we
> all start maintaining that, i.e., using the correct name, which is NetBeans
> or, better yet, Apache NetBeans?
> 
> Yes, Oracle is handing over everything in terms of trademarks to Apache,
> let's put aside that discussion since it's true, if you can point in the
> proposal where this is not clear or can be clearer, tell me and we will
> change/add/whatever. FYI -- no one creating independent products based on
> Apache NetBeans cares what its name is.

The branding requirement is that the ASF wholly legally owns the
trademarks and goodwill therewith before a podling can graduate.
Separately, during incubation and soon after a podling graduates to TLP,
the ASF expects the donor to update their own displays of the name to
properly reflect the ASF's ownership.

That being said, I noticed that the trademarks were explicitly marked in
the proposal, and know from past experience with an Oracle donation that
the transfers weren't a problem, so I'm not concerned.  The only issue
will be how many registrations and/or primary landing pages at Oracle
that will eventually need to be updated - I'm confident it will all be
done, but Geertjan and team should be prepared for the amount of work
when the time comes. 8-)

> 
> Only two things are in discussion right now: (1) licensing [which has been
> discussed quite a bit with Apache folks like Bertrand and Ate prior to the
> proposal being published and we are comfortable we'll be able to solve
> everything] and (2) infrastructure migration [which has been outlined
> already, though we are working on a lot more details at the moment so that
> everything will be crystal clear].
> 
> Thanks,
> 
> Geertjan
> 
> On Wed, Sep 14, 2016 at 8:40 PM, Roman Shaposhnik 
> wrote:
> 
>> On Wed, Sep 14, 2016 at 11:34 AM, Wade Chandler
>>  wrote:
>>> Do you mean from the stand point of it being a Java based application,
>> or that some how
>>> NetBeans and the Java TCK are related? I don’t think either is an impact
>> on NetBeans IMHO;
>>> not any more than it is for the Eclipse IDE or IntelliJ. Do you mean
>> because it is being contributed
>>> by Oracle perhaps? If so, does the donor have as much impact on
>> contributions as that once
>>> adopted by Apache? I may be misunderstanding what you are asking. I am
>> not an employee
>>> of Oracle; just an NB contributor.
>>
>> I think the question is more along the lines of what else would be
>> required to produce a "canonical"
>> release of Apache Netbeans. If everything that is required is being
>> donated -- I think we're good.

Indeed - and remember, I'm not a regular NetBeans user.  But when I
google "NetBeans", I see lots of links of bundled JDK downloads and
various plugins that do all sorts of cool Java stuff.  My question is:
does producing a fully working core NetBeans require running any TCKs?
Similarly, do any of the top popular plugins that are de facto used by a
large part of the community (and might come to Apache) need to run TCKs
to ensure they comply with various Java standards?

I might be misunderstanding the way NetBeans works myself, but I know
that anything dealing with TCKs has been an issue for Apache projects
for a while now, and the IPMC needs to understand if that's a likely
issue for this potential podling or not.

- Shane

>> IOW, the project must be self-contained and not depend on anything
>> still left behind the firewall
>> to do on-going development and most important releases. E.g. if I send
>> you a patch -- you can't
>> reject it on the grounds that some test behind Oracle's frewall I've
>> never seen failed. Stuff like
>> that.
>>
>> On a related note, I haven't seen it explicitly  mentioned in the
>> proposal, but I hope you guys do
>> realize that once this project is accepted the Netbeans brand belongs
>> to Apache. IOW, if Oracle
>> or anybody else ever want to have an independent product based on
>> Apache Netbeans they will
>> have to call it something else.
>>
>> Thanks,
>> Roman.
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>
> 


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

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Shane Curcuru]

Given the historical difficulty in securing usable Java-related TCK
licenses from Oracle, will that be an issue in attracting long-term
contributors to the project in the future?

A number of existing Apache projects have noted that lack of proper and
formal access to TCKs is an issue for some of their users.  Given the
wide range of plugins and integrations, I wonder if this would also be
an issue for a future Apache NetBeans project.

Just curious: I'm not a major NetBeans user so perhaps this isn't that
relevant to the future of the potential podling.

- Shane

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

[Shane Curcuru]

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

[Shane Curcuru]

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

Re: Notes on branding

[Shane Curcuru]

John D. Ament wrote on 6/29/16 7:36 AM:
> Hey guys
> 
> I'm starting to go through the podlings to identify branding issues.
> Touched the first 12 projects, for those that had websites, 4 were not
> within branding requirements.
> 
> I'm not sure if other scan give a hand here on contacting podlings, but I
> went through Airflow -> Fineract, and contacted Airflow, Atlas, Beam and
> Blur.  Otherwise I'll continue to churn through contacting projects.
> 
> John
> 

Thanks for the good work!  Please do report back - here or to
trademarks@ - about your progress and how PPMCs respond.

In particular, any feedback on our published policies/guidelines is very
important.  As we scale, we need to ensure that most podlings can figure
out the right thing to do from the docs, and not as much from direct
pushes by our volunteer mentors and IPMC folks.

Separately, a long-term project of mine is to ensure the branding bits
on the incubator site are clear and point to the right parts of the
formal trademark policies here:

  http://www.apache.org/foundation/marks/resources

- Shane

-
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

[Shane Curcuru]

John D. Ament wrote on 6/29/16 9:21 AM:
> On Wed, Jun 29, 2016 at 9:18 AM Justin Mclean 
> wrote:
> 
>> Hi,
>>
>>> The presence of the word "incubator" in the URL is deliberate: it alerts
>> users
>>> that a podling is incubating.  I'd feel better about this proposal if
>> podlings
>>> weren't so successful about concealing their incubation status[1][2].
>>>
>>> -0, since the Incubator remains unserious about incubation disclaimers on
>>> websites.

I agree the IPMC as a whole needs to take ensuring that podlings are
properly branding their status seriously - in particular, to provide
better oversight, regular reminders to podling communities as needed,
and direct action (or raising to board@) if podlings don't pay
attention.  I also understand historically it's been hard to organize
getting this done.

I personally don't want to weigh in on the URL.  I can see the large
hassle it is for changing various references when graduation comes
around.  I like having it there as a reminder; but what's far more
important is if the overall appearance of the website clearly shows the
incubation status - rather than just the URL.

>>
>> Perhaps a solution to this it's a require poddlings to be serous about
>> this when they make a release? i.e. vote -1 if the incubating disclaimer is
>> not clear on a poddling site.
>>

Nice.  Any way there can be a simple check for people reviewing process
steps is helpful.  And yes, if the podling doesn't have an appropriate
website, then you should vote -1 on the release.  Podlings can wait the
couple of days it takes to fix their website.

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

I definitely like all the ideas focused on better explaining and better
defining what the specific policies are.  In particular, requiring the
incubator logo and a more prominent "under incubation" disclaimer are
things I very much welcome.

- Shane

> 
> John
> 
> 
>>
>> (And I would be willing to vote that way on releases if this vote passes)
>>
>> Thanks,
>> Justin


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

Re: [DISCUSS] Pirk Incubation Proposal

[Shane Curcuru]

Certainly sounds like an interesting project.  One thing to think about
will be ensuring you can find sufficent datasets and testsets under
appropriate licenses so any project participant can run tests against a
realistic scenario.

Joe Witt wrote on 6/7/16 11:25 AM:
> Benjamin,
> 
> The correct way to refer to any Apache project is 'Apache Foo'

True, but in practice - especially outside the project - it is  often
shortened to drop the Apache.  That's fine in some cases; unfortunately
for some very popular projects it happens so often it's a serious
problem.  We have a basic guide that needs more review:

  http://www.apache.org/foundation/marks/guide

> 
> I look forward to hearing people say 'Apache Pirk'.  Now matter now
> many times I try to say that quickly it sounds good.
> 
> Was there any other concern about the naming other than transposition
> of characters?

Oddly, my first thought was in an English accent and I heard "Birk",
which is not necessarily a polite thing.

In any case, it's up to the PPMC of the podling itself (presuming it
gets started here) to choose it's own name.  Everyone else here is just
making suggestions, it's up to the people doing the work to decide
(modulo being an acceptable PODLINGNAMESEARCH, when the time comes).

- Shane
> 
> Thanks
> Joe
> 
> On Tue, Jun 7, 2016 at 11:21 AM, Benjamin Young  wrote:
>> Say it 100 times real fast to someone over a low-grade cell connection. Type 
>> it 50 times as fast as you can without looking at the screen. Or just swap 
>> the middle two letters...
>>
>> Mostly, if there's a chance it will be heard, read, or typed incorrectly it 
>> should--if it can--be avoided. This one just seems too easy to get wrong.
>>
>> Hope that helps!
>> Benjamin
>>
>> -Original Message-
>> From: Joe Witt [mailto:joe.w...@gmail.com]
>> Sent: Tuesday, June 7, 2016 11:15 AM
>> To: general@incubator.apache.org
>> Subject: Re: [DISCUSS] Pirk Incubation Proposal
>>
>> Benjamin,
>>
>> Definitely good to get solid discussion going on naming early.
>> Curious to understand more of your perspective on what could be potentially 
>> offensive about Pirk.
>>
>> Thanks
>> Joe
>>
>> On Tue, Jun 7, 2016 at 10:50 AM, Benjamin Young  
>> wrote:
>>> Looks like a great project!
>>>
>>> I'd like to propose (early!) that you consider changing the name from Pirk, 
>>> however. It's too close to things that could easily be offensive or 
>>> misunderstood.
>>>
>>> My personal recommendation would be "Piranha"
>>>
>>> http://www.morewords.com/ has several more options if you search for `pir*` 
>>> or `*pir` or even `*pir*`.
>>>
>>> Beyond that, it looks like you're off to a great start!
>>>
>>> Cheers,
>>> Benjamin
>>>
>>> -Original Message-
>>> From: Ellison Anne Williams [mailto:eawilliamsp...@gmail.com]
>>> Sent: Tuesday, June 7, 2016 9:02 AM
>>> To: general@incubator.apache.org
>>> Subject: [DISCUSS] Pirk Incubation Proposal
>>>
>>> Hi All,
>>>
>>>
>>> We would like to discuss the proposal of a new project to the incubator - 
>>> Pirk.
>>>
>>>
>>> Pirk is a framework for scalable Private Information Retrieval (PIR).
>>>
>>>
>>> The proposal is contained below and can also be found on the wiki at
>>> https://wiki.apache.org/incubator/PirkProposal
>>>
>>>
>>> Looking forward to the discussion -
>>>
>>>
>>> Thanks!
>>>
>>>
>>> Ellison Anne
>>>
>>>
>>> 
>>>
>>>
>>> = Pirk Proposal =
>>>
>>> == Abstract ==
>>> Pirk is a framework for scalable Private Information Retrieval (PIR).
>>>
>>> == Proposal ==
>>>
>>> Pirk is a software framework for scalable Private Information Retrieval and 
>>> is meant to provide a landing place for robust, scalable, and practical 
>>> implementations of PIR algorithms. The initial scalable PIR algorithms of 
>>> Pirk were developed at the National Security Agency.
>>>
>>> == Background ==
>>>
>>> Private Information Retrieval (PIR) is an area of computer science and 
>>> mathematics that enables a user/entity to privately and securely obtain 
>>> information from a dataset, to which they have been granted access, without 
>>> revealing, to the dataset owner or to an observer, any information 
>>> regarding the questions asked or the results obtained. Employing 
>>> homomorphic encryption techniques, PIR enables datasets to remain resident 
>>> in their native locations while giving the ability to query the datasets 
>>> with sensitive terms.
>>>
>>> == Rationale ==
>>>
>>> Although PIR has been in existence for over twenty years, it has largely 
>>> remained an academic discipline with very little robust or scalable 
>>> implementation. Pirk not only provides implementations of novel scalable 
>>> PIR algorithms, but it provides a framework into which robust, scalable, 
>>> and practical PIR may be developed.
>>>
>>> Pirk fits well within the Apache Software Foundation (ASF) family as it 
>>> depends on numerous ASF projects and integrates with several others such as 
>>> Hadoop 

Re: What committers need to know about IP hygiene

[Shane Curcuru]

Jignesh Patel wrote on 6/1/16 6:42 PM:
> Thanks Julian!
> 
> This is very helpful and I’d like to suggest a perhaps having a good
> “default” policy in place that all incubators inherit on inception.
> They may choose to change the default if needed, but this approach
> installs some rail guards in place right away.

I would love to see the IPMC have an easy-to-understand set of default
project bylaws/procedures that are offered to each new podling to
consider for their use.  Not a requirement, but for some projects it
would really help to both get started and to have a better edited set of
these guidelines (that our projects have probably re-created dozens of
times by now).

> 
> As you and Roman have suggested, the Spark guidelines are crisp and a
> great start. Perhaps we could (with the permission of the Spark PMC)
> generalize that and make that the default for all incubators? I’m
> willing to help on that front as we need a crisp policy for
> Quickstep.

While it's polite to ask, it's not required to get permission -
everything is under the Apache license.  8-)

It's certainly a good idea to ask, because that might spur more folks to
collaborate on a really solid IPMC-suggested version.

> Apologies in advance if this suggestion blows against some well
> established principle. This is all new and a learning opportunity for
> all of us in the recently incubated Quickstep project.

No, this is just a good idea long overdue for coordinated action.
Obviously, not every podling will use all the guidelines, and
occasionally podlings come in from existing communities who might have
their own well-understood rules already.  The ASF requires a certain set
of minimum rules (voting, CLAs, IP provenance, branding, etc.) but
beyond that it's up to each group.

> Cheers,
> Jignesh 
> 
> 
>> On Jun 1, 2016, at 3:03 PM, Julian Hyde  wrote:
>>
>> A couple of projects I am mentoring have raised very similar questions 
>> recently:
>> * Do contributions via github PRs require a CLA?
>> * Do PRs require a JIRA case?
>>
>> I know the answers to these questions, but I was unable to find them clearly 
>> documented. All committers, including those in podlings, need to be very 
>> clear on IP policy. I looked in the Committers’ FAQ[1] and Guide for New 
>> Committers[2] but neither of them explicitly answered the questions. 
>> Searching for answers, I found legal JIRAs [3], [4] but we can’t expect all 
>> committers to find these.

I applaud the care and thoughtfulness you used to bring this issue up,
and completely agree with you.  Nice research too!

- Shane

>>
>> Now, maybe the answer is “Every project must write its own set of committer 
>> guidelines.” But if so, we as the IPMC should be helping podlings do that.
>>
>> Julian
>>
>> [1] http://www.apache.org/dev/committers.html 
>> 
>>
>> [2] http://www.apache.org/dev/new-committers-guide.html 
>> 
>>
>> [3] https://issues.apache.org/jira/browse/LEGAL-156 
>> 
>>
>> [4] https://issues.apache.org/jira/browse/LEGAL-249 
>> 
> 
> 
> -
> 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] Accept Pony Mail into the Apache Incubator

[Shane Curcuru]

+1 (binding)

Daniel Gruno wrote on 5/24/16 1:56 AM:
> Since it seems the discussion has died down, I am now calling a vote on
> accepting Pony Mail into the Incubator. Sorry in advance for potato.
> 
> This vote will run for the usual 72 hours.
> 
> ### PROPOSAL BELOW ###
> 
> Abstract
> 
> Pony Mail is a mail-archiving, archive viewing, and interaction service,
> that can be integrated with many email platforms.
...

> Affiliations
> 
> Daniel Gruno - Quenda IvS
> Tony Stevenson - pctony ltd, VocalIQ Ltd
> Richard Bowen - Redhat, inc.
> Ulises Beresi - Datastax, inc.
> David P Kendal - Quenda IvS
> Francesco Chicchiriccò - Tirasa S.r.l.
> Sam Ruby - IBM
> Shane Curcuru - IBM(?)
> Jim Jagielski - Capital One

Please note I will (very, very soon) be independent, as my last day with
$Employer is Tuesday, so we should take off my affiliation.

Thanks,
- Shane

-
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

[Shane Curcuru]

Gino Bustelo wrote on 5/19/16 12:30 PM:
...
> In Toree we have an LGPL dependency that is not a simple rip an replace.
> The library is JeroMQ and it is a JVM binding to 0MQ. This is THE protocol
> layer used in Jupyter between clients and kernels (Toree serves as a
> Jupyter kernel). Over the past months, we've worked with the JeroMQ
> community to help move along a license change to MPL v2 (
> https://github.com/zeromq/jeromq/issues/327). The progress showed huge
> promised at the start and we are down to 3 committers out of 31 who have
> not responded. The JeroMQ community is moving towards code remediation.

If LGPL code is included either in your source tree or in your existing
release(s), why isn't that reflected in a top-level LICENSE and NOTICE
file?

>From reading the homepage of the website and quickly browsing the source
tree, the only reference is in DISCLAIMER, which is awfully small.  It
wasn't obvious to me besides that tiny bit that you include some LGPL code.

Or am I missing how this dependency works?

Yes, I agree that incubation is a process, and there is great progress
both here and in the other project towards an Apache-license-harmonious
outcome.  But we need to be very careful that end-users have a
crystal-clear understanding that there is copyleft style licenses in
releases or dependencies of anything at Apache.

- Shane


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

Re: The new project site is up!

[Shane Curcuru]

(Please note mix of public/private lists)

Daniel Ruggeri wrote on 5/17/16 7:48 AM:
> On 5/16/2016 8:57 PM, Mike Jumper wrote:
 Also, I've been beaten into submission... erm, I mean... TRAINED to look
 for trademarks. I haven't dug through the archives yet to know if this
 was discussed, but registration (tradema...@apache.org) and including
 the TM in prominent places on the site (particularly the home page and
 downloads pages) are things to keep in mind as goals once graduation
 from Incubator occurs.

>> If we don't need to wait for TLP status to request registration of
>> "Guacamole" as an ASF trademark, I'd be glad to get that process
>> going. Is this the case?

In general, we do not expend funds for registrations for podlings until
they graduate to TLP.  As a public charity that relies on
sponsors/donors, we need to be careful with legal expenses.

The fact that the PPMC is already thinking about this and has some nice
consistent logos is great, so don't let that discourage you!

I recommend reviewing the PMC branding requirements, and putting TM on
first/most prominent uses of the name and logos, etc., so you can get a
head start on the details:

  http://www.apache.org/foundation/marks/pmcs

The PPMC should make sure to submit a PODLINGNAMESEARCH as per this:

  http://www.apache.org/foundation/marks/naming.html

If you're still excited about branding while you're building community
(which I love to hear!) then you can start making a request to register
your future project name by following this:

  http://www.apache.org/foundation/marks/register#register

Do let me know if 1) any of these procedures aren't clear, and 2) if
there's a better way to ensure that other incubator podlings know about
them.  I never have the time to delve into incubator documentation, but
I know there are still some improvements to make there in terms of
clearly referencing the right docs.

Thanks,
- Shane
>>
>> Logos as well? We currently have three:
>>
>> 1) The detailed full-color guac bowl (currently used as the page favicon)
>> 2) The low-detail tri-color guac bowl (the logo used on the homepage,
>> within the web application, and just about everywhere else)
>> 3) A monochrome version of the same low-detail logo
> 
> This is a good question (that I can't answer without making stuff up) so
> I've added the trademarks@ address to see if that's a thing that can be
> kicked off right now. I've also added general@ for awareness/sage wisdom.
> 


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

Re: Throwing my hat in the ring

[Shane Curcuru]

drugg...@primary.net wrote on 5/14/16 8:18 PM:
> Hi, all;
> I've been having a lot of great F2F talks the past few days at the con
> and Marvin has talked me into throwing my hat in the ring to help with
> the incubator project. So, yeah - I'm game to help where I can (and by
> sending this email, it kinda forces me to follow through).

Big +1 for Daniel, great interaction, good ideas, and I love his
Lightning Talks at #ApacheCon.

- Shane

> 
> AIUI, I'm able to be an informal mentor for any podlings of interest
> (hey, there Guacamole!) so I'll just kinda poke around with that for a
> while, but I'll also keep an eye out here for other stuff that comes up.
> 
> I've been soaking up documentation while airport hopping to get a better
> idea of what goes on and what I can do specifically, but unfortunately
> haven't had a chance to read the archives for this list.
> 
> -- 
> Daniel Ruggeri


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

Re: In-flight release in Incubator

[Shane Curcuru]

Chris Riccomini wrote on 5/5/16 6:26 PM:
> Hey all,
> 
> Airflow was in the middle of a release prior to joining Apache Incubator,
> and had several RCs out. The release has already been delayed by several
> weeks due to bugs we've discovered. We don't want to tie this release to
> the full-blown Apache release cycle, since we're not yet ready to tick off
> all the boxes there. Is it possible for us to finish off our prior release
> outside of Apache (i.e. tag it in Git, and put a package in PyPI)?
> 
> Cheers,
> Chris

I don't see why not.  Just don't call it an Apache project or release -
call it whatever you used to call it, using whatever release platform
the project used in the past.

You can certainly email the dev@ list noting the release, just clearly
noting that it's a release outside of Apache.

All the code is open source licensed, so people are free to use it as
they wish, just not using "Apache" with it (yet).

- Shane


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

Re: Preferred name for package distributions

[Shane Curcuru]

(bcc: trademarks@ so we can document recommendation at stable URL)

Thanks for the commentary and excellent pulling together of different
information on this question!

The details of trademarks are more applicable to project homepages,
download pages, and the info or about blurbs that various global package
listings provide.  I.e. when a human comes to learn about your FOO code,
they should see Apache FOO first and clearly understand it's an Apache
project.  The details of the actual filename software blob they then get
is less important.

My rule of thumb:

- If the package manager has clear standards that are widely used for
org-product or product naming styles, follow that, whatever it is.

- Otherwise, we prefer apache-foo naming style.

Make sense?  It's always useful to include the Apache, but it's more
important for software filenames to follow the expected convention in
that particular universe.

- Shane

Anthony Baker wrote on 4/26/16 1:30 AM:
> In a recent thread on the dev@geode list [1] the subject of naming for
> package manager distributions came up, specifically around a Homebrew
> formula [2] for Apache Geode.  Does the ASF provide a recommendation on the
> preferred format when a project name is used in a technical context?  That
> is, should we prefer:
> 
> $ brew install apache-FOO
> $ apt-get install apache-FOO
> $ yum install apache-FOO
> 
> OR
> 
> $ brew install FOO
> $ apt-get install FOO
> $ yum install FOO
> 
> I reviewed the branding requirements [3] and found a really great thread
> [4] on a related subject but not see a clear recommendation.
> 
> My observations [5]:
> 
> 1) In the case of Homebrew, there are 57 Apache formula with only 6 using
> the apache-FOO naming format (there are two others that are aliased to
> support both forms).
> 2) Fedora / RHEL / ContOS use apache-FOO.
> 3) Ubuntu / Debian use FOO.
> 
> Should this be left to the discretion of the package distributions and/or
> package maintainers?
> 
> Any pointers to previous discussions would be greatly appreciated.
> 
> Thanks,
> Anthony
> 
> [1]
> http://mail-archives.apache.org/mod_mbox/incubator-geode-dev/201604.mbox/%3c09f50a34-461b-4a56-81ca-c253d2a1f...@pivotal.io%3e
> [2] https://github.com/Homebrew/homebrew-core/blob/master/Formula/geode.rb
> [3] http://www.apache.org/foundation/marks/pmcs.html
> [4]
> http://mail-archives.apache.org/mod_mbox/incubator-general/201508.mbox/%3cCA+nPnMzLdtm=-mjzhy5yxeql564so2xaktb9gh7tvdearb3...@mail.gmail.com%3e
> [5] https://pkgs.org/search/apache-
> 


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

Re: [LAZY] Simplify Champion role

[Shane Curcuru]

Marvin Humphrey wrote on 3/31/16 10:44 AM:
> On Tue, Mar 29, 2016 at 3:54 AM, Bertrand Delacretaz
>  wrote:
> 
>> As for the patch I suggest a slightly expanded definition of Champion,
>> "A Member of the Apache Software Foundation who supports a Candidate's
>> application for Incubation and acts as a liaison between the incoming
>> podling and the Incubator in the early stages of incubation".
>>
>> Apart from that I agree that the 2012 clarification of the Champion
>> role does not make sense anymore, due to other (good) changes that
>> happened in the meantime.
> 
> Thanks, Bertrand!
> 
> Here's an updated version of the patch simplifying the Champion role,
> as discussed in another thread[1].
> 
>   https://paste.apache.org/KvMQ

+1.  The only concern is that we don't want to see lazy champions or
mentors, so while this specific patch is fine, we will still need to
ensure we find active mentors who get up and go when helping their podlings.

Should we start a mentor exercise program or the like?

8-)

- Shane
> 
> If no one formally lodges a -1, I will claim lazy consensus after 72
> hours and apply.
> 
> Marvin Humphrey
> 
> [1] https://s.apache.org/GDhG
> 
> -
> 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: Policy should be simple (was "Allowed Champions on podlings")

[Shane Curcuru]

Roman Shaposhnik wrote on 3/22/16 4:56 PM:
> On Tue, Mar 22, 2016 at 1:18 PM, Julian Hyde  wrote:
>> If you want to simplify policy, get rid of the champion.
>> Or rather, reduce the champion’s role to nominating a project for incubation.
>> Once the project has entered incubation, the champion’s role ends.
> 
> +1000 to the above. With all of my experience getting projects through the
> incubation I couldn't find a single instance where a Champion role would
> prove to be really valuable ON TOP of active mentor(s).

With the most important point in this entire thread being "active
mentors".  No parenthesis around the (s), I mean multiple mentors who
are truly engaged with the podling, actively assisting, and ensuring
that they review the quarterly podling reports going to the IPMC (and
then to the board).

If having some ASF Member or the like get the title "Champion" is shown
to help ensure we have active mentors, then we need to keep it.  If
that's not true, then I agree: needless complication.

A secondary concern (from reading board reports over the years) is
ensuring that enough mentors on each podling *truly* get the Apache Way,
so that we know a podling going towards graduation really is ready, and
that we have multiple inputs to that evaluation.

Overall, Incubator continues to improve, both with activity and clarity
of process, which is awesome.  8-)

- Shane

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

Re: Hosting links to pre-Apache releases

[Shane Curcuru]

Frank McQuillan wrote on 3/14/16 6:49 PM:
> Good day,
> 
> We have moved the Apache MADlib (incubating) web site to ASF infra at
> http://madlib.incubator.apache.org/
> 
> However there is remaining a download page for pre-ASF releases on the old
> infra at
> http://madlib.net/download/
> 
> Is it OK and appropriate to move the http://madlib.net/download/ download
> page to http://madlib.incubator.apache.org/ as well, as long as we clearly
> indicate that the artifacts are pre-ASF?
> 
> Thanks in advance,
> Frank
> 
Sounds appropriate to me.  Ensure people know they're not ASF releases,
but are from the earlier organization (i.e. whoever is donating the
project), and be crystal clear if the license is different than the
Apache license.

Note we probably don't want to host the actual downloads themselves;
just point to the existing old download page.  Including links to
previous releases can be important and useful information for users who
might want to see history or get old code.

Also, for perspective as to some other ways that it's OK to link to
other corporate pages, see these best practices:

  http://www.apache.org/foundation/marks/linking

- Shane



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

Re: Making license adjustment tools publicly available

[Shane Curcuru]

Christopher wrote on 2/4/16 7:25 PM:
> It might be relevant that that both of those tools appear to be licensed
> under ASL 2.0, which explicitly permits redistribution (presumably outside
> the private area?). I would think it confusing to have an open source
> license on software which is expected to remain private, or otherwise
> restricted from redistribution. As such, it seems prudent to move them to a
> more appropriate area. That's my opinion, anyway.

Yes, the Apache license explicitly gives broad permissions.  But the ASF
organizationally is very conservative about actually redistributing
software.  That is, we *could* legally redistribute some random software
we found under AL or MIT or the like, but if someone makes it clear they
*didn't* intend to submit it to an Apache project, then we'll generally
respect their wishes.

In this case, it's all work done by ASF Committers for the purpose of
doing work on Apache projects, so I can't see why it would be a problem.
 It's most likely that once Apache projects finished updating to 2.0
license, no-one bothered to think of these tools again.

In any case, I would definitely recommend either testing them, or
putting in behavior so that it doesn't actually change files in the
default command line (to prevent surprises, if it doesn't work as
someone anticipated).

- Shane

> 
> On Thu, Feb 4, 2016 at 7:14 PM Roman Shaposhnik  wrote:
> 
>> Hi!
>>
>> a podling recently asked me why:
>> https://svn.apache.org/repos/private/committers/relicense/
>> https://svn.apache.org/repos/private/committers/tools/copy2license.pl
>> are only available to commiters. I see
>> no reason why, but of course I'm appreciative
>> of the warning here:
>> https://svn.apache.org/repos/private/committers/README
>>
>> Two questions:
>>1. Is there any disagreement that making this tool publically
>> available would be a 'good thing' ?
>> 2. Who should bless the svn mv if we all agree?
>>
>> Thanks,
>> Roman.
>>
> 


-
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

[Shane Curcuru]

Alex has it right, and it's important to remember that the ASF never
asks for copyright assignment of code; we only ask for an SGA grant or a
voluntary submission from a contributor of ICLA signer.  We only want a
license to be able to ship the eventual Apache project under the Apache
License v2.0.

The details on Apache source header policy, for posterity:

  http://www.apache.org/legal/src-headers.html

- Shane

Alex Harui wrote on 1/15/16 11:32 AM:
> 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"  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"  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  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"  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: Milagro trademark

[Shane Curcuru]

Alex Harui wrote on 1/16/16 12:59 AM:
> I would recommend asking this on trademarks@a.o.

Correct, someone associated with the podling please gather all the
information and ask what you need there (which is privately archived).

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

Also correct.  Do not try to do both things in one step.  The SGA should
be left as is, and done with the code transfer normally.

Separately, we will need a commitment by the existing trademark holder
(i.e. someone from the legal owner) to execute a standard trademark and
goodwill transfer agreement for any marks intended to be donated, to be
signed before the podling *graduates*.  We're happy to be flexible on
the timing there, because we all want to ensure the podling is healthy
and moving towards graduation first.

- Shane

> 
> -Alex
> 
> On 1/15/16, 5:58 PM, "toki"  wrote:
> 
> 
> 
> 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
>>
>> -
>> 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: [PODLINGNAMESEARCH] Tempo - will there be issues using this name?

[Shane Curcuru]

(note mixed public/private lists)

Thanks.  The ASF has slightly different criteria for a name search than
most software vendors, so this bears discussion.

If someone could forward brief details of the proposed podling, what
company is donating it, and any other name search details to the
privately-archived tradema...@apache.org mailing list then we can look
into it.

In particular, if the donating company is willing to do a more thorough
name search with their counsel and send us the results at
tradema...@apache.org, that is immensely helpful to us as a non-profit.

- Shane

Hadrian Zbarcea wrote on 12/4/15 4:36 PM:
> This is an issue for trademarks actually. For the reason Tony described
> I assume the podling should look for a more suitable name.
> 
> Advice appreciated.
> Hadrian
> 
> On 12/04/2015 03:03 PM, Tony Faustini wrote:
>> Hi all,  as part of the due diligence for the TempoProposal we need to
>> see if the name ’Tempo’ is viable. I did a search of the US Trademark
>> Electronic Search System (TESS) and found 188 live uses of this name
>> as well as a Google Search. The most interesting one that emerged and
>> that is directly related to this technology space was a Chicago based
>> start-up called TempoIQ see
>> https://www.crunchbase.com/organization/tempo#/entity
>> . It would be
>> good to get the Apache Legal team perspective on this. I didn’t do an
>> International search on the name yet but will do so if needed.
>>
>> Thanks
>> -Tony


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

Re: Incubator mail archives lagging badly

[Shane Curcuru]

Mike Percy wrote on 11/20/15 1:55 PM:
> Is the ASF mail archive webapp OSS? I wonder how hard it would be to make a
> couple minor usability improvements.

Of course it is!  It's just an httpd module, actually, which (in theory)
makes install/maintenance really simple, basically pointing it at a
directory of MBOXes.

  http://httpd.apache.org/mod_mbox/

It is, er, a touch crufty, so I imagine that medium term the Ponymail
interface will eventually be used for our official archives (i.e.
permanent and stable URLs) going forward, once there's a plan to get it
installed/maintained.

MarkMail is a good alternative search engine (third party):

  http://apache.markmail.org/

- Shane

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

Re: [DISCUSS] OpenMiracl for Incubation

[Shane Curcuru]

Marvin Humphrey wrote on 11/11/15 12:42 AM:
> On Tue, Nov 10, 2015 at 9:32 PM, Nick Kew  wrote:
> 
>>> The ASF project called OpenMiracl and Certivox/MIRACL continuing to use the
>>> MIRACL mark would seem to muddy the water between the two. Would this not
>>> disadvantage others building something based on OpenMiracl?

Merely adding "Open" to "Miracl" does not really make them separate
brands, so if they both existed as the same kind of functionality, it
would be a clear problem.

>>
>> Isn't it the same distinction as Mesos vs Mesosphere?
> 
> Or, sadly, CouchBase and CouchDB.  Not contesting the name Mesosphere
> was a mistake, just as not contesting CouchBase was a mistake. I hope
> we do not keep making the same mistake.

Indeed, you should not draw conclusions or future actions from
individual past branding questions like those two, nor from how some
Subversion projects by third parties are branded - some of those cases
cited in this thread are... not optimal.

- Shane

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

Re: [DISCUSS] OpenMiracl for Incubation

[Shane Curcuru]

Marvin Humphrey wrote on 11/13/15 9:27 AM:
> Hello, Brian,
> 
> Thanks for collaborating with Nick and bringing this proposal to us!
> 
> On Thu, Nov 12, 2015 at 12:45 PM, Brian Spector
>  wrote:
>> Hi all,
>>
>> among cryptographers in the embedded / IoT space, the 'MIRACL' brand has a
>> lot of household name recognition. Most degreed cryptographers have used it
>> in their research. Code from the open source library is in hardware from
>> Intel, Microsoft, Google, Siemens, Gemalto, etc.
>>
>> When we started the business around the MIRACL library, our intention was
>> always to name the business MIRACL as well. As a small business its easier
>> to managed a branded house vs house of brands.
> 
> This is of course a sensible business plan -- there are many companies who
> have made that choice. However, it happens to introduce complications when
> proposing usage of that brand for an Apache project which must have project
> independence.
> 
>   https://community.apache.org/projectIndependence.html

A key point here is: would other organizations be interested in having
their employees contribute to the project?  Or would other organizations
likely see that your company effectively held the controlling interest
in the new Apache project?

Project independence is about ensuring an Apache project can attract new
contributors from all sources - both individual as well as corporate,
even from corporations who are otherwise competitors with each other.
(Note: corporations don't directly contribute, only individuals do, but
a lot of work is done by software vendor employees).

>> To be clear, we're not looking for the same name as the Apache incubation
>> project as our corporate name, i.e., Apache Miracl vs. Miracl Miracl. We
>> just not sure what to call the incubation project and still inherent the
>> brand recognition of MIRACL and not confuse people.
> 
> There are others around the ASF who are more expert than myself on such
> matters, but it seems to me that the least problematic resolution would be to
> have the Apache project take a name which is not confusingly similar -- a la
> the Adobe-PhoneGap/Apache-Cordova split.  It seems quite unreasonable to ask
> your business to cede the hard-earned value in the MIRACL brand.  And yet
> it's hard to envision a project named Apache OpenMiracl and a company
> named Miracl to co-exist around the same product and benefit simultaneously
> from the same brand equity without marketplace confusion.

The key question - which we're all discussing at the right time! - is
having a project donor making a conscious decision if they want to
donate the brand as well as the code.  It depends on the situation and
the donor organization if you donate the brand as well or not.

The decision is for MIRACL to make.  But I can't see how you could
continue with that as your company name, while having the Apache project
be called OpenMiracl.

Either way is fine - donating the brand, and working on a new corporate
name; or keeping your corporate name, and using Incubation at Apache as
a chance to talk up a new name and excitement for the new open project.

ASF policy is flexible with the brand during Incubation.  The
requirement is that upon graduation to a top level project, the ASF owns
the trademark rights (and any existing registrations) that apply to that
project's brand.  But making name changes during incubation does have an
infrastructure cost, so it's good there's real thought about this during
the proposal stage.

Separately, understanding our Powered By policy is useful:

  http://www.apache.org/foundation/marks/faq/#products

You can use an Apache project name in your own software product, but
only using the "Yoyodyne SuperThing, Powered By Apache Foo" format.

> 
>> The intention is that MIRACL (the company name) sells a supported crypto
>> platform geared to cloud providers called Datacenter Cryptosystem. That's
>> the product name. We'll also run (hopefully one of thousands of) community
>> D-TAs and have dedicated D-TAs for paying customers, as we hope a lot of
>> others will do so, as NTT has committed to.
>>
>> The open source platform for everyone is (at the moment) called OpenMiracl,
>> a cryptosystem for cloud computing.
>>
>> Nick proposed thought this would be a good way to distinguish the open
>> source offering from a closed source offering, we agreed. We're not really
>> bothered with what to call it, we just wanted to make sure it inherited the
>> MIRACL brand in some way.  We've got thousands of crypto developers that
>> have downloaded the MIRACL libraries over the years that we know will be
>> very interested in platform, that was the reasoning behind the naming
>> convention. To preserve the history, essentially.
> 
> Yes, that rationale is understandable.  But we want downstream commercial
> entities such as yours to thrive based on our products!  So if your company
> continues to benefit from the MIRACL brand, while the 

Re: [DISCUSS] Mentor neutrality policy

[Shane Curcuru]

Daniel Gruno wrote on 10/9/15 3:18 PM:
> On 10/09/2015 08:02 PM, Sam Ruby wrote:
>> On Fri, Oct 9, 2015 at 1:25 PM, Bertrand Delacretaz
>>  wrote:
>>> Hi,
>>>
>>> On Fri, Oct 9, 2015 at 5:07 PM, Daniel Gruno  wrote:
 ...Furthermore, I would like to see this extended to votes on graduating or
 retiring podlings,..
>>>
>>> IMO this is where independence is important. We could require that 3
>>> "organizationally independent" IPMC members review each podling before
>>> graduating or retiring. Those people do not need to be project
>>> mentors.
>>
>> I much prefer a formulation of "3 independent" over "no financial
>> ties", and would prefer such a criteria be considered whenever the
>> impulse arises to ensure that NO involved individual has a vested
>> interest.
... snip...

For me, the point is that as a whole organization we truly have the
documented oversight of a sufficient number and variety of Mentors to
provide independent oversight.

The details are indeed tricky to work out.  I personally don't mind if
some mentors casting binding votes are tied to the project (and that
indeed does make for more engaged mentors). But we definitely need some
mentors from other employers or organizations or something to also have
a more robust assurance of an independent view.

- Shane

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

Re: [DISCUSS] Mentor neutrality policy

[Shane Curcuru]

Daniel Gruno wrote on 10/9/15 11:07 AM:
> Hi Incubator folks,
> 
> I would like to propose we adopt a mentor neutrality policy for
> incubating podlings:
> 
> - A mentor must not be financially tied to the project or its incubation
> status.
> - A mentor must not have a vested interest in incubating, graduating or
> dismantling a podling that goes beyond the general Apache mission
> - A mentor must not be affiliated with the entity granting the code
> (company or original project community)
> 
> Furthermore, I would like to see this extended to votes on graduating or
> retiring podlings, so that only people with no organizational (aparty
> from the ASF) or financial ties to the project (or the companies behind
> it) can cast a binding vote on graduation or retirement.
> 
> This would essentially mean:
> 
> - If you work for a company (or are hired as consultant/advisor) that is
> entering a project into incubation, you cannot mentor it nor vote
> for/against its incubation, graduation or retirement.
> - If you are a in the original community behind the project, you cannot
> mentor it nor vote for/against it.
> 
> I believe this would create a neutral mentorship whose sole mission is
> to guide podlings with the interests of the ASF in mind.
> 

This ties directly into the concept of independent project governance:

  http://community.apache.org/projectIndependence.html

It's really hard to feel confident that each of our soon-to-graduate
podlings is truly operating as an independent project in some cases.

Question: has everyone here read that essay?  Does everyone here agree
that project independence as described in general terms there is a
requirement of every TLP?  Do people think that this concept is clear to
every Apache PMC?

The fact that we are the "Switzerland of software" - a vendor-neutral
place where everyone could be comfortable collaborating, and we ensure
all of our governance is truly independent of commercial influence or
the influence of our various employers - is probably the hardest issue
we face in the big picture.  I sometimes wonder if we all are on the
same page with that point.

It's clear that the details of any changes here need discussion, and our
general rule of having at least three mentors (presumably, not all of
whom are at the same employer) goes a long way to helping.

But if you think about conflict of interest laws and procedures in the
world of corporate software - or really, any sort of business - the ASF
is the far outlier in trusting and assuming that we are all individuals
wearing our appropriate Apache hat.  That's a good thing, and it's part
of what makes the ASF special - but we also need to remember that the
rest of the world does not always understand our almost laissez-faire
way of treating everyone as an individual unaffected by their outside
affiliations.

- Shane

> 
> Please do discuss this. If there is (mostly) positive feedback, I would
> like to, at some point, have a vote on including this in the Incubator
> policy. I realize this would cut down on the number of potential
> mentors, and I would ask that more people step up to the challenge of
> mentoring if adopted.
> 
> With regards,
> Daniel
> 
> -
> 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: September 2015 Report

[Shane Curcuru]

On 8/30/15 9:40 AM, John D. Ament wrote:
 I remember asking about public vs private board reporting in the past.  I'm
 curious what you have to report that is private (since the final report
 does become public record).

Correct: board reports become public record when posted, typically the
following month after the board reviews the minutes at their next
meeting.  Note that anything marked private is redacted from the
minutes before posting publicly. /private

For more details of what's expected in TLP project reports (which is
what a podling should be thinking of for the future), and what kinds of
things are marked private, see:

  https://www.apache.org/foundation/board/reporting

- Shane

 
 John
 
 On Sat, Aug 29, 2015 at 2:58 AM jan i j...@apache.org wrote:
 
 Hi.

 I really like our open way of reporting using the wiki but we have a small
 flaw in the procedure.

 The wiki is not the place to report a private/private section, so I
 will send it to private@i.a.o and hope it will  be included.

 rgds
 jan i.


 On 29 August 2015 at 01:00, Marvin Humphrey mar...@apache.org wrote:

 Greetings, {podling} developers!

 This is a reminder that your report is due next Wednesday, September
 2nd.  Details below.

 Best,

 Marvin Humphrey, Report Manager for September, on behalf of the
 Incubator PMC

 ---

 Dear podling,

 This email was sent by an automated system on behalf of the Apache
 Incubator PMC. It is an initial reminder to give you plenty of time to
 prepare your quarterly board report.

 The board meeting is scheduled for Wed, 16 September 2015, 10:30 am
 Pacific.  The report for your podling will form a part of the Incubator
 PMC report. The Incubator PMC requires your report to be submitted 2
 weeks before the board meeting, to allow sufficient time for review and
 submission (Wed, September 2nd).

 Please submit your report with sufficient time to allow the incubator
 PMC, and subsequently board members to review and digest. Again, the
 very latest you should submit your report is 2 weeks prior to the board
 meeting.

 Thanks,

 The Apache Incubator PMC

 Submitting your Report

 --

 Your report should contain the following:

 *   Your project name
 *   A brief description of your project, which assumes no knowledge of
 the project or necessarily of its field
 *   A list of the three most important issues to address in the move
 towards graduation.
 *   Any issues that the Incubator PMC or ASF Board might wish/need to be
 aware of
 *   How has the community developed since the last report
 *   How has the project developed since the last report.

 This should be appended to the Incubator Wiki page at:

 http://wiki.apache.org/incubator/September2015

 Note: This is manually populated. You may need to wait a little before
 this page is created from a template.

 Mentors
 ---

 Mentors should review reports for their project(s) and sign them off on
 the Incubator wiki page. Signing off reports shows that you are
 following the project - projects that are not signed may raise alarms
 for the Incubator PMC.

 Incubator PMC




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

Re: apache binary distributions

[Shane Curcuru]

On 8/28/15 8:53 PM, Dave Fisher wrote:
 Dennis this is now triple posted including one private list. I
 request you no longer contact me directly as I thought I was replying
 privately to our prior conversation and would have moderated some of
 my language. BTW what I wrote has NOTHING to do with the Incubator. I
 am sure the IPMC has zero interest in re-incubating OpenOffice.org.
 
 Trademarks, legal-discuss tell me if the following idea is crazy. You
 can split the thread. Just say which you are replying on.

Which idea?  The original thread was (effectively) about trademark
policy issues relating to developer-related projects being redistributed
by well-known packaging mechanisms, typically in linux distributions.
That is an entirely separate issue from Apache OpenOffice related
branding questions, especially as how they relate to other similar
software providers.

 
 I'll note that this should go to the AOO dev list soon with an
 appropriate formulation as a proposal.

That sounds like a good idea.  If the AOO community and PMC have some
other specific questions about how to write or implement branding
policy, please do bring them up separately.

- Shane

 
 Regards, Dave
 
 Sent from my iPhone
 
 On Aug 28, 2015, at 4:21 PM, Dave Fisher dave2w...@comcast.net wrote:

 Our trademark is abused by LibreOffice.
 
 Change this to misused in Linux distributions.
 
 How do we find a policy where can get Linux distributions near compliance.

 Since LO rebased and declared a new license we can impute how much of that 
 is really AL 2 via a diff. If the LO code is a nominal percent Apache OO 
 then we say it is sufficient to be based on Apache. If they move below 
 that percent then they are no longer compliant.

 To stay compliant they can contribute upstream and help us have a source 
 release that they can remain compliant against.

 Essentially we use the trademark as a honey trap to stay relevant.

 Purity will never happen.

 Anyone that has a distro that is sufficiently close can then get a powered 
 by use of the mark. If we can't do a binary for a platform then we can 
 point users to all of the powered by binaries. The SVN model.

 Sent from my iPhone

 On Aug 28, 2015, at 3:10 PM, Dennis E. Hamilton dennis.hamil...@acm.org 
 wrote:

 [Not cross-posting to a private list.]

 Dave,

 I don't exactly understand what it is expected that trademarks@ would be 
 doing or clarifying with regard to your specific Foo Manchu case.

 Please explain what you mean by a percentage.

 - Dennis

 PS: How do you see a case where the Manchu project makes nothing more than 
 nominative mentions of Foo and Foo is not used at all in the naming of the 
 Manchu product?  Are specific instances of the use of Foo in a manner that 
 would confuse Manchu with Foo what you have in mind for bringing to an 
 Apache Foo PMC?

 PPS: I assume we are talking about something other than how third parties 
 use and attribute ALv2 licensed code one way or another.  I'm not certain 
 how trademark enters there.  There is related discussion on legal-discuss, 
 however.

 -Original Message-
 From: Dave Fisher [mailto:dave2w...@comcast.net] 
 Sent: Friday, August 28, 2015 14:35
 To: general@incubator.apache.org
 Cc: tradema...@apache.org; stephen.alan.conno...@gmail.com
 Subject: Re: apache binary distributions

 Again mixed. Let's substitute a real case.

 Sent from my iPhone

 On Aug 28, 2015, at 6:21 AM, Shane Curcuru a...@shanecurcuru.org wrote:

 (Please note mixed private/public lists)

 On 8/25/15 5:17 PM, Stephen Connolly wrote:
 [ ... ]

 package-name: foo
 description: The Manchu team's packaging based on Apache Foo.
 Apache Foo is a framework for doing bar.
 Apache, Apache Foo and Foo are trademarks of the Apache Software
 Foundation.

 Foo = OpenOffice
 Manchu = LibreOffice

 This is the reality in Linuxland without the attribution. This has been 
 going on for sometime. I think since prior to Oracle's grant.

 Rolling that back should be a goal for the PMC.

 Maybe we diff the codebases and accept a percentage. This standard might 
 the encourage upstream contribution.

 I would like to formulate this idea for the AOO dev list. The above has 
 really helped me crystallize what I've been kicking around in my mind for 
 months and months.

 Thoughts before I take it there?

 I know I'm not following Shane's thoughts below. OpenOffice is uniquely 
 problematic.

 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



-
To unsubscribe, e-mail: general-unsubscr

Re: apache binary distributions

[Shane Curcuru]

(Please note mixed private/public lists)

On 8/25/15 5:17 PM, Stephen Connolly wrote:
 So there is - to my mind - the obvious stuff:
 
 1. The package description should ACK our marks. End of Story there.
 2. The package description should call out those cases where there are
 significant deviations from the official distributions. Significant
 deviations will be determined by the individual PMCs as they know what is
 significant and what is not.
 
 That leaves the technical package name.
 
 Is using our mark in the technical package name (which cannot have space to
 ACK the mark, but assuming there is an ACK of the mark in the description)
 an issue?
 
 So if we have:
 
 package-name: foo
 description: The Manchu team's packaging based on Apache Foo.
   Apache Foo is a framework for doing bar.
   Apache, Apache Foo and Foo are trademarks of the Apache Software
 Foundation.
 
 is the Manchu packaging of Foo ok to use foo as the package name?
 
 It would seem to be a disservice to users to force Manchu to pick a
 different name for Foo (i.e. the firefox vs iceweasel issue)

Correct.  For the ASF's purposes, if it is essentially unmodified
software - or only modified in the normal and well-understood way to
fit into that particular platform or distro - then we want the packager
to use our actual product names.

We definitely should ask for trademark attributions in descriptions or
other well-known places.  The actual implementation and enforcement of
that is a question that depends on the situation.  In many cases, if
it's simple packaging that truly is just doing the right thing from our
perspective, legal attribution probably isn't that big a deal.

In particular, a lot of the importance depends on what a well-informed
consumer would expect from that particular well-known packaging system.
 I.e. if the packager is doing what is normal and expected - even if
that changes some of the software from our product - it's probably fine.

 
 On the other hand, packaging up Apache Foo for the Manchu installer
 framework may require significant patching of Apache Foo such that it is
 necessary to declare that it is *based on Apache Foo*
 
 Compare and contrast with homebrew's packaging of Apache Maven where they
 just download the convenience binary published by the Apache Maven team...
 that seems reasonable to be called `maven` because it is actually
 installing exactly what the Apache Maven team released without
 modifications.
 
 Shane, do you need further clarifications?

Thanks for the excellent distillation of the technical aspects.  This is
definitely a question we need to draft a clear policy for, so that we
can have a consistent way we ask packagers to do things.

Trademark law is well established for consumer products, but less so for
highly technical software products and different ways that the products
are offered to the public.  So I need a clear question to bring to
counsel to get their perspective on what we should cover.

The easiest way to see the applicability of trademarks is to provide a
description of an end-users view of the process.  Could someone here
come up with a description of the process that an end-user would go
through when they're trying to get a specific Apache product using one
of these methods?

I.e. assume you're a developer or sysadmin who is *not* an Apache
committer.  You know you need to get a software project management tool
for the linux machines you maintain, and you've heard of something
called Maven.

- What is the actual process by which you'd find out how to get this
software (i.e. you'd search for it), and how you'd actually install it?

- How would you normally detect if you're getting the original Maven
software, versus some different software - either a different vendor's
version, or perhaps a bogus version with adware in it, or perhaps some
non-standard version that is apparently popular, but is *not* the
default version used on your platform?

* Separately: does anyone have links to any trademark/branding policy
pages that common package managers have out there?  I'm wondering what
policy or best practices that are *clearly documented* is already out
there for the actual linux distros or package management systems is.

Thanks.

- Shane

 
 On 25 August 2015 at 11:52, Roman Shaposhnik ro...@shaposhnik.org wrote:
 
 On Wed, Aug 19, 2015 at 1:46 AM, Stephen Connolly
 stephen.alan.conno...@gmail.com wrote:
 But I am still awaiting guidance from brand on whether a technical name
 usage - e.g. installer package name - is a use of the mark.

 Makes two of us. I see a log of good consensus on this thread which helps
 me get a gut feel on what is the right way to go about enforcing the use
 of the mark. That said, I still would love to read Shane's meditation
 on the matter ;-)

 Thanks,
 Roman.

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

Re: apache binary distributions

[Shane Curcuru]

On 8/16/15 9:05 PM, David Nalley wrote:
 On Sun, Aug 16, 2015 at 3:43 PM, Roman Shaposhnik ro...@shaposhnik.org 
 wrote:
 On Sun, Aug 16, 2015 at 12:33 PM, Ted Dunning ted.dunn...@gmail.com wrote:
 On Sun, Aug 16, 2015 at 12:29 PM, Roman Shaposhnik ro...@shaposhnik.org
 wrote:

 The Hadoop PMC is utterly free to produce a Hadoop RPM with Hadoop in it
 that corresponds to an Apache Hadoop release.  Having project Foo
 produce a
 release of Bar, Baz and Pigdog is pretty far off the reservation,
 however.

 It is. But if they screw up packaging guidelines inadvertently and the
 downstream
 want to take matters in their own hands -- how is it off the reservation?


 The downstream shouldn't be calling their artifacts Hadoop if they aren't
 the Hadoop PMC in any case.

 But they do. And not just hadoop -- go do searches on pkgs.org and see
 for yourself.

 Now that takeaway from this thread for me so far is this: in order for the
 trademark enforcement to be invoked there has to be a legitimate concern
 from the PMC. The foundation is not in a business of blatant brand policing
 (otherwise quite a few CD should've been sent already to various Linux
 distros).

 
 It is the PMC's reponsibility to police their brand. [1] Some projects
 police it very loosely, others much more rigidly. If a project were to
 wish to go the Mozilla route, I am sure they could.  The foundation
 provides projects with nice, generic scaffolding that gives some
 flexibility, but generally just works. The foundation itself rarely
 engages in trademark policing without the PMC requesting help.

That being said, let's be clear since we're on a publicly archived list
here: The ASF owns all Apache trademarks on behalf of our projects.  We
certainly hope - and often only have the volunteer energy for - having
the PMCs take the lead in reporting and attempting to police misuse of
their project's marks.  But if a PMC is truly falling down on the job -
or if a PMC is unfairly allowing one/some companies to take advantage of
their project brand - the ASF can and will enforce our polices at the
Foundation level.

This really is a rare case, but we do need to be clear from the policy
side.  I'm not particularly concerned about less-active projects that
might just let things slide (or not be aware of) or slide into
obscurity.  I am concerned that some PMCs might not take policing
seriously enough when it comes to vendors specifically pushing the
boundaries in ways that harm our Apache wide reputation for project
independence:
  https://community.apache.org/projectIndependence.html

- Shane

 
 
 [1] http://apache.org/foundation/marks/responsibility#responsible
 
 -
 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: What is the legal basis for enforcing release policies at ASF?

[Shane Curcuru]

On 8/16/15 4:25 PM, Roman Shaposhnik wrote:
 On Fri, Aug 14, 2015 at 3:59 PM, Shane Curcuru a...@shanecurcuru.org wrote:
 On 8/7/15 7:53 AM, Niclas Hedhman wrote:
 Bill,
 So I can release Niclas Hadoop platform, based on Apache Hadoop ?? I
 thought the discussion a few years ago was that this was misleading...

 No, you cannot.  See our actual trademark policy:

   https://www.apache.org/foundation/marks/faq/#products

 Our release policy, as Roman originally asked about, applies only to ASF
 projects, and has no bearing on third parties.  However our trademark
 policy, and trademark law, prevents third parties from publicly
 providing software using our trademarks.

 Our operational policies only apply to our projects, just like any other
 corporation.  Some policies, like our license itself and our formal
 trademark policy, inform the rest of the world how they are allowed to
 use our websites, software code, and brands.

 Make sense?
 
 It does, but our relationships with downstream Linux vendors
 (just to take the most obvious example) set a very confusing
 precedent.
 
 Shane, if would be super helpful if you took a look at:
http://pkgs.org/search/hadoop
http://pkgs.org/search/maven
http://pkgs.org/search/subversion
 and pubished your narrative of how the ASF branding
 policies apply in both cases.
 
 The 3 projects I'm picking represent a pretty diverse
 set of cases of how PMCs are conducting themselves.

OK, that will take some time.  It would help if we can setup a call or
get someone to writeup a description of what those pages mean from the
larger perspective:

Trademarks are about preventing consumer confusion as to the source of
goods.  So we need to consider this from the point of view of an
experienced software developer in the general sense - someone who is
*not* an Apache committer and not experienced with our products in
specific, but someone who is an experienced software developer, systems
architect, or devops type who's trying to evaluate a bunch of software
for their company.

The issue is I don't use pkgs.org (I use homebrew, but only for more
end-user applications recently), so I'm trying to translate to the
experience of an actual developer consumer who'd be trying to find and
use these products.

The problem is that trademark analyses are much easier to do for
consumer products, and for physical goods.  Software is inherently
different in that marketing brochures or store signs or packaging is
very different, and widely varied on a whole bunch of web pages.  Plus,
most of our products are highly technical: very few computer end users
are downloading Hadoop or Maven - it's software developers who are
looking for these.  So understanding the common software developer
perspective on how they see *where* these named downloadable software
products are being displayed matters.

- Shane


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

Re: What is the legal basis for enforcing release policies at ASF?

[Shane Curcuru]

On 8/7/15 7:53 AM, Niclas Hedhman wrote:
 Bill,
 So I can release Niclas Hadoop platform, based on Apache Hadoop ?? I
 thought the discussion a few years ago was that this was misleading...

No, you cannot.  See our actual trademark policy:

  https://www.apache.org/foundation/marks/faq/#products

Our release policy, as Roman originally asked about, applies only to ASF
projects, and has no bearing on third parties.  However our trademark
policy, and trademark law, prevents third parties from publicly
providing software using our trademarks.

Our operational policies only apply to our projects, just like any other
corporation.  Some policies, like our license itself and our formal
trademark policy, inform the rest of the world how they are allowed to
use our websites, software code, and brands.

Make sense?

- Shane


 
 
 
 On Fri, Aug 7, 2015 at 12:30 PM, William A Rowe Jr wr...@rowe-clan.net
 wrote:
 
 On Thu, Aug 6, 2015 at 7:50 PM, Roman Shaposhnik ro...@shaposhnik.org
 wrote:

 Hi!

 while answering a question on release policies and ALv2
 I've suddenly realized that I really don't know what is the
 legal basis for enforcing release policies we've got
 documented over here:
http://www.apache.org/dev/release.html

 For example, what would be the legal basis for stopping
 a 3d party from releasing a snapshot of ASF's project
 source tree and claim it to be a release X.Y.Z of said
 project?


 Nothing other than the Trademarks.

 If someone wants to call httpd trunk 3.0.1-GA, they cannot do this as
 Apache httpd 3.0.1-GA or Apache HTTP Server 3.0.1-GA.

 They can certainly release trunk under the AL license and call it Kindred
 Http Server 3.0.1-GA, based on Apache HTTP Server. That is a statement of
 fact and not an abuse of the mark, IMHO. (If it was not actually based on
 Apache HTTP Server, then that would similarly be a Trademark infringement
 as it is a false use of the mark.)

 There are no less than two marks, one is the name of the foundation itself
 in conjunction with Open Source Software, and the other is the specific
 project name.

 
 
 


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

Re: apache binary distributions

[Shane Curcuru]

On 8/6/15 4:29 AM, Jochen Theodorou wrote:
 Am 06.08.2015 08:22, schrieb Niclas Hedhman:
 On Thu, Aug 6, 2015 at 8:43 AM, Roman Shaposhnik ro...@shaposhnik.org
 wrote:

 I honestly see no problem with that, again provided that the artifact
 can
 NOT
 be confused with the one coming from Apache project.

 I think the problem lies in Trademarks. Debian's Tomcat7 is labeled
 Servlet and JSP engine and its Tomcat8 is labeled Apache Tomcat 8 -
 Servlet and JSP engine, yet I don't see Apache Tomcat project
 creating/maintaining a Debian dist.

 Now, is Debian allowed to call it Tomcat? Is it allowed to call Tomcat8
 to BE Apache Tomcat8, when in fact(!) there are changes to the source,
 such as the start script in Debian Tomcat is not original of Apache
 Tomcat,
 but instead follows a Debian template for how those scripts should be
 written. I am not sure what all the changes are, feel free to check;
 http://anonscm.debian.org/cgit/pkg-java/tomcat8.git/tree/debian/patches

 IF (like Mozilla) Apache decides to strike down on Debian and not
 allowing
 it to use the same names, _I_ think it is a disservice to the users
 (IceWeasel browser), but as it stands, Apache trademark licensing
 seems to
 not really be followed (Perhaps Debian has some permission that was
 granted
 long in the past... I may have missed that).
 
 I think there is nothing in the apache license 2 forbidding the usage of
 the project name or even apache (version 1.1 and 1 have been different
 and did indeed require a permission). The trademark weapon is more one
 of last resort. For example to go against false releases with malicious
 code added and the distributor not willing to take it of the web.

Have folks here read the license recently?

6. Trademarks. This License does not grant permission to use the trade
names, trademarks, service marks, or product names of the Licensor,
except as required for reasonable and customary use in describing the
origin of the Work and reproducing the content of the NOTICE file.

  https://www.apache.org/licenses/LICENSE-2.0.html#trademarks

So our license explicitly excludes any Apache trademarks (i.e. APACHE
and the names of all of our projects, among other things) from any of
the other grants the license makes.  Beyond that, trademark law (which
varies in different countries) applies when anyone is using one of our
trademarks in association with a software product or other related
product or service that they provide *publicly*.

Employees in a $BigCo could call an internal release Best Apache Foo,
and we likely couldn't legally do anything about it (although we'd
certainly not be happy about it, and if we found out should ask them to
change it).  But when some other company or individual releases
Something Apache Foo publicly that we can - and should! - complain and
ensure that they're following our published trademark policy:

  https://www.apache.org/foundation/marks/faq/#products

Having specific examples to discuss is a much better idea.  It's very
important both 1) what, specifically, the thing is that's being provided
(download, maven repo, whatever), 2) what an end user would perceive the
branding of that thing to be, and 3) who - what specific person or
organization - is providing that thing.

- Shane





 
 At least I hope no-one has some crazy idea as that ;)
 
 bye blackdrag
 


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

Re: apache binary distributions - Apache policies

[Shane Curcuru]

On 8/9/15 9:37 PM, Roman Shaposhnik wrote:
 On Fri, Aug 7, 2015 at 1:52 PM, Ted Dunning ted.dunn...@gmail.com wrote:

 The question is: do we have ASF-wide trademark guidelines or do
 we allow each PMC to make those as they go.

Um, yes, we do:

  https://www.apache.org/foundation/marks/

Question: raise your hand here (or in a private email to me) if you are
on the IPMC and have never read that page before.  If so, please go read
it.  I'll wait.

.
.
.

Thanks.

Separately: the ASF is a corporation, which has a board and a number of
corporate officers who are empowered by the board to set specific kinds
of ASF-wide policies, which are *required* (if so marked; many are best
practices) of all Apache projects.  If you haven't read the minimal list
of these requirements, I highly recommend it - it's a much simpler read
than the trademark policy [1]:

  https://www.apache.org/dev/project-requirements

These ASF policies are required for our projects (and podlings, so they
can graduate), but obviously we don't have the authority to require
third parties (other companies or people) to follow them.  We can,
however, insist legally that third parties follow our Apache license and
our trademark policy.

- Shane

[1] Apologies for the long-windedness of the trademark policies.  It's
on my I'd really love to list to break it up into simpler chunks.



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

Re: [DISCUSS] Freemarker Incubation proposal

[Shane Curcuru]

On 6/2/15 8:02 PM, Ralph Goers wrote:
 I would proceed with the plan that the project will succeed in
 graduating.

+1.  Focus on the positive, and finding new community contributors.
Trying to incubate while regularly talking about well, if we don't make
it, we're going to leave and do X is not a welcoming feeling.

 Usually project names stay with the ASF. I am not sure what the
 policy would be for a project that failed to graduate. I would
 suspect the project could keep it after leaving.  However, if the
 project fails to graduate the likelihood of it succeeding anywhere
 would be minimal.

The ASF owns all trademarks on behalf of our project communities.  For
top level projects (TLPs), the intent is to keep all trademarks: as a
non-profit public charity, we have a duty to try to keep the reputation
of top level projects for the public good.

For Incubating projects, we explicitly note that they are *not* top
level projects, so the policy is different than for TLPs.  If a podling
community fails to graduate, but is acting in good faith, the ASF would
be happy to arrange any trademark transfers back to the original owners.

We have had case(s) in the past where project donors with notable
trademarks asked for an explicit clause confirming the return of the
trademarks if Incubation fails, which we accepted, so that's OK.

In terms of the code, given that any code under SGA or developed during
incubation will be under the Apache license, of course the previous team
(or anyone else) is welcome to fork at any point.

- Shane

 
 Ralph
 
 On Jun 2, 2015, at 4:42 PM, Daniel Dekany ddek...@freemail.hu wrote:

 That's certainly won't be a problem in reality, as Jacopo said.

 What I'm curious about is if what happens if Freemarker gets into the
 Incubator but then sadly later fails to graduate, so then it has to
 continue outside ASF, probably with the earlier owners. I guess then
 we will have to fork the work done during incubation (or can that be
 given back with some kind of SLG?), which is messy (complicates the
 license permanently, right?), but doable. But we will need to get the
 product name back too! Is that promised formally somewhere, or how
 does that go? Well, let's hope no such thing will happen, but still, I
 should know this.

 -- 
 Thanks,
 Daniel Dekany


 Thursday, May 28, 2015, 11:39:17 AM, Bertrand Delacretaz wrote:

 Hi,

 On Thursday, May 28, 2015, Jacopo Cappellato jacopo.cappell...@gmail.com
 wrote:

 ...Should we move to the next step (that I think is starting a vote)?...


 I think so, with two comments:

 Having just two committers is very small but that can hopefully be solved
 during incubation.

 The proposal does not mention how the Freemarker name/trademark donation
 will be handled, if the copyright owners also own the name that won't be a
 problem. And anyway that can be solved during incubation, but if you can
 make sure before entering incubation that the name can be donated that's
 easier.

 -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
 


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

Re: [DRAFT] May 2015 Board Report

[Shane Curcuru]

On 5/15/15 11:51 AM, John D. Ament wrote:
 On Fri, May 15, 2015 at 11:20 AM Marvin Humphrey mar...@rectangular.com
 wrote:
...
 I am encouraged by increasing feedback on the draft report.  I would be
 further encouraged if more people took it to the next level and fixed the
 problems they see!

 
 Here here.  Let's hope we get more people contributing to the report going
 forward.  With all these new members, plenty of room for new shepherds and
 report contributors.  These things always become a bear, and just so
 happens  a release date of mine slipped and overlapped with the board
 report this time around.
...

Thanks to all the IPMC members and podling committers for doing all the
work on writing, reviewing, and posting Incubator reports!  The IPMC
reporting has continued to improve in the past few years with each of
our recent IPMC chairs.  Nice stuff.

If new folks who have some ruby experience are interested, the Apache
Whimsy pTLP is likely to be created soon, and it would be really sweet
if the Whimsy board report tool had a custom Incubator report section.
Imagine how cool it would be if mentors/shepherds could use the board
director commenting/approving tools in Whimsy wihin the Incubator report...

  https://whimsy.apache.org/board/agenda/

- Shane


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

Re: [DISCUSS] Whimsy PMC

[Shane Curcuru]

On 4/27/15 10:05 PM, Greg Stein wrote:
 On Mon, Apr 27, 2015 at 8:51 PM, Ross Gardler (MS OPEN TECH) 
 ross.gard...@microsoft.com wrote:
 
 It's a tough one. We could be setting a precedence here that we absolutely
 do not want to set. On the other hand, it's problematic (not to mention
 simply ridiculous) if the foundation not being able to use Apache software
 because we don't pay for development and might want to submit a patch
 upstream.

 As long as all committers are equal and earn their merit in the
 traditional way I don't see a problem from the projects side. IN this
 instance the ASF is just another contributor to the project.

 This means the foundation never pays for development to something like
 the foundation never pays for development except where the modification is
 made as part of our normal infrastructure operations. On these rare
 occasions the foundation is just another employer and the contributor is
 just another community member. Changes are contributed upstream through the
 normal contribution process. There is no special role for ASF infra
 contractors.

Yes, that's a separate and important point.  Every project PMC
determines merit for their project independently.  Just because someone
is root@ does not mean they get a free committer bit on project X or
binding votes - unless that PMC votes them in.


 
 The ASF pays for Infra contractors. Their job/role is to maintain our
 systems. Sometimes their duty *may* be to contribute software to $Project
 (wherever that may be).

It's pretty simple.  Infra contractors are responsible to code/maintain
software and systems that the ASF needs to operate, including a variety
of services that we provide to our projects.  Their duty is to build
stuff the ASF needs for our own operations.

It doesn't matter where that code goes; Whimsy is no more special than
STeVe is for that matter.

 That is *very* distinct from paying a person to contribute directly to
 $ASFProject.

Exactly.  The ASF does not pay infra contractors to write code for
anyone else - only for our own organization's needs.  Luckily, some of
those needs require software that may also be useful for the rest of the
world - but our own needs are what we do paid work for.

I don't see this being a problem.  8-)

- Shane

 
 Cheers,
 -g
 


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

Re: [DISCUSS] Whimsy PMC

[Shane Curcuru]

On 4/23/15 5:41 PM, Ross Gardler (MS OPEN TECH) wrote:
 Infra already  supports Whimsy so having a TLP is irrelevant in that
 respect (although on reason Sam is doing this is because infra
 expressed a concern about maintaining a service that only had Sam
 working on it).

To be clear: is the current whimsy.apache.org with a variety of board
agenda, email lookup, etc. services a formally infra-supported service?
 Just curious.  I would lobby that it should be formally supported at a
normal level (i.e. it's not critical level like email/svn is).
(Apologies if we already formally talked about this)

The service is separate from the TLP status.  We run the service to help
our own project operations, which we'll do in any case.  The presumed
pTLP would be to develop the code; I could easily imagine some of the
code being useful as examples outside of the ASF.  Being a pTLP would
also make development easier for newcomers, since code/mailinglists/etc.
would all be normalized with other projects.

I'm +1 and will join.

- Shane

 
 Ross
 
 -Original Message-
 From: jan i [mailto:j...@apache.org] 
 Sent: Thursday, April 23, 2015 2:32 PM
 To: general@incubator.apache.org
 Subject: Re: [DISCUSS] Whimsy PMC
 
 On Thursday, April 23, 2015, Sam Ruby ru...@intertwingly.net wrote:
 
 Initial sketch placed on the wiki:

 https://wiki.apache.org/incubator/WhimsyProposal

 Anyone who is so inclined is welcome to edit the proposal directly.

 No urgency or timeframe in mind (other than preferably starting 
 sometime in 2015ish).  My current thinking is to follow in Steve's 
 footprints and go directly to TLP, but I'm starting a discussion here 
 (in Incubator) to see if there are any other thoughts on the matter.
 
 I like the proposal, it is very clear, I do miss one bit though.
 
 If this becomes a TLP project is infra then prepared to support keeping 
 whimsy running 24/7, or do they have additional requirements on the project?
 
 maybe the response to the above could be worked into the proposal.
 
 rgds
 jan i
 

 - Sam Ruby

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


 
 --
 Sent from My iPad, sorry for any misspellings.
 
 -
 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: [GROOVY] mailing lists are ready, see you there!

[Shane Curcuru]

This is obviously a question for the new podling's PPMC and the existing
Groovy community mailing lists to decide, but in most other situations
auto-subscribing people to a new list is usually a bad idea.

I would definitely give people plenty of notice and clear instructions
on how to unsubscribe before blindly moving subscriber lists from
anywhere else to an Apache mailing list.  Even better would be some way
that people could explicitly opt-in to the new list by signing up
somewhere (i.e. somewhere simpler than the ezmlm send subscribe mail,
reply to the reply confirmation dance), and not auto-subscribing.

But that's just my opinion.

- Shane


On 3/27/15 2:25 AM, Paul King wrote:
 
 Only users from the previous list will be added and there was an
 assumption that all code/patches sent to that list would be Apache
 licensed by default. So, not quite the same thing but as long as we warn
 people and tell them how to unsubscribe, I think auto subscribing them
 would be OK?
 
 Cheers, Paul.
 
 On 27/03/2015 8:21 AM, Andy Seaborne wrote:
 Signing up to Apache list means the user is making an explicit act of
 joining a place where code (or pointers to code) sent is granted to
 Apache.

 Implicit subscription muddies the waters for contributions.

  Andy

 On 26/03/15 21:55, Ted Dunning wrote:
 your loop is a fine solution.  Just test it carefully ahead of time.



 On Thu, Mar 26, 2015 at 2:44 PM, Konstantin Boudnik c...@apache.org
 wrote:

 I think you can write a script to do a call to
  echo subscribe | mailx -s subscribe dev-subscribe-john=
 host.dom...@groovy.incubator.apache.org
 via the list of current list subscribers.

 Or perhaps open a INFRA ticket and provide them with the list of emails
 addresses to be subscribed.

 There might be another way that I am unaware about though. Anyone?

 Cos

 On Thu, Mar 26, 2015 at 09:54PM, Guillaume Laforge wrote:
 And how to add in batch the current subscribers of the old list.

 2015-03-26 21:29 GMT+01:00 Cédric Champeau
 cedric.champ...@gmail.com:

 BTW should we already update the links [1] on the website? How should
 we
 proceed to migrate/deprecate the Codehaus lists?

 [1] http://groovy-lang.org/mailing-lists.html

 2015-03-26 20:34 GMT+01:00 Cédric Champeau cedric.champ...@gmail.com
 :

 I got them too.
 Le 26 mars 2015 19:10, Guillaume Laforge glafo...@gmail.com a
 écrit
 :

 I also got moderation messages

 2015-03-26 18:51 GMT+01:00 Roman Shaposhnik ro...@shaposhnik.org:

 I don't.

 On Thu, Mar 26, 2015 at 10:47 AM, Andrew Bayer 
 andrew.ba...@gmail.com
 wrote:
 Just making sure - others besides me are getting the subscribe
 moderation
 emails?

 A.

 On Thu, Mar 26, 2015 at 10:22 AM, Bertrand Delacretaz 
 bdelacre...@apache.org wrote:

 On Thu, Mar 26, 2015 at 6:21 PM, Jochen Theodorou 
 blackd...@gmx.org

 wrote:
 ...listname-subscribe@groovy.incubator.a.o ?

 of course yes, sorry - the names on INFRA-9339 are correct.

 -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




 -- 
 Guillaume Laforge
 Groovy Project Manager

 Blog: http://glaforge.appspot.com/
 Social: @glaforge http://twitter.com/glaforge / Google+
 https://plus.google.com/u/0/114130972232398734985/posts






 -- 
 Guillaume Laforge
 Groovy Project Manager

 Blog: http://glaforge.appspot.com/
 Social: @glaforge http://twitter.com/glaforge / Google+
 https://plus.google.com/u/0/114130972232398734985/posts

 -
 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


 
 
 ---
 This email has been checked for viruses by Avast antivirus software.
 http://www.avast.com
 
 
 -
 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: Do we need @ASFIncubator ?

[Shane Curcuru]

On 3/23/15 7:58 PM, Roman Shaposhnik wrote:
 I would *really* prefer if run it via twitterdeck. Managing group
 accounts that way is WAY better than sharing credentials.
 I'm enjoying this with @TheASF right now and I think this
 way needs to be promoted for all the @ASFxxx accounts.

+1 I would strongly prefer the twitter credentials were shared among a
few officers securely, and we use Twitterdeck or HootSuite or whatever
other method for allowing others to sign up for access.

Having an ASFIncubator account will be a great thing, especially if we
can tweet both podling news as well as selected pointers to key How
Apache really works things, to help the world better understand the ASF
and the Incubator.

Roman, as VP, do you want to start setting this up?

- Shane

 
 Any objections?
 
 Thanks,
 Roman.
 
 
 On Mon, Mar 23, 2015 at 4:55 PM, Ted Dunning ted.dunn...@gmail.com wrote:
 Done.

 Credentials sent to IPMC private list.



 On Mon, Mar 23, 2015 at 4:50 PM, Konstantin Boudnik c...@apache.org wrote:

 As a big-time user of @ASF... twitter accounts, I think it's a great idea!

 On Mon, Mar 23, 2015 at 02:05PM, Roman Shaposhnik wrote:
 Hi!

 while trying to spread the good news that the Groovy
 vote has passed, I've realized that we don't have
 a dedicate Incubator Twitter account.

 Question for all: should we leverage @TheASF for
 the incubator-level announcements or should we
 establish our own handle?

 WDYGT?

 Thanks,
 Roman.

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


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


 
 -
 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] Groovy Incubation proposal

[Shane Curcuru]

On 3/17/15 12:41 PM, Roman Shaposhnik wrote:
 On Wed, Mar 11, 2015 at 3:23 PM, Shane Curcuru a...@shanecurcuru.org wrote:
 On 3/11/15 4:20 PM, Martijn Dashorst wrote:
 Great initiative!

 Just one question: I don't see anything related to the groovy name and
 possible trademark in the proposal. Does Pivotal have any claims to
 the name groovy, and if so are those claims transferred to the ASF?

 Good point.  Just from the Apache *policy* side, the ASF must have
 trademark rights to a podling's name before the board will approve a
 graduation vote.  With such a long history, we would need a clear
 statement of some sort from whoever was previously hosting Groovy
 software product releases, which would seem to be Pivotal.  Or, the
 podling would have to choose a new name that we did have rights to.  8-)

 If the PPMC requests it, we can then register the project's name as a
 trademark in the US *after* graduation.

 If this podling joins the incubator, please coordinate some Groovy PPMC
 and Pivotal contacts with trademarks@.  Presuming Pivotal is willing
 (and I can't imagine why they wouldn't be), trademarks@ can ensure the
 right stuff gets done.
 
 Turns out it is not up to Pivotal. In fact, the statement I've just got goes
 like this: Pivotal does not have, nor will it make, any claims to the GROOVY
 trademark

Can you ensure that whoever actually wrote that from the Pivotal side
communicates it to trademarks@, or at least to vp-brand@?  If we do have
questions later, counsel will need to email someone directly about it.

 
 Basically, Pivotal was happy to sponsor the project (just like it sponsors
 RabbitMQ or Redis) but wasn't involved in sorting out the situation around
 the Groovy project name and its legal status.
 
 Shane, please let me know if this bit of information is sufficient for you.
 It appears as though ASF will have to do the usual PODDLINGNAMESEARCH
 and determine the status of Groovy trademark on its own.
 
 I plan to start a [VOTE] thread sometime on Wed, unless you tell me otherwise.

No need to gate a podling acceptance vote on branding issues.  The only
hard requirement is before graduation.

- Shane

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


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

Re: [DISCUSS] Groovy Incubation proposal

[Shane Curcuru]

On 3/11/15 4:20 PM, Martijn Dashorst wrote:
 Great initiative!
 
 Just one question: I don't see anything related to the groovy name and
 possible trademark in the proposal. Does Pivotal have any claims to
 the name groovy, and if so are those claims transferred to the ASF?

Good point.  Just from the Apache *policy* side, the ASF must have
trademark rights to a podling's name before the board will approve a
graduation vote.  With such a long history, we would need a clear
statement of some sort from whoever was previously hosting Groovy
software product releases, which would seem to be Pivotal.  Or, the
podling would have to choose a new name that we did have rights to.  8-)

If the PPMC requests it, we can then register the project's name as a
trademark in the US *after* graduation.

If this podling joins the incubator, please coordinate some Groovy PPMC
and Pivotal contacts with trademarks@.  Presuming Pivotal is willing
(and I can't imagine why they wouldn't be), trademarks@ can ensure the
right stuff gets done.

- Shane


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

Re: Soliciting feedback for a detailed pTLP policy document

[Shane Curcuru]

On 3/4/15 1:41 PM, Benson Margulies wrote:

 On Wed, Mar 4, 2015 at 1:12 PM, Doug Cutting cutt...@apache.org
 mailto:cutt...@apache.org wrote:

 On Mon, Mar 2, 2015 at 5:31 PM, Roman Shaposhnik r...@apache.org
 mailto:r...@apache.org wrote:
...
 As a director, I still don't think the board needs to be involved in a
 pTLP's graduation.  As far as I'm concerned, any provisional
 status is self-imposed by the PMC and can be removed at its pleasure.
 From the board's perspective it's either an ASF project or it's not,
 there's not a useful middle ground.  As a project it needs to provide
 reports, release according to accepted standards, operate openly, etc.
 It may be a young project, with a PMC dominated by old-timers who
 aren't responsible for much of the contribution, but I don't see why
 that requires a new formal status any more than we need a formal
 status for old, slow-moving projects that rarely release.
 
 Put directly, what does a pTLP's graduation change from the board's
 perspective?  How should it change the way we review the project's
 reports, etc.?  In short, why should we care about this label?  If a
 PMC wishes to call itself blue that's fine too, but we don't need a
 resolution when it decides to call itself purple.
 
 
 What's your view of 'incubation disclaimers'? The above paragraph makes
 most sense to me if there are none for pTLPs.

The bigger question is: what does pTLP mean to the rest of the world?

Incubation disclaimers are there to inform the rest of the world that
the community working there, and the software it produces, are not (yet)
true Apache projects.  That is, we want end users to understand that
there may be different expectations of project behavior and software
product quality or availability for Incubator podlings than the world
has for full Apache projects.

How are we clearly describing to end users what differences they might
expect between the operations and functionality of pTLPs versus Apache
projects (i.e. formal TLPs)?  And who, specifically, decides when the
pTLP becomes a TLP?

While it's important to ensure that we're being clear within our
communities about how we operate and improve, in this case it's also
really important that we make it clear to the rest of the world what a
pTLP is.

- Shane


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

Re: Podling Name Searches

[Shane Curcuru]

Yes, you still need to do a podling name search.  Hopefully that will
show that the existing name is already good to start with and doesn't
conflict with other, pre-existing similar software products.

If the community intends to keep the name, we need a clear donation of
the trademark itself from the current holder.  Ask on trademarks@ once
you are ready to start.  Registered trademarks can be transferred with a
pretty basic legal document that Apache counsel can provide if needed;
the existing owner merely needs to sign, we do the rest of the legal
transfer for a registration.

- Shane

On 1/26/15 1:38 PM, Rob Vesse wrote:
 One option would be to get the company involved to donate the trademark,
 if you check with trademarks@a.o then I am pretty sure that has happened
 in the past and they can likely guide you on procedures for this
 
 Your wording implies that perhaps this isn't an option in this particular
 podlings case?
 
 Rob
 
 On 25/01/2015 06:45, Branko Čibej br...@apache.org wrote:
 
 On 25.01.2015 14:08, John D. Ament wrote:
 All,

 If a podling had its name and codebase donated from a company, which had
 already secured rights to the name,

 The term secured rights is a bit misleading. Even if they have a
 registered trademark, that's no guarantee that it doesn't infringe on
 anything, especially in a different jurisdiction.

 what is required in the podling name search?

 IMO, same as always. There's no reason for the ASF to implicitly trust
 corporate lawyers. We should always look for names that are globally
 unambiguous.

 -- Brane


 -
 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