Legally Ignoring The License

Perhaps the biggest current challenge to open source software is companies which ignore open source software licenses. That sounds so “yesterday” from an era of license scanners and compliance scares. But the issue is as relevant today as it was 20 years ago – just not the way you think!

Contributor agreements have been a controversial topic throughout their history. The choices by Elastic (and others before them) to relicense previously open source software under a licensing arrangement that discriminates against certain users threw the use of contributor agreements into sharp relief. But the controversy around them focused too much on the wrong problem. The main problem with a copyright-assigning agreement is not it giving the right to the aggregator to relicense the work (although that is a problem as it enables the end game of a rights ratchet). The main problem is it allows the aggregator, uniquely in the community, to ignore the license altogether.

A Brief History Of Scareware

All Open Source licenses grant unconditional permission in advance to those who comply with their terms to use, improve and share the software in any way and for any purpose. At a stroke, scope for artificially making the (inherently non-rivalrous) software scarce are eliminated. Of course, that’s a serious problem if you’re an entrepreneur whose imagination only extends to directly monetising access to the software.

Right from the start wily entrepreneurs realised that Copyleft licenses scared and confused some people, especially lawyers. So they sold customers the right to replace the open source license with a proprietary one – for some reason something customers’ lawyers found less scary. The pioneer of this approach was probably Sleepycat Software Inc whose BerkeleyDB embeddable database came under a source-available arrangement that left their users in no doubt that they had to make their own private work available to the public. Sleepycat sold a “commercial use” license that didn’t have the same requirement but which also left the user with none of the four freedoms. Selling indulgences had been profitable in the middle ages and it also worked for Sleepycat, all the way to acquisition.

Inspired by that success, many other companies sold indulgences. As the market wised up to the GPL and corporate counsel was no longer scared by it, companies transitioned to using other scareware licenses such as AGPL as well as to using “open core” approaches where the commercially valuable functions were not in the open source code at all. By using the no-charge availability of the software to gain adoption, free adoptors could be converted to paying customers and ultimately to lock-in. Some users of this strategy – notably SugarCRM – were able to ratchet back the freedom over time until they had an old-style proprietary software business.

Controlling The “Community”

However, there was an inconvenience. For much software, gaining adoption meant persuading cautious, picky developers to use the code — hand-waving to the boss was no longer enough. Once they were using the source, developers might well improve it. Inspired by the likes of Apache and Mozilla they then might well share their improvements, thus forming a community to produce better code than you. So it was smart to invite and use their improvements and thus keep control of the community.

But then the presence of these contributions under the GPL would make you subject to the GPL yourself and unable to sell indulgences or ignore the license. The fix to this was to speak to the sense of fairness and desire for an easy life (and pleasure of recognition) and claim it was in everyone’s interests for the core company to own all the copyrights. Apache and the FSF helped things along by socialising the idea of copyright assignments1. All these factors led developers to agree to gift the IP rights to their work to the core company. The name of such a document is a contributor license agreement or CLA.

Once they have a CLA, a company is able to aggregate all the rights to the software as if they own it. This has several consequences for the project:

  • They can sell indulgences, so that some community members are able to ignore the license.
  • They can ignore the license as well, enabling open core models that could otherwise be impossible.
  • They can do secret deals with other companies to treat the code as their own or even sell the complete rights, including to a company that actually wants to end the project. Because they can act secretly they can potentially preempt forks.
  • They can make releases without community consensus, making it impossible for peers to join in.
  • They can change the license by fiat, including to one that harms bona fides contributors they want to disadvantage
  • They can end the public project completely, as SugarCRM did.

Socially Unacceptable

An open source licence is a multi-lateral constitution of a community, setting norms that apply equally to all. Having every developer and user subject to the same terms is one of the pillars of community. A copyright assignment provides unqualified and unappealable immunity to all that. The presence of one in a commercially-backed project is almost certain to mean someone doesn’t want to be subject to the rules and norms everyone else must abide by, usually as part of a rights ratchet. They and their sham freedoms should no longer be tolerated by open source contributors.


Footnote 1: In both cases the CLA is – at best – marginal to the community. At Apache, the CLA is redundant with section 5 of the Apache License which many people believe grants all the rights the community needs. Folklore at Apache says that IBM’s lawyers were not sure of that and just to be certain insisted there be a CLA as well. At the FSF, the CLA is also redundant with GPLv3 (and likely with GPLv2 as well) but it has long argued that the FSF needs to own the copyrights in the USA in order to pursue license compliance — even though they don’t do so much and the surrender of copyright reduces the ability of the actual developers to choose to enforce.

Rights Ratchet Talk

Simon delivered a talk for the new Tidelift conference “Upstream”. In it he drew together the threads of several earlier posts about the rights ratchet model (“bait & switch meets boiling frogs”) using the history of the now-defunct Sugar CRM open source project as an initial case study and then examining the various ratchets that remove rights from open source project participants, ways to detect that a project is actually a rights ratchet and steps to mitigate the consequences including promoting permission in advance.

FLOSS Weekly 622: Keith Packard

Simon joined Doc Searls to host episode 622 of FLOSS Weekly featuring Keith Packard, one of the key figures of the open source software movement. They talked about Keith’s involvement in the X System and Freedesktop.org and strayed into related topics including the many projects Keith has helped and his interest in rocketry!

One significant discussion considered the thread joining the fork of XFree86, the recent vote to change the board of Nominet in the UK and the controversy over the reinstatement of Richard M Stallman to the board of the Free Software Foundation this week. Each represents a significant entity to the open movement which has leadership that was established as a “club” between activists and failed to progress into a well-governed organisation representing and controlled by the community.

Permission Beyond Licensing

Is that single-company-controlled project actually open source in the sense of delivering software freedoms to you or just about delivering prospective customers to its host company? Here are 7 tests.

I frequently sum up the nature of open source licensing as granting permission in advance to developers or users to use, improve and share the software for any purpose. But the “Permission In Advance” lens has uses beyond just the rights to copyrights and patents granted in an OSI-approved license. 

In my consulting engagements, I use a “thinking tool” to help clients work through their proposals for new open source community activities. Evaluating a project’s licensing, patent, and community management strategy — both to join it and to host it — should begin with the question: “How confident are community members that they have permission in advance to do whatever they need to succeed?” The more reasons for confidence, the larger the community.

Here are some of the questions community members will be asking, perhaps silently, about single-company open source projects and their own agency as a member of the community:

Continue reading

OSI Board Evolution

I spent last week in New York at the annual new-inductees face-to-face Board meeting of the Open Source Initiative Board (pictured below – Christine Hall is also a member but was unable to join us).  Having spent the last 11 years working on refactoring OSI for a new generation, I had advised the Board in advance that I intended to step down as President to make way for fresh blood. The Board elected Molly de Blanc as the new President and Josh Simmons as Vice President, with Hong Phuc Dang bravely volunteering to be CFO. I agreed to serve as Board Secretary until someone else feels ready to play that role – no later than next April when my term ends.

OSI Board 2019.jpg

OSI Board 2019-20.  Standing: Simon Phipps, Elana Hashman, Pamela Chestek, Molly de Blanc, Faidon Liambotis, Chris Lamb, Hong Phuc Dang, Patrick Masson. Kneeling: Carol Smith, Josh Simmons.

The OSI I’m handing over to the new Board is very different to the one I first attended in 2008 (as an observer – I wasn’t invited to join until 2010). It is now elected rather than selected (albeit via an indirect mechanism to make California regulation easier to manage). The electors are over 60 affiliate organisations representing the majority of the world’s core open source developers and an ever growing community of individual members. OSI now has a viable income arising largely from a diverse range of around 30 sponsors. It now has a staff, including a full-time General Manager (Patrick Masson, far right). It now has maintained systems for managing donations, lists and outreach. And there’s more been achieved – those are just stand-outs.

All together that means OSI has a proven foundation for the new Board to build upon. Already built on that foundation there are a postgraduate curriculum, a programme to advocate open source in the world of standards, a programme to equip schools with recycled PCs, working relationships with peer organisations like FSF and FSFE and more. There are many people responsible for all this change, too many to name here, and I thank them all.

People always look forward rather than back and there are still plenty of issues to deal with which are the new Board’s focus. We are already working to improve the license review process, for example.  But I’m really pleased with what we have all achieved over the last decade at OSI and am thrilled that there’s an energetic, more diverse and younger crew taking over.

5 Reasons Facebook’s React License Was A Mistake

Facebook’s BSD+Patent license combo fails not because of the license itself but because it ignores the deeper nature of open source.

Beware Falling Rocks

In July 2017, the Apache Software Foundation effectively banned the license combination Facebook has been applying to all the projects it has been releasing as open source. They are using the 3-clause BSD license (BSD-3), a widely-used OSI-approved non-reciprocal license, combined with a broad, non-reciprocal patent grant but with equally broad termination rules to frustrate aggressors.
Continue reading

Give Generously! Seven Ways To Help Open Source

Should you donate money to the open source projects you use? Or is there a better way to help?

heavy-load_8081048699_o

Your business most likely depends on open source software. But are you playing your part to make sure it will still be there in the future? For that to happen, the projects where it is both maintained and improved need to flourish. Continue reading

7 Rules For Engaging Communities On Legal Matters

When you need to discuss a license, a legal document like a CLA or a governance rule with an open source community, what’s the best approach to take?

Squirrel pops up behind log to check things outHaving watched a fair number of people attempting to engage both the Open Source Initiative’s licensing evaluation community and the Apache Software Foundation’s legal affairs committee, here are some hints and tips for succeeding when your turn comes to conduct a discussion over legal terms with an open source community. Continue reading

4 Lessons From Watching Governance Games

Even near-perfect governance like Apache’s can get gamed by a determined and well-resourced player. What lessons can we learn from their experience? 

snake-warning_9391539040_o

 

I’ve previously written about the fact the Apache Software Foundation offers an exemplar of large-scale open source governance. Even with those supreme qualities, things can still go wrong. Apache offers some of the best protections for open source contributors but its mature rules can be manipulated by skilled politicians and/or determined agendas. What can we learn from their experience? Continue reading

Engaging Open Source Communities

At FOSDEM 2017, Simon gave a well-attended talk explaining many of the things that could go wrong for a company trying to engage a large open source project over legal or governance issues. Based loosely on a mailing list thread at the Apache Software Foundation, the talk highlighted seven things to avoid and gave ideas on how to do so.

Continue reading