corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <dennis.hamil...@acm.org>
Subject RE: Is Qt the right choice ??
Date Tue, 04 Aug 2015 16:46:33 GMT
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 <lrosen@rosenlaw.com>
Subject: RE: Third Party FOSS licenses

On Aug 3, 2015 16:48, "Lawrence Rosen" <lrosen@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]



Mime
View raw message