Mailing-List: contact dev-help@corinthia.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@corinthia.incubator.apache.org
MIME-Version: 1.0
In-Reply-To: <002e01d01d46$3eda3b30$bc8eb190$@apache.org>
References: <002e01d01d46$3eda3b30$bc8eb190$@apache.org>
Date: Sun, 21 Dec 2014 19:48:43 +0100
Message-ID: 
 <CAK2iWdTptych5wacJAewG_rGVstQ+XYLCX_ripfTZQwCMPnXxg@mail.gmail.com>
Subject: Re: [PROPOSAL] White-Box Releases Only
From: jan i <jani@apache.org>
To: "dev@corinthia.incubator.apache.org" <dev@corinthia.incubator.apache.org>,
	"orcmid@apache.org" <orcmid@apache.org>
Content-Type: multipart/alternative; boundary=001a113488a2288453050abe640f

--001a113488a2288453050abe640f
Content-Type: text/plain; charset=UTF-8

On Sunday, December 21, 2014, Dennis E. Hamilton <orcmid@apache.org> wrote:

> 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.


Terminology is important here. We will only have source releases, but we
will have several convenience  binaries:
- dfformat library to be embedded in other projects
- dfconvert an appl to convert files
- dftest, is more internal
- editor which hopefully is the appl used most.

all these should be made available on all platforms we support.

I do however not see that as white box or black box, which are terms more
related to test.


>
> 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.


If we use digital signing then it for sure will be a branded product.  In
general I am in favor for branded applications and non-branded libraries
and source.

>
> [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.

+1 we do want to repeat the problems from AOO.

>
> 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.

here we only talk about dfconvert and the editor. It would be nice to have
digital signing for those....and knowing the signing process (with my infra
hat) this is not difficult.

thanks for starting this discussion.

rgds
jan i.

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

-- 
Sent from My iPad, sorry for any misspellings.

--001a113488a2288453050abe640f--