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 <field...@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: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
