What do you know about open source software?

ZOOOM raises awareness on the differences between different open source software license terms, establishing criteria to determine which collaborative authorship model serves the needs of the open source project (e.g., joint authorship, collective work etc.), how to fit the business model into the licensing structure, especially for service-based models where software is deployed on cloud instances, etc.
Check out:
Open source software, free software, or both?
The Open Knowledge Foundation has adopted an extensive definition of ‘open’ which captures the spirit of the ‘open everything’ movement. In its latest version 2.1, the Open Definition ‘makes precise the meaning of “open” with respect to knowledge, promoting robust commons in which anyone may participate, and interoperability is maximized’. The key points of the definition have been summarised, as follows:
Knowledge is open if anyone is free to access, use, modify, and share it — subject, at most, to measures that preserve provenance and openness.
Openness is defined in terms of freedom of use, study, modification, and sharing. Restrictions to these freedoms are only acceptable if they preserve attribution and ensure that that material which is released under an open license remains open. As Andrew Katz has noted, the conversation on open technology is dominated by two competing rationales of use-maximisation, advocated by the Open Source Initiative, and anti-closure, advocated by the Free Software Foundation.
These competing rationales are what gave birth to the two terms ‘Open Source’ and ‘Free Software’. Open source was coined by a group of pragmatic technologists who feared the rhetoric of the Free Software movement could discourage adoption of open source software by business. The term ‘open source’ was an attempt to reconcile the differences between the two approaches.
There is not one uniform definition of ‘Open Source’, but it is generally understood that Open Source refers to both a development methodology and a licensing model. The term originated in the field of software engineering precisely because if the value that this development model gives to software.
What is open source software?
In spite of the competing philosophies behind Free Software and Open Source Software (OSS), the two definitions reveal similarities. The Free Software Definition, which is stewarded by the Free Software Foundation, formulates the four essential software freedoms, namely:
- The freedom to run the program as you wish, for any purpose (Freedom 0)
- The freedom to study how the program works and change it so it does your computing as you wish (Freedom 1)
- The freedom to redistribute copies so you can help others (Freedom 2)
- The freedom to distribute copies of your modified version to others. By doing this, you can give the whole community a chance to benefit from your changes. (Freedom 3)
The Open Source Definition (OSD), which is stewarded by the Open Source Initiative (OSI), takes a more pragmatic approach. The OSD makes it clear that open source doesn’t just mean access to source code. The definition formulates 10 principles, which must all be met for a licence to be called ‘open source’. These principles are summarised in the following table:
Principle | Content |
1. Free Redistribution |
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. |
2. Source Code |
The program must include source code and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost, preferably downloading via the Internet without charge. 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 pre-processor or translator are not allowed. |
3. Derived Works | The license must allow modifications and derived works and must allow them to be distributed under the same terms as the license of the original software. |
4. Integrity of The Author’s Source Code | The license may restrict source-code from being distributed in modified form only if the license allows the distribution of “patch files” with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software. |
5. No Discrimination Against Persons or Groups | The license must not discriminate against any person or group of persons. |
6. No Discrimination Against Fields of Endeavor | The license must not restrict anyone from making use of the program in a specific field of endeavour. For example, it may not restrict the program from being used in a business, or from being used for genetic research. |
7. Distribution of License | The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties. |
8. License Must Not Be Specific to a Product | The rights attached to the program must not depend on the program’s being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the program’s license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution. |
9. License Must Not Restrict Other Software | The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software. |
10. License Must Be Technology-Neutral | No provision of the license may be predicated on any individual technology or style of interface. |
It is important to distinguish the development from the licensing model: while source code can be both open source and proprietary (eg, dual licensing models), a licence can either be open source or not. Any licence that does not conform cumulatively to all ten principles of the OSD cannot be considered an ‘open source’ licence.
The need of openness arises where there is closure, for example, in the form of intellectual property. The expressions of computer programs are protected by copyright law as literary works. Functional aspects of software that meet the criteria for patentability may also be protected by patents. Keeping control over software in source or binary form therefore depends on intellectual property rights, specifically copyright and patents. Any open source licence relies on the private law mechanisms of licenses and contracts to allow rightsholders to authorise certain acts (eg, reproduction, distribution, use etc.) that are otherwise prohibited by the default IP rules.
Not choosing a licence does not mean the software is open source
If a rightsholder, e.g., a developer, chooses not to pick a licence upon releasing their software, this means that the software is not released as open source software. For example, the GitHub policy on licensing a repository clarifies that without a license, the default copyright laws apply, meaning that you retain all rights to your source code and no one may reproduce, distribute, or create derivative works from your work. Similarly, allowing computer programs to enter the public domain is not an alternative to the challenges of applying copyright law to open source. This is so because the category of public domain depends on surrendering of legal rights, some of which may be inalienable in some jurisdictions (e.g., moral rights).
Legally, open source software is defined by the categories of ownership and licensing. This means that any rightsholder who wants to enable use of source code, such as modification or (re)distribution, must rely on licences or contracts. Software can be dual licensed under both proprietary (i.e., non-open source) and open source license. However, if a developer wants their software to be considered open source, then it must be released under an open source software licence that meets the OSD. While software can be released under both an open source and a proprietary license, licenses are either open source or not.
Finally, unlike the other two types of subject matter, open source software has been the subject of several court cases interpreting various aspects of open source licensing and the nature of open source licenses. The most relevant of these cases are summarized in the appendix to this deliverable.