incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <dennis.hamil...@acm.org>
Subject RE: Binary dependencies in source releases (Was: [VOTE] Release ManifoldCF 0.5-incubating, RC0)
Date Wed, 28 Mar 2012 16:52:57 GMT
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:robweir@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 <fielding@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message