☆ Is LibreOffice Open-By-Rule?

+5Charles-H Schulz from The Document Foundation submitted the data for a benchmark evaluation of LibreOffice. I have read his evaluations and added scores, giving a current evaluation of +5 for LibreOffice (on a scale of -10 to +10). This would firmly identify LibreOffice as open-by-rule.

There is still some room for improvement, but that’s to be expected from a young organisation with ambitious goals. I look forward to being able to re-evaluate in a few months.

Rule Data Evaluation Score
Open, Meritocratic Oligarchy Community postings and
Bylaws
While the LibreOffice project is only 4 months old both its development track and its community governance show a fast pace of developers’ growth and an open and meritocratic oligarchy. This last point is particularly reflected in its bylaws that emphasize the notion of openness, freedom and meritocracy. 

Score: +1 for open to all contributors, 0 for unproven meritocracy, +1 for structured leadership

+2
Modern Licence Licensing Explanation LibreOffice inherits from the licensing of OpenOffice.org and the copyright assignment schemes from both Oracle and Sun Microsystems. This means that the bulk of the code, that stems today from OpenOffice.org shares the same license of its older brother (LGPL v3). Yet newly developed code done inside the LibreOffice project has a triple license: (L)GPL v3 + and MPL.  It is thus a situation where LibreOffice has no other choice than to deal with previous licensing choices, not to make new ones. 

Score: 0 for OSI-approved licensing not under the control of the community

0
Copyright Accumulation Policy statement LibreOffice got rid of any copyright accumulation in the sense of copyright assignments to The Document Foundation and does not require a contributor agreement. +1
Trademark policy Draft trademark policy The trademark policy is almost finished at this point. It attempts to define specific allowed uses for logos, etc. without stumbling too much in certain GNU/Linux distributions’ own policies. While this is a big plus (these distributions’ developers are often part of the LibreOffice core team) it has been noted that the Trademark policy itself is sometimes complex to understand, especially for business uses. 

Score: 0 for trademark policy under community control (+1 once completed)

0
Roadmap Release plan Efforts are made to make LibreOffice releases predictable and the plan looks good. However it does not mean we know what feature would be included for each release. 

Score: 0 for intent to have a schedule and roadmap, +1 once established

0
Multiple co-developers List of contributors Contrary to OpenOffice.org, LibreOffice has always wanted to be a diverse community. At this stage the main contributors are Novell and Red Hat, followed by an impressive numbers of independent developers (patches between the “independent” and the corporate are about 50/50). Expect Canonical to ramp up its contributions with its new hire(s). +1
Forking feasible Developer how-to One can fork LibreOffice very easily. The problem is that it’s a very heavy application that has its own technologies and idiosyncrasies that most of developers would need to get really familiar with before trying to fork it. LibreOffice has already invested a lot of effort improving this situation and it will continue to be a priority, so this rule should eventually score +1. 0
Transparency Steering Committee While the Document Foundation is being set up not everything in its governance is fully enabled: for instance the Document Foundation still has to elect a full-fledged board, as the present Steering Committee is only an interim one. However significant efforts have been made to make the governance transparent. +1
Total +5

Many thanks to Charles for the submission. More submissions most welcome.

☆ More Ratings Please

Given the interest in my earlier article about a scorecard for open source and my own rough-and-ready benchmark proposal, I’d be interested in seeing how well the benchmark works at rating a variety of open source projects. If you’re familiar enough with a project to be willing to have your name associated with rating it, please complete the table below in the same style as my own evaluation of OpenJDK. Cut & paste into an e-mail and send the completed table to me.

I will review the information you’ve provided, possibly adjust your proposed scores a little to match the scoring style used for other evaluations and then I’ll publish all valid good-faith submissions on my blog.

Rule Data Evaluation Score
Instructions Provide sample extracts from public sources supporting your evaluation, together with links Read the Benchmark. Evaluate as objectively as possible, and conclude with a rationale for the score you are giving. Score -1 for a rule where the governance implementation detracts from open-by-rule; score 0 for implementations that have an overall neutral effect; score +1 for implementations that contribute positively to an open-by-rule community. “Open/Meritocratic/Oligarchy” scores between -3 and +3, evaluating for each word. I’ll review your submission before publication, so don’t worry too much 🙂
Open, Meritocratic Oligarchy +/-3
Modern license +/-1
Copyright accumulation +/-1
Trademark policy +/-1
Roadmap +/-1
Multiple co-developers +/-1
Forking feasible +/-1
Transparency +/-1
Summary (scale -10 to +10) +/-10
Project name
Project URL
Your name

☂ Governance Benchmark Available

My article establishing an open-by-rule benchmark for checking the governance of open source communities is now available in the Essays section.

☆ Rating OpenJDK Governance

I used to be a member of the Interim Governance Board for the OpenJDK project I helped Sun start to host an open source implementation of the Java platform under the GPL. For various reasons, the governance was never fully defined and the entire subject has been silent for over a year. There’s other context I assume most readers understand listed on CWUK. This week, news emerged that I am no longer a Board member (neither a surprise nor an issue for me), and that a governance proposal has been published.

How does the proposed OpenJDK governance fare when ranked against the open-by-rule benchmark I outlined earlier in the week? Scoring below involves +1 for each positive implementation of a rule, zero for each non-detrimental implementation or omission and -1 for each implementation that detracts from an open-by-rule governance.

Rule Data Evaluation Score
Open, Meritocratic Oligarchy “The Governing Board consists of five individuals:

  • The Chair, appointed by Oracle;
  • The Vice-Chair, appointed by IBM;
  • The OpenJDK Lead, appointed by Oracle; and
  • Two At-Large Members, nominated and elected as described below.”
This is initially a closed plutocracy comprising mostly people who have never been involved in OpenJDK, as long-term Free Java leader Mark Wielaard has pointed out. The initial Board is all appointed by Oracle and IBM and they have picked only people they can trust to represent them and taken few risks (only Doug Lea has spoken out in the past, when he resigned from the JCP) and omitted key OpenJDK contributors Red Hat and Google (and recent joiner Apple). Future Boards will always comprise at least two Oracle staff and one IBM member. Interestingly, this is not conformant with the original OpenJDK Charter, which gave a majority of seats to elected representatives.

There is scope for the Board to be grown in the future and it’s theoretically possible eventually for the Board to have community-appointed members outnumbering the Oracle-IBM axis, but the rules are poorly defined and there’s undoubtedly scope for them to be gamed in order to maintain control.

Scoring 0 for closed/open given the benefit of doubt for the possible expansion process; -1 for non-meritocratic majority; -1 for non-representative oligarchy.

-2
Modern license (not mentioned in governance) OpenJDK uses a complex licensing arrangement based on GPLv2 plus a variety of exceptions. GPLv2 has decent implied patent protection according to most legal sources I have consulted. It’s actually a good combination of licensing both for software freedom and as the basis for Oracle to build a business around the code, but it’s not mentioned anywhere in the governance so could presumably change at any time based solely on Oracle’s choices.

If the governance committed to maintaining GPL as the license I’d score this as +1 but the lack of mention makes it 0.

0
Copyright aggregation “A Contributor is a Participant who has signed the Oracle Contributor Agreement or who works for an organization that has signed that agreement or its equivalent. Only a Contributor may submit anything larger than a simple patch.” Copyright is explicitly aggregated solely in Oracle’s hands. There are actually good historic reasons for this and without it I doubt that either IBM or Apple would be involved in OpenJDK since it would be impossible for Oracle to privately license the resulting Java implementation to them under terms they would accept (neither of them like GPL). Furthermore it allows the existing Java licensing arrangements to be sustained, meaning OpenJDK can be the locus of development for Java SE.

While I would rather see the overall copyright vested in a non-profit foundation, the pragmatic balance of factors means I score this as 0.

0
Trademark policy (not mentioned in governance) The OpenJDK trademarks are all dealt with outside the scope of the governance and are the exclusive property of Oracle who even claim control of their use within the source, a context I’m surprised to see alleged trademark law is applicable. This clearly scores -1. -1
Roadmap “If a Governing Board member objects in good faith to a technical or release decision made by the OpenJDK Lead then that decision may be appealed via the following process.”

JDK Release Projects may only be proposed by the OpenJDK Lead and may only be Sponsored by the Governing Board.”

“Every OpenJDK Member will have the opportunity to propose features for inclusion in JDK Release Projects, and decisions about which features to include will be made in a transparent manner.”

Despite being intended to ensure “that sufficient infrastructure is available to Community members” there’s no mention of how releases will be conducted – there should at least be baseline principles. There’s an appeals process, but it is only open to Board members and there’s a clear intent that the roadmap is at Oracle’s sole discretion. This especially applies to JDK releases. The nod towards transparency is a positive sign but contradicted by the appeals process.
 

While this is all nothing new, it’s hardly “open-by-rule” so a clear -1.

-1
Multiple co-developers There’s a cross-section at FOSDEM. OpenJDK is blessed with enthusiastic co-development from both independent community participants and from corporations like Red Hat, Google and now Apple. It’s a shame verging on an insult that they weren’t involved in creating or starting the governance, but overall this is OpenJDK’s biggest strength and a clear +1 score. +1
Forking feasible IcedTea, multiple co-developers, Classpath history The code is under the GPL, but the copyright is aggregated by Oracle and the trademarks all belong to them. There are enough co-developers outside Oracle to sustain a fork (after all, Classpath was a viable Java implementation before and IcedTea is still running). Chances are that IBM is subject to a no-forking agreement in return for lending its credibility to the governance. The documentation is subject to rules intentionally designed to prevent them being used on a fork.

Overall, this is a tough rule to score but on balance I think forking would be tough but possible. Given all the factors making it tough, I score this as 0.

0
Transparency “I’m happy to report that, since last November, I’ve been doing just
that: Drafting a set of Community Bylaws in collaboration with John
Duimovich and Jason Gartner of IBM, Mike Milinkovich of Eclipse,
Prof. Doug Lea of SUNY Oswego, and Adam Messinger of Oracle.”
Despite having roots in the work of the previous governance board (which also inherited ideas from OpenSolaris), the governance itself has come from nowhere and that bodes ill for future transparency, no matter how often the word is used in the document. The track record for OpenJDK has shown a mixed history for transparency. The corporate pressures are likely to mean lots of back-room dealings and the governance does little to prevent them.

Again, tough to score. I’m tempted to score this as -1 but the fact there’s  a public governance at all and that Mark promises there will be a ratification step (albeit undefined) makes me give the benefit of the doubt and thus a score of 0.

0
Summary (scale -10 to +10) -3

-3That score isn’t as bad as it could be, but given that

“The goal of these Bylaws is to foster the long-term health and growth of the Community by enabling and encouraging its members to act in an open, transparent, and meritocratic manner.”

I think there’s still plenty of work required to make them fit for purpose. I’m offering these comments in the spirit of contribution and dialogue. I’d be pleased to help the OpenJDK project in any way I can if they wish during the drafting and ratification process. I’ll be at FOSDEM this weekend speaking on this subject in the Free Java DevRoom, so meet me there if you’d like to discuss anything.

I have hoped from the beginning that OpenJDK would be an open-by-rule community in which everyone with a commitment to Java can participate as equals. Let’s hope this new development can deliver on that vision.

☝ The Open-By-Rule Governance Benchmark

With Oracle’s OpenJDK Project about to announce new community governance, many people have asked what I look for in good open source project and community governance. My personal benchmark is over on ComputerWorldUK today – take a look. I will probably be speaking about this in the Java DevRoom at FOSDEM on Saturday afternoon.

☝ Private Agreements Harm Communities

I pointed yesterday to an interesting comment about contributor agreements attached to a report about Michael Meeks speech a LPC. Another comment to the same article by Meeks himself casts light on another, much more serious issue for open source communities; bilateral agreements.

Read on at ComputerWorldUK.

☝ Contributor Agreements Say You’re Not Welcome

The conversation around LWN’s coverage of Michael Meeks’ talk at the Linux Plumbers Conference (sadly paywalled until now but available today and worth reading all the way through) provoked interesting comments. The subject of the discussion is LibreOffice and the code ownership issues which provoked the fork. But what caught my eye was a comment from Josh Berkus describing his consulting experiences.

Read on over at ComputerWorldUK.

★ Rehost And Carry On

Revised version of British wartime poster, found on Wikipedia

T-Shirts Now Available!

I spent the last two days in Brussels with many of the key participants  in the OpenESB Community. OpenESB is a large software subsystem that conveniently allows all kinds of applications to communicate with each other across networks. It was created by Sun, but since the Oracle acquisition has, as the former Sun project leader (now at Google) wrote eloquently, languished in the decline reserved for projects with important customers which are nonetheless no longer wanted. There’s the soft sound of footsteps backing away to leave it in splendid, unannounced isolation.

The community around OpenESB is actually fairly active, and they (or, as it includes ForgeRock where I now work, perhaps I should say “we”) want OpenESB to stay around. But what do you do if the project is hosted somewhere under the control of a disinterested party? There’s no huge crime or disagreement to “justify” a fork and the code is still out there, but on the other hand any new plans really will need the source and the community presence hosted in a way that allows the interested parties to change and improve things without having to wait for weeks to get replies to requests and risk having them declined if they are deemed inconvenient.

That’s why the topic under discussion is not forking – the remaining community is not divided – but rehosting. That’s also how I would characterise what ForgeRock has done with OpenAM (formerly OpenSSO) and OpenDJ (formerly OpenDS). No conflict, no malice, just a desire by the remaining community to carry on in the aftermath of the main sponsor backing silently away.

[An expanded version of this post can be found on ComputerWorldUK]

✍ Community Types Essay

Nested community layers diagramMy essay on Community Types is now available in the Essays section of the site. It defines what I mean by terms like “co-developer” and “deployer-developer” when I use them in conversation.

★ On Copyright Aggregation

Monarchs on EucalyptusA collaborative activity dubbed Project Harmony is now under way between corporate and corporate-sponsored participants in the free and open source software communities (not to be confused with the Apache Java project of the same name). The project seeks to harmonise the various participant and contributor agreements – collectively termed “contributor agreements” by some – used by many open source projects.

The goal of the project’s initiators is to reduce the legal costs of analysing paperwork faced by companies contributing to open source projects. Initiated and sponsored by Canonical, meetings have already been held several times under the Chatham House Rule, including one recently during LinuxCon in Boston. The participants also number several people who are skeptical of the value of copyright aggregation, myself included. At the meeting I was asked to write about my skepticism; this article is the result. I’m by no means the first to tread this ground; you’ll also want to read the earlier article by Dave Neary, and the comprehensive article by Michael Meeks ends with a useful list of other articles.

What are “contributor agreements”, why do they exist, and are they a good thing?  The need often arises from the interaction with open source of certain approaches to business. They serve a need of those approaches, but they can come at a significant cost to the health of the project. If you’re starting a new project, it’s worth understanding the bigger picture before diving in with a practical guide on the assumption “everyone uses contributor agreements” because not everyone does. For good reasons.

Dual Licencing

One of the dimensions of the business of open source has been the dual-licensing business model. The name is a little confusing since there is (usually) only one open source licence used – the second arrangement is usually a proprietary license or contract exempting the customer from some of the terms of the open source licence. It can be better to describe this as “selling exceptions to the open source licence”, and it is commonly done in conjunction with the GNU General Public License (GPL) which has clauses some businesses regard as hard to accept.

Under this model, open source software is genuinely present, guaranteeing the freedoms of its users, but the business owning the copyright makes money by selling benefits such as the right to make derivatives under a different licence, commercial terms that offer additional guarantees and (most famously) anything-but-the-GPL as the licence under which the software is used. This last option means dual-licensing has often been associated with shady sales tactics along the lines of “it would be a shame if your business got infected with that evil GPL viral licence…”

Copyright Aggregation

In order to use this model, the business owning the copyright has to own the entire copyright to the software they are distributing. As a consequence, when any community member wants to add a modification or enhancement to the source code for the software, the owner demands that to do so they must also hand over their rights to the addition. To achieve this, the copyright owner makes signing of a legal document mandatory for any involvement in the community that involves co-development.

Usually called a “contributor agreement” (to the detriment of older arrangements that use that term for community participation agreements that don’t actually aggregate copyright), the document gives rights amounting to ownership of the copyright in the new work to the copyright aggregator. It may also include other clauses, such as a statement or originality (“this is my work and I didn’t plagiarise it”), a grant of patent rights and even an indemnity (“if you get sued you can blame me”). In most cases the author retains rights to their individual work in some form or receives a license back, but it’s only the aggregator who has ownership of the copyright to the whole system.

So What’s The Problem?

Open source can be defined as the co-development of software by a community of people who choose to align a fragment of their self-interest in order to do so. The commons in which they work contains software under an OSI-approved licence free from usage restrictions with guaranteed freedoms to use, study, modify and distribute it – “free software”. The community members each work at their own expense in order to achieve a shared outcome that benefits all, including themselves. When they create an enhancement, fix a defect, participate in a design, they are not “working for free” or “donating their work” so much as they are “participating in co-development”.

That favoured word “contributor” gives a clue to the problem copyright aggregation agreements cause. An open source community is an open, meritocratic oligarchy – ruled by an elite who gained leadership based on the merit of their participation and skills, open equally to anyone who does the same in the future. The presence of a “contributor agreement” that involves copyright aggregation may be a warning sign that the community using it has one member who is more equal than all the others.

Communities whose members are termed “contributors” rather than “members” or “participants” may well be unequal places where your interests are subsidiary to those of the copyright owner. They are often dominated by users and fans of the software rather than by co-developers, since the inequality makes it hard-to-impossible for a genuine co-developer to align any fragment of their interests on equal terms. Indeed, this inequality is seen by some dual-license proponents as one of the attractions of the model as they seek a community of enthusiasts and (hopefully) customers that they can exploit without competition.

Exceptions

There can be justifications for having copyright aggregation by and for a community. When the beneficiary of the aggregated copyright is the community itself (in the case of a community hosted by a non-profit Foundation), there are benefits available that may outweigh the disadvantages. These include giving the Foundation the legal right to enforce the copyright in certain jurisdictions, and the freedom to update the open source licence later. They may also include the granting of additional rights such as patent licences in the case where the open source licence does not adequately deal with patents, or to help in countries where copyright law is sufficiently different from US law that the US-centric concepts behind open source fail. Richard Fontana covered these well in his LinuxCon presentation.

Even with these benefits available, there are many communities that choose not to aggregate their copyrights – notably the Linux kernel, GNOME, Apache and Mozilla communities. The recent policy and guidelines on copyright assignment by the GNOME Foundations are especially worth reading. Having diverse copyright ownership leads to a deeper mutual trust and an assurance that the playing-field remains level. Insisting on copyright aggregation is one of the more certain ways a company can ensure the open source community it is seeding remains small and lacking co-developers. With the rise of “value add” business models such as Apache-based open core or service subscriptions, it is less necessary for the businesses involved to aggregate copyright.

Some Foundations that avoid aggregation (such as Mozilla) do have a document termed a contributor agreement but the purpose it serves might be better termed a “participant agreement” since it mainly addresses community norms and specifically avoids copyright aggregation. Indeed, there are some who suspect a motivation for using the term “contributor agreement” vaguely to describe agreements also aggregating copyright is a tactic to screen the toxicity of copyright assignments from general view.

How To Flourish

It may well be advisable to have a participant agreement for your community, to ensure that everyone has the same understanding of and commitment to the project if they are sharing its evolution. But if you want your community to flourish, eschew aggregated copyrights, or vest them in a non-profit entity representative of and open to the community. In fact, avoid any institutional inequality and focused control. Communities should be open-by-rule.

In my experience,  attempting to retain control of a project you’re starting or hosting leads to mistrust, contention and a rules-based focus that diminishes your reputation. Relaxing control will lead to the community innovating and growing in ways you’ve not anticipated, as well as enhancing your reputation. As I’ve frequently said (although less frequently been heeded): trade control for influence, because in a meshed society control gets marginalised while influence delivers success.

[First published in ComputerWorldUK]

%d bloggers like this: