corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan i <>
Subject Re: Is Qt the right choice ??
Date Tue, 04 Aug 2015 17:34:31 GMT
On 4 August 2015 at 18:46, Dennis E. Hamilton <>

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

jan i.

>  - Dennis
> ----- Forwarded Message (abridged) -----
> From: William A Rowe Jr []
> Sent: Monday, August 3, 2015 23:46
> To:; Lawrence Rosen <>
> Subject: RE: Third Party FOSS licenses
> On Aug 3, 2015 16:48, "Lawrence Rosen" <> 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]

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message