incubator-ctakes-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy McMurry <>
Subject Re: [VOTE] Apache cTAKES 3.0.0-incubating RC5 release
Date Fri, 25 Jan 2013 21:30:58 GMT
Hello ! 

I work with Geurgana and Pei and Britt on the de-identification software and papers using

>>> We already have a maven repository and bamboo server for at least as long as
it takes to clear this ASF issue. << 

In my experience anytime "open source" and "legal doubts" are mixed the answer can drag on
for unreasonably long. 
We can host binaries and continuous integration on without much effort.

This is how how already host binary dists for Scrubber (de-id engine that depends on ctakes).

We could easily do the same for cTAKES. 

BINARY DISTS (maven repo );quick~scrubber


I offered Guergana the Maven repo and Bamboo builds last year. 
From memory, I think she just wanted to use whatever things were the least time consuming.

If ASF is questionable about binary hosting, we can host on (and build  continuously).

TL;DR: Maven Repo with continuous builds for cTAKES. 
Its a good thing. 

Yay, nay? Hooray? 

-- Andy McMurry

On Jan 25, 2013, at 11:04 AM, "Mattmann, Chris A (388J)" <>

> Guys, FYI if you want to follow on general@ there is a question posed for
> cTAKES community. Binary convenience bits aren't dead. Let's get a
> resolution to the LEGAL issue again calling for outright objections or
> otherwise lazy consensus (again) for another week and then just move on.
> The binary convenience bits can come in this release, or in a future one
> (as Pei suggested) but let's just move this on, it's a never ending thread
> of potentially conflicting information that won't get a resolution b/c
> it's up to the community to work within the confines of the ASF (which are
> surprisingly not as black and white) to make it happen.
> Cheers,
> Chris
> On 1/25/13 10:59 AM, "Mattmann, Chris A (388J)"
> <> wrote:
>> Hi Guys,
>> On 1/25/13 10:29 AM, "Benson Margulies" <> wrote:
>> [...snip...]
>>>> Sorry, that's really what I meant: to think about that file as to
>>>> whether it
>>>> can do any harm and how to determine its safety.  I haven't looked at
>>>> the
>>>> file, but it sounds like you know it can do harm.
>>> Depends on what you mean by 'harm'. A model could exhibit hostile
>>> behavior, intentionally giving wrong or biased answers for certain
>>> inputs. Some people would call that 'harm'. Others would focus on
>>> malware, in which case having the model be a big file of numbers that
>>> gets turned into a big array would indeed be defined as harmless.
>> So, this is all conjecture. I don't think either of us are qualified
>> Benson to comment or even remotely suggest the harmful nature, validity,
>> etc., of a medical model, or set of them developed by institutions who
>> have accepted the risk (well beyond the ASF's willing accepted risk, etc.,
>> for *software*) of leveraging the model for scientific study and
>> prediction. Those institutions go as high up as the National Institutes of
>> Health, the Department of Health and Human Services, etc., etc.
>> Here's what it boils down to -- I get Roy's point, but does everyone else
>> get Roy's point? Roy isn't going to *sanction* wearing big ASF hat the
>> inclusion of things that the ASF isn't willing to accept risk on. The good
>> news? The ASF is NOT a top down organization it's a bottom up one with
>> minimal centralized oversight. That being said there's a subtle hint Roy's
>> text on record that describes what *individuals* as part of a PMC (who are
>> the ones that *release* the software) are, and are not able to do, and
>> what risk they are and are not able to (implied) take on, and perform,
>> within their community. This isn't the ASF coming top down with a policy
>> (good luck every getting one) -- but it's something that has happened in
>> the past with respect to binary "convenience" bits that even people like
>> Roy say can go on the server.
>> So, why don't we let this sit for a bit, and cTAKES community (and
>> mentors, please speak up) if we are still wanting to proceed down this
>> path, then let's do so, and I think we're going to be OK.
>> See post from Jukka Zitting and I on cTAKES lists:
>> Cheers,
>> Chris
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

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