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.

Don’t Call It Relicensing!

Using open source elsewhere is not relicensing, it’s overlaying a second license.

So you’re considering taking some open source code under a minimal, non-reciprocal OSI-approved license and putting it under a different open source license, hopefully in combination with your original code (or another form of larger project). 

Don’t call this “relicensing” – it is not! The original license will continue to apply and you remain responsible for complying with its requirements. Only the copyright holder can change the license. You’re not relicensing – instead you are using the rights the license has given you and applying an additional license to the combination of the earlier work and your work. 

Continue reading

An End To API Gaslighting?

The Supreme Court decision in Oracle vs Google ends a decade-long nightmare for open source developers.

Sunlight or gaslight?*

The decision of the US Supreme Court (SCOTUS) to reverse the erroneous conclusion of the US Federal Circuit appeals court (CAFC) that Google’s use of the Java SE API in Android was a copyright infringement comes as a great relief to open source programmers everywhere. Software developers have always assumed that merely including a function prototype in their code does not require copyright permission as it’s just a fact about the implementation.

Continue reading

A Rights Ratchet Score Card

A draft scorecard for determining if a software project is open as bait for a business pivot or genuinely keeping your freedoms protected.

Open or closed? You decide.

The seven signs a project is following the rights-ratchet route to riches and the framework for going beyond licensing can be augmented by some straightforward indicators of an issue. None of these alone is necessarily a cause for concern, but the more clicks, the more risks. Here’s a rough-and-ready first draft of a scorecard to check whether your software supplier considers you a community peer and will respect and protect your essential freedoms, or visualises you more like one of those pods in The Matrix. Just count the clicks; the more clicks, the higher the risk this is a rights-ratchet that will end up closed.

Continue reading

What Did Sun’s OSPO Do?

Started in 1999 and established as an official corporate function in 2005, Sun’s Open Source Program Office (OSPO) was among the first in the industry and maybe the first to use the name.

As I’ve discussed in earlier posts, corporations are the vehicle for the collective expression of many individuals. However, to the outside world they are a monolith, and are expected to be consistent as well as predictable in their actions.  With the many varied, implicit expectations and explicit obligations that different open source projects have, transforming a company’s reputation into that of a good actor in open source is a complex task.  It’s also a necessary one if you expect other actors to invest their time and work in your project, or to give you influence in steering a project together.

Continue reading

Accommodating Open Source In Standards Processes

Holders of zero-tolerance positions on both sides of the divide need to realise that accommodating open source productively inside standards bodies is both viable and happening now.

A fine balance

You’ll recall that open source and open standards are orthogonal concepts where even the words they share (like “open”) are defined differently. That doesn’t mean they are mutually exclusive, nor that they are bad together – they can be cultivated well in the same garden. There is great value from accommodating the two orthogonal concepts so that neither is invalidated by non-mandatory elements of the other. When they combine, great value is unleashed.

Continue reading

Growing Blueberries

Why accommodating open source at a standards body is like growing blueberries.

Fresh-from-the-bush blueberries are one of the good things of life. When I set up my home office about a decade ago, I had to install an underground conduit to supply essential services — power, water, network — and dug a deep trench all along the path that leads there. When I refilled the trench I decided to plant a blueberry hedge so looked into how to grow good blueberries.

Continue reading

The FAQ as Vital OSPO Tool

Using a community FAQ as a way to get internal disagreement addressed and external communities on board – the OpenJDK experience!

In this talk from FOSS Backstage 2021, Rich Sands and I discuss the way we used a (very large) FAQ to both align the disparate corporate functions inside Sun Microsystems and address the lack of trust in Sun by both the Free Java community and the wider open source community. What we did back then is still a highly appropriate tool for any OSPO that needs to stand in the divide between a controversial corporate position and an aggravated community.

Software Freedom For Business Value

Software freedom is important to as an idea, but it also creates all the value of open source for business and should be jealously guarded by OSPOs.

In talking about open source, I and others routinely use the expression “software freedom” to refer to the set of rights upon which the open source phenomenon is based. It arises as a synonym for “free software”, an unfortunately ambiguous term that leads people hearing it for the first time to conclude all the primary attributes of open source software relate to money — price, cost-of-ownership, license fee and so on.

“Software freedom” puts the focus in the right place — on the essential liberties required to benefit from the software. One problem with this alternative term is we are becoming accustomed to hearing discussions of “freedom” be limited to activist or political contexts, and consequently regard the term “software freedom” with caution. But a focus on software freedom isn’t just for the revolutionaries.

Continue reading

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