Hi Rob; I specifically avoided answering to this on Sunday because in my religious beliefs it is a day to rest and I didn't really want to spend time on this.
Since the time this was posted I think I have seen the light (TM) and I am willing to share it with you if you have the patience. The comments that follow are NOT meant for the faint of heart if you are likely to have strong feelings about this please STOP READING NOW. Also, if you are still here, remember ... don't kill $MESSENGER. --- Sab 14/1/12, Rob Weir <[email protected]> ha scritto: > > OK, though this is solving a problem we don't really have, > right? > Although we have not yet built a script to produce a source > package per Apache rules, when we do it will not include > any of the /ext-src modules, correct? It won't include > the category-a and it will not include the category-b > either? What would be the point, since the > build script brings down what it needs via the bootstrap, > per the configuration flags used? So if we really want to > give proper notice to the person downloading our source > release, this needs to be done: We do have to include Category-A in the release or the release wont build. Separation has to happen. Here is the first big flaw in your reasoning: there is no such thing as a source release or a binary release, there is simply a release. Let me explain it this way: long, long ago, before the Internet ever was, release engineers would talk about preparing the distribution stuff they could put into specific media as a Release. The media then was usually tapes, later floppies, then CDs, and with the advent of the Internet new forms of media appeared and new formats corresponded to those distribution, ZIP files, .tar.gz archives, you get the idea. Eventually, new releases and updates were made available by electronic means without dealing directly with tarballs or zipfiles and the tendency is indeed to use such modern methods when possible. One of such methods is called "subversion" (SVN) and it has been very popular in the advent of Opensource software, where the source code is sometimes more important than the accidental binaries. And the point here is: a release is not just what is included in a source tarball or a zipfile it is what is tagged and branched in SVN. Also, if you check the documentation on how tags and branches are created you will notice we have to clearly separate what belongs to the release to what doesn't. > > I have no objections if you want to shuffle things around > in the directory structure, and update bootstrap logic > accordingly. "shuffling" things is not a problem but I don't think updating the bootstrap logic was mandatory. Our releases have to build on their own and as you note the sources for Category B stuff are not included anyways, but let me point out the second big failure in your reasoning. As I said before there is no such thing as "source releases" or "binary releases" and such terms don't appear anywhere in the the Apache licensing policies: http://www.apache.org/legal/3party.html Now, this phrase concerning Category-B has received a particular wrong reading: "Code that is more substantial, more volatile, or not directly consumed at runtime in source form may only be distributed in binary form." We, and particularly you, have read this as a prohibition to include MPL'd code in "source release" but the truth is that it is a prohibition to distribute Category-B software *at all*. Distribution certainly includes subversion. The point is further clarified: "In addition, C-based projects may have difficulty using works under these licenses since they would have to deal with platform-specific binaries, rather than just distributing source that can be built on most any platform." This last clarification has an upside: we can include in our releases (and therefore in SVN) platform independent files like Java bytecode and fonts under a Category-B license. Pedro. PS. My proposal was a step in the right direction but given that it's already insufficient I hereby withdraw it.
