Stuff Michael Meeks is doing

Why choose terms you won't accept ?

Very disappointed to read Kohei's blog. Sun re-writing a contributor's code because they refuse to accept the licensing terms they give to other people: the LGPL; saddening. Sun chooses the licensing for OO.o; why choose a license they won't accept themselves ?

To step back a bit, it's worth understanding how Novell now contributes to OO.o. Clearly, we recognise & salute Sun's huge investment here over many years, and for all our changes to the core (> 50% of our work) we assign rights to Sun outright, and plan to carry on doing so as we labour to improve up-stream OO.o. We work closely with Sun's (excellent) engineers on joint development projects such as OpenXML import, VBA interop, core application features, re-factoring old code etc. To put it another way - we know Sun re-licenses this code as proprietary software, for it's own advantage, and we like our friends to be able to eat. Novell even uses a similar structure in two other very limited scenarios: for a tiny fraction of Mono, and for evolution.

What we don't like is the insistence that all and any contributed code, shipped at OpenOffice.org must end up being owned by Sun. In this case, the solver is a nicely separated, individual shared library UNO component and completely de-coupled from OO.o. I'm personally a fan of the LGPL, and OO.o (and StarOffice) contains lots of non-Sun owned modules including several LGPL modules, in it's core: eg. Daniel Velliard's nice libxml2 library. Due to static linking, there is even pure LGPL code floating outside the 'external' project. So - why is Kohei's nicely separated, working, specified, UNO component not acceptable purely under the project's license: the LGPL ?

How to offend developers

If OpenOffice was blessed (like other more sensibly structured projects) with a large, diverse and healthy developer-base, then perhaps we could expect to go around rejecting big chunks of code, offending developers and driving away potential contributors. To do this solely in order for Sun to retain total ownership of the code-base (and even loosely coupled components) - seems rather a betrayal of it's self-appointed stewardship role wrt. OO.o code ownership (under the JCA).

Then of course we have the announcement of the duplication itself (last comment in the issue), (though it was announced at OOoCon too), some nice myths: the "shared ownership" myth showing up in the solver integration

Stefan Taxhet wrote:
    Kohei, we would be happy to help you with the integration of
    your contribution in the main code base following the project
    guidelines. This implies shared ownership and licensing under LGPL.

'shared ownership' sounds friendly doesn't it: unfortunately as soon as more than one legal entity touches a piece of code, the only owner of the complete work becomes Sun: so not that 'shared'. Thus we can summarise this as: Allow Sun to re-license your code as proprietary software, or you can't be part of 'Open'Office.

    We are confident that this is the way the collaboration can
    do well with the best support from all participants.

What does that mean ? the best form of collaboration is where the weaker party assigns all their rights to the stronger ? Surely Sun is aware of the effect that this sort of decision has on potential contributors both corporate and individual. I for one, having (foolishly) championed encouraging people to sign the JCA at many conferences, am only too aware of how many clueful developers politely refuse, nevermind corporations.

    As this seems not to be an option for you we start to implement
a solution within the spreadsheet project.

There already is a fully implemented solution within the spreadsheet project, it's Kohei's solver, it even has a specification, it works, and it is there now. There is only one substantive issue: Sun doesn't own it.

    "You are welcome to join this effort."

Incredibly condescending to inviting Kohei to re-join his own project, this time as an unpaid Sun employee, but a kind thought ?

Summary

Sun is throwing away many months of Kohei's life, I surmise, because it knowingly asks others to accept a license, it will not itself accept. It insists on refusing contributions licensed under the project's own license.

Of course there are other projects that demand total copyright assignment, and given a choice of that vs. proprietary software it's clearly better to have Free software. However these projects tend not to produce a wide base of contributors, something that OO.o for the success of the Linux desktop desperately needs (oh and they tend not to call their projects "Open"Foo).

Copyright assignment can actually be useful, when you want to change licensing (though was not needed for dropping SISSL). If the primary goal of ownership is to allow (hopefully infrequent) licensing changes, surely having a sensibly structured non-profit to allow that, rather than a for-profit corporation would safeguard better governance.

Ultimately, it seems to me the current setup is not a winning, open approach, but a dangerous situation that hobbles OpenOffice.org, and leaves us in a bind. What can be done with our (un-acceptable) code ? (apart from rampant appeasement). Unfortunately the situation simply cannot be changed; and Sun totally dominates the whole OO.o process. Hearing yet again the rational that it must be this way, because it always has been this way is really not that satisfying either.

A way out ?

For many years, there has been a collaboration among Linux distributions (and others) to maintain a patch set for OO.o, including all those features & fixes that for reasons of time, process problems etc. have not yet made their way into OO.o (stalled in the bug tracker eg.).

Our aim with ooo-build has been to slowly work at evaporating this patch set away, by increasing the pace of up-streaming, contributing the core changes to Sun, and thus OO.o; and of course this is no set-back to continuing to get as many as possible of the core fixes included into Sun's OpenOffice version.

Regrettably though, it appears that some of these things can never go up-stream, as Sun refuses to accept them. Thus, it seems the best approach is to continue working where we can with Sun on OO.o, (helping them eat by improving their core) - while simultaneously providing our rejected features directly to users somehow.

Of course, this is not a new thing, we've always distributed a custom flavour of OO.o derived from ooo-build, as have many other Linux distributions, but recently, with the new SuSE build service and a (finally) updated web-site, we hope to be able to make development versions more widely available (including on Win32) at http://go-oo.org; you can grab Kohei's solver there today.