Legitimizing the flaws of maximalism
In opting to follow the maximalist model of contributor agreements, Harmony inherits, and thereby legitimizes, all of that model’s problems. There is growing awareness that the maximalist approach can impair the effectiveness of the open source community development model, creating unnecessary barriers to contribution. Rather than attempting to address those problems, Harmony merely hides them in attractive packaging.
One such problem is the departure of the maximalist model from the traditional free software norm of licensor equality. I believe that greater equality among project participants benefits FLOSS by facilitating the growth of vibrant developer and user communities around projects. Harmony’s insistence that the contributor assign copyright or grant a maximally broad copyright license signals that contributors are second-class citizens, undeserving of the same legal power as the project entity. With Harmony’s maximalist predecessors, this problem is exacerbated in the worst instances of the so-called “dual-licensing” business model, where a commercial project entity uses the GPL as its “community” license, spreads unwarranted fear about the GPL, and retains the sole power to provide alternative proprietary licenses.
Another problem is that maximalist contributor agreements, particularly complex ones like the Harmony templates, seem to signal that there is something legally insufficient or doubtful about open source licensing. If open source licensing is good enough for outbound licensing, why is it not good enough for inbound licensing? Why, in other words, is it considered necessary to impose an additional foreign legal layer on top of open source licenses? By legitimizing maximalism, and rejecting the inbound=outbound tradition, Harmony’s drafters call open source licensing itself into question.
The perils of uniformity
One of the stated goals of Harmony is to reduce the supposed proliferation of contributor agreements through a new standard set that is thought to embody best practices. The hope, presumably, is that Harmony will come close to occupying the field, perhaps ultimately supplanting existing contributor agreements and alternative practices, including the inbound=outbound tradition and minimalist approaches.
In this one respect, Harmony reminds me of efforts by two prestigious U.S.-based institutions, the American Law Institute (ALI) and the Uniform Law Commission (ULC), to ‘restate’ and unify the law on various subjects. Most of that work has been of great value. But in the software industry we have twice seen the dangers of an ill-informed push for unification. The ULC’s Uniform Computer Information Transactions Act (UCITA) met with such strong opposition that it was adopted in only two U.S. states. The more recent case is the ALI’s Principles of the Law of Software Contracts, of which Harmony’s chief drafter, Mark Radcliffe, has been a notably outspoken critic.
Formal contributor agreements, whether maximalist or minimalist, remain an uncommon phenomenon in open source. We are only beginning to learn what works, what fails, and what causes harm to open source community development. It is premature for us to unify, or harmonize, the ‘law’ of open source contribution policies. We are particularly not ready to declare victory for the perennially controversial maximalist approach, let alone Harmony’s new take on it.
I therefore apply to Harmony the words its chief drafter himself used to warn the software industry about the ALI’s Principles. If widely adopted, this unified maximalist contributor agreement system may well “have a very negative effect on the open source software industry” and “could have a significant negative impact on open source licensors and contributors”.
The misappeal of Creative Commons
Canonical founder Mark Shuttleworth has likened Harmony to Creative Commons. Given the enthusiasm for Creative Commons among many open source developers, I have expected supporters of Harmony to use that tactic in urging its adoption. There may be some similarities between the Creative Commons license suite and Harmony, but I am not sure those similarities are good.
The Creative Commons suite includes licenses that implement various policies. Some, like CC BY and CC BY-SA, are normatively consistent with corresponding permissive and copyleft families of free software licenses. Others, however, particularly its “NC” (no commercial use) and “ND” (no derivative works) licenses, are in conflict with basic principles of free software and free culture. I am not alone in lamenting the application of the Creative Commons umbrella brand to cover licenses with such disparate qualities. One consequence has been a general confusing dilution of the meaning of “openness” in the context of cultural works. A more specific problem is the evidence of confusion on the part of content authors interested in applying Creative Commons licenses to their works, and resulting confusion by those interested in making use of such works. Too often a work is labeled as being licensed under “a Creative Commons license”, without specifying accurately, or specifying at all, which free or nonfree policy the author sought to apply.
What resemblance Harmony has to Creative Commons raises similar concerns. Giving Harmony the greatest benefit of the doubt, I fear that the application of “Harmony” as an appealing global label to a set of permutations with differing legal consequences will confuse projects and contributors alike. In the context of Creative Commons, those concerns are somewhat attenuated by the nature of the material to which such licenses are applied. From the perspective of open source, the very different legal culture established by Creative Commons is not only tolerated but welcomed as an enormously successful experiment that is safely cabined to non-software content. It might be different if Creative Commons recommended, as it explicitly does not, the use of its licenses for software. Were someone to propose that a seemingly simple Creative Commons-like suite, designed by some central committee, should replace all traditional FLOSS licenses as they exist organically today, it would be quite alarming. I hope that Harmony is not the first step towards such a goal.
Software freedom and responsibility
Readers who have come this far may well ask, “Who cares?” If projects sincerely interested in building communities perceive that Harmony is problematic, they are free not to use it. If contributors perceive that Harmony is problematic, they are free to shun projects that use it. Part of the answer lies in the surface appeal of Harmony, and in its likelihood of causing confusion.
The rest of the answer lies in the backing of Harmony by the prestige of Canonical and its founder, or so I have thought. I have expected Canonical, the company that is behind one of the most popular Linux distributions, and Mr. Shuttleworth, a man with many resources at his disposal, to use their influence to promote Harmony. In the week following Harmony’s 1.0 launch, however, I have seen no pertinent press release from Canonical, nor any supportive statement from Mr. Shuttleworth. This puzzles me, but for now I must suppose that Mr. Shuttleworth has not lost interest in this project. I will assume that we may yet see some effort by him and his company to encourage community and industrial adoption of Harmony.
Canonical and my own employer, Red Hat, are very different technology companies, yet we are united by common cultural origins. We are both authentic products of the free software movement, and in particular that part of it that produced GNU and Linux. Our respective and very different successes give us each a special place in the FLOSS universe. But that special place also implies a special responsibility to conserve and nurture the community development culture from which we both sprang, and to exercise great care not to do anything that might damage it. It is with that responsibility in mind that I say to Mr. Shuttleworth, with all respect, that I cannot join him in any support of the Harmony initiative.