incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Spector <>
Subject Re: [DISCUSS] OpenMiracl for Incubation
Date Tue, 17 Nov 2015 23:06:15 GMT
Hi Shane,

given your role, I'm hoping you can make some suggestions to help us out of
this bind so we can move forward. It would really be appreciated.

As stated previously, 'OpenMiracl: A cryptosystem for cloud computing' is a
'proposed' Apache Project / platform name. MIRACL is the name of the
company contributing most of the initial code out of the gate, along with
NTT and a few others.

The main product we sell is a Datacenter Cryptosystem. Any development work
we do goes directly into the project, and our business is to sell a
supported, documented, QA'd, certified to run on different OS's, etc.,
version of this platform, i.e., the Datacenter Cryptosystem.

In addition, we will offer community (free, no restriction to connect to),
and dedicated, Distributed Trust Authority services (as part of the DC

It's important to note that anyone can and should be able to make a
business out of running a Distributed Trust Authority, and NTT, Experian,
and others plan on running community Distributed Trust Authorities to
support the project on launch.

We have customers such as Experian, the UK government, NTT and others
already using components from the Datacenter Cryptosystem in production at
scale, so it's possibly more mature than some other incubation projects
have been when starting.

That's the plan.

Here is the history, which I think deserves special consideration rather
than a blanket "no".

The "Miracl' name has been trademarked, etc. and we are happy to bequeath,
co-assign, etc., do what we have to do make that good so that the Miracl
name somehow is associated with the project.

This is a special circumstance given the historical nature of the name
MIRACL.  This name has household name recognition amongst professional
cryptographers. It's been a well known cryptographic library for embedded /
constrained (IoT before IoT) device environments since 1991.

You will find the Miracl crypto library in everything from IoT devices to
mobile chips, handsets, software applications and beyond. The closed source
licensees range from Intel, Google, Microsoft, ARM, Siemens, etc.

We want the generation of professional cryptographers who know MIRACL
library to know that this is part of the larger 'OpenMiracl: cryptosystem
for cloud computing' platform. The success of this project depends on
getting this group (cryptographers) involved. They are not an easy audience
to connect with.

We are bequeathing components from this library, which had been AGPL with
closed source option, to Apache Foundation as part of the wider software
stack that goes with OpenMiracl: A cryptosystem for cloud computing.

What do you suggest we do? Do you think it's worth it given the history to
dump the 'MIRACL' name from the project?

I can't speak to the bad decisions that were made regarding past
alliterations but I would hate to see the historical circumstance not be
considered in the overall view.


On Tue, Nov 17, 2015 at 8:08 PM, Shane Curcuru <> wrote:

> Marvin Humphrey wrote on 11/11/15 12:42 AM:
> > On Tue, Nov 10, 2015 at 9:32 PM, Nick Kew <> wrote:
> >
> >>> The ASF project called OpenMiracl and Certivox/MIRACL continuing to
> use the
> >>> MIRACL mark would seem to muddy the water between the two. Would this
> not
> >>> disadvantage others building something based on OpenMiracl?
> Merely adding "Open" to "Miracl" does not really make them separate
> brands, so if they both existed as the same kind of functionality, it
> would be a clear problem.
> >>
> >> Isn't it the same distinction as Mesos vs Mesosphere?
> >
> > Or, sadly, CouchBase and CouchDB.  Not contesting the name Mesosphere
> > was a mistake, just as not contesting CouchBase was a mistake. I hope
> > we do not keep making the same mistake.
> Indeed, you should not draw conclusions or future actions from
> individual past branding questions like those two, nor from how some
> Subversion projects by third parties are branded - some of those cases
> cited in this thread are... not optimal.
> - Shane
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message