On Thu, Oct 20, 2011 at 8:20 PM, Dennis E. Hamilton <dennis.hamil...@acm.org> wrote: > It doesn't matter Rob.. You already covered this case over here and I hadn't > seen that when I replied over there. >
OK. That may explain it. I was vainly searching for what you were saying new. I assumed you were trying to point out some fine distinction over what I had said, but couldn't find it ;-) -Rob > - Dennis > > -----Original Message----- > From: Rob Weir [mailto:robw...@apache.org] > Sent: Thursday, October 20, 2011 17:11 > To: ooo-dev@incubator.apache.org > Subject: Re: Clarification on treatment of "weak copyleft" components > > 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 >> >> > >
