RE: [NOTICE] corinthia PPMC+committer -= dortef, franz, gbg, ianc, jani, louis, pmkelly

[Dennis E. Hamilton]

I can speak to the specific case.

The desire is to adopt Qt as the best-choice, most-cross-platform GUI framework 
for Corinthia on the desktop.  The non-commercial, open-source license for Qt 
is LGPL/GPL.  See .

As I understand it, a second-thought alternative to full-up dependence on Qt is 
to make an experimental implementation that employs a wrapper API under which a 
Qt-specific integration layer is introduced.  The Qt integration layer is meant 
to be optionally replaceable by an alternative one and corresponding framework 
under the wrapper API.  The wrapper API and integration layer for any 
functionally-equivalent integration/replacement is TBD.  A cautionary concern 
was raised about the prudence of having an optional-replacement of an LGPL 
dependence rather than an optionally-employable LGPL dependence.  

No specific proposal or request for any sort of exception is at legal-discuss 
or the LEGAL JIRA.

 - Dennis

-Original Message-
From: Jochen Theodorou [mailto:blackd...@gmx.org] 
Sent: Sunday, September 6, 2015 09:23
To: general@incubator.apache.org
Subject: Re: [NOTICE] corinthia PPMC+committer -= dortef, franz, gbg, ianc, 
jani, louis, pmkelly

Am 06.09.2015 04:22, schrieb Dave Fisher:
[...]
> Also Apache needs a release policy for binaries that would allow the best 
> UX/UI API for the platform to be used even if it is GPL. If you have 
> subscribed to legal-discuss the last few months you know why that discussion 
> was impossible. If that can be worked out then at least it would help other 
> projects.

can you explain the case a bit? Do you link statically? What is the license?

bye blackdrag

-- 
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.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: [NOTICE] corinthia PPMC+committer -= dortef, franz, gbg, ianc, jani, louis, pmkelly

[Jochen Theodorou]

Am 06.09.2015 19:43, schrieb Peter Kelly:

On 6 Sep 2015, at 11:22 pm, Jochen Theodorou 
wrote:

Am 06.09.2015 04:22, schrieb Dave Fisher: [...]

Also Apache needs a release policy for binaries that would allow
the best UX/UI API for the platform to be used even if it is GPL.
If you have subscribed to legal-discuss the last few months you
know why that discussion was impossible. If that can be worked
out then at least it would help other projects.


can you explain the case a bit? Do you link statically? What is the
license?


We wanted to use Qt, the open source version of which is LGPL. All
other suitable candidates we could find were similar; GTK is LGPL,
and wxWidgets has a license that is very close to LGPL. We also
needed to use WebKit, regardless of the toolkit involved, and that is
(mostly I think) LGPL also.


I would have thought about wxWidgets as well... true the license is 
basically LGPL, but "works in binary form may be distributed on the 
user's own terms" (https://en.wikipedia.org/wiki/WxWidgets#License). I 
would assume that allows the binary to be Apache Licensed for example. 
But Webkit blows it up again, yes.




There was some debate about whether or not it was ok to write an
application which used Qt, though we did not propose including any of
the actual Qt source code in the release artefacts. It would be used
as an external library, dynamically linked, similar to how many
programs use glibc.


my position on this is, it is ok as long as qt is not part of the 
binary, since then it has to be part of the system... And I think you 
mean this as well. Though, I doubt that works for QT under windows. GTK+ 
maybe, once the windows runtime becomes available again.



An assertion was made in the discussion that if we cannot develop our
app without using Qt, it should not be part of the project (I assume
this same argument would have been made if we had chosen one of the
others above). Given that this app was a major component (though by
no means all) of what we planned to do, it seemed that if that
argument was valid (and I don’t think it was, but I’m still not
sure), we would have to do so outside of ASF.


I think it would be bad to have the UI and the functionality separate - 
even if the UI part would be so much bigger. But that would allow other 
applications to use it as library independent of the editor. But given, 
that you are supposed to build a community and that the community most 
likely will want to use the editor in the beginning... I find that 
decision reasonable. Is licensing the project under LGPL an option? 
Afaik apache does not like that very much, but could allow it.



There were numerous other factors involved with our design to resign,
mostly involving personal disputes among PPMC members which I won’t
get into here out of respect for all involved. But the discussion
about licensing and implications for the project was one of the
factors, and certainly caused a division in the community.


Personal disputes will happen, just belongs to life imho. For me the 
licensing problem would be enough to move away from apache in your 
case... if LPGPL is not option for the project.


[...]
bye blackdrag



--
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/


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

Move HAWQ, HORN to different reporting group

[Marvin Humphrey]

Greets,

Our podlings are unevenly distributed among the 3 reporting groups,
resulting in a heavy load once every three months.

* 1 (Jan, Apr, July, Oct): 18 podlings
* 2 (Feb, May, Aug, Nov): 21 podlings
* 3 (Mar, Jun, Sep, Dec): 32 podlings

HAWQ and HORN were initially placed in group 3, but I've taken the
liberty of moving them to group 1.  This means that after monthly
reports in Oct, Nov, and Dec, they will start reporting quarterly with
a Jan report.

The groups don't need to be perfectly balanced and so IMO we don't
need to move other podlings around, but I'd prefer not to worsen the
imbalance when scheduling new podlings.

Marvin Humphrey

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

[ANNOUNCE] Apache Kylin v1.0-incubating released

[Luke Han]

Hello

The Apache Kylin team would like to announce the release of
Apache Kylin v1.0-incubating:
http://kylin.incubator.apache.org/blog/2015/09/06/release-v1.0-incubating/

Apache Kylin is an open source Distributed Analytics Engine designed
to provides SQL interface and multi-dimensional analysis (OLAP) on Hadoop
supporting extremely large datasets.

More details on Apache Kylin can be found here:
http://kylin.incubator.apache.org/

The release artifacts can be downloaded from here:
http://kylin.incubator.apache.org/download/

Maven artifacts have been made available here:
https://repository.apache.org/content/repositories/releases/org/apache/kylin
/

Release notes available here:
http://kylin.incubator.apache.org/docs/release_notes.html

Great thanks to everyone who made this release possible.

Thanks.
The Apache Kylin team


DISCLAIMER

Apache Kylin is an effort undergoing incubation at The Apache Software
Foundation (ASF), sponsored by  Apache Incubator. Incubation is required of
all newly accepted projects until a further review indicates that the
infrastructure, communications, and decision making process have stabilized
in a manner consistent with other successful ASF projects. While incubation
status is not necessarily a reflection of the completeness or stability of
the code, it does indicate that the project has yet to be fully endorsed by
the ASF.

Re: [NOTICE] corinthia PPMC+committer -= dortef, franz, gbg, ianc, jani, louis, pmkelly

[Peter Kelly]

> On 6 Sep 2015, at 11:22 pm, Jochen Theodorou  wrote:
> 
> Am 06.09.2015 04:22, schrieb Dave Fisher:
> [...]
>> Also Apache needs a release policy for binaries that would allow the best 
>> UX/UI API for the platform to be used even if it is GPL. If you have 
>> subscribed to legal-discuss the last few months you know why that discussion 
>> was impossible. If that can be worked out then at least it would help other 
>> projects.
> 
> can you explain the case a bit? Do you link statically? What is the license?

We wanted to use Qt, the open source version of which is LGPL. All other 
suitable candidates we could find were similar; GTK is LGPL, and wxWidgets has 
a license that is very close to LGPL. We also needed to use WebKit, regardless 
of the toolkit involved, and that is (mostly I think) LGPL also.

There was some debate about whether or not it was ok to write an application 
which used Qt, though we did not propose including any of the actual Qt source 
code in the release artefacts. It would be used as an external library, 
dynamically linked, similar to how many programs use glibc.

An assertion was made in the discussion that if we cannot develop our app 
without using Qt, it should not be part of the project (I assume this same 
argument would have been made if we had chosen one of the others above). Given 
that this app was a major component (though by no means all) of what we planned 
to do, it seemed that if that argument was valid (and I don’t think it was, but 
I’m still not sure), we would have to do so outside of ASF.

There were numerous other factors involved with our design to resign, mostly 
involving personal disputes among PPMC members which I won’t get into here out 
of respect for all involved. But the discussion about licensing and 
implications for the project was one of the factors, and certainly caused a 
division in the community.

If it’s not possible to write apps using LGPL libraries as part of apache 
projects, then this seems to pretty much rule out any cross-platform native 
desktop apps, unless you write your own toolkit. I realise OpenOffice has it’s 
own custom toolkit which is still used for historical reasons, but I don’t 
think that can adapt well to mobile platforms, so other than that that there 
don’t seem to be any viable choices which could work with the policy.

—
Dr Peter M. Kelly
pmke...@apache.org

PGP key: http://www.kellypmk.net/pgp-key 
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)

Re: [NOTICE] corinthia PPMC+committer -= dortef, franz, gbg, ianc, jani, louis, pmkelly

[Ralph Goers]

Licensing is always a thorny issue.  

In general, http://www.apache.org/legal/resolved.html#optional 
 says that you can use 
libraries under licenses such as the LGPL for optional dependencies. This is so 
that user’s can use your project in its base mode with no “surprises”.

However, if the library is something that you would expect to be already 
installed on the platform(s) you support that is a different story. See 
http://www.apache.org/legal/resolved.html#platform 
.

If someone can take your work, modify it, and then attach whatever license they 
want to the combined work then whatever you are doing is probably OK. 

Ralph



> On Sep 6, 2015, at 10:43 AM, Peter Kelly  wrote:
> 
>> On 6 Sep 2015, at 11:22 pm, Jochen Theodorou  wrote:
>> 
>> Am 06.09.2015 04:22, schrieb Dave Fisher:
>> [...]
>>> Also Apache needs a release policy for binaries that would allow the best 
>>> UX/UI API for the platform to be used even if it is GPL. If you have 
>>> subscribed to legal-discuss the last few months you know why that 
>>> discussion was impossible. If that can be worked out then at least it would 
>>> help other projects.
>> 
>> can you explain the case a bit? Do you link statically? What is the license?
> 
> We wanted to use Qt, the open source version of which is LGPL. All other 
> suitable candidates we could find were similar; GTK is LGPL, and wxWidgets 
> has a license that is very close to LGPL. We also needed to use WebKit, 
> regardless of the toolkit involved, and that is (mostly I think) LGPL also.
> 
> There was some debate about whether or not it was ok to write an application 
> which used Qt, though we did not propose including any of the actual Qt 
> source code in the release artefacts. It would be used as an external 
> library, dynamically linked, similar to how many programs use glibc.
> 
> An assertion was made in the discussion that if we cannot develop our app 
> without using Qt, it should not be part of the project (I assume this same 
> argument would have been made if we had chosen one of the others above). 
> Given that this app was a major component (though by no means all) of what we 
> planned to do, it seemed that if that argument was valid (and I don’t think 
> it was, but I’m still not sure), we would have to do so outside of ASF.
> 
> There were numerous other factors involved with our design to resign, mostly 
> involving personal disputes among PPMC members which I won’t get into here 
> out of respect for all involved. But the discussion about licensing and 
> implications for the project was one of the factors, and certainly caused a 
> division in the community.
> 
> If it’s not possible to write apps using LGPL libraries as part of apache 
> projects, then this seems to pretty much rule out any cross-platform native 
> desktop apps, unless you write your own toolkit. I realise OpenOffice has 
> it’s own custom toolkit which is still used for historical reasons, but I 
> don’t think that can adapt well to mobile platforms, so other than that that 
> there don’t seem to be any viable choices which could work with the policy.
> 
> —
> Dr Peter M. Kelly
> pmke...@apache.org
> 
> PGP key: http://www.kellypmk.net/pgp-key 
> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
> 

Re: [NOTICE] corinthia PPMC+committer -= dortef, franz, gbg, ianc, jani, louis, pmkelly

[Branko Čibej]

On 06.09.2015 19:43, Peter Kelly wrote:
> If it’s not possible to write apps using LGPL libraries as part of apache 
> projects,

I expect you did get to read this page:
http://www.apache.org/legal/resolved.html

It explains why we cannot include code under certain libraries in our
releases. It's fine to have optional dependencies on code under one of
these licenses, such that the user can include them when they build
binaries from our sources. But "optional" means that the absence of such
a module doesn't affect the core functionality. If the core
functionality is to be a user interface, then you'd have to find an
appropriately-licenses UI toolkit.

I'm not aware of any such toolkit that's compatible with ALv2 ... which
is a  bit of a pain.


-- Brane

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

Re: [NOTICE] corinthia PPMC+committer -= dortef, franz, gbg, ianc, jani, louis, pmkelly

[Jochen Theodorou]

Am 06.09.2015 04:22, schrieb Dave Fisher:
[...]

Also Apache needs a release policy for binaries that would allow the best UX/UI 
API for the platform to be used even if it is GPL. If you have subscribed to 
legal-discuss the last few months you know why that discussion was impossible. 
If that can be worked out then at least it would help other projects.


can you explain the case a bit? Do you link statically? What is the license?

bye blackdrag

--
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/


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

Re: [NOTICE] corinthia PPMC+committer -= dortef, franz, gbg, ianc, jani, louis, pmkelly

[Peter Kelly]

> On 7 Sep 2015, at 1:17 am, Branko Čibej  wrote:
> 
> On 06.09.2015 19:43, Peter Kelly wrote:
>> If it’s not possible to write apps using LGPL libraries as part of apache 
>> projects,
> 
> I expect you did get to read this page:
> http://www.apache.org/legal/resolved.html
> 
> It explains why we cannot include code under certain libraries in our
> releases. It's fine to have optional dependencies on code under one of
> these licenses, such that the user can include them when they build
> binaries from our sources. But "optional" means that the absence of such
> a module doesn't affect the core functionality. If the core
> functionality is to be a user interface, then you'd have to find an
> appropriately-licenses UI toolkit.
> 
> I'm not aware of any such toolkit that's compatible with ALv2 ... which
> is a  bit of a pain.

Indeed. And I did read that page at the time and come away with an 
understanding that’s essentially what you explained, though I think the page 
could be a lot clearer (a direct statement like “You cannot link against LGPL 
libraries” would go a long way to avoiding ambiguity).

My hope (and those of some others on the project) was that we could make our 
editor app an optional component - there are other parts of the project which 
are very much useful in and of themselves. The Qt editor is only part of what 
we had planned (or I should say, have planned, since we’re still going ahead 
with it, just outside of ASF), but we also were working on a web-based editor 
which would not use any LGPL code or that of any other incompatible licenses.

The policy raises the rather tricky question of what can reasonably be 
considered “optional”. For a project with say three components, one of which 
inherently requires an LGPL library, should the latter considered optional? 
Arguments could be made in both ways, but on balance, I suspect probably not.

LGPL allows use in commercial applications, and e.g. WebKit (which is LGPL) has 
been used in Safari, Chrome, and countless other closed-source projects. I sort 
of understand the reasoning behind it’s prohibition; I don’t agree with it, but 
nonetheless it’s considered a resolved issue. I wish I’d realised this coming 
into incubator, since we’d planned a Qt component from the start, but it’s not 
the end of the world - the project will continue on GitHub, where we are free 
as a community to make our own decisions about such matters.

—
Dr Peter M. Kelly
pmke...@apache.org

PGP key: http://www.kellypmk.net/pgp-key 
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)