incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject Re: [VOTE] Apache cTAKES 3.0.0-incubating RC5 release
Date Fri, 25 Jan 2013 03:23:24 GMT
It's unfortunate to have this conversation in parallel here and on
https://issues.apache.org/jira/browse/LEGAL-157.

Also, this thread is a combo of the discussion of ordinary
jars-of-classes (where I'd forgotten the policy) and the much more
tangled question of models, which is what the JIRA is wrestling with.

To answer Ted, I think that Roy might write something like:

"It's not the mission of the ASF to create complete,
end-user-friendly, software products. It's our mission to create open
source code. If someone else wants to build up an end-user-friendly
aggregation of ASF code and models from bombs of whatever, that's
great, and we encourage them."

On Thu, Jan 24, 2013 at 8:19 PM, Branko Čibej <brane@apache.org> wrote:
> On 25.01.2013 01:50, Ted Dunning wrote:
>> On Fri, Jan 25, 2013 at 7:37 AM, Branko Čibej <brane@apache.org> wrote:
>>
>>> On 21.01.2013 21:08, Benson Margulies wrote:
>>> ...>>
>>>>> I am referring to this discussion  http://s.apache.org/MUZ
>>>> Well, that clear enough, even if it is a typical example of how our
>>>> founders yell at us but we have no mechanism to channel those yells
>>>> into concise, unambiguous, documentation.
>>> Per haps off-topic ... but I fail to see how "source release" is
>>> ambiguous or not concise.
>>>
>>> Unless the Java world has a different definition of "source code" than
>>> us stuck-in-the-mud plodders, and it's only considered binary once it's
>>> been JIT-compiled. :)
>>>
>>
>> It isn't necessarily ambiguous when applied to code, but there is a
>> different case when applied to models  or parameter settings.
>>
>> For instance, commons match has polynomial coefficients embedded in code
>> that approximate certain functions.  These are the results of computations
>> done using other systems and the source code and the data used in those
>> other computations are not included in the released code, only the
>> parameter values are.
>>
>> This same sort of thing applies here except that the model in question has
>> a much larger set of values and is being packaged in a binary, inspectable
>> format.  Would your opinion change if the model were expressed in a textual
>> model?  Would it matter that the textual model is too large and obtuse to
>> usefully inspect?
>
> In cases like this one, it would seem reasonable for the source code to
> refer to those models and computations, which presumably anyone can then
> reproduce to their own satisfaction. This is unlike compiled code in
> that compilation results are notoriously hard to reproduce exactly,
> because they depend on many factors that are usually hard to document,
> let alone reproduce. I'd expect a mathematical model, no matter how
> large, does not suffer from such ambiguities (and shut up, Gödel).
>
> However, that's beside the point, because ...
>
>> What about a hypothetical case where the model is derived from the
>> explosion of a nuclear bomb?  Would the release of the numbers require the
>> inclusion of a suitable bomb design so that everybody could replicate the
>> derivation?
>
> ... the issue is not about the exposing all the knowledge that goes into
> writing the code, but to expose the code itself so that it can be
> reviewed for, e.g., back-doors and other security issues. Neither of
> your examples is relevant.
>
> -- Brane
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message