incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: Clarification on treatment of "weak copyleft" components
Date Fri, 21 Oct 2011 00:33:37 GMT
On Thu, Oct 20, 2011 at 8:20 PM, Dennis E. Hamilton
<dennis.hamilton@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:robweir@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 <orcmid@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: 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
>>
>>
>
>

Mime
View raw message