decoration decoration

When you want to know more...
For layout only
Site Map
About Groklaw
Legal Research
ApplevSamsung p.2
Cast: Lawyers
Comes v. MS
Gordon v MS
IV v. Google
Legal Docs
MS Litigations
News Picks
Novell v. MS
Novell-MS Deal
OOXML Appeals
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v Novell
Sean Daly
Software Patents
Switch to Linux
Unix Books
Your contributions keep Groklaw going.
To donate to Groklaw 2.0:

Groklaw Gear

Click here to send an email to the editor of this weblog.

To read comments to this article, go here
Thank you Michael, but no, thank you... by Charles H. Schulz
Tuesday, October 09 2007 @ 07:05 AM EDT

Thank you Michael, but no, thank you...
~ by Charles H. Schulz

Someone wrote a long time ago that a fork was not necessarily a bad thing. Indeed, it is certainly one of the most vivid expressions of the freedom Free and Open Source software carries. On the second of October, a much mediated engineer of and long time contributor of the project, announced that Novell would host and distribute custom builds of without the JCA. What's interesting here is that many people would not have paid attention to this news if the press article reporting it had not carried a headline explicitly stating, "Sun refuses the LGPL, Novell forks".

To this widely spread but utterly inaccurate assertion, two things should be said in response. First, *is* released under the LGPL. Second, and perhaps more interestingly, Novell did not deny that it was forking, aside from Michael Meeks trying to nuance and to minimize this claim.

In this article I would like to give some insights into what the real issues are between Novell and and rest of the project, the now famous JCA, what I think a solution could be, and where I think is heading.


Novell and

The history of Novell and is a complicated one. Novell was certainly one of the earliest non-Sun, corporate contributors to the project. The contributions of Novell are substantial, especially in terms of patches and specification writing. It should be noted that to this day, "i-teams" formed of Sun, Novell and other engineers are defining specs for the suite. But the most significant contribution of Novell is perhaps their own build system, dubbed "ooo-build". This system allows you to compile and release under a binary form. It is thus a central piece of the development process of But it is not the only build system for Most of the other builds are either custom or compiled like "Sun" with another build system. And that's where you find the summarized ambiguity of Novell's role inside they are contributors with another build system. So when Michael Meeks announced that builds would be released on (a web site that has existed for years) it was, as he wrote himself, hardly news.

That being said, the ooo-build is being used (as a technology) by several, if not all the Linux distributions out there. And this was never considered a fork. Rather, it was a complementary approach. While the 'vanilla' builds were reputed to be stable, the ones built through the Novell method could integrate more patches quicker but were also problematic. As a consequence, vanilla builds started to appear as .rpm and .deb packages recently.

The Joint Copyright Assignment (JCA)

The JCA [PDF] is basically an agreement whereby the contributor shares the code ownership (copyright) with one, major copyright holder which acts as the copyright clearinghouse and steward. Similar agreements exist for other major projects, such as the Apache project, the FSF, Fedora, MySQL and others. The difference is that in some of these agreements, the contributor gives the entity a perpetual copyright license and other things, but retains ownership. If you look at the SCA, the newer Sun Contributor Agreement you'll see it's not identical to the JCA.

There are two main advantages to such agreements: first, the project can enjoy a true legal protection and second, this avoid the kernel "babylon" where you have hundreds of contributors that make it nearly impossible, in practice, to change the license.

Where things become more complex is when the prominent copyright holder is a commercial entity. In the case of, it is Sun. This allows Sun to sell StarOffice, that is, to create one proprietary product based on Free Software. This would also allow Sun to change the license overnight, say from LGPL to BSD or even to a proprietary one. So far Sun should be credited with having been extremely reasonable in regard of the license. In the future for instance, 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.

The issue some developers have with the JCA is thus understandable: you actually give joint ownership of your copyright to Sun; you may share it, you may contribute to Free Software and enjoy all the benefits that come with it, including using your own code for your own purposes, but essentially one big company benefits from the code you wrote (not that Sun does, actually -- they're not making much money with StarOffice).

For the record, several developers have found this a bit hard to swallow. But the great majority of them, independent developers and corporate ones such as IBM -- and, may I remind you, Novell itself -- have signed it. But then you may ask, what's the whole point of the issue?

Where things go wrong

This part is going to be a bit speculative, mostly because the logic of events is a bit confusing.

What the press and Michael Meek's blog report is that Kohei Yoshida refused to sign the JCA and thus had its solver software for Calc rejected by the development team. This is a sad story, because I think that a better communication between developers could have helped here. But where it becomes really strange is that Kohei Yoshida , a respected contributor of signed the JCA when he was an independent developer, got then hired by Novell, and then refused to contribute code under the JCA. I and others are still lost in conjectures as to why Kohei (or Novell?) had a problem with the JCA. In a similar fashion, one could wonder why Michael Meeks started to criticize the JCA after having praised it so often and encouraged contributors to sign it. One could also wonder, by the way, about the silence of Novell Corp. As of today, nobody else from Novell aside from Michael has confirmed it was a fork or said anything else.

Some have found a compelling argument in showing the connection between the Novell team's twist of thought and the agreement signed between Novell and Microsoft.

What the Novell decision could mean

Once again, it is safe to remember that we do not have Novell's official opinion about Michael's decision to fork.

What Michael Meeks did announce was that the former "sandbox" website, would be used in conjunction with Novell's ooo-build to produce builds integrating patches and contributions that are not covered by the JCA.

So is this really a fork?

My answer is: Not yet. For the moment what these new, Novell builds could integrate would be the Calc solver. But there the connection with the Microsoft agreement becomes really compelling to me. A much overlooked part of that agreement refers to a common interoperability lab stemming from both Novell and Microsoft. Part of this work by that lab involves cooperation on OpenXML.

Bear with me now: The project is developing import filters for OpenXML, but not export filters. Why? Because, I believe, it does not want to make a service to Microsoft by being the second major office suite to produce OpenXML documents on the fly. Novell sees this issue from a different point of view, but let's not get carried away. Working with Microsoft on interoperability, as Novell claims, includes working on OpenXML filters and plugins. While Novell contributes quite normally to's import filters, it is also developing an OpenXML export filter that won't be available in that is, if you choose to use 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. This could, perhaps, explain Michael's odd questions on this list of

So these new builds from Novell would thus include new features, but features that will carry sometimes an unverified intellectual property. And that's certainly an issue if Microsoft joins the game. Would that mean Michael's move was made in order to serve some corporate interests?

My perception is that regardless of what the truth is on that, Novell's builds will end up containing Microsoft technologies. I also think that as a consequence of this, Novell builds of may never switch to the third version of the LGPL or even GPL, as Michael and other Novell engineers were very reluctant to discuss that point on some mailing lists of the project.

And that, aside from losing some very valuable contributors, is the worst logical consequence of what happened this week inside

What lies ahead

The future looks uncommonly bright for these days. Several contributors have joined the project: IBM, RedFlag just joined the community and in doing so, they just took away the perception that somehow there's "only Sun contributing" to

The community of independent contributors has gained access to much more say in the project, people work better between each other, and Novell won't leave the project in such a fast and clearcut way. Whatever its engineers might say, Novell cannot address the complexity of the entire code. In other words, they may well fork, but they will still be dependent on

Yet, the community is left with a bitter taste in its mouth. Autonomy, influence, and work habits built over years of working with Sun may change by the integration of new corporate heavyweights. It also renews interest in finding a new balance between corporate resources and the community representativity. Contrary to some of Michael Meeks' claims in one of his older blog pieces, one should not evaluate its might just by counting the number of developers declared to be contributing to the project. This strangely martial view of things does not take into account the commits on the CVS, nor does it take into account the diversity of tasks aside from pure development: today, for instance, it is safe to assume that the Quality Assurance of is largely a community task, just like localization and native-language communities have made the success of and the largest part of its community.

Perhaps the balance can be found in this view on, not without some irony: without Sun, it would be nothing. Yet without the community, it would still be just one out of many other corporate internal projects.

1 Charles H. Schulz is one of the founders of Ars Aperta, a consultancy firm providing strategic insight and expertise on Open Standards and Free Software, and he is also a longtime volunteer of He is the lead of the Native-Language Confederation of but the views expressed in the article are his own. He introduced ODF at the Linux Solutions 2006 expo in Paris. Ars Aperta is a member of OASIS.

  View Printable Version

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )