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:wr...@rowe-clan.net] Sent: Monday, August 3, 2015 23:46 To: legal-disc...@apache.org; Lawrence Rosen <lro...@rosenlaw.com> Subject: RE: Third Party FOSS licenses On Aug 3, 2015 16:48, "Lawrence Rosen" <lro...@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]
