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.
- 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: [email protected] [mailto:[email protected]] On Behalf Of Sam Ruby Sent: Thursday, October 20, 2011 14:27 To: [email protected] Cc: [email protected] 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. [ ... ]
