www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <kevan.mil...@gmail.com>
Subject Re: What constitutes a source release?
Date Tue, 30 Apr 2013 16:26:57 GMT

In case there are still problems with my mail-archives link, here's the email from general@incubator.
It was under the subject "Binary dependencies in source releases (Was: [VOTE] Release ManifoldCF
0.5-incubating, RC0)": 

On 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.
> http://incubator.apache.org/guides/releasemanagement.html
> 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
> package.
>> On Tue, Mar 27, 2012 at 11:50 AM, Roy T. Fielding <fielding@gbiv.com> 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:
> http://incubator.apache.org/guides/releasemanagement.html#best-practice
>>> 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.
> ....Roy

To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org

View raw message