Open-source software today has not only allowed programmers to write increasingly complex software – but also democratized the software industry where off-the-shelf modules are available for even small programming teams to build larger-than-life software platforms and applications. The whole idea behind publishing software with an open source license is to make it available for everyone to understand its internal functioning, which they may use to build over it, and make it better. The open source initiative was founded in February 1998 and defined what open source meant, ultimately determining which software license fit under open-source certification. Open-source however does not always mean that the source code is available for use without conditions or associated costs, contrary to popular opinion among developers. For instance, the GNU General Public License (GPL) is a widely used free software license that allows free distribution, but with the condition that any modifications made to the software should also be distributed under the parent license for free (barring minimal cost for shipping and handling). In order to label software as open-source, it must satisfy the following conditions: FREE DISTRIBUTION: The license cannot hold back a party or an individual from selling or giving away the software as a constituent of corporate software which may contain various other open-source licenses. The license holder is not obliged to pay any kind of royalty or other fee as a condition for sale. SOURCE CODE: It is mandatory that the program includes the source code, and must grant permission for distribution in both compiled and source code forms. During exceptional cases when a form of a product is not distributed with source code, there must be a widely known way to obtain the source code, in exchange for a reasonable reproduction cost, or should be available for download via the internet without any charge. The source code must be produced to the licensee according to his requirement of use. Any deliberate attempt to confuse the users by providing obscure or unintelligible source is prohibited. The user should be provided with a complete source code and not any intermediaries such as the output of a preprocessor or a translator. DERIVED WORKS: The license must allow modifications and derived works, and allow them to be distributed under the same terms as the license of the original software. INTEGRITY OF THE AUTHOR’S SOURCE CODE: The license may limit the distribution of modified source code by only allowing it if it contains patch files. A patch is a text file with the help of which you can change a set of source files from one version to another. By using a patch, you can create a new version of source code from the original source code by applying the patch to a copy of the original source code. This helps you modify the source code, while keeping all the versions intact - most importantly the original source code. Random changes made to the source code may give rise to vulnerabilities, and grouping these differences may help monitor them. NO DISCRIMINATION AGAINST PERSONS OR GROUPS: The license must not discriminate against any person or group of persons. NO DISCRIMINATION AGAINST FIELDS OF ENDEAVOR: The license must not pose any restrictions from making use of the program in a specific field, like business or genetic research. DISTRIBUTION OF LICENSE: The rights attached to the parent program shall be applied to whomsoever the program is being distributed to. There is no requirement to execute an additional license by those parties. LICENSE MUST NOT BE SPECIFIC TO A PRODUCT: The rights attached to a program do not change if it is being used as a part of a particular software distribution. The distribution is obliged to enforce the same rights as the original software in case any party decides to use the program from the distribution. LICENSE MUST NOT RESTRICT OTHER SOFTWARE: Other software that are distributed along with the licensed software are not subject to any kind of restrictions. For example, a license cannot state that all programs distributed on the same medium should be open source. LICENSE MUST BE TECHNOLOGY-NEUTRAL: The provision of license is not biased on individual technology, specific part, or component, material, or style of interface. Open source licenses can be broadly divided into two categories - Copyleft and Permissive. While both these licenses allow users to freely copy, distribute, and change the software that use them, the conditions under which they can do so is where they differ. 1. COPYLEFT LICENSES A copyleft license would require users to preserve the same rights in derivative works as the original license. Under a copyleft license, the author gives permission to every recipient of the copy of his work to reproduce, adapt, or distribute it, but only under the same licensing agreement. This is in contrast to copyright, which gives exclusive rights to the creator of an original work to determine under what conditions his work is to be used by others. So copyleft is a variant of copyright in which the author surrenders part of his rights, while also giving him the privilege to impose some restrictions on those who want to engage in activities that would otherwise be prohibited under a copyright. A copyleft license for software must be provided with all the necessary information required to reproduce or modify the work. The source code files would generally include a copy of the license terms and an acknowledgement for the authors. The GNU General Public License was the first of its kind and till date remains to be the most widely used copyleft license. GNU General Public License The GPL family has dominated the market for copyleft licenses since its first launch in 1989. The original GPL was based on the concept of unifying similar licenses used for earlier versions of GNU softwares such as the GNU Emacs (1985), the GNU Debugger and the GNU C compiler. The problem it posed was that it offered specific licenses to each program. The goal was to make a single license that could be used for any project, which enabled multiple projects to share code. GPLv1 Prior to the release of GPL’s version 1, some distributors published files in binary format only. Although executable, it didn’t the help the users much as it was impossible to decipher or modify. The GPLv1 proclaimed that in order to copy or distribute copies or any portion of the program, a human readable source code should be made available. Combining two softwares that had different sets of restrictions on distribution gave rise to new complications. The combined work would require making a union of the two sets of restrictions that ultimately resulted in unacceptable license terms. The GPLv1 solved this problem by setting a standard that all modified versions, as a whole would be distributed under the terms of GPLv1. So software under the GPLv1 when combined with software that’s under a more permissive license wouldn’t call for any changes in the terms and conditions under which the integrated software will be distributed. GPLv2 With the introduction of the GPL version 2 the license terms were made more stringent, stressing on the fact that a GPL-covered work may only be distributed, if the licensee can satisfy all of the license’s obligations, regardless of whether they are bound by any other legalities. This means that even if there is a single part of the contract which is held illegal or conflicting, the program could not be distributed under the GPL license. This was mainly intended to abolish parties from using patent infringement claims or other litigation in order to limit the freedom of a user under the license. GPLv3 The GPLv3 was officially released on 29 June 2007 by the Free Software foundation. The third edition of the GPL family brought some very prominent changes particularly related to software patents, free license software compatibility, and hardware restrictions on software modification. Besides that there were several factors that justify why the upgrade from GPLv2 was necessary - As compared to the GPLv2, GPLv3 has a broader domain of licenses that it’s compatible with. In addition to that, it allows you to associate with code that have separate requirements that are not present in GPLv3 itself. Tivoization is a process in which manufacturers provide hardware with the source code under the GPLv2 license that restricted the user to perform any modification to the software. User products distributed under the GPLv3 license posed no such restriction and provided the necessary information with the help of which users could modify the software. The language used in GPLv3 was taken to be very U.S centric, giving rise to ambiguity among terminologies used outside the U.S. For instance, the word “distribute” which was used in the GPLv2 to describe distribution of software, was also used in other countries in their copyright law, but had a completely different meaning. The GPLv3 was written with an attempt to avoid this confusion by modifying it to a language that is well interpreted by the international laws as intended by the FSF (Free Software Foundation). The GPLv3 also provided developers with the privilege of adding local disclaimers, which also helped escalate its usage outside the United States. The GPLv3 protects users from laws that prohibit free software. Codes released under the GPLv3 can be used to develop DRM technology. Anyone who can break the DRM has the right to freely distribute his software as well. Laws like Digital Millennium Copyright Act and the European Union Copyright Directive that make it illegal to break DRM are deemed invalid under the GPLv3. In circumstances when a user violated the license of software that was based on GPLv2, the user automatically and permanently lost the rights. In order to get them back, the user had to appeal to the copyright holder for a formal restoration of the license which could be prove to be extremely cumbersome. The GPLv3 solved this problem by stating that if a user violates the license, the rights can be re-enforced if the user stops the violation. The GPLv3 is compatible with The Apache License version 2.0, a permissive free software license written by the Apache software foundation (ASF). Other than that the GPLv3 also improved compatibility with the GNU Affero General Public License, which could not be combined with the GPLv2. AGPL (Affero General Public License) A problem seen in the GPLv3 was that only the parties that are actually distributing their modified version of GPL code abide by the GPL, failure to which would render your copyright provisions inapplicable. Since sharing a piece of software over the network and letting users interact with it does not qualify as distribution, the programmer isn’t required to share his modifications to the code. The AGPL offers the same restrictions and freedoms as of the GPLv3, however it is particularly built for network software, and closes the loophole by making it mandatory to distribute the source code along with a web publication. LGPL (Lesser General Public License) The LGPL can be taken as an intermediary between a strong copyleft license like the GPL, and more permissive licenses such as the BSD and MIT licenses. It allows developers and companies to use and modify software released under the LGPL without the obligation of providing the source code of your own modification. If the user wishes to use the modified version as proprietary software, the code under the LGPL is usually used in the form of shared library, which helps distinguish the proprietary and LGPL components. The word ‘lesser’ signifies that the software only guarantees freedom of modification strictly for components licensed under the LGPL and not the ones that come under proprietary license. The use of LGPL is limited to software libraries and similar set ups. The LGPL can be upgraded to a full-fledged GPL licensed project if required, however the reverse is not possible. Microsoft Public License (Ms-PL) The Microsoft Public License is a free license released by Microsoft and was recognized as open source by the OSI on 12 October 2007. You can freely reproduce and distribute original or derivative works of any software licensed under the Microsoft Public License as long as you’re not using any contributor’s name, logo, or trademarks. The author is protected under the license in the way that it doesn’t offer any warranty concerning the functioning of the code. This means that the author shall not be held accountable if the code doesn’t work well under some instances. If you wish to distribute any portion of your software in source code form, you can only do so under the Microsoft Public License, by including a copy of the license with your distribution. However, if you distribute it under compiled or object code form, you can do it under any license that complies with the Microsoft Public License. This also explains why the Ms-PL is called a weak copyleft, making it incompatible with the GNU GPL, the latter being much more restrictive than Ms-PL- The GNU GPL requires you to release your entire source code if you’re using any GPL licensed component in your software. Other than that, softwares released under Microsoft Public license can also be easily commercialized. Eclipse Public License (EPL) The Eclipse Public License is a weak Copyleft License published by the Eclipse foundation on 24 August 2017. If you modify software licensed under EPL and distribute it in the source code form as part of your program, you’re required to disclose the modified code under EPL only. However, if you wish to distribute it in its object code form you are required to state that the source code would be made available upon request. In addition to that the EPL doesn’t require you to open source your entire code but only the parts that include the modified EPL components. This makes the EPL incompatible with the GNU GPL, as the latter requires you to release the software’s entire source code regardless of how much GPL’ed code you’re using. 2. PERMISSIVE Permissive software licenses have lesser obligations when compared to copyleft licenses pertaining to how open source softwares can be distributed. Primarily, permissive licenses differ from copyleft licenses over the fact that permissive licenses do not require copies and derivatives of the source code to be made available on terms not more restrictive than those of the original license. This however, makes it uncertain whether the future generations would be able to enjoy the same rights as they would’ve under the original license as there is no guarantee if the software will remain free and publicly available in the long run. So while permissive licenses promise maximum freedom to its first hand users, it may not be the best option for you if you’re at the further end of the chain. In most cases, if you license software under permissive license, it gives you the flexibility to use it in a closed software project without having to provide the source. A copyleft license, because it doesn’t let you instill your own set of restrictions in the software, helps preserve the freedom of the original open source software for the downstream users. Furthermore, a company that used permissive software to derive proprietary software doesn’t need to go through the hassle of conducting license audits to check whether they are in agreement with copyleft licenses. Another noteworthy point is that while using permissive licenses, it becomes nearly impossible to borrow code that uses a copyleft license, however the opposite holds true when comes the situation of a copyleft license borrowing code that uses a permissive license. This is one situation where permissive licenses are impaired. MIT License A product of the Prestigious Massachusetts Institute of Technology, the MIT license is a permissive free software license that offers excellent compatibility. As long as you include a copy of the MIT license terms and copyright notice with all copies of the licensed software, the MIT license permits reuse within proprietary software. The MIT license is compatible with the copyleft General Public License, and has an option to completely integrate into it, but not the other way round. The MIT license offers many variants due to which the Free Software foundation considers the license to be ambiguous. Some of the variants include the Expat and the X11 licenses. A modified MIT license used by Xfree86 contains an advertising clause that requires all advertising of the software to display a notice, crediting its authors. The MIT is considered to be as one of the most permissive license around. You are just required to add a copy of the original MIT license and copyright notice to your modification, and you can practically do anything with a software licensed under the MIT. In addition to that the MIT license particularly gained popularity because of its short and straightforward license agreement. BSD Licenses The original BSD license (4-clause license) was published in 1988 by the Regents of the University of California and was used for the Berkeley Software Distribution (BSD) which was a Unix-like operating system. The 4-clause license had an “advertising clause” (not seen in any of its descendants) that required authors of derivative works to include an acknowledgement of the original source in all advertising material. The clause stated – All advertising materials mentioning features or use of this software must display the following acknowledgment: This product includes software developed by the University of California, Berkeley and its contributors <organization>. It was alright till the time the <organization> remained the same; University of California, Berkeley and its contributors. However, when people started using the name of their own institutions instead, it resulted in a plethora of licenses especially when they incorporated multiple programs into an operating system. BSD License 2.0 The BSD version presently in use is the 3-clause license (BSD license 2.0), and is compatible with the GNU GPL. This version allows unlimited redistribution for any purpose as long as its copyright notices and the license's disclaimers of warranty remain intact. The license also contains a clause restricting use of the names of contributors for endorsement of a derived work without permission. 2 Clause License The main difference between the BSD license 2.0 and 2 clause license is that the non-endorsement clause is eliminated in the latter. Both the MIT and BSD licenses have no such obligation that requires the user to release the source code of your software. Unlike the more recently published permissive licenses like the Apache 2.0, the MIT and BSD licenses do not include express patent license, primarily because both these licenses were drafted prior to when patentability of software was recognized under U.S law. Apache License The Apache license is a permissive free license written by the Apache Software Foundation. The latest version 2.0 requires a copyright notice and a disclaimer to be maintained. The version 1.1 was published in 2000 removed the ‘advertising clause’ seen in version 1.0 and also the BSD license 2.0. Derived products were only required to include attribution in their documentation and not in their advertising materials. The version 2.0 was adopted by the ASF in January 2004 and promised the following improvements-license would be made simpler for non-ASF projects:
Improved compatibility with GPL based software
Allowing the license to be included by reference, instead of listed in every file
Clarifying the License on contributions
Requiring a patent license on contributions that necessarily infringe a contributor’s own patents
What makes the Apache license so different is that it is the only license that explicitly grants rights to users that can be applied to both copyrights and patents, as opposed to other permissive licenses that are applicable only to copyrights and not patents. Being a permissive license, you get the benefit of releasing modified parts of the code under a license of your choice, however the unmodified parts need to be released under the same license (Apache). Every licensed file must also contain any original copyright, patent, trademark, and attribution notices in its redistributed code. In addition to that, every modified file must also contain a notice about all the changes made to the original file. Unlike the MIT license, the Apache license is less permissive when it comes to modifications. It requires you to specifically list the modifications you made to the original software. The Apache License also restrains you from naming your product in any way that suggests that it is being endorsed by Apache. zLIB License The zLIB license is a permissive free software license used for the zLIB library and many other open source libraries, and is also compatible with the GNU General Public License. You’re not required to make the source code available under the zLIB if you’re distributing binary code. The authors of the license are not obligated to any damages caused by its use. The license also requires you to change the name of the modified software. In addition to that, the authorship of the original software should not be misrepresented neither the license notice should be removed from source distributions. Notable Cases Arising From Open-Source Violations: [1] “CoKinetic Systems Pursues $100 Million GPL License Violation Case Against Panasonic Avionics”, https://wptavern.com/cokinetic-systems-pursues-100-million-gpl-license-violation-case-against-panasonic-avionics, https://resources.whitesourcesoftware.com/blog-whitesource/the-100-million-case-for-open-source-license-compliance [2] “Open Source Security Inc v. BRUCE PERENS”, https://regmedia.co.uk/2017/08/03/grc_lawsuit.pdf [3] ” Versata Software, Inc. et al v. Ameriprise Financial, Inc”, https://opensource.com/law/14/12/gplv2-court-decisions-versata, https://cases.justia.com/federal/district-courts/texas/txwdce/1:2014cv00012/668973/28/0.pdf?ts=1428925526 https://www.casemine.com/judgement/us/5914e7f5add7b0493491b1aa [4] “ Hellwig v. VMware” https://sfconservancy.org/news/2015/mar/05/vmware-lawsuit/ https://www.theregister.co.uk/2016/08/15/vmware_survives_gpl_breach_case_but_plaintiff_promises_appeal/ https://www.theregister.co.uk/2015/03/16/vmware_wants_amicable_end_to_meritless_linuxlifting_lawsuit/ [5] “Copyright and Software: Oracle v. Google”, https://www.iplawtrends.com/copyright-and-software-oracle-v-google/ https://spicyip.com/2018/04/oracle-v-google-us-court-of-appeals-rules-against-googles-fair-use-of-oracles-java-apis.html https://www.wired.com/story/the-case-that-never-ends-oracle-wins-latest-round-vs-google/ [6] “ARTIFEX SOFTWARE, INC v. HANCOM, INC, https://ia801909.us.archive.org/13/items/gov.uscourts.cand.305835/gov.uscourts.cand.305835.32.0.pdf https://opensource.com/article/18/2/top-10-open-source-legal-stories-shook-2017 [7] “ERIK ANDERSEN and ROB LANDLEY (principal developers of BusyBox) v. MONSOON MULTIMEDIA, INC, http://torquemag-hhvm.s3.amazonaws.com/uploads/2013/03/SFLC-BusyBox-lawsuit.pdf [8] “Jacobsen v. Katzer”, https://en.wikipedia.org/wiki/Jacobsen_v._Katzer http://www.epiclaw.net/blog/2008/10/23/jacobsen-v-katzer-significant-victory-open-source [9] “Free Software Foundation (FSF), Inc. v. Cisco Systems, Inc” https://en.wikipedia.org/wiki/Free_Software_Foundation,_Inc._v._Cisco_Systems,_Inc. https://www.networkworld.com/article/2270727/smb/cisco-sued-by-free-software-foundation-for-copyright-infringement.html [10] “gpl-violations.org v. Fortinet and others (2005)”, https://www.cnet.com/news/fortinet-settles-gpl-violation-suit/ [11] “ARTIFEX SOFTWARE INC., a California Corporation v. PALM INC., a Delaware Corporation, https://www.courtlistener.com/recap/gov.uscourts.cand.222215.1.0.pdf [12] “Artifex Software Inc. v. Premier Election Solutions (Diebold Inc.)”, https://misc.int-property.narkive.com/BOzoWOvg/artifex-v-diebold-the-gpl-is-non-commercial [13] “PROGRESS SOFTWARE, CORP., et al (Nusphere) v. MySQL AB, et al https://www.gnu.org/press/mysql-affidavit.html https://www.linux.com/news/cease-fire-between-mysql-ab-and-nusphere [14] “Jin v. IChessU (settled Israeli case)”, https://www.linux.com/news/defence-statement-released-israeli-gpl-test [15] “Computer Associates Int’l v. Quest Software, Inc. https://casetext.com/case/computer-associates-intl-v-quest-software [16] “Planetary Motion v. Techsplosion”, https://matthewminer.name/law_stuff/briefs/2L/Summer+Term/LAW+783-001+%E2%80%93+Trademark+Law+and+Practice/Planetary+Motion,+Inc.+v.+Techsplosion,+Inc. https://caselaw.findlaw.com/us-11th-circuit/1481575.html [17] “Welte v. Sitecom”, http://media.straffordpub.com/products/open-source-licenses-copyright-and-trademark-compliance-2010-07-07/presentation.pdf, page 20 https://wiki.fsfe.org/Migrated/GPL%20Enforcement%20Cases#Welte_vs_Sitecom_.282004.29 https://www.pillsburylaw.com/images/content/1/6/v2/1655/A9A22185D029BBE6EAA4332F1A7249E2.pdf, page 4 [18] “Welte v. D-Link”, http://media.straffordpub.com/products/open-source-licenses-copyright-and-trademark-compliance-2010-07-07/presentation.pdf, page 20 https://www.pillsburylaw.com/images/content/1/6/v2/1655/A9A22185D029BBE6EAA4332F1A7249E2.pdf, page 4 [19] “Welte v. Skype”, http://media.straffordpub.com/products/open-source-licenses-copyright-and-trademark-compliance-2010-07-07/presentation.pdf, page 20 https://wiki.fsfe.org/Migrated/GPL%20Enforcement%20Cases#Welte_vs_Skype_.282008.29 [20] “Welte in AVM vs Cybits case”, https://wiki.fsfe.org/Migrated/GPL%20Enforcement%20Cases#Welte_in_AVM_vs_Cybits_case_.282011.29 [21] “Welte vs Fantec”, https://wiki.fsfe.org/Migrated/GPL%20Enforcement%20Cases#Welte_vs_Fantec_.282013.29 [22] “Wallace v. FSF (2005) & Wallace v. IBM et al (2006)”, https://wiki.fsfe.org/Migrated/GPL%20Enforcement%20Cases#Wallace_v._FSF_.282005.29_.26_Wallace_v._IBM_et_al_.282006.29 [23] “AFPA v. Edu4”, https://wiki.fsfe.org/Migrated/GPL%20Enforcement%20Cases#AFPA_v._Edu4_.282001.29 http://fsffrance.org/news/article2009-09-22.en.html [24] “Free/Iliad”, https://wiki.fsfe.org/Migrated/GPL%20Enforcement%20Cases#Free.2FIliad_.282007.29 [25] “Geniatech v. Mchardy” http://laforge.gnumonks.org/blog/20180307-mchardy-gpl/ References i. https://opensource.org/licenses ii. https://opensource.org/licenses/category iii. https://en.wikipedia.org/wiki/Open-source_license iv. https://choosealicense.com/ v. https://www.techopedia.com/definition/8687/open-source-license vi. https://resources.whitesourcesoftware.com/blog-whitesource/top-open-source-licenses-trends-and-predictions vii. https://www.toptal.com/open-source/developers-guide-to-open-source-licenses viii. https://www.smashingmagazine.com/2010/03/a-short-guide-to-open-source-and-similar-licenses/ ix. https://resources.whitesourcesoftware.com/blog-whitesource/top-10-eclipse-public-license-questions-answered x. https://resources.whitesourcesoftware.com/blog-whitesource/top-10-apache-license-questions-answered xi. https://resources.whitesourcesoftware.com/blog-whitesource/top-10-microsoft-public-license-ms-pl-questions-answered xii. https://resources.whitesourcesoftware.com/blog-whitesource/top-10-gpl-license-questions-answered xiii. https://resources.whitesourcesoftware.com/legal/the-saas-loophole-in-gpl-open-source-licenses xiv. https://resources.whitesourcesoftware.com/white-papers/all-you-ever-wanted-to-know-about-the-most-common-open-source-licenses-and-never-dared-to-ask xv. https://tldrlegal.com/