Mailing-List: contact dev-help@corinthia.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@corinthia.incubator.apache.org
Reply-To: <orcmid@apache.org>
From: "Dennis E. Hamilton" <orcmid@apache.org>
To: <dev@corinthia.incubator.apache.org>
Subject: [PROPOSAL] White-Box Releases Only
Date: Sun, 21 Dec 2014 09:47:49 -0800
Organization: Interoperability Architect
Message-ID: <002e01d01d46$3eda3b30$bc8eb190$@apache.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AdAdQliJaxT+0R0ER9a/+Vqs6+Ta4g==
Content-Language: en-us

I am not clear on to what degree Corinthia Source releases will allow =
building of binaries that are end-user meaningful and working in =
anything more than console sessions.  This proposal is intended to =
anticipate the prospect of the code being compilable to store "apps" and =
GUI-based end-user applications on many form factors and platforms.  =
This proposal is particularly relevant to cases where forks will compete =
for monetization, including via embedded advertising and also sales =
through search-engine optimization and purchased ad placement.

PROPOSAL

Corinthia project source code releases and the source-code repository =
shall build to "white box" binaries and distributions/deployments with =
default branding as unsupported Corinthia development editions (stable =
or otherwise).  Provisions for branding of a distribution (and =
distributions of forks) will be incorporated and given default settings. =
 This also extends to producing digitally-signed versions designed to =
satisfy certification requirements for introduction into software "app" =
stores.  There may be instructions for how to successfully build a =
branded and supported authentic distribution, but one should not be =
directly obtainable using the stable source without modification.

[There is no time-limit on this proposal.  Let's see the discussion =
first.]

DISCUSSION

If there are to be convenience binaries that are branded as authentic =
Apache Corinthia (incubating) distributions, there must be an =
arrangement where the branded builds are accomplished in an auditable =
way without releasing the branding materials to the public.  These =
builds cannot be part of the Apache Release process, but there would =
have to be arrangements that demonstrate the integrity of the resulting =
code.=20

Note: This is not intended to prevent commercial derivatives of =
Corinthia source code, whether closed source or with licensed open =
source code.  It's just about misidentification of authentic origins.

ADDRESSING A PROBLEM

It must not be easy to produce a fake product that trades on "Corinthia" =
and its Apache project status as a way of obtaining sales and abdicating =
any support obligations by passing-off to the Corinthia project.  Fakery =
can be innocent/careless, it can be willful (it has to be at least that =
much in the case of this proposal), and it can be malicious.  All of =
these are seen with impersonation of "Open Office" and it can be =
expected in the current mobile space "Wild West" equivalent of =
patent-medicine nostrums.

An example of the situation is on this thread:
<http://mail-archives.apache.org/mod_mbox/openoffice-dev/201412.mbox/brow=
ser>.