Jan Iverson points out that White-Box is confused with a particular form of software testing. I probably mis-remembered the term for generic labeling, and I am changing it here.
-----Original Message----- From: Dennis E. Hamilton [mailto:[email protected]] Sent: Sunday, December 21, 2014 09:48 To: [email protected] Subject: [PROPOSAL] White-Box Releases Only 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 label" 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. 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/browser>.
