The subject of Open Source and OS licenses has been waxing and waning over time. Recently, it became hot again. In this post, I'd like to do a quick recap to set the stage. Then, I'll analyze reasons for license changes.

The rise of Open Source

Before I actually started my career - even I was before even born - software was provided with its source code. The value was in the hardware. Most customers - if not every one of them - modified and adapted the source code to their hardware. Then, in 1969, the United States' government ruled (against IBM) that the bundling of software and hardware together was anticompetitive. The value moved from hardware to software because of an unexpected side-effect of the previous ruling. Thus began the rise of Microsoft Windows. Interestingly enough, that also changed the way software was delivered. Customers only got the binaries, not the source code. Of course, this is mostly the case today.

Around ten years later, a new trend started in reaction to that: some with Richard Stallman decided that releasing the source code was the only right way to deliver software. Furthermore, their position was that software should be free. Because that tiny initiative became a respectable model, this view on things is more than relevant today. Today, Open Source means different things in the mind of different people.

Open Source is a loaded term

Literally, Open Source is only the delivery of the source code along the binary. No more, no less. For commercial software, if carefully worded in the purchasing contract, that means that the customer should be able to maintain the software if the vendor doesn't anymore (e.g. goes bankrupt). Yet, according to Stallman's definition, software needs to be free:

Free as a bird

Free as a beer

To avoid any confusion, I'd rather use the expression Free Open-Source Software a.k.a. FOSS.

What qualifies as Open Source

This gap in the terms were deeply materialized in tensions in the community between tenants of the business-compatible Open Source and FOSS as defined above. From the former group was born the Open Source Initiative. The importance of this organization cannot be understated: it decides what licenses are considered Open Source, based on the Open Source definition. Criteria are:

Free Redistribution
Source Code
Derived Works
Integrity of The Author's Source Code
No Discrimination Against Persons or Groups
No Discrimination Against Fields of Endeavor
Distribution of License
License Must Not Be Specific to a Product
License Must Not Restrict Other Software
License Must Be Technology-Neutral

As of the time of writing of this post, licenses that are allowed to be qualified as Open Source are limited in number. Here's a couple of them:

Here are two counter-examples:

The Climate Strike License is not Open Source, as it's not in the list above
Creative Commons licenses are not Open Source, as they don't apply to software only

Monetizing Open Source

Open Source began as a community of like-minded people who wanted to create something together, and were willing to put on the extra effort, after office hours. However, today, the main contributors on the main projects are paid by private companies: they code during office hours. The reason for that is that Open Source - not FOSS - is compatible with business.

There are a couple of ways to monetize Open Source software:

Training and consulting

If you provide a great software, companies will start using it. At some point, there are chances they will need consulting, for advanced usage. After that, they will also need training to level up their workforce. It has been the traditional way to make money with Open Source. Unfortunately, this doesn't scale.

Support

While consulting is planned, support comes in handy when the sh... has already hit the fan. Picture this: it's 10PM, the monitoring Open Source stack your company uses has crashed, and refuse to start again. One definitely needs support in this case. In general, managers don't like to use any kind of software - whether FOSS, Open Source or something else - if they don't have an associated support contract.

Open Source core

The software offers features that are Open Source. A set of features available via extensions/plugins operate under a commercial (i.e. paying) license. The respective size of each depends on one's strategy. The more features in the Open Source part, the more people will use it, but the less money one will get. This is a fine balance to find.

Dual license

The software is available under two different licenses, one Open Source, the other commercial. When one uses the software, one needs to choose which license should apply. For this model to work, and companies to decide to pay a license fee, the Open Source license should be a deterrent. The GNU General Public License is a solid choice: it mandates that software that embeds the GPL software should be released under the GPL license itself i.e. for free.

Service-wrapping

It's no mystery that "the Cloud" has become ubiquitous since a couple of years, whether you like it or not. As more companies moved their IT-systems to the Cloud, the Cloud service providers became a force to be reckoned with. With that power, they bargained with software vendors on ways to provide the latter's software on their infrastructure. In general, the deal was pretty much one-sided: Cloud providers got a larger portfolio of services, while software vendors got "free advertisement" for their software, and in the best of case, crumbs of the revenue.

But even that was not enough. Some cloud providers became so bold as to stop pretending it was even a deal. They just got they greedy hands on the Open Source software, and service-wrapped it. It was completely legal, as none of the licenses prevents that. However, it raises the question of revenue sharing: one company is paying to develop the software, while another company is getting the biggest share of the revenues, because it controls the marketplace.

Because of that, some software vendors decided to change their license to prevent service wrapping. The issue is that no Open Source license is able to achieve that. Hence, those new licenses are not considered Open Source, as per the Open Source Initiative definition.

Other license changes

Changing one's license is in general not a great idea. When somebody uses your software, they need to be able to trust they can use it in the future under the same terms. The anti-service wrapping changes made sure that was the case.

Interestingly enough, I saw recently a license change unrelated to service wrapping. In the light of the CoVid-19 pandemics, somebody thought it would be a good idea to change the license to a new one:

CoronaVirus License :

The coronavirus is coming to you. It's coming at an exponential speed: gradually, and then suddenly. It's a matter of days. Maybe a week or two. When it does, your healthcare system will be overwhelmed. Your fellow citizens will be treated in the hallways. Exhausted healthcare workers will break down. Some will die. They will have to decide which patient gets the oxygen and which one dies. The only way to prevent this is social distancing today. Not tomorrow. Today. That means keeping as many people home as possible, starting now. >
To use this program, you must

1) Read the following article: https://dummy.com/coronavirus
2) Apply social distancing

If you live in UK, Europe, North & South America, Iran, Japan, Korea... and if you refuse to do so, please uninstall Dummy from your system and do not use this service anymore.

While the intention behind this change was commendable, the change was not. This is a sure sign the license cannot be trusted. If it changes today, why cannot it change tomorrow, for other reasons? I'd advise everybody in this situation not to do that.

Note that the license change was rollbacked as it was considered at least partially unlawful.

Conclusion

In this post, we described the origin of Open Source Software. We looked at the semantics of the expression "Open Source", and described the difference with FOSS. Then, we wrote about the Open Source Initiative, the characteristics it applies to define Open Source, and some licenses that fit this definition. We proceeded to list some ways on how to monetize FOSS. Finally, we described the problematic behavior of some Cloud providers, and how changing the license is a way to avoid it. Other reasons for license changes might break the contrast of trust between a software vendor and its users.

To go further:

Originally published at A Java Geek on July 12^th, 2020

On Open Source, licenses and changes