Hello Marvin,
Le Wed, 8 Jun 2011 06:04:42 -0700, Marvin Humphrey <mar...@rectangular.com> a écrit : > On Wed, Jun 08, 2011 at 09:43:45AM +0200, Jochen Wiedmann wrote: > > On Wed, Jun 8, 2011 at 6:51 AM, Norbert Thiebaud > > <nthieb...@gmail.com> wrote: > > > On Tue, Jun 7, 2011 at 9:43 PM, Noel J. Bergman > > > <n...@devtech.com> wrote: > > > > > > [...] their downstream code cannot be used. Hence, the best > > > outcome under the current licensing regime is for all core > > > development to be done here, and for TDF to be a downstream > > > consumer. > > > > > > Just because you choose a particular license that does not make > > > you de-facto 'upstream'. > > > > Noel is describing a fact: It there is going to be something like > > "upstream", it can only be an ASL licensed OO, not a LGPL'ed LO. > > What he misses (as quite a few others do, which is possibly why you > > are reacting angry) is a certain amount of sensibility that > > acknowledges that this fact is just as likely to cause a total > > split between LO and OO. > > +1 > > The split between LO and OOo is reality. > > The code bases are already divergent and it would be very difficult to > reconcile them. To make Apache OOo "upstream" from LO would mean one > of two things: > > 1. The LO people throw out everything they've done and start over > from scratch. > 2. The LO people organize a large collective software grant to > Apache for their work. Since there are a lot of people involved, > this would be a daunting task even if it wasn't politically toxic. > > In both scenarios, TDF, after all they've gone through, after all the > work they've done, takes on a reduced role: to use Norbert's analogy, > they go from being the auto factory to being a custom shop. > > We're coming off like some know-it-all newbie manager waltzing in > after a hostile takeover and imperiously informing the people closest > to the project that they are being demoted and they should be happy > about it 'cause our organization is so freakin' awesome. > > What we ought to be doing instead, if we really want to form good > relationships with the LO community, is not continually repeating > abrasive "facts" about licensing, but showing a modicum of *humility*. > > The reason I praised Sam is that he is clearly sensitive to all > this. He has been an exemplary ambassador, and my hat is off to > him. It is worth repeating his recommendations in their entirety: > > That indeed would be a wonderful place to end up. > > At the present time, there are people who would rather not > participate in such an arrangement. They have something that works > just fine for them. Many are skeptical that we can deliver. The > most that we can do is (a) enable such collaboration, and (b) > execute. If we do both well, we will achieve much more than we could > by prior agreement. > > I think it is in our best interests to acknowledge that we don't > yet have a track record or anything new to offer. And that in such a > context it is rather presumptuous at this point for us proclaim > that we are the core or even are relevant. > > I think that passage represents the best of Apache's inclusive > traditions, and I hope we can live up to it -- both the sake of the > project and for our own sake as human beings. Well spoken; although I believe that humility has to be equally shared among every stakeholder :-) I think you have perfectly summarized the issue here, and I think it's perhaps time to consider this issue to be clearly stated in this way (at least the part related to TDF). Now if we could move forward I think that what could make sense would be to define or clarify what exact purpose would serve the OpenOffice code base at Apache and the Apache Openoffice project. I know that no codebase ever had any intent in itself and that people do whatever they want. That's true and by the way that's why software patents are dangerous, (but that's another discussion), but it does not preclude the project and its vision to be articulated in a different way than a general purpose office suite that's free, open source and uses ODF. In this case, LibreOffice fits the bill, but so does KOffice/Calligra (btw, nice examples to draw inspiration from), Abiword/Gnumeric, etc. My understanding is that the Apache OpenOffice codebase matters to IBM and anyone who would want to use the specificities of the Apache licensing, and I understand this as being a reality we can all agree on. Instead of spending hours and keystrokes pondering on the ability of the Apache OpenOffice project to execute or to become LibreOffice's upstream, I would like to rephrase or reframe Simon's proposal, esp. its points 2 and 3 (2: rename the project to Apache ODF suite 3. make this project not the office suite that competes with LibreOffice but make it the meeting point of development efforts for specific purposes and ODF). Basically this amounts to think about the current proposal based on two factors: 1. find a proper coherence and relevance between Apache OOo & LibreOffice on a technological level and on a distribution level 2. find a proper coherence with IBM's business requirements (Symphony). I hope we can move forward on this. Best, -- Charles-H. Schulz Membre du Comité exécutif The Document Foundation. --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
