incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Ruby <ru...@intertwingly.net>
Subject Re: Clarification on treatment of "weak copyleft" components
Date Thu, 20 Oct 2011 21:27:22 GMT
On Tue, Oct 18, 2011 at 12:08 PM, Rob Weir <robweir@apache.org> wrote:
> One last question, based on OpenOffice 3rd party dependencies.
>
> We have a good number of MPL dependencies.  I'm trying, with some
> difficulty, to interpret what we can do based on the description here:
>
> http://www.apache.org/legal/resolved.html#category-b
>
> How does this fit into a release strategy that has both source and
> binary releases.  Is this the idea:
>
> 1) Source releases would include binary object files/libraries for
> these 3rd party components, but not their source.
>
> 2) Binary releases could link into such objects/libraries.
>
> 3) We give proper notices
>
> 4) Downstream consumer would need to make extra effort to retrieve and
> modify the source of the MPL components, since we're not including the
> source.
>
> Is that the idea?

Yup.

> 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?

> One party that is left out in this scenario is the downstream consumer
> who wishes to port AOOo to another platform.  They would not receive
> the source to the MPL components.  And if they downloaded the original
> source from the original OSS project, it would lack our patches.  So
> they only thing they can do is download from our SVN (or from
> Apache-Extras if we decide to do that).

Apache-Extras was not intended as a means to bypass Apache policies.

> (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.

> Any suggestions?
>
> Note that in some cases, these dependencies have no reasonable
> alternatives.  For example, if we want to integrate with Mozilla's
> address book for supporting mail merging in memos, then we need to use
> the interface that Mozilla has defined, with the library they provide,
> which is naturally MPL.

Any reason such integration couldn't be an option?

> -Rob

- Sam Ruby

Mime
View raw message