incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <>
Subject Re: Binary dependencies in source releases (Was: [VOTE] Release ManifoldCF 0.5-incubating, RC0)
Date Tue, 27 Mar 2012 17:16:27 GMT
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.

This issue is not open for discussion.  It is is a mandate from the
certificate of this foundation -- our agreement with the State of Delaware
that I signed as incorporator.  It is fundamental to our status as an
IRS 501(c)3 charity. It is the key charter delegated by the board
as part of every TLP resolution: "charged with the creation and
maintenance of open-source software ... for distribution at no charge
to the public."

Class files are not open source.  Jar files filled with class files
are not open source.  The fact that they are derived from open source
is applicable only to what we allow projects to be dependent upon,
not what we vote on as a release package.  Release votes are on verified
open source artifacts.  Binary packages are separate from source packages.
One cannot vote to approve a release containing a mix of source and
binary code because the binary is not open source and cannot be verified
to be safe for release (even if it was derived from open source).

I thought that was frigging obvious.  Why do I need to write documentation
to explain something that is fundamental to the open source definition?

> Also, let's make a clear distinction between "binary distributions"
> (i.e. the packages that result from building one of our source
> releases) and "binary dependencies" (i.e. binary distributions of
> upstream projects). AFAICT there's clear consensus that binary
> distributions are *not* official Apache releases, and we've been
> pretty consistent about that so far. However, the word on binary
> dependencies is much less clear. There's explicit Apache policy
> (category B, etc.) that talks about binary dependencies and plenty of
> Apache releases contain them. This is clearly not an area where we
> have consensus.

Please point those packages out to me and I will ask Joe to give me root
access again so that I can go through and personally delete them from
our dist directories.  Seriously.  I am so tired of having to send these
emails, write the documentation, and then watch Java projects to do the
wrong things again and again.  It is time for the sledgehammer.

The Category B is about products in general, not just source packages.
Yes, that documentation sucks.  Yes, I said so at the time.  No, it is
NOT an approved policy document of the ASF.  The categories are about
software licensing of the product as a whole, including hard dependencies
and built packages, not whether something is included in a source code

> On Tue, Mar 27, 2012 at 11:50 AM, Roy T. Fielding <> wrote:
>> Likewise for jar files of dependencies -- they are NOT our product and they
>> MUST NOT be present in the source code package that is voted on for release.
> Citation needed. Note that the "source materials" reference you
> mentioned earlier is vague. It covers stuff like configure scripts in
> httpd releases, test files, and indeed (as far as it so far has been
> interpreted) binary dependencies of upstream open source projects. I'm
> fine if this point needs to be clarified and some current practice
> terminated, but let's follow standard process to do so.

It isn't even remotely vague.  Source has only one definition.  And it
isn't just that document:

>> If any ASF member is aware of an Apache release package that is not 100%
>> open source code, you are hereby instructed to DELETE it from our servers.
> What hat are you holding here? Which packages explicitly are you referring to?

My hat.  I'll make it a board directive at the next meeting, if you like.
If I had known of any such packages, I would have deleted them already.
Don't you remember the similar conversation we had about Jackrabbit releases?
The only jar files we should have in subversion are the non-product
trees -- the places where we store build tools, the artifacts for binary
packages, website tools, and the dist directories themselves.  They do
not belong in our open source product trees.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message