On Mon, Jul 4, 2011 at 12:19 PM, Pedro F. Giffuni <[email protected]> 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 <[email protected]> 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] [email protected] >> > >> >> 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. >
