Is Open Yet Closed Still OK?

In these days of code that no single mind can grasp, it’s hard to see how software freedom is present when there’s no realistic community access to source code.

Copycat Tree

In the early days of Free Software, it was a safe assumption that anyone using a computer had coding skills of some sort — even if only for shell scripts. As a consequence, many advocates of Free Software, despite a strong focus on user freedoms, had a high tolerance for software that made source available under free terms without providing other access to the project, especially in the days when that meant tapes by mail.

Limited access was considered undesirable, but as long as the source code could be used it was not disqualifying. From this starting point, cumming entrepreneurial minds found many other ways to ensure that the software was somehow impractical to deploy without a commercial relationship with a particular vendor, even if the letter of the rules around Free Software was met.

This tolerance for “open but closed” models continued into the new Open Source movement. As long as code was being liberated under open source licenses, many felt the greater good was being served despite obstacles erected in service of business models.

But times have changed. Random code liberation is still desirable, but the source of the greatest value to the greatest number is the collaboration and collective innovation open source unlocks. While abstract “open” was tolerated in the 20th century, only “open for collaboration” satisfies the open source communities of the 21st century. Be it “open core”, “scareware”, “delayed open”, “source only for clients”, “patent royalties required” or one of the many other games entrepreneurs play, meeting the letter of the OSD or FSD without actually allowing collaboration is now deprecated.

As a consequence, OSI receives more complaints from community members about “open yet closed” than any other topic. Companies of all sizes who loudly tout their love for open source yet withhold source code from non-customers generate the most enquiries of this type. When approached, OSI contacts these companies on behalf of the community but the response is always that they are “within their rights” under the relevant open source licenses and can do what they please.

One claim that deserves to be soundly debunked is that it’s OK to withhold open source code from non-customers. All open source licenses should be interpreted as requiring source to be made available to the public. OSD 2 is very clear:

2. The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost, preferably downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed.

Interestingly it’s common that the companies involved obtained the source code they are monetising under an open source license, while they themselves own the copyrights to a tiny percentage of the code. They can be considered to have enclosed the commons, enjoying the full benefits of open source themselves — and celebrating it — but excluding others from collaboration on the same terms.

Many community members would tolerate this were it not for the company claims to be strong supporters of open source. Even this behaviour might be mitigated for some with upstream code contributions. But in the absence of public code, most community members dispute something is open source, regardless of the license used. “Open yet closed” may have been tolerated twenty years ago, but today the rule is open up or shut up.


(First published by the Open Source Initiative, November 14, 2017, with the support of Patreon patrons).