You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@corinthia.apache.org by "Dennis E. Hamilton" <de...@acm.org> on 2015/08/04 18:46:33 UTC
RE: Is Qt the right choice ??
The actual construction of a functioning editor that might be available in a source release and also a convenience binary for one or more platforms is a bit down the road. I understand that.
Nevertheless, I am concerned that this podling is playing with fire and tempting unfortunate consequences.
I just want to give fair warning that even an "example" having only unapproved dependencies may be frowned upon if one cannot build a fully functioning version from the release without such a dependency. Satisfying that condition would be a great example and also in the spirit and letter of ASF requirements for software provided by its projects.
The NULL case that I have seen described does not qualify as fully-functioning, in my opinion. I look forward to further details in that approach so one can explore providing a reference version having full functionality the substitutability of dependencies, including optional use of Qt.
I have nothing more to add beyond this cautionary warning concerning the attraction of a Qt-first approach.
- Dennis
MORE BACKGROUND
There are periodically long and contentious discussions about non-category-A dependencies from Apache Project source code. One is going on at the moment. These tend to come from one vocal advocate. The Foundation, so far, has not accepted those arguments and sticks to its official policy, regardless of what the specifics of various non-category-A licenses might or might not allow.
The abridged message, below, is representative of a recent response about comingling of dependencies on category-B and category-X (i.e., [L]GPL) in any manner. You can see the complete message, and the related thread, at
< http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201508.mbox/%3CCACsi251pLmV8qKf5NFuJ-oK02KWLLwdTwBXn6JQVc7J0%2BUvqXQ%40mail.gmail.com%3E>.
I chose this message, posted today, because the author summarizes what I have seen to be where all of these debates end up. Rowe has provided a perfect capsule summary with a warning case.
- Dennis
----- Forwarded Message (abridged) -----
From: William A Rowe Jr [mailto:wrowe@rowe-clan.net]
Sent: Monday, August 3, 2015 23:46
To: legal-discuss@apache.org; Lawrence Rosen <lr...@rosenlaw.com>
Subject: RE: Third Party FOSS licenses
On Aug 3, 2015 16:48, "Lawrence Rosen" <lr...@rosenlaw.com> wrote:
[ ... ]
> I admit that "copyleft" includes MPLv2, EPL, GPL, and lots of other licenses, although DRM for binaries is irrelevant for FOSS software. And true enough, as long as those components are and remain FOSS, you are free to create derivative works but you must reciprocate with your license.
Which is why they are category X, yes. Where they are optionally part of a larger combination of ASF and external works, whether X or B, that provides the benefit of a larger FOSS ecosystem, but its long been codified in policy that ASF works cannot require such components to be functional.
[ ... ]
The APR project has a set of interfaces for a number of key value data stores. The license terms vary widely. In creating binaries, the user may combine with whichever are both acceptably licensed and offer acceptable performance. A downstream licensor such as some BSDs might never include the [L]GPL providers, but has other effective options to combine with BSD licensed clients.
If projects seek to build something that only functions with [L]GPL solutions, it is a issue and that project has better homes elsewhere in the sphere of FOSS foundations.
Indeed, dependencies can be resolved, but here the onus is on the PMC to find those alternatives. One incubating project already demonstrated they could not remove a key ffmpeg dependent, and that project, warned early on, was eventually retired without graduating.
> And anyway, such decisions are not yours and mine to make, but for each PMC and each customer to decide for itself. That's the policy change.
No, the PMC doesn't have that authority until the policy is changed. [ ... ]
[end of abridged extract]
RE: Is Qt the right choice ??
Posted by "Dennis E. Hamilton" <de...@acm.org>.
I've said my piece about what I consider the hazards of a Qt-first approach, even as an example.
However, I was pointed to an important policy document as part of a separate discussion. I recommend that folks look at <http://www.apache.org/legal/resolved.html#prohibited> and the statement "Can Apache Projects Rely on Components whose Licensing Affects the Apache Project?"
I recommend that passage because it provides the yardstick for acceptable Optional dependencies and how they are handled. This certainly applies to Category X (such as [L]GPL) dependencies.
Please keep that in mind.
I will now shut up about that.
- Dennis
-----Original Message-----
From: jan i [mailto:jani@apache.org]
Sent: Tuesday, August 4, 2015 23:53
To: dev@corinthia.incubator.apache.org
Subject: Re: Is Qt the right choice ??
On Wednesday, August 5, 2015, Peter Kelly <pm...@apache.org> wrote:
> Fair point - to be honest I really don’t want to do the GUI work, and
> think that the resistance against Qt is extremely …. how should I say,
> unfortunate.
please remember the resistance is pretty isolated, and please believe I had
not made my suggestion about an editor framework had I not had a qualified
idea that it is acceptable.
[ ... ]
Re: Is Qt the right choice ??
Posted by jan i <ja...@apache.org>.
On Wednesday, August 5, 2015, Peter Kelly <pm...@apache.org> wrote:
> Fair point - to be honest I really don’t want to do the GUI work, and
> think that the resistance against Qt is extremely …. how should I say,
> unfortunate.
please remember the resistance is pretty isolated, and please believe I had
not made my suggestion about an editor framework had I not had a qualified
idea that it is acceptable.
>
> Sometimes the most effective way of motivating me is to make me angry. The
> “fine, i’ll write my own damn cross-platform UI toolkit” response is what’s
> been driving me the fast few days :)
>
> But I agree this is work other equally-capable members of the project
> could do, my time is best devoted to Flat (which I enjoy working on much
> more).
once you have verfied zip on the other platforms I will make the release
branch. This will not take much of my time. so I could start making a
design proposal which we all can discuss.
>
> Dennis, is the UI abstraction layer something you would be willing to
> contribute to?
good idea, Dennis has experience from AOO and other places, that would be
nice to integrate.
rgds
jan i
>
> —
> Dr Peter M. Kelly
> pmkelly@apache.org <javascript:;>
>
> PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
>
> > On 5 Aug 2015, at 1:29 pm, jan i <jani@apache.org <javascript:;>> wrote:
> >
> > With all due respect I am a bit concerned.
> >
> > I think the interface to Qt and e.g. Cocoa, is a important interface for
> > the project, so we should discuss the general design before you start
> just
> > programming. I have
> > no doubt that you are capable of doing it, but I am also sure there are
> > other people (like myself) who also have experience can attribute
> > positively to make the
> > interface more flexible and a community effort.
> >
> > My second concern is that you are also working on "flat", which seems to
> me
> > to be the most critical part for the project. I have a good understanding
> > of what you are developing, but I am pretty sure the others don´t.
> >
> > You do not want to be the main programmer, but by taking all the
> > interesting pieces and leaving bread crumbs, you will continue to stay
> the
> > main developer. I
> > am not the one to block you from doing things, but I would wish you would
> > concentrate on getting flat to a condition where we can release it. The
> > editor framework is
> > surely a lower priority and can be done by others (e.g. me) of course
> with
> > the input from the rest of the team.
> >
> > I know you have a fantastic energy and burn for the project, so please do
> > not read this as I am criticizing, please read it as a concern as to how
> we
> > get others
> > to be main developers alongside you.
> >
> > We do not get new main developers, by developing pieces to interfaces you
> > have defined. Taking me as the example, I have Qt experience (did core
> work
> > on Qt years ago) but have 0% interest in developing code to a given
> > interface for a platform I do not care about, so I would do other things
> > (like I just did 32/64bit and zip), but
> > it means I would not be a main developer.
> >
> > rgds
> > jan i.
> >
> >
> >
> > On 5 August 2015 at 05:53, Peter Kelly <pmkelly@apache.org
> <javascript:;>> wrote:
> >
> >>> On 4 Aug 2015, at 11:46 pm, Dennis E. Hamilton <
> dennis.hamilton@acm.org <javascript:;>>
> >> wrote:
> >>>
> >>> The actual construction of a functioning editor that might be available
> >> in a source release and also a convenience binary for one or more
> platforms
> >> is a bit down the road. I understand that.
> >>>
> >>> Nevertheless, I am concerned that this podling is playing with fire and
> >> tempting unfortunate consequences.
> >>>
> >>> I just want to give fair warning that even an "example" having only
> >> unapproved dependencies may be frowned upon if one cannot build a fully
> >> functioning version from the release without such a dependency.
> Satisfying
> >> that condition would be a great example and also in the spirit and
> letter
> >> of ASF requirements for software provided by its projects.
> >>>
> >>> The NULL case that I have seen described does not qualify as
> >> fully-functioning, in my opinion. I look forward to further details in
> >> that approach so one can explore providing a reference version having
> full
> >> functionality the substitutability of dependencies, including optional
> use
> >> of Qt.
> >>
> >> As part of the abstraction layer I am developing, my intention is to
> make
> >> a Cocoa backend (Apple’s API for building native OS X apps), as well as
> a
> >> Qt backend. Thus we will have at least one platform on which it is
> possible
> >> to build a fully-functioning version of the editor, and thus we can
> include
> >> it as a core component of a Corinthia distribution.
> >>
> >> The Qt backend will be optional in the sense that someone can choose not
> >> to use it, if they prefer to instead write their own abstraction layer
> for
> >> whatever platform they are targeting.
> >>
> >> Contributions in the form of code to help support more platforms without
> >> Qt will be very welcome.
> >>
> >> —
> >> Dr Peter M. Kelly
> >> pmkelly@apache.org <javascript:;>
> >>
> >> PGP key: http://www.kellypmk.net/pgp-key <
> http://www.kellypmk.net/pgp-key>
> >> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
> >>
> >>
>
>
--
Sent from My iPad, sorry for any misspellings.
Re: Is Qt the right choice ??
Posted by Peter Kelly <pm...@apache.org>.
Fair point - to be honest I really don’t want to do the GUI work, and think that the resistance against Qt is extremely …. how should I say, unfortunate.
Sometimes the most effective way of motivating me is to make me angry. The “fine, i’ll write my own damn cross-platform UI toolkit” response is what’s been driving me the fast few days :)
But I agree this is work other equally-capable members of the project could do, my time is best devoted to Flat (which I enjoy working on much more).
Dennis, is the UI abstraction layer something you would be willing to contribute to?
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
> On 5 Aug 2015, at 1:29 pm, jan i <ja...@apache.org> wrote:
>
> With all due respect I am a bit concerned.
>
> I think the interface to Qt and e.g. Cocoa, is a important interface for
> the project, so we should discuss the general design before you start just
> programming. I have
> no doubt that you are capable of doing it, but I am also sure there are
> other people (like myself) who also have experience can attribute
> positively to make the
> interface more flexible and a community effort.
>
> My second concern is that you are also working on "flat", which seems to me
> to be the most critical part for the project. I have a good understanding
> of what you are developing, but I am pretty sure the others don´t.
>
> You do not want to be the main programmer, but by taking all the
> interesting pieces and leaving bread crumbs, you will continue to stay the
> main developer. I
> am not the one to block you from doing things, but I would wish you would
> concentrate on getting flat to a condition where we can release it. The
> editor framework is
> surely a lower priority and can be done by others (e.g. me) of course with
> the input from the rest of the team.
>
> I know you have a fantastic energy and burn for the project, so please do
> not read this as I am criticizing, please read it as a concern as to how we
> get others
> to be main developers alongside you.
>
> We do not get new main developers, by developing pieces to interfaces you
> have defined. Taking me as the example, I have Qt experience (did core work
> on Qt years ago) but have 0% interest in developing code to a given
> interface for a platform I do not care about, so I would do other things
> (like I just did 32/64bit and zip), but
> it means I would not be a main developer.
>
> rgds
> jan i.
>
>
>
> On 5 August 2015 at 05:53, Peter Kelly <pm...@apache.org> wrote:
>
>>> On 4 Aug 2015, at 11:46 pm, Dennis E. Hamilton <de...@acm.org>
>> wrote:
>>>
>>> The actual construction of a functioning editor that might be available
>> in a source release and also a convenience binary for one or more platforms
>> is a bit down the road. I understand that.
>>>
>>> Nevertheless, I am concerned that this podling is playing with fire and
>> tempting unfortunate consequences.
>>>
>>> I just want to give fair warning that even an "example" having only
>> unapproved dependencies may be frowned upon if one cannot build a fully
>> functioning version from the release without such a dependency. Satisfying
>> that condition would be a great example and also in the spirit and letter
>> of ASF requirements for software provided by its projects.
>>>
>>> The NULL case that I have seen described does not qualify as
>> fully-functioning, in my opinion. I look forward to further details in
>> that approach so one can explore providing a reference version having full
>> functionality the substitutability of dependencies, including optional use
>> of Qt.
>>
>> As part of the abstraction layer I am developing, my intention is to make
>> a Cocoa backend (Apple’s API for building native OS X apps), as well as a
>> Qt backend. Thus we will have at least one platform on which it is possible
>> to build a fully-functioning version of the editor, and thus we can include
>> it as a core component of a Corinthia distribution.
>>
>> The Qt backend will be optional in the sense that someone can choose not
>> to use it, if they prefer to instead write their own abstraction layer for
>> whatever platform they are targeting.
>>
>> Contributions in the form of code to help support more platforms without
>> Qt will be very welcome.
>>
>> —
>> Dr Peter M. Kelly
>> pmkelly@apache.org
>>
>> PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
>> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
>>
>>
Re: Is Qt the right choice ??
Posted by jan i <ja...@apache.org>.
With all due respect I am a bit concerned.
I think the interface to Qt and e.g. Cocoa, is a important interface for
the project, so we should discuss the general design before you start just
programming. I have
no doubt that you are capable of doing it, but I am also sure there are
other people (like myself) who also have experience can attribute
positively to make the
interface more flexible and a community effort.
My second concern is that you are also working on "flat", which seems to me
to be the most critical part for the project. I have a good understanding
of what you are developing, but I am pretty sure the others don´t.
You do not want to be the main programmer, but by taking all the
interesting pieces and leaving bread crumbs, you will continue to stay the
main developer. I
am not the one to block you from doing things, but I would wish you would
concentrate on getting flat to a condition where we can release it. The
editor framework is
surely a lower priority and can be done by others (e.g. me) of course with
the input from the rest of the team.
I know you have a fantastic energy and burn for the project, so please do
not read this as I am criticizing, please read it as a concern as to how we
get others
to be main developers alongside you.
We do not get new main developers, by developing pieces to interfaces you
have defined. Taking me as the example, I have Qt experience (did core work
on Qt years ago) but have 0% interest in developing code to a given
interface for a platform I do not care about, so I would do other things
(like I just did 32/64bit and zip), but
it means I would not be a main developer.
rgds
jan i.
On 5 August 2015 at 05:53, Peter Kelly <pm...@apache.org> wrote:
> > On 4 Aug 2015, at 11:46 pm, Dennis E. Hamilton <de...@acm.org>
> wrote:
> >
> > The actual construction of a functioning editor that might be available
> in a source release and also a convenience binary for one or more platforms
> is a bit down the road. I understand that.
> >
> > Nevertheless, I am concerned that this podling is playing with fire and
> tempting unfortunate consequences.
> >
> > I just want to give fair warning that even an "example" having only
> unapproved dependencies may be frowned upon if one cannot build a fully
> functioning version from the release without such a dependency. Satisfying
> that condition would be a great example and also in the spirit and letter
> of ASF requirements for software provided by its projects.
> >
> > The NULL case that I have seen described does not qualify as
> fully-functioning, in my opinion. I look forward to further details in
> that approach so one can explore providing a reference version having full
> functionality the substitutability of dependencies, including optional use
> of Qt.
>
> As part of the abstraction layer I am developing, my intention is to make
> a Cocoa backend (Apple’s API for building native OS X apps), as well as a
> Qt backend. Thus we will have at least one platform on which it is possible
> to build a fully-functioning version of the editor, and thus we can include
> it as a core component of a Corinthia distribution.
>
> The Qt backend will be optional in the sense that someone can choose not
> to use it, if they prefer to instead write their own abstraction layer for
> whatever platform they are targeting.
>
> Contributions in the form of code to help support more platforms without
> Qt will be very welcome.
>
> —
> Dr Peter M. Kelly
> pmkelly@apache.org
>
> PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
>
>
Re: Is Qt the right choice ??
Posted by Peter Kelly <pm...@apache.org>.
> On 4 Aug 2015, at 11:46 pm, Dennis E. Hamilton <de...@acm.org> wrote:
>
> The actual construction of a functioning editor that might be available in a source release and also a convenience binary for one or more platforms is a bit down the road. I understand that.
>
> Nevertheless, I am concerned that this podling is playing with fire and tempting unfortunate consequences.
>
> I just want to give fair warning that even an "example" having only unapproved dependencies may be frowned upon if one cannot build a fully functioning version from the release without such a dependency. Satisfying that condition would be a great example and also in the spirit and letter of ASF requirements for software provided by its projects.
>
> The NULL case that I have seen described does not qualify as fully-functioning, in my opinion. I look forward to further details in that approach so one can explore providing a reference version having full functionality the substitutability of dependencies, including optional use of Qt.
As part of the abstraction layer I am developing, my intention is to make a Cocoa backend (Apple’s API for building native OS X apps), as well as a Qt backend. Thus we will have at least one platform on which it is possible to build a fully-functioning version of the editor, and thus we can include it as a core component of a Corinthia distribution.
The Qt backend will be optional in the sense that someone can choose not to use it, if they prefer to instead write their own abstraction layer for whatever platform they are targeting.
Contributions in the form of code to help support more platforms without Qt will be very welcome.
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
Re: Is Qt the right choice ??
Posted by jan i <ja...@apache.org>.
On 4 August 2015 at 18:46, Dennis E. Hamilton <de...@acm.org>
wrote:
> The actual construction of a functioning editor that might be available in
> a source release and also a convenience binary for one or more platforms is
> a bit down the road. I understand that.
>
> Nevertheless, I am concerned that this podling is playing with fire and
> tempting unfortunate consequences.
>
> I just want to give fair warning that even an "example" having only
> unapproved dependencies may be frowned upon if one cannot build a fully
> functioning version from the release without such a dependency. Satisfying
> that condition would be a great example and also in the spirit and letter
> of ASF requirements for software provided by its projects.
>
> The NULL case that I have seen described does not qualify as
> fully-functioning, in my opinion. I look forward to further details in
> that approach so one can explore providing a reference version having full
> functionality the substitutability of dependencies, including optional use
> of Qt.
>
It is a fair opinion, which we have to disagree on...providing a framework
is not the same as providing an editor.
>
> I have nothing more to add beyond this cautionary warning concerning the
> attraction of a Qt-first approach.
>
Thanks for the warning, it is always nice to have a sanity check.
>
> - Dennis
>
> MORE BACKGROUND
>
> There are periodically long and contentious discussions about
> non-category-A dependencies from Apache Project source code. One is going
> on at the moment. These tend to come from one vocal advocate. The
> Foundation, so far, has not accepted those arguments and sticks to its
> official policy, regardless of what the specifics of various non-category-A
> licenses might or might not allow.
>
It sure is ongoing, but it actually targeting something quite different.
This discussion is more about why we cannot distribute 3rd party as part of
our code.
>
> The abridged message, below, is representative of a recent response about
> comingling of dependencies on category-B and category-X (i.e., [L]GPL) in
> any manner. You can see the complete message, and the related thread, at
> <
> http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201508.mbox/%3CCACsi251pLmV8qKf5NFuJ-oK02KWLLwdTwBXn6JQVc7J0%2BUvqXQ%40mail.gmail.com%3E
> >.
>
> I chose this message, posted today, because the author summarizes what I
> have seen to be where all of these debates end up. Rowe has provided a
> perfect capsule summary with a warning case.
>
he sure does. I still do not see the relevance to a framework, that does
not include 3rd party code.
Again should we actually have trouble down the road (which you warn about,
and I do not believe), then we only release the framework, end of story.
Any PPMC or a group of PPMC can then publish (mark the difference, not
release) the rest.
rgds
jan i.
>
> - Dennis
>
> ----- Forwarded Message (abridged) -----
> From: William A Rowe Jr [mailto:wrowe@rowe-clan.net]
> Sent: Monday, August 3, 2015 23:46
> To: legal-discuss@apache.org; Lawrence Rosen <lr...@rosenlaw.com>
> Subject: RE: Third Party FOSS licenses
>
> On Aug 3, 2015 16:48, "Lawrence Rosen" <lr...@rosenlaw.com> wrote:
> [ ... ]
> > I admit that "copyleft" includes MPLv2, EPL, GPL, and lots of other
> licenses, although DRM for binaries is irrelevant for FOSS software. And
> true enough, as long as those components are and remain FOSS, you are free
> to create derivative works but you must reciprocate with your license.
>
> Which is why they are category X, yes. Where they are optionally part of
> a larger combination of ASF and external works, whether X or B, that
> provides the benefit of a larger FOSS ecosystem, but its long been codified
> in policy that ASF works cannot require such components to be functional.
>
> [ ... ]
> The APR project has a set of interfaces for a number of key value data
> stores. The license terms vary widely. In creating binaries, the user may
> combine with whichever are both acceptably licensed and offer acceptable
> performance. A downstream licensor such as some BSDs might never include
> the [L]GPL providers, but has other effective options to combine with BSD
> licensed clients.
>
> If projects seek to build something that only functions with [L]GPL
> solutions, it is a issue and that project has better homes elsewhere in the
> sphere of FOSS foundations.
> Indeed, dependencies can be resolved, but here the onus is on the PMC to
> find those alternatives. One incubating project already demonstrated they
> could not remove a key ffmpeg dependent, and that project, warned early on,
> was eventually retired without graduating.
>
> > And anyway, such decisions are not yours and mine to make, but for each
> PMC and each customer to decide for itself. That's the policy change.
> No, the PMC doesn't have that authority until the policy is changed. [ ...
> ]
>
> [end of abridged extract]
>
>
>