A Brief History of the Open Source Movement

1. The ‘Open Source’ Movement

• The Free Software Foundation (“FSF”) founded by Richard M. Stallman articulated the concept of ‘free as in speech not as in beer’ as a backlash to what he saw as the rising commercialization of software and restriction of critical information needed by programmers (source code)

• The FSF is the body behind the open source creed, encapsulated in the following 4 freedoms:

  • 1 - freedom to run (computer program);

  • 2 - freedom to study and modify;

  • 3 - freedom to redistribute

  • 4 - freedom to improve, release improvements to the public (for the benefit of the whole community) *

  *Note: the second part of the last freedom contains also the shade of an ‘obligation’ i.e. the idea of staying faithful to the wishes of the core project developers and to the OSS movement as a whole

• Stallman also started the GNU project in 1984, launched the GNU Manifesto and wrote the first GPL License, coining the term ‘copyleft’ in the process

• By the year 2000, GPL was the license of choice for approximately 50% of all open-source projects.

2. Linux

• By the early 1990’s the internet had become well enough established that the prospect of teaming up with like-minded developers throughout the world by email and distributing software via the internet medium had become a realistic proposition

• Previous work had been undertaken to create an open operating system ‘OS’ based on UNIX(a project where code sharing had become standard practice but had subsequently been commercialized by AT&T and Sun Microsystems).

• With PCs now running on the new Intel 386 microprocessor a group of programmers designed a project to port to the 386 the UC Berkeley developed (BSD) variant. The FSF’s GNU project was also working on a rival free UNIX OS system. However, both projects were unable to react quickly to the new internet realities due to legal or internal issues.

• The gap was filled by Linus Torwalds from Finland. Exploiting the new internet capabilities and using the GNU Project tools and GPL, Torwalds launched Linux (a PC UNIX) which became the first major internet-based open source project. The Linux ‘kernel’ project attracted a multitude of developers and developed with rapid speed providing a focal point for the burgeoning open community

• At this point another group of programmers formed, which complimented the FSF but with a different philosophical approach: less moralistic in its approach to proprietary software and some would say more pragmatic and business-oriented. This group also grew out of the same ‘hacking’ culture as Linux and the GNU project but it moved the paradigm from free software to open-source software. The Open Source Initiative was founded, joining forces with the FSF under the portmanteau of FOSS. However, each organization has retained its specific philosophical approach.

3. The Open Source (License) Definition Part1

• The Open Source Initiative (“OSI”) is the custodian of what is referred to as the ‘Open Source Definition”. The OSI is responsible for determining whether a license to be applied to a software program or to any of its component parts is truly an ‘open source license’ according to the principles set out in the definition.

• If a license has not been approved by the OSI then it is not permitted to call itself an open source license

• To be recognized as an open source license, the software ‘distribution’ terms of the license must adhere to the following principles;

  • free redistribution of the software, as a component of an aggregated software distribution containing programs from other sources, must be permitted i.e. the licensee must not be restricted from selling or giving away the software or required to pay the licensor a royalty or fee for such a transaction

    Note: this does not mean that the recipient (licensee) cannot charge for the OSS component in his subsequent redistribution! Remember ‘free as in freedom not as in beer’

  • the licensed program must include its source code and must allow distribution in source code as well as in some compiled form i.e. a binary ‘executable’ but if the licensee chooses to distribute the program without the source code, he must also provide a well-publicized means of obtaining the source code in its preferred form for no more than a nominal fee (cost of reproduction)

    Note: preferred form means the form in which it can be most readily modified by another programmer, no obfuscated code and no intermediate source forms such as the output from a translator

  • the license must not restrict the creation of modifications and derivations based on the licensed program and must allow those modifications and derivations to be distributed under the same terms as the original software program

    Note: this principle of itself does not force the recipient licensee to adopt the same OSS license for its distribution of modifications and derivations but some open source licenses do – see copyleft definition and remember the 4^th software freedom of FSF. The principle does not allow a licensor to stipulate a different form of license from the one they selected for the original software program

4. The Open Source (License) Definition Part2

• the license may restrict the source code of the original software program from being redistributed in modified form (i.e. honoring the author’s integrity right) provided that it allows the recipient/licensee/modifier to distribute “patch files” with the source code to enable downstream programmers to integrate the modification at build time

  Note: the license must explicitly allow distribution of software built from modified source code

• the license must be non-discriminatory:

  • against any particular person or group of persons (this includes natural persons and artificial persons such as corporations);

  • against the use of the code in any particular field of endeavor (e.g. research, education, particular business fields or business in general);

  • against any particular form of technological implementation (i.e. license provisions must be technology neutral and not predicated on use of a specific technology, interface style etc);

  • against any particular application or suite of applications (i.e. the license must not stipulate that the rights conferred depend on the licensed program being part of any particular software/product distribution)

• the license rights attached to the original program must automatically apply to all in the downstream chain of distribution without them having to execute an additional license and regardless of how they acquired their copy of the program;

• other software which is being distributed alongside the original licensed program (e.g. programs which stand independent but are distributed on the same medium) must not be subjected to restrictions imposed by the licensor of the original licensed program (this reflects basic tenets of copyright law as applied to software)

5. Free Software Principles vs Open Source Definition and the Emergence of OSS License Types

• Keep in mind that open source licenses will still meet the Open Source Definition even though they allow a recipient/licensee to incorporate the original code or a modified version of it into a closed source application. In other words, copies and derivatives can be redistributed under more restrictive terms than those of the original license – see definition Permissive License.

• As regards direct copies, there is arguably little impact here on the FSF freedom principles since the original software is already available for the community benefit. When it comes to modified versions the same is not necessarily true.

• Thus there is a certain tension between the Free (FSF) and Open Source (OSI) principles but this tension is largely a by-product of the law of copyright (specifically of copyright ownership, which provides for discreet ownership of individual copyrightable contributions in a sequential chain of development).

• However, the Open Source Definition does allow an OSS license to stipulate that derivatives must carry a different name or version number from the original licensed program. This is ostensibly to avoid confusion arising between the public project and a privately forked version of it (compare chain of title questions for real estate)

• The expectation remains that the private entity which ‘owns’ the derivative software will voluntarily release its improvements back to the community but this cannot always be taken for granted.

• OSS communities wanting to ensure the public benefit aspect is maintained may resort to issuing releases of software from the project under a copyleft license but this can be a heavily nuanced decision and must take into account the ultimate purpose(s) and objective(s) of the project.

6. Conclusions

• Technical Complexity - In this vast array of potential technical scenarios, there will always be the potential for code to be deliberately or inadvertently mingled: proprietary (closed source) with proprietary (closed source); proprietary (closed source) with open source; open source with open source.

• Legal Complexity - The Open Source Initiative openly admits that by facilitating the adoption of so many different types of OSS licenses, they have effectively created a legal ‘Babel’

• Risk -Many scenarios will be benign from both a technical and legal standpoint.

• Consequences - Many will not and could give rise to any number of ‘events’ that could seriously impact the short-term bottom line of a business, seriously undermine its marketability or even its long-term survival prospects.

• Choices - As a result of developer preference, the prevalence of the ‘hacker’ culture and the growth of the internet, OSS has become an inescapable facet of the technological environment we live in (if OSS hasn’t yet “eaten” software, it is well into the main course!), accounting in good measure for the rapid development of new technologies. The question organizations of all size and maturity are being forced to contend with is this : do we want to be in tune with the march of technological progress or not? It appears that most do.

• Realities - In recent years with the spotlight on information security and after some highly publicized security breaches of OSS software products, some questions have been raised about the capacity and sustainability of the OSS movement. The critics of OSS often neglect to mention that security was and is also a fundamental concern in the context of proprietary software. In the end, programmers and s/w developers are humans and human error or human limitations are difficult to eradicate. Vulnerabilities persist.

  In typical open source fashion, the OSS community is rallying to the security concern in a way that the purveyors of proprietary software have so far been reluctant to do.

• Future – With the rapid growth of the public cloud, the business model of Cloud Services (SaaS, PaaS, Iaas, DbaaS, CpaaS etc…….) and AI, there is the possibility that the commercialization so despised by the FSF will once again dominate the software arena, big will eat small and the healthy competition sustained by the collaborative practices adopted by the OSS movement will be successfully subverted for the benefit of just a few giant organizations. Unless you happen to be working for one of these tech giants, this is the time to face up to the benefits and risks of investing in OSS, in other words to take OSS engagement seriously.