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: <1326486446.61183.YahooMailClassic@web113510.mail.gq1.yahoo.com>
Date: Fri, 13 Jan 2012 12:27:26 -0800 (PST)
From: Pedro Giffuni <pfg@apache.org>
Reply-To: pfg@apache.org
Subject: PROPOSAL (was Re: Category-B tarballs in SVN )
To: ooo-dev@incubator.apache.org
In-Reply-To: 
 <CAP-ksojgo1werGZ9oW-3-j1GWZ9Y8x3N78MdHCruURwzc6xJ=w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hello fellow indians; ;)=0A=0AI think there is consensus that this is (at l=
east)=0Aa gray area so I have the following proposal, which=0Ashouldn't get=
 in the way of having this properly=0Asolved by legal but which I think sho=
uld solve at=0Aleast temporarily the issues that we have. It's=0Aactually v=
ery simple but who knows, maybe it's even=0Aacceptable as a general incubat=
or policy at the ASF.=0A=0AThe ext_source in shall be divided, according to=
=0Athe categories of the licenses, into two=0Adirectories in SVN, namely:=
=0A=0Aext_source_A=0Aext_source_B=0A=0A- Ext_source_B shall have a prominen=
t text note that warns=0Ausers that the code there is made available only f=
or=0Abuilder convenience but that the code is in general=0Anot acceptable f=
or inclusion in Apache source code=0Areleases.=0A=0A- It is understood that=
 ext_source_B is a quarantine=0Aarea. The idea is that the code we have the=
re will=0Aonly shrink with time. The code there can be updated=0Afor securi=
ty reasons but in general no new code should=0Abe brought in without specif=
ic consensus (voting, checking=0Awith the PPMC, etc, but not lazy consensus=
).=0A=0ANOTE: Consensus for replacing standard OOo 3.4=0Afunctionality like=
 the CoinMP solver code is a given=0A(particularly as the licensing is bein=
g worked on) but=0Awe don't want this to be a loophole to bring in MPL'd=0A=
code into AOO.=0A=0AOf course we still have to comply with the standard=0AA=
pache policies concerning Category-B : "Code that is=0Amore substantial, mo=
re volatile, or not directly consumed=0Aat runtime in source form may only =
be distributed in=0Abinary form." but at least now it should be pretty clea=
r=0Aand easy for everyone downloading the code from SVN where=0Athey can ex=
pect licensing issues.=0A=0APedro.=0A