What's the meaning of Open Source?
"maddog" examines the real meaning and ramifications of the term "Open Source."
Many years ago, people had become used to calling a facial tissue by a company's name, Kleenex. If people were going to use the name Kleenex as a generic thing (a tissue), the corporation was going to lose the ability to protect their trademark. Every "tissue" could then be called a "Kleenex," and the value of the brand would be worthless. The Kleenex corporation went on a large advertising campaign to make everyone aware that they should say "Kleenex tissue," or "a tissue that is Kleenex" rather than just the name of their brand.
Today, we run the same risk with the term "Open Source." Many companies (especially two very large ones) claim that their products are either "Open Source" or "based on Open Source." If all software becomes "Open Source," how can people select the type of software they need?
In my mind, true Open Source software, while not giving you all the guarantees of the GPL, gives you the expectation of certain capabilities. Open Source should allow you to look at the source code to see how it works. It should allow you to fix parts of your source code if it needs it, and it should allow you to put it on every platform.
However, a better understanding of these needs is also required.
First, in the realm of true Open Source, you tend to have leaders who rise to the position through meritocracy. They show their skills in creating code either by starting the project and attracting people to it or by contributing to the project over time. If, as sometimes happens, their leadership fails, then the codebase can be forked and the project can continue. Project leadership is not dictated by a company, any company.
Second, the tool chain to create the code is also Open Source. It does an end user no good that the sources to a large project are available if the compilers and source code control system to build it are not available.
Third, code can still be Open Source but be patent bearing. Although very little code is truly safe from patents, no true Open Source person would put patent-bearing code into their sources unless the patent was freely licensable. A company that wanted to brag about being "Open Source" and having the community help them develop the code could simply put patent-bearing code into their sources and later demand royalty payments for their patents in lieu of license fees for their software.
True Open Source should not be specific to a product. The software, within reason, should be applicable to any hardware, OS, and/or application suite. Of course, the developers can make a unilateral decision that certain hardware is not worth supporting or that the requirements of an application to run cannot be met with their resources, but they should have no inherent goal to keep that hardware or application from being supported. If the resources could be found, that architecture and application could be supported.
True Open Source licenses allow for derived works, as long as they are distributed under the same Open Source license of the original software.
True Open Source has no "binary blobs" that limit its lifetime or tie the end user to the development team. Although some "Open Source" projects do have these ties (e.g., some device drivers in the Linux kernel), the true projects discourage them and replace them with FOSS whenever possible. In the Linux kernel, it is possible to build the entire kernel without using those "blobs," so end users are not forced to use any code for which they do not have the sources.
Some companies, however, think that all they have to do is say the words "Open Source," and somehow their code and projects should be honored by the Open Source community and user base as much as true Open Source (or Free Software) projects. They want FOSS developers to work for them, not realizing that some FOSS developers see the work they do for the FOSS community coming back to them as true FOSS that they can use, not just a weak version of "Open Source."
Many of these companies are not breaking any laws or even FOSS licensing to my knowledge, but they are violating the spirit of the FOSS community and confusing end users who have heard about the value of FOSS and are now tricked into using software that is less than capable of supplying the benefits that most FOSS software gives.
I have welcomed companies who have been closed source and have switched to an Open Source business model, but I do not respect those that are not clear and open about what they are doing. It is better to be completely closed than only partially open.
Buy this article as PDF
New release marks the arrival of AMD’s unified driver strategy.
A new study by IDC charts big changes in the big hardware market.
Azure CTO says Redmond has already considered the unthinkable.
Lead developer quells rumors that the Debian version is slated for center stage.
MSBuild is now just another GitHub project as Redmond continues its path to the light.
Malware could pass data and commands between disconnected computers without leaving a trace on the network.
New rules emphasize collegiality in coding.
Upstart lands in the dust bin as a new era begins for Linux.
HP's annual Cyber Risk report offers a bleak look at the state of IT.
But what do the big numbers really mean?