incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <apa...@robweir.com>
Subject Re: OOO and LibreOffice.
Date Tue, 05 Jul 2011 02:15:39 GMT
On Mon, Jul 4, 2011 at 12:19 PM, Pedro F. Giffuni <giffunip@tutopia.com> wrote:
> In general I avoid commenting threads like this, as in my
> POV the licensing differences are not surmountable..
>

It is hard to tell whether 100% of TDF developers insist on copyleft.
 Certainly there is a vocal contingent for which the license issue is
a deal breaker.  But there are others who are indifferent, and will be
willing to work with us on areas of mutual interest.  As Simon said,
TDF is happy to accept Apache 2.0 code.  Great.  So we work with those
who are willing to work with us, even if it is a subset of the full LO
project.  Even if it is a small subset.  I'm certain that we'll find
areas where we collaborate.

> --- On Mon, 7/4/11, Simon Phipps <simon@webmink.com> wrote:
> ...
>>
>> >
>> > As each developer retains ownership of their code it
>> maybe better to ask
>> > on the developers list [1].  The SC has no
>> control over the devs.
>> >
>> > [1] libreoffice@lists.freedesktop.org
>> >
>>
>> Since Rob is asking the Steering Committee to make a
>> statement, their list
>> is the best place to do that.
>>
>
> I don't see much hope in that request, especially since
> someone already mentioned the word "veto" if it ever
> happens.
>

I see nothing in the TDF bylaws that speaks of a "veto".  So I'm
taking that as just a "no" vote.

http://wiki.documentfoundation.org/CommunityBylaws

> What I think could be done is to work out some mechanism
> where LibreOffice developers can tag their commits as AL,
> and that we can take those changes without anyone signing
> an ICLA, but by the time that is arranged I doubt most of
> the LO patches may apply cleanly, and for the time being
> we do have a LOT to do to make the incubation successful.
>


So a few tangible modes of collaboration:

1) LO as downstream consumer.  This is what LO has done with OOo 3.3
and 3.4.0.  It is what LO's predecessor, Novell's Go-OO, did for many
years as well.  This can continue well into the future, if LO wishes.
 But I don't think they do.

2) Patch exchange.  A developer who fixes a bug or adds a feature can
contribute it to both projects under each project's respective
license.

3) A componentized approach to #1 above.  So instead of  the entirety
of AOOo, LO takes selected components, similar to how they (and we)
take components from other open source projects.

4) Like #3 above, but where we take components from LibreOffice.  This
might be possible in specific cases, even with LGPL licensed  code,
provided this is unmodified binaries, optional features, etc.  (I'm
not intimate with the exact rules at Apache for this, but it seems
that there may be some scope for collaboration even here).,

However you look at it, it seems the finer grained approaches give us
the most flexibility, since we only need to rely on the willingness of
individual developers to collaborate.  Of course, a modular approach
has many other benefits and is something we should be considering in
any case.

-Rob

> Pedro.
>

Mime
View raw message