On Thu, Oct 20, 2011 at 7:53 PM, Dennis E. Hamilton <orc...@apache.org> wrote: > I want to point out another case that I have seen in practice, including in > the construction and deployment of binary releases for OpenOffice.org. This > discussion may impinge on that practice in terms of how it can be retained in > Apache OpenOffice.org binary releases and their deployment. >
Life is too short to read all of your notes, Dennis. Could you maybe state up front, in a summary, whether you are raising a question. answering a question, or just digressing? In this case I have no idea what your point is. Thanks, -Rob > - Dennis > > QUASI ARMS-LENGTH DEPENDENCIES: > > In the cases of licenses where the source is not compatible for inclusion in > a release and [patched] libraries are needed to build the OpenOffice.org > code, the practice that I have seen already used is the following: > > The build process includes a script that > > 1. downloads a source tarball of a specific version from a known external > location, > 2. extracts the source from the tarball into a working directory, > 3, applies any patches, > 4. compiles the library, > 5. uses the library in the build, and then > 6. erases all of that ephemeral stuff so that there is no residue in the > released source nor in the shipped binary package, > 7. provides for a NOTICE (or equivalent) that indicates the dependency (and > could provide links to the origin and the specific source code, for that > matter). > > Variations on this theme include (1) making/redistributing [the Microsoft > redistributables case] a run-time shared library that is shipped and > installed with the binaries, the source/redistribution license permitting, > and (2) using libraries, even source, that may already be available on the > platform used to make the build. > > This seems to have happened with libraries from the Boost collection that are > shipped with some GNU/Linux compiler configurations. Note that dependencies > on header files for C/C++ have to be addressed as well, since it may be > tricky to even include those in an Apache project source release, depending > on notices affixed to those files. Some of the libraries in the Boost > collection consist entirely of C++ header files. > > I can't speak to whether or not patches are submitted back to the upstream > source in the cases I've noticed in the current OpenOffice.org build process, > but they certainly should be. And when a version including an > upstream-acceptable patch is available, the build process could be adjusted > accordingly. > > The remark made about LGPL elsewhere seems to work here, but I don't think > the above scenario relieves us of reciprocity concerning patches in the case > of LGPL and certain other reciprocal licenses. (I must constantly remind > myself that the LGPL includes the GPL by reference and the modifications it > makes to GPL provisions are specific and limited.) > > [Note: The Boost collection is a bad choice because (a) it may be found to be > Apache compatible and (b) it is going to show up, over time, as standard in > C++ compiler distributions that honor the 2011 ISO specifications.] > > There are murky dependency interactions that become tricky as well. For > example, dependency on an address-book service may also be required to locate > public-key infrastructure certificates. > > -----Original Message----- > From: sa3r...@gmail.com [mailto:sa3r...@gmail.com] On Behalf Of Sam Ruby > Sent: Thursday, October 20, 2011 14:27 > To: ooo-dev@incubator.apache.org > Cc: legal-disc...@apache.org > Subject: Re: Clarification on treatment of "weak copyleft" components > > [ ... ] > >> Now, for our SVN, we need to host the actual source of the MPL >> components, since we need to build the binaries on the platforms that >> we support. And in several cases we have patches the original source. >> Is this a problem? > > That normally is highly discouraged / not allowed. Why can't the > patches be contributed back to the original projects? > > [ ... ] > >> (Or back to an earlier note, is there any problem with having the >> build script automatically download such 3rd party dependencies?) > > Automatically is typically the hang-up in discussions such as these, > but a specific exemption for well-disclosed sources to despondencies > which are distributed with the project could be discussed. > > [ ... ] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: legal-discuss-unsubscr...@apache.org > For additional commands, e-mail: legal-discuss-h...@apache.org > >
