Stuff Michael Meeks is doing
Older items: 2012: ( J F ), 2011: ( J F M A M J J A S O N D ), 2010: ( J F M A M J J A S O N D ), 2009, 2008, 2007, 2006, 2005, 2004, 2003, 2002, 2001, 2000, 1999, legacy html
Measuring programming progress by lines of code is like measuring aircraft building progress by weight.Clearly that cheap lead-alloy airframe was a great investment. Still none the wiser on how long it takes to write a (S)LOC though; 1000 LOC/week would be 2+minutes / line, which seems a lot, though unfortunately sending everyone on typing courses is not going to help; ho hum.
ENVCFLAGS=-Werrortesting, some lack-of-assertion testing - looks lovely; 'Ready for QA'.
So far Sun should be credited with having been extremely reasonable in regard of the license. In the future for instance, OpenOffice.org can switch to the (L)GPL version 3 quite easily. That could not happen without Sun's joint ownership, but for that matter, Michael Meeks' reaction was less than warm.This is easy to rebut; here's what Novell says about the GPLv3. I'm happy for OO.o to move to the LGPLv3 as/when/if Sun decides to do that (but ultimately it's only Sun's decision). As I said in my first post, I'm personally a fan of the LGPL for OO.o, my concern is that there should not be one company that doesn't have to accept the terms of the license. Also, a lovely excluded middle: of course, it's possible to re-license without Sun owning everything - there are at several solutions: eg. ownership by a foundation, or using the "LGPLv2.1 or later" language of the LGPL.
Novell ... is also developing an OpenXML export filter that won't be available in OpenOffice.org that is, if you choose to use OpenOffice.org and not "Open Office, Novell Edition". And since these export filters are supposedly developed in collaboration with Microsoft, this technology would logically include Microsoft's sacred intellectual property that Sun and many others don't want to see covered by the JCA.Simply stunning, he knows of an effort going on in secret inside my team that I'm unaware of myself ! - more details much appreciated. Categorically, as of now, this is false; we're not actively working on native export filters to match the import filter. Furthermore my concerns wrt. Sun's ownership should be transparently free-standing, and are emphatically unrelated to Microsoft, in any way, whatsoever. It is also interesting to remember that Sun also has several well known agreements with Microsoft, around OO.o (or StarOffice). As for knowingly injecting other people's IP into OO.o that is a pretty repulsive accusation, and one rebutted before.
It was always absolutely clear from the very beginning of Kohei's work and it was reinforced several weeks ago that the Kohei Solver will not get into the OOo code base without a JCA.
To sum up: the decision whether the Kohei solver or any other of the components Novell holds back will be contributed to OOo or not is a decision of Novell, not of anybody else.
This SCA goes a long way in addressing a variety of concerns with the current agreement. The most community friendly aspect of moving to the SCA is the inclusion of language stating that any contribution licensed out by Sun will also be licensed under an OSI or FSF approved license.So - lets look at the most community friendly piece, in this carefully reviewed document; is it so ? does it really meet Simon's claim "... so that proprietary-only forks are impossible.". It's good to link to Sun's FAQ but what about reading the actual agreement text. Lets start with clause 1 (IANAL etc. etc.):
1. "Contribution" means any source code, object code, patch, tool, sample, graphic, specification, manual, documentation, or any other material posted or submitted by You to a Project.So far so simple, (and AFAICS an improvement on the JCA, it removes the unclear delivery / acceptance language). What about clause 2 (my emphasis):
2. You hereby assign to Sun joint ownership in all worldwide common law and statutory rights associated with the copyrights, copyright applications and copyright registrations in Your Contribution. You understand that (i) this Agreement may be submitted by Sun to register a copyright in Your Contribution, and (ii) Sun may exercise all rights as a copyright owner of Your Contribution, including enforcement against infringers. You hereby grant to Sun, to the extent that the foregoing assignment is or becomes void, ineffective or unenforceable, a perpetual, irrevocable, non-exclusive, worldwide, no-charge, royalty-free, unrestricted license to exercise all rights under such copyrights, including sublicensing those rights to third parties through multiple tiers of sublicensees or other licensing mechanisms at Sun's option. Whether by assignment or license, both parties to this Agreement shall be able to do all such things in relation to Your Contribution as if each of us respectively were the sole owners of the copyrights therein. Neither party has any duty whatsoever to consult with, obtain the consent of, pay or render an accounting to the other party for any use or distribution of a Contribution or derivative work thereof. To the extent allowable under applicable local laws and copyright conventions, You agree never to assert against Sun or its licensees or transferees any moral rights in Your Contribution. Any Contribution that Sun subsequently makes available under any license will also be made available under a suitable FSF- or OSI-approved license.Well there it is; I guess what you would expect in a joint copyright assignment - though comparing to the JCA, the 'much improved' nature seems to revolve mostly around: "... several layers of agreement, so that if one proves to be unenforceable in some jurisdiction, there are other layers ..." (Simon Phipps), ie. it is longer and stronger.
Any Contribution [ any source code submitted by You to a Project ] that Sun subsequently makes available under any license will also be made available under a suitable FSF- or OSI-approved license.So ... Sun covenants to make your (own) code submission available under an FSF/OSI approved license. I guess that is good: but since you already submitted your source code under such a license how does that help re-assure the contributor ? Again, it seems to me that this requirement is fully satisfied simply by a public archive of contributed patches, and does nothing at all to stop proprietary forks. At best, the commitment is slightly easier to fulfill if Sun chooses an FSF/OSI approved license for a project.
Of course, clobbering the env. variable is necessary to bootstrap from a suitable configuration file, but of course - magically putenv holds a pointer to your internal buffer; so as OString goes out of scope - bang. After more digging discovered// Unless you do this, obviously you don't deserve to have anything work rtl::OString aCfg( "CFG_INIFILE=" + rtl::OUStringToOString( curWd, RTL_TEXTENCODING_UTF8 ) + "/configmgrrc" ); fprintf (stderr, "Env '%s'\n", aCfg.getStr()); putenv( (char *)aCfg.getStr() );
rtl_bootstrap_setwhich seems ideal for the task.
"There is an "open source covenant" - Sun promises that any contributions that get used will always remain as Free software wherever else they may end up, so that proprietary-only forks are impossible."but is that really what the new sca (do read it!) actually says ? [ not that OO.o actually uses it ] or am I missing something, is it this clause:
Any Contribution that Sun subsequently makes available under any license will also be made available under a suitable FSF- or OSI-approved license.surely this is fulfilled just by having your 'Contribution' (defined term) in a Sun funded Revision Control System: ie. it safeguards your right to always get your own code back again (much like a backup tape). I really don't see how that makes proprietary only forks impossible - I must be missing something: what ?
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 ?
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 ?
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.
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.
My content in this blog and associated images / data under
data/ directories are (usually)
created by me and (unless obviously labelled otherwise) are licensed under
the public domain, and/or if that doesn't float your boat a CC0
license. I encourage linking back (of course) to help people decide for
themselves, in context, in the battle for ideas, and I love fixes /
improvements / corrections by private mail.
In case it's not painfully obvious: the reflections reflected here are my own; mine, all mine ! and don't reflect the views of SUSE, Novell, The Document Foundation, Spaghetti Hurlers (International), or anyone else. It's also important to realise that I'm not in on the Swedish Conspiracy. Occasionally people ask for formal photos for conferences or fun.Michael Meeks (email@example.com)