I was thinking about binary-only components such as a linker library or shared library that was under a non-Apache license but that needed to be included in deployments of OpenOffice.org. That would require a different version of the binary-only component for every platform environment the Apache code is expected to build for and deploy to.
Since OpenOffice.org code is mostly C++ and the trend is to remove the Java dependencies (at least over on LibreOffice), this seems more awkward than whatever the benefit might be. I need to step back and look at this more carefully. My starting-out assumptions are that OpenOffice.org builds don't depend on binary-only components in deployed distributions. In addition, I'm trusting that any dependencies on third-party source code or binary libraries are either non-toxic, can be worked-around/done-without for as long as we'd need to have an alternative in place. Whistling in the dark here ... - Dennis -----Original Message----- From: Greg Stein [mailto:gst...@gmail.com] Sent: Saturday, June 04, 2011 23:22 To: dennis.hamil...@acm.org; general@incubator.apache.org Subject: RE: OO/LO License + Why LO needs the AFL 2.0 to exist (quickly) On Jun 4, 2011 6:25 PM, "Dennis E. Hamilton" <dennis.hamil...@acm.org> wrote: >... > 2. With regard to building distributions, binary libraries are terribly > awkward unless Apache were to limit its OpenOffice project to a single > platform and programming model. In contrast, LibreOffice is going full-up > C++ and the Java dependencies are shrinking. And for a reference > implementation, or the parts of Apache OpenOffice that could serve that > purpose, I don't think that will fly at all. I'm not sure that I've parsed and understood this. Apache should only ship one binary? Or it should only go Java, or only C++? And is that just (reference) parts, or how we handle the whole distro? .... I'm not trying to poke fun of you here. Just trying to understand where you're going. Thanks, -g --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
