Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <1326730644.49612.YahooMailClassic@web113502.mail.gq1.yahoo.com>
Date: Mon, 16 Jan 2012 08:17:24 -0800 (PST)
From: Pedro Giffuni <pfg@apache.org>
Reply-To: pfg@apache.org
Subject: Re: PROPOSAL (was Re: Category-B tarballs in SVN )
To: ooo-dev@incubator.apache.org
In-Reply-To: 
 <CAP-ksoi1iT5vtzr=4xwudMFN5kUznpYe5P_L0XoSE4QiyKW_1A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Rob;=0A=0AI specifically avoided answering to this on Sunday because=0Ai=
n my religious beliefs it is a day to rest and I didn't=0Areally want to sp=
end time on this.=0A=0ASince the time this was posted I think I have seen t=
he light=0A(TM) and I am willing to share it with you if you have the=0Apat=
ience.=0A=0AThe comments that follow are NOT meant for the faint of=0Aheart=
 if you are likely to have strong feelings about this=0Aplease STOP READING=
 NOW. =0A=0AAlso, if you are still here, remember ... don't kill=0A$MESSENG=
ER.=0A=0A--- Sab 14/1/12, Rob Weir <robweir@apache.org> ha scritto:=0A=0A> =
=0A> OK, though this is solving a problem we don't really have,=0A> right?=
=0A> Although we have not yet built a script to produce a source=0A> packag=
e per Apache rules, when we do it will not include=0A> any of the /ext-src =
modules, correct?=A0 It won't include=0A> the category-a and it will not in=
clude the category-b=0A> either?=A0 What would be the point, since the=0A> =
build script brings down what it needs via the bootstrap,=0A> per the confi=
guration flags used?=A0 So if we really want to=0A> give proper notice to t=
he person downloading our source=0A> release, this needs to be done:=0A=0AW=
e do have to include Category-A in the release or the=0Arelease wont build.=
 Separation has to happen.=0A=0AHere is the first big flaw in your reasonin=
g: there is no=0Asuch thing as a source release or a binary release, there=
=0Ais simply a release.=0A=0ALet me explain it this way: long, long ago, be=
fore the=0AInternet ever was, release engineers would talk about=0Apreparin=
g the distribution stuff they could put into=0Aspecific media as a Release.=
 The media then was usually=0Atapes, later floppies, then CDs, and with the=
 advent of=0Athe Internet new forms of media appeared and new formats=0Acor=
responded to those distribution, ZIP files, .tar.gz=0Aarchives, you get the=
 idea.=0A=0AEventually, new releases and updates were made available=0Aby e=
lectronic means without dealing directly with tarballs=0Aor zipfiles and th=
e tendency is indeed to use such modern=0Amethods when possible. One of suc=
h methods is called=0A"subversion" (SVN) and it has been very popular in th=
e=0Aadvent of Opensource software, where the source code is=0Asometimes mor=
e important than the accidental binaries.=0A=0AAnd the point here is: a rel=
ease is not just what is=0Aincluded in a source tarball or a zipfile it is=
=0Awhat is tagged and branched in SVN. Also, if you=0Acheck the documentati=
on on how tags and branches=0Aare created you will notice we have to clearl=
y separate=0Awhat belongs to the release to what doesn't.=0A=0A=0A=0A> =0A>=
 I have no objections if you want to shuffle things around=0A> in the direc=
tory structure, and update bootstrap logic=0A> accordingly.=0A=0A"shuffling=
" things is not a problem but I don't think=0Aupdating the bootstrap logic =
was mandatory. Our releases=0Ahave to build on their own and as you note th=
e sources for=0ACategory B stuff are not included anyways, but let me point=
=0Aout the second big failure in your reasoning.=0A=0AAs I said before ther=
e is no such thing as "source releases"=0Aor "binary releases" and such ter=
ms don't appear anywhere in=0Athe the Apache licensing policies:=0A=0Ahttp:=
//www.apache.org/legal/3party.html=0A=0ANow, this phrase concerning Categor=
y-B has received a particular=0Awrong reading:=0A=0A"Code that is more subs=
tantial, more volatile, or not directly=0Aconsumed at runtime in source for=
m may only be distributed in=0Abinary form."=0A=0AWe, and particularly you,=
 have read this as a prohibition to=0Ainclude MPL'd code in "source release=
" but the truth is that=0Ait is a prohibition to distribute Category-B soft=
ware *at=0Aall*. Distribution certainly includes subversion.=0A=0AThe point=
 is further clarified:=0A"In addition, C-based projects may have difficulty=
 using works=0Aunder these licenses since they would have to deal with=0Apl=
atform-specific binaries, rather than just distributing=0Asource that can b=
e built on most any platform."=0A=0AThis last clarification has an upside: =
we can include in=0Aour releases (and therefore in SVN) platform independen=
t files=0Alike Java bytecode and fonts under a Category-B license.=0A=0APed=
ro.=0A=0APS. My proposal was a step in the right direction but=0Agiven that=
 it's already insufficient I hereby withdraw=0Ait.=0A