Re: Websites at podling.apache.org

[Daniel Dekany]

I'm managing most of the transition to the ASF infrastructure on
FreeMarker's side, so let me answer. My intent was that until the
project manages to graduate, freemarker.org will continue to be the
"official" and only FreeMarker homepage (as it is for 10 years or so),
only the content comes from the ASF web server. Of course there we
would show the incubation disclaimer or whatever is required, like
perhaps an incubator logo. I was told that the
freemarker.incubator.apache.org URL is required to exist, so I said
that it should just redirect to freemaker.org. (We don't need two
homepages, one for normal users and one for contributors.) To my
surprise, when the domain was transferred to ASF, freemaker.org has
redirected to freemarker.incubator.apache.org instead. So I have asked
tradema...@apache.org if it's OK if it works the other way around
(freemarker.incubator.apache.org redirects to freemarker.org), and
after Shane Curcuru said the he sees no problem with that, I have
opened an issue for it on
https://issues.apache.org/jira/browse/INFRA-10787. It's not like it
impedes development, but it's still unresolved, after two months now.
(I didn't know that this will trigger a such a long discussion, though
I suppose as you let in projects established elsewhere, this will come
up sometimes anyway.)

-- 
Thanks,
 Daniel Dekany


Thursday, January 14, 2016, 9:02:16 AM, Bertrand Delacretaz wrote:

> Hi,
>
> On Wed, Jan 13, 2016 at 6:43 PM, John D. Ament  wrote:
>> ...Can we move freemarker forward to not impede them?..
>
> I'm not sure what you are asking, can you clarify?
>
> -Bertrand
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


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

Re: Websites at podling.apache.org

[John D. Ament]

And this issue brought up that both podling.a.o and podling.i.a.o started
working at some point and a large unrelated branding issue.

I've responded to the infra ticket, my hope is that they move forward on it
at this point.

On Sat, Jan 16, 2016 at 8:14 AM Daniel Dekany  wrote:

> I'm managing most of the transition to the ASF infrastructure on
> FreeMarker's side, so let me answer. My intent was that until the
> project manages to graduate, freemarker.org will continue to be the
> "official" and only FreeMarker homepage (as it is for 10 years or so),
> only the content comes from the ASF web server. Of course there we
> would show the incubation disclaimer or whatever is required, like
> perhaps an incubator logo. I was told that the
> freemarker.incubator.apache.org URL is required to exist, so I said
> that it should just redirect to freemaker.org. (We don't need two
> homepages, one for normal users and one for contributors.) To my
> surprise, when the domain was transferred to ASF, freemaker.org has
> redirected to freemarker.incubator.apache.org instead. So I have asked
> tradema...@apache.org if it's OK if it works the other way around
> (freemarker.incubator.apache.org redirects to freemarker.org), and
> after Shane Curcuru said the he sees no problem with that, I have
> opened an issue for it on
> https://issues.apache.org/jira/browse/INFRA-10787. It's not like it
> impedes development, but it's still unresolved, after two months now.
> (I didn't know that this will trigger a such a long discussion, though
> I suppose as you let in projects established elsewhere, this will come
> up sometimes anyway.)
>
> --
> Thanks,
>  Daniel Dekany
>
>
> Thursday, January 14, 2016, 9:02:16 AM, Bertrand Delacretaz wrote:
>
> > Hi,
> >
> > On Wed, Jan 13, 2016 at 6:43 PM, John D. Ament 
> wrote:
> >> ...Can we move freemarker forward to not impede them?..
> >
> > I'm not sure what you are asking, can you clarify?
> >
> > -Bertrand
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Release Apache Ranger 0.5.1 (incubating)

[Justin Mclean]

Hi,

+1 binding, but please looking into the issues below for next release.

I checked:
- name contain incubating
- signature and hash good
- disclaimer exists
- NOTICE and LICENSE have some issues
- there a few source files without Apache headers e.g. python scripts in [1]
- no unexpected binary files

For NOTICE file:
- Year is incorrect
- There is no need to list MIT or BSD software in NOTICE [2]

LICENSE is missing:
-  Block UI Copyright 2011, Ben Lin (MIT) [3]
- "Copyright (c) Nicolas Gallagher and Jonathan Neal" for MIT backgrid filter 
[4]
- JQuery migrate [5]
- Qunit [6]
- bootstrap editable [7]
- bootstrap [8]
- jsDump [9]
- font awesome [10] (and perhaps open sans font as well)

The visual source [11] is MIT so I’m not sure why it’s not grouped with the 
other MIT licenses.

Note that most of these issues were raised for the last release candidate and 
haven’t been fixed. [12]

Also can the release be place in the correct location and not on people. [13]

Thanks,
Justin

1.  ./migration-util/ambari2.0-hdp2.2-ranger0.40/bin/
2. http://www.apache.org/dev/licensing-howto.html#permissive-deps
3. ./security-admin/src/main/webapp/scripts/modules/XAOverrides.js
4. 
./security-admin/src/main/webapp/libs/bower/backgrid-filter/css/backgrid-filter.css
5. ./security-admin/src/main/webapp/libs/bower/jquery/js/jquery-migrate.js 
6. ./security-admin/src/main/webapp/libs/bower/globalize/test/qunit/qunit.js
7. 
./security-admin/src/main/webapp/libs/bower/x-editable/js/bootstrap-editable.js
8. ./security-admin/src/main/webapp/libs/bower/bootstrap/js/bootstrap.js
9. ./security-admin/src/main/webapp/libs/bower/globalize/test/qunit/qunit.js
10. ./security-admin/src/main/webapp/fonts/fontawesome/*
11. ./security-admin/src/main/webapp/libs/other/visualsearch/js/visualsearch.js
12. http://apache.markmail.org/thread/aja7o2bodr45clcp
13. http://www.apache.org/dist/incubator/ranger/

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

[Roman Shaposhnik]

On Fri, Jan 15, 2016 at 1:39 PM, Ted Dunning  wrote:
> On Fri, Jan 15, 2016 at 1:30 PM, Danese Cooper  wrote:
>
>> It is true that the ASF and the FSF have historically been religiously
>> incompatible on the subject of licensing combinatorics. As I usually
>> explain to my clients, the worst case scenario for the FSF is that code
>> become unfree (in the non-proprietary sense); the worst case scenario for
>> the ASF is that code become unused (in the code reuse sense). Both points
>> have their validity.
>>
>
> Actually FSF explicitly says that ASL is compatible with GPL.  The reverse
> is, of course, not true if you want to preserve the ASL semantics and both
> ASF and FSF agree on that.

A fun little fact that not a lot of zealots on both sides realize is
the above plus
the revers fact that FSF actually *recommends* ALv2 under certain conditions:
   http://www.gnu.org/licenses/license-recommendations.en.html
(see the Small Programs ;-) and Libraries paragraph).

Thanks,
Roman.

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

Re: [VOTE] Release Apache Zeppelin (incubating) 0.5.6-incubating (RC2)

[Justin Mclean]

Hi,

+1 binding

I checked:
- incubating in name
- signatures and hashes correct
- DISCLAIMER exist
- LICENSE and NOTICE correct
- all source file have apache headers
- no unexpected binary files
- can compile from source

The year needs updating in the NOTICE file.

I also had a quick look at the binary, I’d suggest you check [1] (no need to 
add apache licensed software to license) and [2] (no need to duplicate the 
developed at line).

Not 100% sure but I think there’s also no need to add extra copyright Apache 
lines either, if not there there’s a number of projects which are not doing 
that.


Thanks,
Justin

1. http://www.apache.org/dev/licensing-howto.html#permissive-deps
2. http://www.apache.org/dev/licensing-howto.html#bundle-asf-product
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

[Peter Kelly]

> On 16 Jan 2016, at 12:32 AM, Alex Harui  wrote:
> 
> Probably too late, but some comments in-line.
> 
> On 1/15/16, 6:55 AM, "Peter Kelly"  wrote:
>> 
>> However, one important factor which really killed things for us was the
>> inability to use Qt.
>> 
>> The desktop app was the main priority, however.
>> 
>> To do a cross-platform desktop app, and to do it properly, it’s necessary
>> to use a suitable UI toolkit which provides all the necessary
>> functionality. As it turns out, the only viable candidates we were able
>> to identify (Qt and GTK, with wxWidgets and fltk as less desirable
>> fallback options) are all licensed under the LGPL. For most open source
>> projects, this would be no problem - LGPL and ASLv2 are compatible with
>> each other, in the sense that you can distribute software combining the
>> code from the two licenses without problems; doing so just means that
>> users of the software are bounds by the terms of both licenses.
> 
> It appears that Qt is no longer under LGPL and now just GPL? [1]  That
> could limit the number of commercial users which is one reason why the ASF
> has the CategoryX restriction.

It’s now available LGPLv3 - they’ve just LGPLv2.1 as an option, for new 
releases.

> 
>> 
>> We very quickly settled on Qt as the toolkit of choice, on technical
>> grounds. It seemed to us to be the most mature, feature-rich, and best
>> designed library of the available choices, and some of us had already
>> used it on other projects in the past. However, even if we had chosen one
>> of the other libraries, the outcome would have been the same.
> 
> FWIW, Apache Flex and Apache Cordova can create cross-platform desktop
> apps.  I think these are pretty mature projects.

I recently discovered Electron (http://electron.atom.io 
) which I’ve used as part of some other work I’ve 
done recently and actually quite like. It also services as the framework for 
GitHub’s Atom text editor. If I’d known about it a few months ago when the 
podling was still active, I would have suggested using this for the editor.

Having spent some time using Atom, I think that Electron would be have been a 
good solution for Corinthia’s editor. It’s available under the MIT license, 
which according to http://www.apache.org/legal/resolved.html 
 makes it acceptable to use as a 
project dependency. I would recommend this as an option to new ASF podlings 
that wish to build a cross-platform desktop app. Another advantage of Electron 
is that it’s all based on web technologies, so most if not all of your UI code 
can be used in a browser environment.

Unfortunately, the hostility and attitude of specific individuals who objected 
to our proposed to of Qt lead the decision making off-track, and into 
arguments. The was essentially was basically "no, you cannot use Qt, and 
therefore the editor should not be part of the project” (i’m paraphrasing 
here). This caused the discussion to descend into arguments which severely 
harmed the community.

My suggestion to people involved with ensuring that ASF policies are adhered to 
- such as the licensing issues I mentioned - is to say “Ok, this particular 
solution is not permitted within the rules. However, given the requirement in 
question is a very important part of the project, let’s work together to find a 
solution that allows us to achieve our goals within the context of ASF”. If 
this approach had been taken, I think there’s a pretty good chance we would 
have ended up conducting more research into available options, and ended up 
going with Electron.

That didn’t happen though, and as result the whole podling fell apart and 
numerous people (myself included) left. In my particular case, the experience 
was stressful enough that I longer wish to have anything to do with an ASF ever 
again.

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

I should explain a bit more about the nature of the way of the software we 
planned to to write which depended upon Qt. I’d like to first mention though 
that I own a company which is already using the non-UI Corinthia codebase in a 
for-profit manner (UX Write, a word processor for iOS) - in fact this is where 
the code originally came from. The iOS version has a (closed source) UI using 
Apple’s native APIs, and does not use Qt.

There are three components to the project

1) A C-based file 

Re: [VOTE] Accept the iota project into the Apache Incubator

[Hadrian Zbarcea]

The vote is as usually open for at least 72 hours.

Here's my +1.

Hadrian


On 01/16/2016 03:12 PM, Hadrian Zbarcea wrote:

Hi,

The iota proposal [1] (initially Tempo) was proposed about 6 weeks ago.

Because of the naming conflict that would have likely required to change
name at graduation, the project name was changed to "Apache iota" (the
greek letter), which resonates better with the IoT field the project
targets and passed a summary podling name search.

The code was made available in December for our review and answers on
the general@ list have been answered.

We think it's time to move to the next step, a formal vote. Therefore...

Please cast your vote to:
[] +1 - accept Apache iota as a new incubating project
[]  0 - not sure
[] -1 - do not accept the Apache iota project (because: ...)

Thanks,
Hadrian


[1] https://wiki.apache.org/incubator/IotaProposal
[2] https://en.wikipedia.org/wiki/Iota


-

iota Proposal

Abstract

The Apache Foundation has been very successful in bringing together key
software components that have enabled people to interact with each other
via a variety of content platforms and it will no doubt continue to do
so. At the same time modern society is becoming increasingly dependent
on devices that interact with each other and with people. The amount of
data that will be produced by devices will be orders of magnitude
greater than what has been produced by humans in the past. In addition,
the orchestration of devices and people will be an important area of
growth for the foreseeable future. This new dynamic will eventually
become manifest in a growing number of Apache projects that enable this
to occur. Our wish is to contribute to this movement by contributing the
iota system to the Open Source Community via the Apache Foundation.
Apache iota is an open platform to interconnect any and all devices,
sensors, people, and applications, henceforth referred to as points,
through a scalable, secure, and modular architecture, enabling
applications to generate analysis, create actions and/or add
intelligence to their behaviors and patterns.

Proposal

Perhaps you are a homeowner configuring the interaction between your
family and all the smart devices in your home. Or you might be a global
company orchestrating millions of devices and people across different
continents. Either way you face the same fundamental problem; namely,
how do you manage many points in a secure robust and meaningful manner?
Apache iota is an open source software system that enables homeowners
and global companies to download a software system that provides secure
and robust orchestration.

The iota system consists of a variety of components:

A basic but extensible desktop
An extensible mechanism for capturing data from a variety of sources
A set of translators that feed the data capture mechanism and a
framework for the development of additional translators
A secure means of moving data using digital envelopes based on symmetric
and asymmetric encryption and decryption via Apache Kafka
Optionally maintaining data encrypted in a datastore
Support for a variety of data repositories
Authentication and authorization using OAuth2
Secure APIs for access to data and the system information
User management
Device management
Automated software upgrades via Salt
Configuration management
Robust basic infrastructure based on Apache Mesos that enables scalability
Dockerized applications
Background

We are in the midst of a revolution in which the Internet of Things
(IoT) is poised to impact the development of our society in ways we can
not even begin to imagine. Unfortunately, we know of no coherent OSS
(Open Source Software) solution that can harness the potentialities of
this increasingly important trend. Manufacturers of IoT devices, both in
the consumer and industrial spaces, continue to develop proprietary
systems. Apache iota is an open source IoT system that creates an open
source solution enabling the orchestration of IoT devices that brings
the benefits of OSS to this space. Apache iota was initially developed
by Litbit and is deployed in a growing number of Industrial contexts,
especially in the context of Data Center Infrastructure.

Rationale

Apache iota is a general platform for orchestrating IoT devices in both
consumer and industrial contexts. It is complementary to the existing
Apache projects and is itself built using of a number of Apache
projects. Bringing iota into Apache is very beneficial to both the
Apache community and the IoT community.

The rapid growth of IoT needs to be harnessed in the Open Source
Community. We believe the Apache Foundation is a great fit as the
long-term home for iota, as it provides an established process for
community-driven development and decision making by consensus. This is
exactly the model we want for future iota development.

Initial Goals

Move the existing codebase to Apache
Integrate with the Apache development process
Ensure all 

[VOTE] Accept the iota project into the Apache Incubator

[Hadrian Zbarcea]

Hi,

The iota proposal [1] (initially Tempo) was proposed about 6 weeks ago.

Because of the naming conflict that would have likely required to change 
name at graduation, the project name was changed to "Apache iota" (the 
greek letter), which resonates better with the IoT field the project 
targets and passed a summary podling name search.


The code was made available in December for our review and answers on 
the general@ list have been answered.


We think it's time to move to the next step, a formal vote. Therefore...

Please cast your vote to:
[] +1 - accept Apache iota as a new incubating project
[]  0 - not sure
[] -1 - do not accept the Apache iota project (because: ...)

Thanks,
Hadrian


[1] https://wiki.apache.org/incubator/IotaProposal
[2] https://en.wikipedia.org/wiki/Iota


-

iota Proposal

Abstract

The Apache Foundation has been very successful in bringing together key 
software components that have enabled people to interact with each other 
via a variety of content platforms and it will no doubt continue to do 
so. At the same time modern society is becoming increasingly dependent 
on devices that interact with each other and with people. The amount of 
data that will be produced by devices will be orders of magnitude 
greater than what has been produced by humans in the past. In addition, 
the orchestration of devices and people will be an important area of 
growth for the foreseeable future. This new dynamic will eventually 
become manifest in a growing number of Apache projects that enable this 
to occur. Our wish is to contribute to this movement by contributing the 
iota system to the Open Source Community via the Apache Foundation. 
Apache iota is an open platform to interconnect any and all devices, 
sensors, people, and applications, henceforth referred to as points, 
through a scalable, secure, and modular architecture, enabling 
applications to generate analysis, create actions and/or add 
intelligence to their behaviors and patterns.


Proposal

Perhaps you are a homeowner configuring the interaction between your 
family and all the smart devices in your home. Or you might be a global 
company orchestrating millions of devices and people across different 
continents. Either way you face the same fundamental problem; namely, 
how do you manage many points in a secure robust and meaningful manner? 
Apache iota is an open source software system that enables homeowners 
and global companies to download a software system that provides secure 
and robust orchestration.


The iota system consists of a variety of components:

A basic but extensible desktop
An extensible mechanism for capturing data from a variety of sources
A set of translators that feed the data capture mechanism and a 
framework for the development of additional translators
A secure means of moving data using digital envelopes based on symmetric 
and asymmetric encryption and decryption via Apache Kafka

Optionally maintaining data encrypted in a datastore
Support for a variety of data repositories
Authentication and authorization using OAuth2
Secure APIs for access to data and the system information
User management
Device management
Automated software upgrades via Salt
Configuration management
Robust basic infrastructure based on Apache Mesos that enables scalability
Dockerized applications
Background

We are in the midst of a revolution in which the Internet of Things 
(IoT) is poised to impact the development of our society in ways we can 
not even begin to imagine. Unfortunately, we know of no coherent OSS 
(Open Source Software) solution that can harness the potentialities of 
this increasingly important trend. Manufacturers of IoT devices, both in 
the consumer and industrial spaces, continue to develop proprietary 
systems. Apache iota is an open source IoT system that creates an open 
source solution enabling the orchestration of IoT devices that brings 
the benefits of OSS to this space. Apache iota was initially developed 
by Litbit and is deployed in a growing number of Industrial contexts, 
especially in the context of Data Center Infrastructure.


Rationale

Apache iota is a general platform for orchestrating IoT devices in both 
consumer and industrial contexts. It is complementary to the existing 
Apache projects and is itself built using of a number of Apache 
projects. Bringing iota into Apache is very beneficial to both the 
Apache community and the IoT community.


The rapid growth of IoT needs to be harnessed in the Open Source 
Community. We believe the Apache Foundation is a great fit as the 
long-term home for iota, as it provides an established process for 
community-driven development and decision making by consensus. This is 
exactly the model we want for future iota development.


Initial Goals

Move the existing codebase to Apache
Integrate with the Apache development process
Ensure all dependencies are compliant with Apache License version 2.0
Incremental 

Re: Incubation and GSOC

[Greg Stein]

On Fri, Jan 15, 2016 at 7:47 AM, Markus Geiß  wrote:
>...

> Since we are in incubation now (Apache Fineract), I'm wondering how we
> will deal
> with this in the future. Is the IPMC supporting GSOC, is it the
> responsibility of the
> project community, or is Apache in general pro things like GSOC?
>

Apache is very pro GSoC :-) ... I *started* GSoC with Chris DiBona back at
Google in 2005. It was just the two of us running it... it was quite
painful. And being the ASF Chairman at the time, I made sure the ASF was
selected as one of the organizations :-) ... The ASF has participated every
year since, and I don't see that changing.

As Luciano notes, we run it Foundation-wide rather than per-project. It
makes it a lot easier for everybody, and we usually get lots of project
slots assigned to us.

Cheers,
-g

Re: [VOTE] Release Apache Twill-0.7.0-incubating

[Justin Mclean]

Hi,

+1 binding

I checked:
- incubating in name
- signatures and hashes correct
- disclaimer exists
- LICENSE and NOTICE correct
- no binary files
- all files have apache source headers
- can compile from source

Very minor issue - year is incorrect in NOTICE.

Thanks
Justin

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

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

[Roman Shaposhnik]

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

Last time we had this very Qt related discussion it was (I think!) Greg
who pointed out that you should probably use a viability argument for
something like Qt. Is your project still viable if something like Qt is
no longer available to it? (note it may be reduced functionality but
still viable)

If the answer is yes -- getting Qt from the runtime binding should be ok.
If the answer is no -- this wouldn't really be a self-contained ASF project,
would it?

Thanks,
Roman.

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