On 4 August 2015 at 18:46, Dennis E. Hamilton <[email protected]> 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:[email protected]] > Sent: Monday, August 3, 2015 23:46 > To: [email protected]; Lawrence Rosen <[email protected]> > Subject: RE: Third Party FOSS licenses > > On Aug 3, 2015 16:48, "Lawrence Rosen" <[email protected]> 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] > > >
