Stop ‘Forking Around’ with Software Labels

While I was handing out candy on Halloween, a trick-or-treater came to the door dressed as an open-source project. There was code everywhere and volunteer contributors were coming out of his ears. It was a clever costume, but what made it really scary was the giant fork he was carrying.

Open-source users know that forking an open-source project opens a whole new can of worms. If an IT manager builds the organization’s infrastructure on an open-source project and it forks, the manager now has to worry about which fork to stick with, lest he or she end up with an unsupported dead-end version of the project.

Fear of Forking

Lawyers have fear of forking too, but of language, not of code. Lawyers like language that is simple. But sometimes we can’t find simple, all-encompassing language, so instead of saying “you must not give our software to someone else” in a license, we say “you must not transfer, assign, sell, resell, rent, lease, license, distribute, pledge, hypothecate, etc.” to be perfectly clear.

That’s why lawyers are accused of being too wordy. Breaking simple definitions into several definitions makes ordinary conversation harder and lawyers’ work more difficult.

In an earlier column, I suggested we need a better umbrella term for free software and non-GPL open-source software. Currently, “free and open-source software,” or FOSS, is the term in use. But now, a greater problem looms on the horizon because some organizations are “forking” the definition of “open.” They want to co-opt “open” to serve their own purposes, just as food companies have co-opted “low-carb.”

Open Computing

For example, according to IBM, “open” can refer to open computing, open standards or open source. Therefore, to be certain you get a software license that allows you to do anything you want with the software, you might have to ask for the OCOSOS (open-computing, open-standards, open-source) version of the license.

“Open computing” refers to having open interfaces. For hardware, this means standardized interfaces with hardware components, so anyone can offer hardware or software that couples to the open hardware and the user is not limited to offerings of the original hardware vendor.

Open computing hardware and software can be very proprietary. With software, this usually means that the source code is not available, so the software is not modifiable by end users, although there might be a published interface to allow other programs to interact with the open-computing software. Open-computing software also need not be freely redistributable.

Benefits and Side Effects

Open standards provide interfaces to data and/or software that are well-documented and public. Examples include TCP/IP, HTTP, JPEG, MPEG4, SQL and XML. In many cases, the open standard aligns with the expected features of the open-source software.

They are visible to anyone and do not require special licensing for use or distribution. For example, as far as I am aware, nobody claims intellectual property in TCP/IP. Interestingly, some open standards are not freely usable. At least one licensing group asserts intellectual property rights to MPEG4 such that royalties are required from makers of MPEG4 encoders and decoders.

Open-source proponents often tout the benefits of open-source software in terms of side effects rather than direct attributes. Direct attributes of Linux, for example, include the fact that source code is available, per-copy royalties are not required, and it is redistributable. Some side effects of these direct attributes are the large community of skilled programmers that exists to draw support and modification services from, vendor independence, auditability, low acquisition costs and so on.

In some sense, the direct attributes should not be important to a practical IT manager if the desired side effects are obtained. If he or she can achieve vendor independence, the nature of the license to the underlying software might not be important. Advocates of open-source software need to make a compelling case for decision makers to care about direct attributes.

Co-opting the Low-Carb Craze

Companies that co-opt “open” like the label because end users look for that label in making purchasing decisions. It’s the same tactic food industry marketers used in co-opting the “low-carb” label. Their efforts have inspired millions of people to change their eating habits. No more beer, bread and processed snack foods laden with carbohydrates. Now, even fast food restaurants embrace the new trend by offering low-carb foods such as wraps, turkey, and salads.

One of the direct attributes of these types of foods is their carbohydrate content. One of the side effects is weight loss and improved health, (although the side effects might be open to debate).

The point is that once the marketing departments saw the light, everyone began scrambling to produce foods that would result in the desired side effects. Burrito restaurants started serving burrito bowls. Burger restaurants started serving burgers without the bun. Hard alcohol mixed with diet soda was positioned as a healthy “low carb” beverage. The term “net carbs” came into vogue, making it okay to ignore some of the carbs contained in high-carb foods.

Marketing Run Amok

Before marketing departments got involved, “open” meant open and “low-carb” meant low in carbohydrates. Not to indict of creative marketers, but sometimes their efforts can actually derail the development of products that really do have the promised direct attributes that create desired side effects.

In today’s software business, marketing departments attach “open” wherever they can to suggest desired side effects. The same is done with “low-carb.” And in some cases, low-carb bread for instance, the hype and the label do not match the reality. The product may produce some of the same side effects, but it doesn’t have the expected direct attributes.

Before marketers got into the game, programmers and end-users were quietly trading code that was truly open. Now, one has to double-check to be sure it really is open source in the expected sense. (To be fair, this is not entirely the fault of the marketing departments.)

Trick or Treat?

The fair definition of “open” is that I can do anything with the code I might expect to want to do, as well as some actions I know I wouldn’t do but nonetheless want the freedom to do because of the side effects of that freedom. Even if I never look at the source, I still want the right to modify the source. If the supplier wants to extract its revenue from me, it will focus on value added, not just forcing me into an upgrade I don’t want.

Maybe the Halloween trick-or-treater in the open-source costume was really supposed to be IBM. After all, IBM published a paper saying that “open” could mean “open computing” — which is not open-source software — and “open interface” — which is also not open-source software.

I handed over a treat, but maybe I should have sent the individual who was in that costume away with a simple admonition to “Just stop forking around already!”