www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <orc...@apache.org>
Subject RE: Clarification on treatment of "weak copyleft" components
Date Thu, 20 Oct 2011 23:53:39 GMT
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

 - Dennis


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: sa3ruby@gmail.com [mailto:sa3ruby@gmail.com] On Behalf Of Sam Ruby
Sent: Thursday, October 20, 2011 14:27
To: ooo-dev@incubator.apache.org
Cc: legal-discuss@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-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org

View raw message