incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: Clarification on treatment of "weak copyleft" components
Date Sun, 23 Oct 2011 12:53:58 GMT
On Sun, Oct 23, 2011 at 8:02 AM, Robert Burrell Donkin
<> wrote:
> On Thu, Oct 20, 2011 at 10:41 PM, Rob Weir <> wrote:
>> On Thu, Oct 20, 2011 at 5:27 PM, Sam Ruby <> wrote:
>>> On Tue, Oct 18, 2011 at 12:08 PM, Rob Weir <> wrote:
> <snip>
>>>> 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.
> Archiving the compressed source of weak copyleft dependencies in some
> sort of repository[1] is something that Apache will need to become
> comfortable with sometime soon
> But developing downstream derivative works of weak copyleft
> dependencies is likely to be a major issue
>>> 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.
> Downstream packagers face similar issues and typically cope by
> maintaining independent patch sets (applied at build time). Why not
> just use patch sets?

That is what we do.  We store the original source in a tarball and
then apply a patch at build time.  But we store both the source
tarball and the patch on our servers.

> Robert
> [1] Many weak copyleft licenses require distributors to maintain the
> code beyond the lifetime of the organisation which issued the original
> license. We need to get used to the idea that Apache is likely to be
> around much longer than commercial players.

View raw message