When the Open Source Initiative (OSI) was formed in 1998, one of the important objectives of those involved was to create a phrase that can be used to represent all the values of software freedom easily in everyday speech. The phrase "open source" was intended to become a strong, respected brand representing the values of software developers across the software freedom communities. The OSI website says:
Open source is a development method for software that harnesses the power of distributed peer review and transparency of process. The promise of open source is better quality, higher reliability, more flexibility, lower cost, and an end to predatory vendor lock-in.
In the 15 years since then, open source has become a widely used term and a strong, compelling brand, the default choice of an increasing number of governments and enterprises. Open source leaves its users in control of their IT budgets, free to choose the software that solves their problems without asking permission from a vendor first. Open source plays a vital role in the development of all kinds of infrastructure, with developers free to repurpose and redistribute components and even whole subsystems without restrictions.
As a result, there's a large and increasing market value in the term "open source" -- so it's no surprise many companies are trying to cash in. Along with vendors who actually deliver on those open source benefits, a subset use the brand to sell their products without actually making open source freedoms available to their customers. These companies usually benefit from open source themselves, but the product or service they deliver to their customers doesn't include the unrestricted freedom to use, study, improve, and share the software. Not every company using these approaches is behaving badly -- but you need to make sure you protect your flexibility and IT control.
Companies use several models to make you think you're getting open source when you're not. Here's a short history of three potentially "faux-pen source" models.
This was one of the earliest monetization models for open source, famously pioneered by MySQL. Of the three, it's the least concerning because you can often avoid the lock-in. Dual licensing (also called "selling license exceptions") occurs when your vendor has aggregated copyright control of the whole open source codebase and is able to offer a choice of licensing terms. The vendor will usually select the likes of GPL as the open source license for the code, hoping you'll be so concerned by the compliance implications that you'll pay to be able to use the code under other terms.
Dual-license schemes have become much less popular as people have become less concerned about the GPL; as a result, few new businesses pick this model. All the same, the Affero GPL has proven to be a tempting license for those wanting to try dual-license models with Web-delivered software.
A pure dual-license scheme is not much of a threat to your software freedoms, as long as the proprietary license terms don't make you voluntarily surrender the right to switch back to open source terms. If you purchase services or a subscription under proprietary terms in a dual-license arrangement, check that you'll be able to find another supplier of services in the event you choose to switch back to open source. The tightly controlled nature of dual-licensed packages means other commercial vendors are often locked out of the market, diminishing customer choices.
As customers became more confident about open source licensing, dual-license schemes became less popular, so many vendors switched to an alternative model. While creating a "community edition," they also created powerful "enterprise" features -- backup, load balancing, instrumentation, interoperability with proprietary systems -- and sold them under proprietary licenses.
The problem with this approach is obvious. While the vendor is indeed working on and making valuable contributions to the fully open source community edition, the capabilities customers need are actually proprietary and deliver none of the flexibility and control that open source offers.
As long as the enterprise features aren't critical to you, it's still possible to retain your software freedom -- just use the community edition and get your service and support from the group. Many businesses use the community editions of open core packages as an explicit part of their IT strategy.
Commercial open source
Since it's so easy to do, open core vendors increasingly blend together access to subscriptions and support with a requirement you use the "enterprise edition," perhaps even under full proprietary licenses that restrict your freedom to leave. The unfortunate term sometimes used to describe this blended model is "commercial open source." Don't let this deceptive phrasing confuse you.
Check that you are the beneficiary of the four freedoms that open source guarantees, rather than just your vendor. If the software freedoms stop with them, you don't have the flexibility of open source to control what software you use, not to mention how, when, where, and with what level of support. Instead, you are handing control of your IT budget to your vendor with just as much certainty as any other proprietary software.
Practice safe selection
Practice safe selectionThere's nothing wrong with using open source software within commercial solutions. After all, a basic requirement of the open source definition is the freedom to engage in commercial behavior with open source. But if software freedom stops with your supplier, it's deceptive to say you're somehow the beneficiary of open source. If having open source embedded within proprietary systems was all it took, pretty much everything Apple, Microsoft, Oracle, and IBM make could be described as open source. My test: if my relationship with the vendor ends, can I still use the software?
If you encounter a vendor claiming its solution is "open source," yet not delivering software freedom, what should you do? If you have another choice, take it. If you don't have a choice, use the hints I've included here to isolate the proprietary elements from the open source elements as much as you can. Remember: It's not open source to you if it doesn't deliver software freedom.
This article, "Beware these three open source lock-in schemes," was originally published at InfoWorld.com. Read more of the Open Sources blog and follow the latest developments in open source at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.
This story, "Beware open source lock-in schemes" was originally published by InfoWorld.