Back to Basics: What Is Open Source Software?
A primer for newbies and a refresher for veterans, Back to Basics is a regular feature examining some of the basic concepts and technologies involved with delivering online video.
Google's choice a few weeks ago, to use a modified version of the BSD open-source license for its WebM format and VP8 codec raised the discussion of open-sourcing to a level that it was covered by more than just the tech media.
Even after Google dropped the "poison pill" additions that were in the original licensing terms, reverting to a standard BSD license, the question that many involved in online video are asking is "what exactly is open source anyway?"
To help shed light on that question, and its applicability to streaming media, let's look at the difference between commercial proprietary applications, free software applications, and open-source code.
Most programs are delivered to the end user in a compiled form, along with an end user license agreement (EULA) that disallows any de-compiling in order to access the source code.
For commercial applications, banning users via the EULA from de-compiling the program makes commercial and competitive sense, and most users are content to complain about the program's lack of a particular feature or inefficiencies rather than trying to modify the code to stabilize the program or add features
Herding Cats
The open-source community, by contrast, is full of tinkers and hackers who are naturally curious. Some want to put their frustration to good use fixing problems within the programs, others just want to see what's under the hood, to enhance their own programming skills by reading source codes written in a variety of computer programming languages, such as C or even Java.
Since modifications to the source code mean the program must be recompiled before use, open-source initiatives often have a repository to keep track of modifications to particular features or groups of features.
Recompiled versions are known as builds, and a typical commercial project can have tens or hundreds of builds before one is approved for release. In open-source repositories, every single build is available for compiling or re-programming in a different direction. Too many moves in a particular direction away from the main programming intent may result in a branch-a fork in the code that takes a particular feature set in a more active programming direction.
If you think that licensing or restricting open-source code is akin to herding cats, you'd not be far off. While source code modification and re-use is one of the hallmarks of the open-source community, specific rules also govern the use of source code in commercial programs. Open-source developers expect to freely be able to modify source code and are expected, in turn, to publish their enhancements back into the open-source community for use in other open-source projects.
It's not as if open-source code has no license. In fact, the Open Source Initiative (OSI) calls out the fact that a license is assumed, and that it can't be restrictive in a way that inhibits free dissemination of code, compiled or otherwise.
Under Section 1of the OSI's definition of open source, titled Free Redistribution, OSI notes that "the license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources."
"The license shall not require a royalty or other fee for such sale," the section also states, with the rationale added. "By constraining the license to require free redistribution, we eliminate the temptation to throw away many long-term gains in order to make a few short-term sales dollars. If we didn't do this, there would be lots of pressure for cooperators to defect."
While the intent was originally to cover software created by members of the open-source community, OSI and the Free Software Foundation (FSF) are also having to contend with licensing source code for a previously commercial or proprietary software product, as more companies find the goodwill of the open source community advantageous if the commercial company has a software product with potential that they cannot meet with in-house resources.
The royalties question is the one that was raised under Google's modified BSD license, as it appeared MPEG-LA was moving to create a patent pool, once it became clear Google intended to strip the use of the software code from anyone who sued Google over patent infringement. Google's move back to a fully compliant BSD open-source license has, for the moment, eliminated the potential for the patent pool to financially benefit from the code Google released.
So are there ways to make money on open-source software? Yes.
The practice of offering consulting services, including software and hardware set-up, alongside the compiled code is fairly standard practice, starting with companies like RedHat, which got its start with open-source Linux distributions (distros) that were somewhat complex to set up.
If distros, compiled applications, and even the source code are readily available, as required by OSI, why would anyone pay for services to set up or optimize the software?
The answer may be found in OSI's definition of source code.
"The program must include source code, and must allow distribution in source code as well as compiled form," Section 1 states. "The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed."
Related Articles
The company first to offer live streaming with Google's WebM format is now webcasting the first WebM event.
28 Jul 2010
Companies and Suppliers Mentioned