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).

No To “No Hacking” Clauses

Trying to ban clever hacks in an open source licence is not OK.

Rocks

A correspondent asks about the Open Source Definition (OSD):

“Does OSD 6 mean I can’t include a clause in a new open source license that prohibits hacking?”

Yes, you are correct – that’s called a “field of use restriction” (FoU) and copyright licenses that contain field of use restrictions are not approved as open source. Open source licenses are for guaranteeing software freedom, nothing more or less. Continue reading

Rehost and Carry On, Redux

A key value of open source is the ability to switch to a different supplier if your first becomes unavailable or unattractive. Forgerock is apparently withdrawing that value, on which it relied itself for its inception.

Swords

After leaving Sun I was pleased that a group of former employees and partners chose to start a new company. Their idea was to pick up the Sun identity management software Oracle was abandoning and continue to sustain and evolve it. Open source made this possible. Continue reading

Software Freedom, Utility and Maintenance Time

Whilst many may long for a truly open source OS that meets all of their needs, the reality has always been that compromise has a role to play whenever it comes to picking your operating system. Despite the availability and increasing ease of installation of purer open source systems, there remains a trade-off to be made. Systems with a high level of software freedom and an intuitively usable interface seem to require high levels of maintenance to keep them alive. Where a system with high software freedom’s been designed to require less maintenance, the usability seems to suffer. Of course, this triangle has a third point to it too: where a system is both easy to use and maintaining it doesn’t consume too much of your time, it’s software freedom that takes the hit.

What sort of system you choose should depend on which of those three factors you prioritise. Read the details about this theory, along with some pointers for recognising systems that value software freedom in Simon’s InfoWorld Article.