Willem, This issue of embedded binaries for testing purposes has come up before. Examples include network intercepts for testing malware detection or class files for a byte code manipulator. The network files can't easily be recreated since they were observed in the wild and the class files might have been produced by a specific (possibly broken) compiler version that isn't widely available.
The key question is whether these binaries are derived from some source that could be compiled instead of distributing the binary objects. Failing that, can the provenance and justification for the binary object be described? On Sat, Feb 23, 2019 at 6:49 PM Willem Jiang <willem.ji...@gmail.com> wrote: > Hi > > Thanks Justin for the clarification. I guess the policy imply the > source materials cannot have any binary. > But what if the binary is only for testing, which cannot be part of > the released software. > From my point of view, we don't need to modify the source materials > testing binary to do the software release as it is not a part of the > binary release of the software. > > Any thoughts? > > Regards, > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Sat, Feb 23, 2019 at 2:41 PM Justin Mclean <jus...@classsoftware.com> > wrote: > > > > Hi, > > > > > [1]http://www.apache.org/legal/release-policy.html#what > > > > It’s explained in that link there i.e. "The Apache Software Foundation > produces open source software. All releases are in the form of the source > materials needed to make changes to the software being released”. > > > > Thanks, > > Justin > > --------------------------------------------------------------------- > > 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 > >
