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 Thu, 20 Oct 2011 21:41:11 GMT
On Thu, Oct 20, 2011 at 5:27 PM, Sam Ruby <rubys@intertwingly.net> wrote:
> 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?
>

There is no intent to hoard.  From talking to developers on this
project I get the sense that they want to upstream patches more than
was done previously.  But contributing a patch is no guarantee that it
will be integrated by the other project in a timely manner.  Simply
having it checked in by the 3rd party component, but not yet in their
release, is also not optimal, for stability and supportability
reasons.  Release schedules don't always sync up.

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

OK

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

It was not clear to me when I originally asked the question.  But
after reading Robert's comments (and yours) I think we're OK here.

>> -Rob
>
> - Sam Ruby
>

Mime
View raw message