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 <br...@apache.org> wrote: > On 25.01.2013 01:50, Ted Dunning wrote: >> On Fri, Jan 25, 2013 at 7:37 AM, Branko Čibej <br...@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-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
