Stuff Michael Meeks is doing

Measuring programming progress by lines of code is like measuring aircraft building progress by weight.

• Firstly, Charles is extremely generous with his advice on how people should license their code: yet it is not clear to me that he has ever written or contributed any himself, has he ? Secondly though he is well up for other people assigning their code to Sun, his explanation of why this is great falls horribly foul of the speculation that riddles his work: how does he know whom Sun has licensed other people's code to, and under what terms ?
• We also have an LGPLv3 conspiriacy (emphasis mine):

  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.
• Wrt. why we changed view on the JCA, I addressed that yesterday: and yes, I was wrong to encourage people to sign all their rights over to Sun, sorry; mea culpa - obviously I learn only slowly & by experience.
• Now, we come onto the real barn storming speculation (soon to become recieved wisdom) - real vintage groklaw journalism:

  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.
• Wrt. my apparently odd questions - I'm was interested in exploring options to hinder the use of GPL code in proprietary products, is that bad ? Interestingly my interlocutor there Allen Pulsifer has made his views on Sun's recent moves rather plain.
• Summary - vintage groklaw: conspiriacy theory dressed up as fact; with a strong pro-Sun bias. My problem with the JCA is around balance, equity, and proprietary licensing, not choice of license [ something over which as has been pointed out we have ~no real say ].

• First the light-hearted piece, I confess I missed out on mba's amusing pantyhoses piece, due (I think) to not being CC'd as asked in the quoted text (no doubt an honest mistake). The humerous example of the construction of a religious convictionally selective license is amusing: what is less funny is that only Sun chooses how OO.o is (privately) licensed, under what terms, and to whom.
• The historical review is most helpful, although at some level I think it ends up basically just re-stating the problem: that Sun demands total ownership of everything, and will continue to do so; but lets consider it:
• We stated in the ESC that we (Novell) are no longer willing to assign ownership rights to Sun for new, separable modules. Why ? If you're a particular fan of Sun, this can be seen as some malign and divisive strategy - after all, why shouldn't people want to assign their rights to Sun en-masse ? Of course we talk to Sun and others about improving OO.o continually, but the simplest explanation here is a suspicion that this one company is bent on retaining complete ownership of OO.o, as it's share of contribution decreases, and that that is deeply unhealthy and unjust (nevermind deterring other contributors). Anyhow, from subsequent actions it seems that suspicion was strongly vindicated:
• In categorically rejecting this simple and moderate progression to a more balanced ownership structure Sun obviously strongly defended it's demand to continue owning everything, even as it's proportion of contribution shrinks. Sun seems not content to own just it's own code (and changes to that), but wants to own everything. Furthermore, it appears to suggest (on the basis of its various special positions in OO.o ?), that this cannot be changed; it is also interesting to hear that all Sun Open Source projects are like this.
• Subsequently Sun made an offer to distribute the solver as a separate plugin. If Sun (or others) want to provide the solver as a plugin, they have all the rights they need (as has anyone else), as indeed they have all the rights to ship it as part of OO.o itself (under the LGPL), and even to ship it in StarOffice - under the LGPL. As has been said before, we're eager to see the solver (etc.) as part of OO.o.
• So - finally we have the re-statement of the status-quo from Mathias: as if this is an immutable law of gravity:

  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.

• It has never been clear that Sun's demand for total ownership (and hence ultimate control) would continue indefinately. Indeed quite the opposite, we have been promised a foundation from day one. Unfortunately it seems to be the case that there will be no re-examination of the ownership structure; ie. just re-stating the problem.
• Last week, Sun took the steamroller approach of reinforcing it's demands by decided that instead of making the solver a plugin itself (or whatever fudge it could construct), it would start re-implementing it from scratch. At that time, of course we started pointing people to http://go-oo.org/.
• Then, interestingly, later in the week Jim Parkinson basically re-stated Sun's position, though it seems there will be some welcome consultation on it. A major thrust of his blog is a proposed move to the SCA - whose only practical purpose is to strengthen Sun's ownership rights with a stronger copyright assignment; but back to Mathias:

  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.

• The JCA (or SCA) is not an immutable law, it is not necessary to assign everything to Sun to achieve any of the worthy stated aims of defending the license, re-licensing, etc. The JCA is not the very basis of civilisation, without which nothing can exist: an eternal tradition handed down from the elders, beyond question, for-your-own-good, etc. etc. Instead it seems to me an unbalanced control structure that retards OO.o's growth, and requires changing. It could easily be changed tommorrow by Sun. Switching to a more just and reasonable model is emminently sensible - though of course it is hard to imagine a King becoming a radical Republican.
• Finally, I look forward to the result of Jim's first Advisory Board meeting; and applaud his commitment that Sun is steadfastly behind a strong, transparent and fair community process. I am really looking forward to seeing that arrive.

• In the area of governance, I'll suspend judgement on a new Community Advisory Group, perhaps it'll be good, lets see.
• In the are of licensing - again, we see something that sounds wonderful, Jim writes: (my emphasis)

  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.
• So - what about "The most community friendly ..." piece of this stronger assignment of rights to Sun ? lets look at that final sentence, in-lining & special casing the hacker's interest from clause 1 above:

  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.
• Then again, IANAL, and must be mis-understanding this somehow, perhaps some kindly lawyer with a ministry to the bewildered can help me out. So - Jim asked for comments, my comment is: I'm confused - why is this so good, and who is it good for ?

    // 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() );

• Community Norms: it's great to hold up Apache, as a community norm; I'd love to see OO.o on that template: a vendor neutral, level playing field for all to contribute, and look: there is a very wide & dynamic base of contributors. What about all those eclectic ownership situations, where there is no single owner - those seem quite norm-al too. [Update 2012-05-31 - if politics is the art of the possible, then wresting views from the deep past and applying them today is the art of misleading people.]
• Contributor Agreements: - again, the analogy between the FSF and Sun as good stewards of software ownership is a huge stretch. One is an incredibly dedicated champion of software Freedom; and the other is a for-profit company. It is easy to imagine situations where Sun's duty to shareholders mandates them acting to harm OO.o. And it's particularly easy to believe it, given Sun's rejection of code only on the grounds of wanting to retain complete ownership.
• Non-surrender of copyright: - as I said yesterday, it all sounds nice - until any 2nd entity commits a few lines to the code, then the only rights holder is Sun.
• Defending the copyright: - IANAL, and horribly inexpert in this area, so forgive my rambling. I think Danese blogged in 2005 with this line of reasoning (though last I heard she was a staunch advocate of a foundation for OO.o). Is it really true ? Does Sun need to own everything so it can defend everything ? It seems rather convenient to assert that "The reason all the little guys have to assign rights to this big corporation is only so it can defend your rights", what if you want someone else to defend your rights, or do it yourself ? Also, how can you know that Sun hasn't licensed your code to this supposed infringer anyhow under some secret terms ? What about this (apparent) 51% rule ? it sounds nonsensical to me: if I copy Windows and Linux and OO.o onto a million DVDs and sell them - am I immune from copyright infringement law-suits, because no 1 company owns >51% of the thing, that would be extraordinary, is it so ?
• open source covenant: - what Simon says sounds really great:

  "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 ?

• This is hardly a fork - and it's not even something very new in practical terms. As I said very clearly, we're still contributing the majority of our work to Sun, (and hence OO.o) under the JCA, and will continue doing so for the bits that touch their code. Indeed, right after I commit this yast2-gtk thing I'm going to get on with un-stalling my up-stream configmgr re-factor / speedup work, (actually a substantial LOC reduction, for those that like to count such things). So, there is simply no walking away from OO.o here, indeed why would we ?
• http://go-oo.org/ has been around for 5+ years, and despite a new & prettier web-site, simply continues a long tradition of pragmatic workarounds for various sub-optimal situations in OO.o. This is only one of tens of different OO.o variants out there: from StarOffice, RedOffice, Symphony to every linux distro I'm aware of that ships a custom version of OO.o, then of course there are tons of local variants, and individuals re-building & brand it in various ways.
• Wrt. copyright assignment, yes it's good to keep unified copyright assignment for (hopefully extremely rare) changes of Free software license etc. The problem lies not with the license, but the idea that a single company, with it's own agenda, having set itself up as the sole owner of an open source project, will then always act in that project's best interest. That just seems unrealistic, and the bigger the company - IMHO - the less likely it is. Now - a meritocratically constituted foundation, to which all code / translation etc. contributors belonged, with some truly representative governance - I'd love to belong to something like that & assign my rights to it.
• Another (possible) benefit from unified copyright assignment would be defending the copyright in court; again that is something a non-profit (like the FSF) has done in the past, and is presumably handled even in totally eclectic ownership structures eg. the Linux Kernel. And of course, OO.o already includes non-Sun-owned LGPL code.

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.