I think a bigger issue specifically for Apache OpenOffice has to do with branding and status of the "released" binaries.
It is where the Apache (plus "incubating") origin is brought to the users attention and what will be understood for it. It is served up directly (from the user perspective) from www.openoffice.org and the rebranding of that site as under Apache (plus "incubating") custodianship. There is in no sense an indication that this is a downstream product of the formal Apache source-code release. I suspect that ordinary users would be baffled by such a distinction and find it difficult to see why that is significant. To the extent I understand it, I can sympathize with what Roy Fielding says about provenance and reproducibility. I just don't know how the catch-22 here can be dealt with. - Dennis AN ILL-CHOSEN THOUGHT-PROBLEM? Perhaps not a good example, but one that still nags me in wondering how I would handle it on a non-ASF project, especially in the context of Fielding's maxim, is that it has finally been considered all right to bundle GPL-origin artifacts (spelling dictionary, its index, and any thesaurus) in AOO binary distributions. There appears to me -- and I am not expert in this matter -- that there is no evident means to build those artifacts from what the GPL (and the OSD) deems the source code to be. The original distributors have not seen fit to indicate where that can be found (if it was ever made available). Some claim these artifacts are their own sources, being essentially coded data, and the provision of a reliable location not in the Apache SVN for obtaining them may suffice here. If so, I suspect that modifications carried out to correct and modernize these artifacts needs to be under a same-license project somewhere so that the license conditions on the derivatives are satisfied, including combining into OpenOffice extension artifacts and making them readily available. (They are not readily extracted from the AOO bundle and the resulting installed software, although it is technically possible to separate them out if one knows where to look.) Such a project, if that is the appropriate resolution, needs to be meticulous with regard to the license and having its license-honoring artifacts reliably available. It would appear that must be done elsewhere (but not on Apache Extras?). I suppose it is valuable, in this context, that SourceForge has been helpful with related matters. -----Original Message----- From: Rob Weir [mailto:robw...@apache.org] Sent: Wednesday, March 28, 2012 08:26 To: general@incubator.apache.org Subject: Re: Binary dependencies in source releases (Was: [VOTE] Release ManifoldCF 0.5-incubating, RC0) On Tue, Mar 27, 2012 at 1:16 PM, Roy T. Fielding <field...@gbiv.com> wrote: > On Mar 27, 2012, at 12:57 PM, Jukka Zitting wrote: > > > Hi, > > > > [dropped infra@, I believe most interested people are already on > general@] > > > > Let's decouple this thread from the specific issue of the ManifoldCF > > release. There's a long tradition of Apache releases like the ones > > ManifoldCF is producing, so turning this suddenly into a blocker is > > IMHO bad business, especially since no legal issues are involved (this > > is about Apache policy). If we do come to the consensus that releases > > like this are contrary to Apache policy, then affected projects should > > be given a reasonable amount of time to adapt. > > I don't see where you get the idea that there is a long tradition of > including binary artifacts within the source package releases at Apache. > There may be specific groups who are apparently lacking the appropriate > clue and stubbornly refuse to read the messages I have sent multiple > times to this mailing list, legal-discuss, and members, but there is > no question whatsoever that a source package cannot include binaries. > It would not be a source package otherwise. > > I think this may be overstating things. The issue should be lack of source code, not presence of binary code. For example, I could have a Java code that relies on a native method implemented in C code. I could have a source package that contains the complete Java and the complete C code, all under ALv2. But do we really want to say that we cannot also include, in the source page, the native code, pre-compiled as a convenience for the developer? The alternative would be that a downstream developer who is modifying only unrelated Java portions of the source code would be required to compile the native code on all platforms in order to create a package. (It would also require the PMC to have rather elaborate build rituals to create that JAR, since it would require that we shuffle libraries across multiple buildbots) -Rob --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
