On Open Source, licenses and 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.

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 beer

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:

  1. Source Code
  2. Derived Works
  3. Integrity of The Author’s Source Code
  4. No Discrimination Against Persons or Groups
  5. No Discrimination Against Fields of Endeavor
  6. Distribution of License
  7. License Must Not Be Specific to a Product
  8. License Must Not Restrict Other Software
  9. License Must Be Technology-Neutral

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.

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.

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.

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:

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store